Two questions behind a design decision
Imagine a team designing an app for planning trips across buses, trains and shared bikes. It could start by asking, “Who will use this?” A commuter with a tight schedule, a visitor unfamiliar with the city and a parent traveling with a child may need different information. That is the kind of question a persona helps organize. The team could also ask, “What is someone trying to accomplish right now?” Getting to an appointment on time, avoiding a difficult transfer or finding a route that feels manageable are examples of jobs. That is the focus of Jobs to Be Done, often shortened to JTBD.
Neither approach is a substitute for talking to users or observing how a product works in practice. Both are ways to make sense of what a team learns. The difference is where each puts the emphasis: personas frame needs around a person or group, while JTBD frames them around a goal in a specific circumstance.
What a useful persona does
A persona is a concise profile representing a pattern among users. It might describe someone’s goals, habits, constraints and level of familiarity with a product. For the trip-planning app, a persona might represent riders who routinely travel with a stroller and need to assess transfers before leaving home. A useful profile would explain the decisions those riders face, not just assign them a name, age and stock-photo-style biography.
Personas help teams keep different users visible during design. When deciding how to present route options, a team can ask whether a transfer instruction is understandable to a first-time rider or whether it leaves out details that matter to someone managing a stroller. Personas can also help with recruitment for usability testing by highlighting whose experience needs to be included.
Their weakness is the temptation to treat an invented character as evidence. A polished profile built mainly from assumptions can make stereotypes feel authoritative. Even a well-supported persona can become too rigid if a team assumes everyone in a group behaves alike. It is better to record where a persona came from, keep its claims tied to observed patterns and revise it when users reveal something different.
What Jobs to Be Done reveals
JTBD looks at the progress a person wants to make under particular conditions. A rider’s job might be: “When I need to reach an unfamiliar place, help me choose a route I can follow confidently, so I can arrive without an avoidable surprise.” That statement names a situation, an intended outcome and a reason the outcome matters. It does not assume that only one type of person has this need.
This lens is especially useful when the same person makes different choices at different times. A regular commuter might prioritize speed on a familiar weekday trip but want a simpler route when traveling with luggage. Conversely, people with very different backgrounds might all want clear notice that a station lift is unavailable. Looking at the job can reveal alternatives to a proposed feature: clearer signs, better service alerts or fewer steps in the app might solve the problem more directly than a more elaborate route-ranking system.
JTBD can become vague if a job is stated too broadly. “Get around easily” offers little guidance about what to design or test. It can also overlook important differences between users if the team assumes one solution will work for everyone pursuing the same outcome. The circumstances and constraints need to remain part of the description.
Using both on the same product
Suppose the trip-planning team learns that people often hesitate before choosing a route with several transfers. A JTBD framing directs attention to the decision: what information would help someone judge whether the route is manageable? A persona framing prompts a second question: manageable for whom? A rider carrying luggage, someone using a mobility aid and someone rushing to a meeting may interpret the same transfer time differently.
Together, the approaches can guide a modest design experiment. The team could show transfer details more clearly, including walking steps and available accessibility information where those details are known. It could then test the revised route display with people facing different travel constraints and ask whether they can choose a suitable route. The goal is not to prove that a persona or job statement is correct; it is to find out whether the design helps people make the decision.
Choose the lens that exposes the blind spot
Start with a concrete design question, such as why people abandon setup for a smart-home device or struggle to compare charging options for an electric vehicle. Gather examples of what people do, what they are trying to achieve and what gets in the way. Draft a few personas if the team needs to understand meaningful differences among users. Draft job statements if it needs to understand why people choose a product, work around it or stop using it.
Before acting, check what each lens leaves out. Ask whether the personas rest on real patterns rather than assumptions, and whether the jobs are specific enough to suggest a testable change. Revisit both as the product and its users change. Personas and JTBD are most valuable not as labels to defend, but as tools for asking better questions about everyday needs.
