Design Process

There was a long stretch when design meant making screens look good and nothing else. Product wrote the features into a document, a designer drew screens that matched the document, and engineering turned those screens into code. What the designer received was an answer someone else had already chosen. The job was to arrange that answer attractively.

In that order of work, mockup reviews always stalled in the same place. A designer would put three screens on the wall and everyone in the room would add a sentence. The founder finds the blue heavy. An engineer points out that the second option is easier to build. Sales says customers like this sort of thing. Nothing in the room can settle which comment outranks the others, so the decision lands with whoever holds the most senior title, and two weeks later, when that person feels differently, the screens get drawn again.

The larger loss happened somewhere else. Teams kept solving the wrong problem carefully. One team spent two months rebuilding an invite screen, and it turned out people were not inviting teammates because they didn't know their coworkers' work email addresses, not because the screen was awkward. No amount of polish reaches a reason like that. Because no step in the sequence asked what the problem actually was, the team found out only after both months were gone.

A design process exists to put explicit steps in front of the drawing. Research to confirm what the problem is, narrow down which problem to solve, produce several options, test them with users, then revise and ship. The tools used in the research step live under UX research methods — interviews where you ask users directly, usability tests where you watch someone try a screen and note where they stall, and a handful of others.

Naming the steps changes the sentences people say in meetings. Instead of an impression about heavy blue, the evidence becomes an observation: four of five users failed to find the checkout button within three seconds. An impression can't be argued with, only outranked. An observation can be argued with, and better still, it already contains what to fix next.

None of this makes the steps a guarantee. A team can run every one of them and still ship something nobody wants, because research talks to the wrong six people or the test asks a leading question. What the sequence buys is cheaper mistakes. Each step ends with something concrete enough to be wrong about in public — a problem statement, three options, a recording of someone failing a task — and being wrong in public at week two costs less than being wrong in private at month four.

Two branches sit under this term. One covers the shape of the sequence itself (methods), and the other covers how you borrow someone else's eyes inside that sequence (collaboration). The first branch works even for a designer sitting alone. The second only exists once two or more people are in the room.

There are three methods. All three describe the same flow, but they differ in what they emphasize and how many weeks they consume. You also don't pick one and discard the others. Plenty of teams take the attitude from design thinking, use the double diamond to check which step they're standing in, and reserve a design sprint for the one urgent question that needs an answer this week.

1. Design thinking — an approach that starts from empathy with the user. It's usually taught as five steps: empathize, define, ideate, prototype, test. What gets built in the fourth step is not a finished product but a prototype, a temporary version made to see how people react — a screen sketched on paper counts. The character of this approach is how much time it spends on the first two steps. Before deciding what to build, it insists on naming who is struggling and why.
2. Double diamond — a model that draws the same flow as widening and narrowing, twice. The first diamond researches the problem broadly, then narrows to one. The second opens up many solutions, then narrows to one. Its value is that skipped steps become visible. Most teams skip the entire first diamond and start generating solutions, which produces a room full of people working hard on ideas while nobody can say which problem those ideas address.
3. Design sprint — a workshop format that compresses the flow into five days. Monday defines the problem, Tuesday everyone sketches, Wednesday the group picks one, Thursday it gets built, Friday five users try it. It was designed to end arguments that have been running for months, so it pays off most on a question that has been unresolved for a quarter. The cost is real, though: five or six people clear their calendars for a full week, which rules it out for most questions. The other constraint is that the question has to be small enough to show someone on Friday. "How should onboarding work" is too broad; "which of these three ways of picking a plan do people understand" fits.

There are three collaboration terms. Each is an occasion for showing work to other people, and they're named by what you're trying to get out of the showing.

