process

most products go wrong before the first pixel

Not in the screens—in the decision about what to build. So my work starts before the design does, in two steps: Discovery, then embedded design. Here’s what happens in each, and what you get.

The double diamond: Discovery (phase 1, go / no-go, phase 2) finds the right problem; embedded design (try options, test with users, test and ship) builds the right solution.

Discovery, then embedded design

Every project starts with Discovery: your users, your data and your teams, joined into one picture. It runs in two phases, with a go/no-go between them—so you never commit to more than you’ve seen.

Discovery · phase 1

what you already know

  1. talk to product, sales and supportYou get: what each team already knows
  2. dig into the data you already haveYou get: the questions worth answering
  3. join it into one pictureYou get: what we know, and what we’re guessing
  4. go / no-goYou get: a decision you can defend upstairs

No-go?You just saved a quarter of building
the wrong thing.

Discovery · phase 2

what your users actually do

  1. interview and watch real usersYou get: evidence from your real users
  2. test the guessesYou get: what’s worth building, and what isn’t
  3. decide where to startYou get: a plan for where to start

Embedded design

then I join your team

  1. try optionsYou get: options compared before anything is built
  2. test with usersYou get: nothing ships untested
  3. ship and measureYou get: a measured result for every release

Test, learn, repeat.

Most of the answer is already inside your company, split between product, sales and support. I interview them, go through the data you already have, and join it into one picture: what we know, and what we’re guessing. Then you decide whether the guesses are worth checking.

If it’s a go, we check the guesses against reality: interviews and tests with your real users. Guesses become evidence, and evidence becomes a decision: what’s worth building, what isn’t, and where to start.

You know what to build; now it has to be built properly—and that doesn’t fit in a handover document. I stay on as part of your product team, month by month. Along the way: process, design ops and mentoring, so the habits stay after I leave.

questions

questions I get asked

the answer is usually “it depends”, so here’s what it depends on.

How do we start?

A call first, then a short proposal, then Discovery.

How long does Discovery take?

How does pricing work?

What do you need from our team?

What if Discovery says no-go?

Can you work alongside our existing designers?

Do you work remotely, and across time zones?

Do you sign NDAs?

Will you write a case study about our project?

How do contracts and payments work?

get in touch

tell me what you’re building

A 60-minute call, no pitch deck. You tell me the problem, I tell you what I’d look at first.

replies within one working day, from Chișinău