I · Meaning

Where Does a Screen Come From?

One person, one journey, before any screen

Most briefs arrive as a page. We need a settings screen. We need a dashboard with a, b, c and d on it. We need a page for the new feature. The page is the unit of the conversation, so the page becomes the unit of the design, and the designer opens a canvas the size of a page and starts filling it.

I don't work that way any more. It isn't a method so much as a different place to stand.

Start with the people who do it now

Before the journey, before the screen, before I know what the system does: who does this today, and how?

There's almost always a before. A phone call. A spreadsheet. A paper form. A person walking over to another person's desk. A sticky note on a fridge. It's been working, imperfectly, probably painfully, but working, and the people doing it have habits, workarounds and expectations shaped by years of doing it the old way. If I don't understand that, I'll build something that solves problems nobody had and creates problems nobody expected. So I go and talk to them, and I watch, and I ask the questions that matter at this stage: how do you do it now, where does it hurt, and why does it need to change?

Say the brief is "an order management system" for small restaurants. The instinct kicks in: order list, status toggles, live dashboard, notifications. Stop. What exists today? A phone call. A customer calls Rami, who runs a twelve-table shawarma place in Haifa, and here's what actually happens in that call.

The customer needs to know what Rami has, what's in a dish, what it costs, whether he can leave the onions out, how long it'll take, whether he delivers to their street, whether he's even open. Rami needs to know what they want and how many, any changes, the address, a phone number, and how they're paying. Then he writes the order on paper for the kitchen, writes the address separately for the driver, charges the card by hand if it isn't cash, and tells the driver where to go and when.

That's not a feature list. It's an information exchange between two people, followed by a physical handoff, and every part of it exists for a reason. And now I can see where it hurts. Rami recites the menu for the fiftieth time that day while an indecisive customer thinks. "No onions" doesn't get written down. An address is misheard and the driver goes to the wrong street. A card number is read back with one digit wrong. At peak hour the line is busy and the customer calls somewhere else. The kitchen reads "2x" as "1x". None of that was in the brief, and all of it is the product.

The system doesn't invent new information. It changes the channel. The customer still needs to see what's available, choose, say where they are, pay. Rami still needs to receive the order, confirm he can make it, hand it to the kitchen. Same information, same people, different pipe. Every screen is answering a question that used to be asked out loud.

Which also says what the job is, and what it isn't. Most of that call works. The customer asks, Rami answers, the food gets made, the driver goes. The job isn't to redesign what already works, and it isn't to turn a two-minute phone call into a seven-step checkout because a screen can hold seven steps. It's to find exactly where it hurts, the menu recited for the fiftieth time, the onions that never got written down, the misheard street, the digit read back wrong, and take those away. Everything that isn't friction is the part to leave alone.

One person, one thing they want

Once I know how it's done today, I can draw the journey. Not the path through our product. The path, full stop: one person who wants one thing, and the ideal, frictionless way from wanting it to having it, if nothing were in the way. HCI calls this scenario-based design (Carroll, 1995); I just call it the journey.

That path is small. Three steps, five, rarely more. And once I have it, the screens derive themselves. Each step wants a place to happen. Some steps want a whole view. Some want a component. Some want nothing at all, because the step was the system's job, not the person's.

A detail about drawing it that matters more than it sounds. Tom Wujec, in a TED talk from 2013, asks rooms full of people to draw how they make toast. Everyone can do it, and nobody does it the same way: some start at the bread, some at the toaster, some at the shop; some draw six steps, some fourteen. Then he has them do it on sticky notes, one step per note, and the drawings get better, because now a step can be moved, two can be merged, a group can be pulled apart and put back. That's the tool I use for journeys. Not a diagram on a screen. Notes on a wall, one step each, where moving a step costs nothing. Different people will draw the same journey differently, and that's information too; the version you keep is the one that survives being rearranged by everyone who does the job.

Take something as plain as a phone book. The first journeys write themselves: see the contacts, open one, add one, change one, remove one. Four or five journeys, for the collection and for the single item, and they give you a list and a detail view and not much else. That's the wireframe, and it's the wireframe almost every product starts with.

Then ask what a phone book is, its nature rather than its screens. Nobody keeps contacts to look at them. They keep them to reach people. So there's a journey that starts at a contact and ends in a phone call, another that ends in an email, another in a WhatsApp message. There's one where two entries turn out to be the same person and need to become one. The why keeps handing you journeys the brief never mentioned, and each one either finds a home in the wireframe or shows you a piece that's missing.

Where this bends

The frictionless journey can be too frictionless. Rami's phone was a bottleneck: he could take one call at a time, and while he was on it the next customer got a busy signal. That was the pain we set out to remove. But the bottleneck was also doing a job nobody had named. It was capacity management. Rami has one kitchen, one or two drivers, and the lamb he bought that morning; on the phone he could say I'm slammed, call back in twenty, or it'll be forty-five minutes, okay?, or we're out of lamb, want chicken?, one sentence that informs, suggests and keeps the sale. Make ordering asynchronous and thirty people order at 12:15 on a Friday and Rami drowns. We removed the bottleneck. We also removed the judgment. Lucy Suchman (1987) has a name for what the phone call was full of: situated action. Plans are resources for what people do, not descriptions of it, and a journey drawn from the plan alone loses the part of the work that happens in the moment. Every "edge case" in that system was the same question: the phone call had human flexibility in it; what replaces it? So I ask it of every "before" I'm about to turn into a journey: what is the friction quietly doing, and what will do it when the friction is gone?

Building from journeys fails when the first journey was the wrong one. Derive your structure from an edge case and the main case will fight it forever. The first journey has to be the one most people are on most of the time.