1. Design critique — a session for examining intent and reasoning together. No approval comes out of it. Instead of ranking the work as good or bad, the group looks for where a particular user would get stuck. That's why the way people speak in a critique is prescribed. Not "I can't see this button," but "on the checkout screen I couldn't find the next-step button within three seconds" — what you were trying to do, and where it stopped. The rule sounds fussy until you sit in a critique run without it, where an hour produces a list of preferences and no decision anyone can act on.
2. Design review — a step where the people affected by a decision confirm it before it's made. Unlike a critique, it ends with a conclusion: this goes to engineering as is, or this comes back after these changes. The attendees differ, too. A critique gathers peers who do the same craft. A review gathers the engineers and product people whose work changes because of the decision.
3. Co-design — putting users or stakeholders in the designing seat directly. This is different from collecting opinions and going home to apply them. The other person draws the screen with you. Bring three customer-side admins in to sketch a permissions screen together and a layout question the designer chewed on for two weeks can resolve in half an hour, because those three already know who grants access to whom at their own companies.

The two branches don't run separately. Methods decide what happens when; collaboration decides whose eyes get borrowed in each slot. While the second diamond is opening up options, a critique is the right session. Right after it narrows to one, a review is. Run a review during the widening step and people are asked to approve options nobody has chosen yet; run a critique after the narrowing and opinions pile up on a decision already made. Co-design earns the most in the first diamond, where the question is still which problem to solve. Teams that get the pairing wrong rarely notice it as a scheduling problem. They notice it as sessions that feel pointless, and the usual fix attempted is to invite more people, which makes it worse.

"Let's run the full process on this one. Screens come after the research."

Don't start with mockups — the step that confirms what the problem is doesn't get skipped.

"This is a critique, not a review. We're not deciding anything today."

The session was called to widen the options, so don't ask whether it's approved.

"Let's skip the front diamond. We already know the problem."

A proposal to cut the research step, and one that needs the evidence for "we know" to follow immediately.

At Pagedeck this came up constantly during the work on converting free users to paid plans. Grace wanted to redraw the checkout screen. Noa asked for one week before any screen got drawn. In that week she called six teams that had started a paid conversion and abandoned it, and four of the six said the person entering payment details wasn't them. The screen wasn't awkward; there was no way to designate a separate billing owner. That one sentence became the problem statement, and the three screens drawn afterward all dealt with assigning that role.

The first session held on those three screens was a critique. Noa and two other designers looked for where users would stall in each option, and deliberately reached no conclusion. Three days later Mia and Theo joined a review, and one option was chosen there. Theo pointed out that the second option required changing the permissions model and would add two weeks, and the first option won on the spot. Had that come up in the critique, an option nobody had refined yet would have been cut on build cost before anyone examined it. That's the reason for holding two separate sessions at all — merge the widening room and the narrowing room into one meeting and narrowing usually wins.

The most common misreading is treating the process as a straight line you walk once. Every diagram draws the steps as arrows flowing left to right, so the reading is understandable. In practice, moving backward from a later step to an earlier one is normal operation. If five users in the test step each expected something different, that isn't a signal the screens are wrong — it's a signal the problem definition is wrong, and the team belongs two steps back. Leave this misreading alone and going backward starts to read as failure, so nobody proposes it. Screens drawn on a wrong definition ship as they are, and the same fact arrives six months later as support tickets.

The second misreading is that you've done it properly only when every step has been walked. The steps have names written down, which makes them look like a checklist. But the number of steps worth walking tracks the weight of the decision. Changing the wording on one button doesn't warrant a five-day workshop; twenty minutes of critique settles it. Rebuilding an entire signup flow with a single review attached, on the other hand, hardens into something you can't undo two months later. Leave this alone and the cost of the procedure outgrows the weight of the real decisions, so the team quietly skips the process whenever a deadline presses. That's how the sequence written in the document and the sequence actually running come apart. Once the skipping becomes habit, it shows up in the decisions that could go badly wrong too. One test keeps it steadier: the more expensive a decision is to reverse, the longer you spend in the early steps, and anything reversible within a week passes through quickly.