Stop Filing Personas. Start Chasing What Users Are Trying to Control.

You have a folder of personas. Jane, 34, marketing manager, likes hiking and oat milk lattes. It looks thorough. It changes nothing. When a real decision lands on the table, nobody opens that file, because it does not tell you what to build or what to cut.

The fix is not a prettier persona. It is a different question. Stop asking who the user is. Start asking what they are trying to get done, what progress they want, and what they are working to control. That shift turns a reference doc into a tool that settles arguments.

The deep cut

• Behavior is a clue, not the goal. The volunteer in Alex O'Neal's rubber-band demo held a knot steady; the room saw a circle.
• Demographics decide nothing. Knowing Jane's age and family size, as 3.7 Designs notes, never once shapes a page layout.
• Talk to real customers before you design. Amy Thibodeau's rule is to be quiet, be open, and listen for their words.

Why the pretty persona sits in a drawer

Traditional personas personify a segment. Age, income, hobbies, a stock photo. The team at 3.7 Designs built these for years, then admitted the plain truth: they rarely drive a design call. How does knowing someone's family size tell you what to put on a product page? It does not.

A persona is supposed to do two jobs. Give the team shared context, so you can ask "how would this land for her?" instead of "how do we feel?" And point design decisions in a direction. A thin persona fails at both. There is not enough real understanding in it to settle anything.

So the doc becomes decoration. Everyone nods at it in the kickoff, then goes back to designing around their own guesses.

Anchor in the job, not the person

Swap the biography for the work. 3.7 Designs calls their version a User Model, and it centers on three things: the root problem the user is trying to solve, the journey they take to solve it, and a short story to keep the team focused. Jobs-to-be-done statements, top-task analysis, journey maps.

The journey is where this earns its keep. Map the questions and objections a user carries from first search to after they buy. Now you know what to answer, where a call to action belongs, and which alternatives they are weighing. That maps straight onto navigation, messaging, and layout.

You can start today with two questions per user: what is the job they are trying to get done, and what is their top task on your site. The way to answer both is to talk to actual customers about what happened before they came to you.

Progress and control, not the finish line

A job has a deeper shape once you look. Alan Klement argues you should design for progress, not outcomes. People do not want a finish line. They want to feel forward motion in their lives. If you only measure the endpoint, you miss where your product actually helps them move.

There is a related idea worth stealing. Alex O'Neal borrows Perceptual Control Theory to make one point: behavior is not the goal, it is how people keep their experience near a state they want. Her rubber-band story nails it. The room saw a man draw a circle. The man said he was holding a knot over a dot. Same behavior, different intent.

Watch behavior alone and you build the circle. Ask what someone is trying to hold steady and you build the thing they actually came for. That is also why Netflix splitting DVDs from streaming stung. Customers did not want DVDs or streaming. They wanted movies.

Read intent, then decide how much to design

Users do not always know what they want. Sometimes the want is help figuring it out. Jordan Julien sorts intent into a simple grid: explicit or implicit, specific or general. A contact page serves clear, specific intent. A home page has to handle a crowd of fuzzy ones and nudge people toward stating what they need.

The practical payoff is knowing when to simplify. If you know the intent, serve the answer straight. If you do not, design the experience to draw it out. Julien warns against treating users as a school of fish and averaging them into a blur. That average erases the very nuance that would have told you what to build.

Skip this and you pay for it later. Half the redesigns that blow a budget happen because the team forgot something about the user midway through.

Keep it honest with the whole team

Two guardrails make this stick. First, find the hidden user. O'Neal worked on medical software with nurses, billers, and schedulers who seemed to want different things. The shared thread was a person not on the screen: the patient. "Patient first" became the mantra that tied the design together. Ask who your absent user is.

Second, check your metrics against the intent. Amy Thibodeau shows how a clickthrough goal quietly pushes you toward clickbait and fake urgency. The number goes up, the user gets worse off. Ask what your metric means in human terms, and whether it tracks real progress.

An empathy map, per Nielsen Norman Group, is a cheap way to pull what you learn into one place the team can read at a glance. It is a container for the talking, not a substitute for it.

Three questions for your team

• Pick a live project. What is the user actually trying to control or make progress on, and does our current doc say? If it only lists age and job title, it is not doing the work.
• Who is the hidden user we are not designing for? Name the absent person, like O'Neal's patient, whose interest ties every screen together.
• What does our key metric mean in human terms, and does it track real progress? If juicing the number hurts the user, the metric is pointed the wrong way.