Customer personas vs situations: designing for the many sides of me

There is a poster on the wall of the project room. It has a stock photo, a first name, an age, a job title, a line about “values convenience and authenticity” and a quote in italics that nobody ever said. This is one of the customer personas, and every design decision for the next six months is supposed to be checked against her.

Customer personas are fictional profiles that stand in for a group of customers, built from demographics, attitudes and a handful of goals. I have nothing against the people who made this one. Personas were a real improvement on designing for “the user” as an abstraction, and a good one can stop a team building for itself. The trouble is what the poster leaves out, which is nearly everything that decides how a real visit goes.

Consider one customer. On a Tuesday at eight in the morning, she wants the fastest checkout that exists and will abandon a basket over one extra field. On Saturday evening she will browse for an hour and enjoy it. In one visit she is buying for herself; in the next she is buying for her mother, who has different needs, a different budget and a different address. She is the same person on the poster in all four cases, and the poster is wrong about her in at least two.

Key takeaways

• A persona describes a type of person, but customers experience a company in situations, and the situation decides what they need far more than age or job title does.
• The same customer is several customers: a rushed reorder, a gift under pressure and a leisurely browse need different experiences from the same company.
• Occasion-based segmentation asks how much time the customer has, who they are buying for, how sure they are and how much is at stake.
• Research interviews, surveys and journey maps all improve when they are anchored to a specific occasion rather than to a person.
• Demographics still matter for reach and for managing value; they are a poor guide to how a given moment should feel.

What customer personas are, and what they leave out

A persona is a composite. A team takes research on a group of customers, or sometimes just a segment definition, and writes it up as one imaginary person with a name, a face and a story. The idea came into design practice from software in the late 1990s, and it spread because it works on a specific problem: engineers and marketers arguing about “the user” from their own preferences. A named, described person ends that argument.

What a persona contains is mostly stable: who the customer is, what they value, what they are broadly trying to achieve. What it leaves out is everything that varies from one visit to the next. How much time she has today. Whether the money is hers. Whether she has done this before. Whether anyone will be upset if it goes wrong. Those are the things that decide whether the checkout felt fine or infuriating, and none of them appear on the poster.

A persona is also not a segment, though the two get confused. A segment is a group of real customers defined by data, such as value, tenure or behavior, and you can count it and manage it. A persona is a story about a typical member. The story is useful for empathy and useless for arithmetic, and the trouble starts when teams treat the story as if it were the data.

Why the situation beats the type

The persona flattens a person into a type, and then the experience is designed for the type. But customers do not experience your company as types. They experience it in situations, and the situation changes what they need far more than their age or job title does.

The signals that actually shape a visit are things like: how much time do I have, who am I buying for, how sure am I about what I want, how much is riding on getting it right, and have I done this before. A twenty-five-year-old and a sixty-year-old in the same hurry, buying the same gift for the same kind of person, have more in common at that moment than either has with themselves on a lazy afternoon.

There is an older idea in product thinking, usually called jobs to be done, that people hire products to do a job, and that the job, not the person, is the unit of design. I would put it slightly differently for customer experience: the occasion is the unit. Design for the moment, and the type mostly takes care of itself.

None of this makes demographics useless. They still matter for who you reach and how, and a segment defined by customer lifetime value or behavior is a perfectly good thing to manage. But as a guide to what the experience should feel like at a given moment, the occasion beats the person almost every time.

Personas vs situations: which to use when

Both tools have a place. The question is which one is holding the pen for a given decision.

Decision	Persona helps	Situation helps
Who to reach, and through which channels	Yes, this is what it is for	Little
Tone of voice in marketing and content	Yes	Somewhat; the rushed occasion wants less copy
Which fields the checkout should have	Little	Yes, decided by time and stakes
Where a journey map breaks	Weakly, one path per persona	Yes, friction moves with the occasion
How to anchor a survey question	No	Yes, ask about this visit and what kind it was
Which segment to invest in	No, that is a value question	No, that is a value question
Stopping a team designing for itself	Yes	Yes

The last row matters. Both tools do the job personas were invented for, which is keeping the team’s own habits out of the design. Situations do it with the added benefit of being something the team can observe on the shop floor, in the call recordings and in the comments, rather than something they have to imagine.

What changes for research, surveys and journey maps

Taking situations seriously changes three pieces of everyday practice.

Research asks about the occasion. An interview that opens with “tell me about yourself” gets a biography. One that opens with “tell me about the last time you bought from us: what was going on that day?” gets a situation, and situations are what you can design for. Ask what they were trying to get done, what else was competing for their attention, and what would have made them give up. Reading comments this way, occasion by occasion, is also how the numbers get their why.

Surveys say which visit they are asking about. A relationship survey that asks “how satisfied are you with us?” is asking the customer to average across every situation they have been in, and the average describes none of them. Anchor the question to an occasion: this order, this call, this visit. Then add one or two questions about what kind of occasion it was. Was this for you or for someone else? Were you in a hurry? Two questions like that will split your scores into groups that make sense for the first time.

Journey maps have one person and several journeys. The standard map has a persona at the top and one path beneath it. Draw instead a single customer with three or four paths: the routine reorder, the first purchase for someone else, the emergency, the leisurely browse. The friction sits in different places on each. A checkout step that is fine on the browse is fatal on the emergency.

This also cuts through the standardization argument. A company that standardizes itself toward one process for everyone is often standardizing for one occasion and ignoring the rest. A standard process is fine for the occasion it was designed for; the damage comes from assuming there is only one occasion.

How to rewrite a customer persona as three situations

