Before the First Screen

Picture a homeowner three weeks into selling her house. An inspection report just landed in her inbox: forty pages, two hundred photographs, every flaw in the place documented with forensic indifference. Somewhere in those pages are two findings that genuinely matter and a hundred and ninety-eight that don't, and nothing in the document tells her which are which. The report buries her in information. What she lacks are answers: Which of these will scare a buyer? What do the big ones cost? Do I fix the deck or price it in? She stalls. She calls her brother-in-law. The product has just lost her at the exact moment it existed to serve.

Nobody designed that moment badly on purpose. More likely nobody designed it at all, because nobody in the room ever wrote down the questions she'd be facing when the report arrived. Whatever interface delivered that report is probably fine; the failure is upstream of it.

I've come to believe a lot of product failure starts exactly here, with a failure of knowing: a team quietly substitutes its assumptions about people for knowledge of them, then designs with great skill on top of the substitution.

The work I describe here is built on story mapping, the practice Jeff Patton codified. I've run it dozens of times over the past decade as the opening research phase of most of my engagements. Patton's map descends from goals to phases to steps to actions, and for most teams that's where mapping ends and design begins. Over years of running it, I found I couldn't stop there. Underneath every action are the questions a person must answer before they can act, and underneath every question is the information they need in order to answer it. Those layers, in my experience, are where products are won and lost. Mapped all the way down, the result is a structured account of users, goals, actions, questions, information needs, and handoffs: a product schema, the shape of the problem the product must serve. The people are where the work begins, and the schema is what it yields. The rest of this article is the method for getting from one to the other.

The premise: products get hired

People want their problem gone. They want the stress it generates out of their life and they want their world to be measurably better on the other side. In the Jobs-to-be-Done frame, a product gets hired to make that progress happen, and like any hire, it gets fired the moment it stops earning its keep.

This sounds like a slogan until you let it discipline your process. If a product is hired help, then before you can design it you have to know: who is doing the hiring, what job they're hiring for, what stress the job is generating right now, and what "done" looks like in their world rather than in your roadmap. Those answers are the raw material. Everything that goes on the map comes from them.

The shape of the engagement

The work happens in two-hour sessions with the client's subject-matter experts, usually several sessions across a couple of days. Two hours isn't arbitrary: it's roughly the ceiling of useful energy a room of SMEs can spend on this kind of focused excavation before answers get vague and agreeable. I'd rather have four sharp two-hour sessions than one heroic eight-hour one, because the method depends on the quality of answers, and tired people answer with whatever ends the meeting.

Real user data improves everything, and when it exists I use it. When it doesn't, the method has to be honest about what it's working with. SME knowledge is enough to start, but it can't be treated as uniformly proven: some of what a room knows comes from repeated exposure, and the rest is inherited story or guesswork with a job title attached. The output is a map that separates what the team knows from what it merely believes, and marks what still needs testing. I'll come back to why that distinction is the whole point.

We work on a wall, and the map is Patton's in structure. The habit of continuing past actions began during my years in-house at a financial institution, where I ran these sessions and kept watching the same failure repeat: the map would reach actions, design would begin, and the hardest problems would surface months later anyway, always in territory the map had never covered. Extending the map downward started as self-defense.

The wall itself matters more than it seems to. When a step is a sticky note, the room can pick it up and move it, and sequencing problems that survive hours of verbal debate get resolved in seconds because everyone can finally see that the inspection belongs before the agreement, not after. Some of the best decisions in these sessions are made by someone's hands rather than their mouth.

Step one: every user who touches the product

Most teams can describe their primary user. Far fewer have mapped everyone who will actually touch the product. So the first pass is a census: every user type, including the unglamorous ones. The administrator who configures it, the manager who reads its output, the third party who receives its handoff, the support person who untangles it. For each, enough persona and demographic texture to keep them human in the room.

The largest version of this I've run was for a loan origination system: three groups, about fifty people, sessions split across two days, and a workflow where every role's output was another role's input. Seen whole, the product was a relay race, and the design problem was the baton. If we had mapped only the loan officer, we would have designed a beautiful first leg of a race the institution kept losing in the exchanges. Few products are solo performances; that engagement, as much as any, is where this method earned its shape.

Step two: the job, the stress, the better world

For each user type, three questions, asked plainly and pushed until the answers stop being marketing copy.

What is this person trying to accomplish, and what are they hiring the product to do? What stress or problem does it remove, and what is the cost, in time or money or anxiety, of the way things work now? And what will be better in their world after, in words they themselves would use to describe it to a friend?

