Design Process

The right process is just enough process. It isn’t always linear, and it should adapt to the team, product, and moment you find yourself in. What I practice is a set of strong defaults that’re aimed at quickly discovering, testing, and delivering the best possible solution. (By the way, I wrote about the philosophy behind my process if you’d like to read it.)

It’s worth noting that not every product and team needs the same approach. Trying to have a one-size-fits-all approach is precisely how you get bloat, thoughtlessness, and everything that makes a product development process unnecessarily onerous. It also makes for worse products.

What follows are battle-tested practices that I’ve refined over the years. My roles have usually been part IC, part leadership, and this process covers both the craft of moving a product from problem space to outcome, and the work of leading the people in an organization.

Discover and Frame #

Before beginning anything, it’s important to understand the current state of things. I’ll want to know about:

• The problem, impact, and constraints. No solution is any good without alignment on it. Are we losing revenue, do we have a new opportunity? What kind of constraints must we operate under to be successful?
• The users impacted. You can’t craft a good solution without knowing who you’re designing for.
• Desired outcomes and success indicators. Defining success (beyond “we need to build this app and ship it”) and what it looks like is how we know we’re on the right path. It also defines when we might need to pivot.
• Risks and assumptions. We want to validate the ones we’re least certain on and that have the highest cost of being wrong so we have the best chance at winning.
• Facilitation. When alignment doesn’t exist, I create it. I have oodles of facilitated exercises that get us to the core of a question. That includes things like assumptions workshops, design studios, prioritization exercises.

Design #

Here, you’ll see things like prototyping, design systems, user tests, and lots more.

• Do just enough research. I’ll create user research plans, write interview scripts, do ethnographic interviews to understand who we’re helping. Enough to help us make good decisions and no more. I may lean on AI to do some synthesis after my first pass to ensure I didn’t miss any themes.
• Think and build in systems. Everything is connected, so I consider the whole experience a person has with what we make, not just the feature I’m working on. That means building a design system as we go, mapping the journey, and thinking about how each part fits the whole. Here, I may use AI to generate a first cut of components from the tokens, then refine by hand.
• Prototype to learn. Make prototypes to test out ideas before committing to code. It’s cheaper and easier to throw away if you’re wrong. You will be wrong, and I prefer to be wrong where it’s cheap, instead of in the build where it isn’t.
• Validate deliberately. I avoid the temptation to think of testing as an afterthought. It’s how we de-risk. This includes usability tests and lean experiments against the riskiest assumptions before anyone writes production code.
• Collaborate. Anyone’s welcome in my Figma. I pair up with engineers, product managers, and anyone else involved to cultivate a shared sense of ownership and get the most out of everyone’s insights.

Deliver #

Design’s responsibilities don’t end when someone starts writing code.

• Stay through the build. I don’t disappear after handoff. I’m in the standups and the thousand small decisions that come up once code meets reality. I’m there to answer the questions the design didn’t, and to keep the why intact as things adapt.
• Ship in thin slices. We build small, vertical slices that each deliver real user value and can ship on their own, not horizontal layers that can’t stand up by themselves. Every sprint should produce working software. That’s what keeps the cost of being wrong low.
• Keep validating. A prototype only tells you so much. Once it’s real, I keep testing with real users on real builds, because that’s where the truth is.

Post-Release #

Shipping something isn’t the end of my involvement, either. This typically has overlap with product manager duties, but I like that.

• Measure. Back in Discover, we defined what success looks like. This is where we find out. Are the indicators moving? In the right direction? At the pace we expected? If not, I want to understand why before we react.
• Listen. I want to check on support tickets, usage patterns, follow-up conversations. The gap between how I designed something and how people actually use it is where the next round of work lives.
• Decide. Depending on what comes in, do we iterate, pivot, or persevere?
• Feed it back. What we learn can re-prioritize a roadmap and seeds the next round of discovery. Outcomes we hit move off the list. Ones we miss get rethought. New problems surface and get in line.