If you already have personas, do not throw them out. Rewrite them. It takes a workshop of about two hours and produces something the team will actually use.

1. Start from what the persona is for. Ask what decisions the persona was supposed to inform. Usually it is a handful of moments: landing on the site, choosing, checking out, getting help, coming back. Those are your candidate situations.
2. Pick three situations that differ in what they demand. A good set has one routine occasion (the reorder, the regular visit), one high-stakes occasion (buying for someone else, a purchase that is hard to undo, an emergency) and one exploratory occasion (browsing, comparing, not sure yet). Give each a name a colleague would recognize: “the Tuesday reorder”, “the gift under pressure”, “the Saturday browse”.
3. For each, write down four things. What the customer is trying to get done. How much time and attention they have. What would make them give up. What “good” feels like at the end. Keep each situation to half a page, in plain language, with two or three real comments from customers who were clearly in that situation.
4. Map the friction per situation. Walk each situation through the current experience and mark where it breaks. You will find that some steps are fine for one occasion and painful for another, which is exactly the insight the single persona was hiding.
5. Put the situations on the wall where the persona was. Design reviews then ask “which situation is this for?” rather than “what would she do?”, and the first question has an answer.

A worked example (illustrative)

Take a hardware retailer with a persona called “the weekend renovator”. Rewritten, the persona becomes three situations. The Tuesday reorder: a tradesperson collecting the same twenty items as last week, with a van on a meter outside. The Sunday emergency: a homeowner with a burst pipe, no idea what part they need, and the shop closing in an hour. The Saturday project: a couple planning a bathroom, in no hurry, wanting to compare and touch things.

Walk the same store through all three. The reorder needs a saved list and a fast lane; every question at the till costs the customer money. The emergency needs a person at the door who can identify the part from a photo; the layout and the range are irrelevant. The project needs space, samples and someone who will not hurry them. One layout, one till process and one staffing plan cannot serve all three well, and the persona never showed why.

What quietly breaks occasion-based design

Situations fail in their own ways, and most of them come from treating them like posters.

Too many situations. Three is a working number. Eight is a taxonomy, and a team faced with eight will go back to asking what the persona would do. Merge situations until each one demands something different from the experience.

Situations without evidence. A situation invented in a workshop is as fictional as a persona. Each one should carry real comments, real call recordings or real observation, and if you cannot find any, the situation may not exist.

Making the customer declare the occasion. A menu that asks “is this a gift?” at the door is fine; a form that demands the customer classify their visit before they can start is not. Where the occasion can be inferred from behavior, such as a saved list being reordered or a search for a specific part number, infer it.

Forgetting the person entirely. The situation says what the moment needs; the person still sets limits on it. A first-time customer in the emergency situation needs more guidance than a regular in the same fix. Keep one line about who the customer is likely to be in each situation, and no more.

When personas are still the right tool

There are decisions where the type matters more than the moment.

Reach is one. Choosing channels, media and messages depends on who the customers are and where they can be found, and a persona is a good compact way to hold that. Tone is another: how a company writes and speaks is set for a kind of person, not a kind of visit, even if the rushed visit wants fewer words.

In business markets, roles can behave like stable personas. The buyer, the user and the person who approves invoices have different concerns in every situation, and a persona per role is often more useful than a persona per company. The situations then sit underneath each role.

And some businesses have uniform occasions. A commuter coffee shop at eight in the morning serves one situation almost exclusively, and it can design for that situation and then think about the people in it. The point is not that situations always win. It is that the way customers evaluate a purchase has changed a great deal over the years, and what has not changed is that the same person evaluates it differently depending on the day. A poster with one face on it will never capture that. Three situations on an index card each will.

Where to start

1. Pick the persona the team uses most and list the decisions it is supposed to inform.
2. Read fifty recent comments or call notes and mark, for each, what kind of occasion it was. Three or four kinds will account for most of them.
3. Run the two-hour workshop and write up three situations, half a page each, with two real comments in each.
4. Add one occasion question to the next survey wave, such as “was this purchase for you or for someone else?”, and split the scores by the answer.
5. Walk one journey map through all three situations and mark where the friction moves.
6. Replace the poster with the three index cards and change the design-review question to “which situation is this for?”.

FAQ

What is a customer persona?

A customer persona is a fictional profile that stands in for a group of customers, usually with a name, a photo, demographics, attitudes and a few goals. Teams use it to keep a concrete person in mind during design and marketing decisions. It describes who the customer is rather than what is going on when they buy.

What is the difference between a persona and a customer segment?

A segment is a group of real customers defined by data such as value, tenure or behavior; it can be counted, tracked and managed. A persona is a story about a typical member of a group, useful for empathy and not for arithmetic. Problems start when a team treats the story as if it were the data.

What is occasion-based segmentation?

Occasion-based segmentation groups purchases or visits by the situation the customer is in rather than by who the customer is: a routine reorder, a gift bought under pressure, an emergency, a leisurely browse. The same person falls into different groups on different days. It is used to design experiences and to anchor survey questions to a specific visit.

Should you stop using personas?

No, but you should stop using them for decisions they cannot inform. Personas remain useful for choosing channels, setting tone and keeping a team from designing for itself. For decisions about how a specific interaction should work, rewrite each persona as three situations that differ in time, stakes and certainty.

How do you write survey questions around a customer occasion?

Anchor the main question to a specific event, such as this order, this call or this visit, rather than to the relationship as a whole. Then add one or two short questions about the kind of occasion it was, for example whether the purchase was for the customer or for someone else and whether they were in a hurry. Splitting scores by those answers usually explains differences that looked random.