That last question anchors the whole method. Every decision for the rest of the engagement gets tested against it. If a feature, a phase, or a screen can't trace its lineage back to making someone's world better in a way they'd actually recognize, it's a candidate for deletion no matter how reasonable it sounded in the abstract.

Step three: linearize, then keep going

Now each user's goal gets laid out in time: the phases they move through, and under each phase, the steps, and under each step, the actions they take. To this point, a practitioner familiar with story mapping is on home ground. Goals, phases, steps, actions: that's the standard descent, and most discovery work stops there and starts drawing screens.

This is where I keep going, and the next two layers down are the reason this article exists.

Under every action: the questions. Before a person can act, they have to decide, and before they can decide, there are questions they must answer. Return to the homeowner from the opening. On a journey map, her moment is one tidy line: "respond to the inspection report." What she actually faces is a set of questions: Which of these findings matter? What will the big ones cost? Do I fix this or price it in? Which choice nets me more? The action is one sticky note on a wall. The questions are where the person actually lives: where the stress is, where they stall, where they call a friend or hire an expert or abandon the process entirely.

Under every question: the information. For each question, what information does this person need in order to answer it, and where does that information come from? Comparable repair costs. The norm for their market. What the last seller did. Some of it the product can compute, some it must fetch, some it must request from another user, and some doesn't exist yet, which is its own finding.

These two layers are the difference between a journey map and a schema. A map of actions tells you what screens to draw. A map of questions and information needs tells you what the screens are for. It generates, almost mechanically, the information architecture, the data model's outline, the states a flow must handle, who needs permission to see what, and which features are load-bearing versus decorative. I've watched long-running internal debates dissolve at this layer. A team that has argued for months about a dashboard discovers that no user, at any step, has a question the dashboard answers, and the argument is simply over, with no one's ego on the floor, because the schema settled it rather than a person.

Step four: the handoffs

Then the maps get connected. Wherever one user's action produces something another user needs (a submission to review, a report to respond to, an approval to act on), that's a handoff, and each one gets traced explicitly: what is passed, in what form, with what context attached, and what the receiving person needs to know that the sending person takes for granted.

Each role's experience can be individually excellent while the product as a whole fails, because the baton hits the ground between them. Handoffs are also chronically under-designed for a structural reason: in most discovery work, nobody owns the space between users. In this method, the space between users is on the wall like everything else.

The artifact, and how you know you're done

What comes off the wall is the product schema: a structured document of users, goals, phases, actions, questions, information needs, sources, and handoffs, in which every action traces up to a goal and down to its questions, every question lists the information required to answer it, and every information need names its source or is flagged as missing.

Done has a definition: a step is finished when no question under it is unstated and no information need is unsourced or unflagged. The workshop as a whole is finished when that's true across the map and, critically, before any interface design begins. At this stage a wireframe is a probe, never a decision. Sketches are useful when they expose a question and harmful when they let the room avoid one. The purpose of the engagement is to produce the schema from which design can proceed honestly; the moment drawings start functioning as answers, the room has started encoding assumptions again, just faster.

SMEs will disagree, usually about what users actually do rather than what the official process says. The disagreement doesn't get litigated to a winner in the room. Both answers go on the map as competing claims, marked as such. Which brings me to the honest version of what this method does.

What this actually buys you

I used to say this process eliminates assumptions. That's not quite true, and the more accurate claim is more useful. A room of smart SMEs and no user data can't eliminate assumptions. I said earlier that the map separates knowledge from belief and marks what still needs testing, and that distinction is the entire payoff. The method converts assumptions from unexamined and load-bearing into explicit, structured, and testable. Every claim on the map is either knowledge or a marked assumption, and the marked assumptions become a precise research agenda: when user data does arrive, you know exactly which cells of the schema it needs to confirm or overturn, instead of pointing research vaguely at "the user."

The unexamined assumption is the one that kills products, because design inherits it silently and builds on top of it with great craftsmanship. The marked assumption is just a question you haven't answered yet. The whole method, reduced to one sentence, exists to perform that conversion.

And it never stops being about the people. The schema is rows and columns; what the rows and columns hold is a person under stress, the progress they're trying to make, the questions standing between them and making it, and the information that would set them free to act. Get that structure right, drawn from real human problems rather than imposed on them, and design starts where it should: with a set of human questions the product is responsible for answering.