Should you design for People, Personas, Activities or Jobs?
Various human-machine interface design and research theories employ and value user models in different ways. Which is best?
Experience design research has relied upon a variety of techniques over the years to describe users and their requirements for the tools they use to satisfy their needs. These approaches typically have their fans and detractors who argue back and forth about what is the best approach for factoring users into designs. We can gain some insights by considering them all at once.
Anthropometry
The anthropometric approach originated in human factors and ergonomic engineering. With it, the properties of people are measured to determine the population ranges of values for attributes and these are used to determine what is necessary to meet their needs. In the heyday of human factors engineering, product design usually meant the design of physical devices. So, the attributes were almost always physical, if not bodily features, such as such as stature, weight, reach, and so forth. If you can’t comfortably reach the gas pedal with your foot, the steering wheel with your hands, and see over the dashboard while looking in the rearview mirror, you have a problem.
The goal of the anthropometric approach was to design products to accommodate as many people as possible. Typical research tools used were tape measures, weight scales, and calipers. The measurements collected with these were used to calculate population distributions and compile tables. The design target was most often to accommodate at least 95% of the target population on all relevant attributes. A common rule was that one should never design for the average, especially because bodily dimensions correlate poorly with each other.
The catch phrase of anthropometry in human factors was “the measure of man.” Setting aside the unfortunate gender bias, it reflected the hope that by measuring attributes of people we could design products that accommodate most everyone. Optimizing for individuals was rarely, if ever, a goal.
The pinnacle of anthropometric design was airliner seating. By careful consideration of the population parameter limits for femur length, seated height, and pelvic breadth, airplane designers optimized the total amount of human meat they could squeeze into an aluminum tube without being called before the International Court of Justice in the Hague for abuses to the human body and personal dignity.
Usually “anthropometry” is interpreted to mean the measurement of body parts, but the same philosophy has also been applied to the accommodation of sensory and motor attribute variability such as visual acuity, critical flicker fusion frequency (the rate at which a flickering light source becomes noticeable, used to determine monitor refresh rates), the incidence of anomalous color vision, lifting strength and so on.
Today, many of these physical measurements have become standard engineering practices and research interest in anthropometry has declined (Figure 1). Furthermore, this kind of measurement approach doesn’t translate easily into designs in which psychological, emotional, business and social considerations are important. However, accessibility design remains the one area in which the goal of accommodating everyone persists.
Personas
In contrast, the persona approach seeks to create an idealized model of a user as a social and psychological entity. Invented by Alan Cooper (2004, 2008a) a persona is a profile of representative user attributes. These attributes are typically things like goals, skills, attitudes, and environments.
Tape measures, grip-strength dynameters and calipers are of little use here. So, research on personas relies on ethnographic studies, interviews, surveys and questionnaires.
Rather than targeting entire populations, software experiences often focus on user categories to optimize the design for a hypothetical user representing each targeted category. Thus, while anthropometry and accessible design seek to address extremes, personas are more concerned with representative users.
Cooper (2008b) also recommended adding a few fictional, personal characteristics in order to “bring the persona to life”.
Narrative and Essential Persona Attributes. I’ve found it useful to refer to two types of persona attributes based on how they are used. Narrative attributes are Cooper’s fictional characteristics that make stories about personas interesting and memorable. Examples of narrative attributes could include a stock photo representing the persona’s face, where she went to school, her name, ethnic identity, gender identity, affection for cats versus dogs, and favoring hops-heavy versus malty beers.
Essential attributes are those that describe characteristics of the persona that more directly inform design. These include things like skills, experience with a product, responsibilities, goals, and collaborators.
Some who favor narrative attributes argue that the more detailed a persona description is, the easier it is to get inside that persona’s head and consequently, the easier it will be to design to meet that persona’s needs. I’m here to tell you that this is objectively false.
I have three sources of evidence for my bold assertion. One is logical and two are personal. First, personas are imaginary. They do not have heads to get inside of. Second, if the persona likes cats and IPAs, I cannot even begin to imagine its world view. Finally, I know my wife better than any other person in the world. I could list hundreds of her personal attributes. However, years of experience have taught me that this special knowledge is of no value whatsoever when buying her a birthday present.
More seriously, there is empirical evidence that simply taking the perspective of another person does not help in predicting what that person would do or want in a situation. In order to know what a person wants, you had better just ask them (Eyal etal, 2018a, 2018b). It’s not very romantic but you should consider their wish list.
There are other schools of thought regarding how personas should be described and used. Don Norman’s (2008c) ad hoc personas are simple, expedient word tools used when discussing designs. Ad hoc personas are created as needed without extensive demographic information to facilitate discussions. This bare-bones approach is similar to the use of the character names “Bob” and “Alice” used in describing secure communication protocols.
Peterson (2016) advocates using what she calls “behavioral personas”. These are similar to Cooper’s personas in that they are intended to be empirical but focus on essential attributes like attitudes, skills, and goals.
Personas often play the role of actors in user stories:
As <persona name>, I want <capability> so that I can <activity>
(e.g. Davies, 2010)
Personas are very popular design tools. However, their use has drawn criticism. While Cooper (2008b) called for them to be based upon ethnographic research, in practice, this often doesn’t happen. Saffler (2005) asserts that at least half are made up without any research whatsoever.
In the worst cases, they are based on the capabilities and limitations of actual products. If personas are for existing products, they are based on users who have adapted to products designed in the past. If they are designed for future products, they may be created out of whole cloth as the users that we hope to have.
Furthermore, they may be created to buttress arguments in defense of disciplines in a product research and development organization (Massanari, 2010). Designers imagine the persona that would use their designs and developers imagine the persona that could use the software that they develop. When different factions like design, product management, or engineering make up personas without an empirical foundation, they can become a nonproductive battleground.
Regardless of misuses and controversies, the persona concept is well established in design, marketing, and development (Figure 2).
Activities and Tasks
Norman (2005) provided another approach for establishing the requirements for designs. Famously contrarian, he positioned his Activity Centered Design (ACD) as opposing the most cherished assumption of usable design: human-centrism. Norman argued that instead of designing for users, we should instead design with their activities in mind.
In ACD, an activity is an integrated, coordinated set of tasks. Tasks are composed of operations and operations are composed of actions. In human-centric design, technology is expected to adapt or be adapted to the human. However, ACD turns this on its head and stresses that people will adapt to their tools.
This is an interesting twist on the trajectory of Human-Computer Interaction design (HCI) over the past 30 years or so. The assumption that software user interfaces should all be walk-up-and-use has almost always been taken as axiomatic. Consequently, patterns for directed user-interfaces like wizards, verbose labels, and pervasive embedded instructional text are often used as the go-to solutions for ease of use problems.
This works if a tool is used once. But, if it is used frequently, its users adapt to it and come to see it as inefficient.
Norman stresses that regardless of whether we choose to ignore it, the fact is that humans always adapt to their tools.
Consider automobiles with manual versus automatic transmissions. Moving from an automatic transmission to a manual requires considerable adaptation. Manual shifting is a skill that requires multiple simultaneous operations, pushing in the clutch, changing engine speed, and repositioning the shifter. All of this must happen while steering and monitoring road conditions.
The opposite scenario, moving from a manual to an automatic may seem to require little adaptation — just ignore all that clutch and motor speed stuff. But it’s not that simple. With experience, manual shifting becomes automatic (no pun intended). When a manual driver must use an automatic transmission, she must adapt by suppressing those reflexive operations. Attempting to depress a nonexistent clutch when braking can cause the driver to quickly depress the brake. It has also been shown that automatic drivers adapt by relaxing their attention (Cox, etal. 2006, Thakkar, 2019).
Norman identified two limitations of human-centered design:
· Designs optimized for one or a group of users (i.e. a persona) by definition means that the tool will be less than optimal for others.
· Designs optimized for a user at one point in time (e.g. when she is just learning) may mean she will be less satisfied at a later point in time (e.g. when she is experienced).
ACD avoids these problems and takes into account:
· The adaptation of users to their tools over time.
· Relationships between activities. A design that considers what the user may do next will likely be more usable than a design that optimized for each action in isolation.
Although ACD was promoted by one of the biggest names in design, it never quite garnered the mindshare of personas. This might be because Norman’s primary reference on the topic challenged the design community to reconsider their most basic assumptions and beliefs. The history of humankind has shown that challenging beliefs often leads to bloodshed. And to be sure, Norman caught a lot of flak — it didn’t take long for the villagers to get their torches and pitchforks (Norman, 2008b). But for whatever reason, it is an important idea that never quite garnered the mindshare it deserves (Figure 3).
Jobs to Be Done
Jobs to Be Done (JTBD) is a popular concept that originated in marketing as a reaction against using market segmentation and demographics to target customers (Christensen, etal. 2005, 2016). Because demographics brings to mind lists of persona characteristics, the JTBD approach is often introduced while criticizing the use of personas.
The concept of JTBD has given rise to a variety of consultant offerings, books and articles. Its mindshare has been increasing over the past few years (Figure 4).
The essence of JTBD is that information about your customers’ circumstances is more valuable than customer, user, or persona attributes. At best, personal attributes are only correlated with product purchases. In contrast, the circumstances behind a need can be seen as causing a person to purchase a product. In the JTBD vernacular, products are “hired” for a job. If the situation didn’t arise, the solution would not be hired.
As JTBD advocates point out, user attributes provide little information about how to design a product. I’ll give an example.
For many years, I have worked on the design of business automation product — software that choreographs business processes, manages cases, or automates complex, repetitive decisions. Two classes of personas are commonly referred to in business automation. Those who implement business automations (developers) and those who understand business problems (business analysts). Developers and business analysts each have a lot of characteristics; however, most design and development discussions revolve around a single attribute: so-called “technical skill”. The developer is “technical”, and the business analyst is not. The design implications for the business analyst? Consider spreadsheet style UIs but avoid programmatic user interfaces and engineering jargon. This is only a mild exaggeration.
It is possible to write usage stories for JTBD. For example:
When <situation> I have <motivation> so I can <have outcome>
(adapted from Klement, 2013)
The JTBD approach has its advantages. Concentrating on jobs rather than users avoids the need to collect demographic data. Because a job describes challenge of reaching a goal when in a motivating situation it can help to point to the right tool (i.e. a design) for the job. Finally, by abstracting away from the use of existing tools to root causes or situations, JTBD may free the designer to consider more inventive solutions. This last point is captured by Theodore Levitt’s quote, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!” (Christensen etal., 2005).
JTBDs are concerned with causes for hiring a tool for a job. One challenge for the technique is how to identify the most useful cause. (Ritzenthaler, 2016). The trouble with causation is that while we often think in terms of single causes, actions and events are the result of multiple causes. One way of finding root causes is to ask “why” questions about product requirements. This can quickly lead one off into the weeds.
1. Why did you buy a drill? Because I wanted to drill a hole.
2. Why? Because I wanted to hang a picture.
3. Why? Because I want to impress my friends with my good taste.
4. Why? Because I’m insecure.
5. Why? Because I didn’t have a good relationship with my father.
6. …
The reasons expressed are less important than other information gained along the way (Ritzenthaler, 2016). In the drill example, the need for a way to hang a picture (reasons 1 & 2) are what are important. By focusing on these, one can focus on alternative, possibly inventive, solutions (hanger pins, picture shelves, plate holders, picture rails, …). Of course, it is always good to know when to stop asking why.
Another issue with JTBD is confusion over jobs and tasks. One way of distinguishing them is to remember that jobs answer “why” questions and tasks answer “what” (Klement, 2016) or I would say, “how” questions.
The Best Approach?
These four approaches were all invented to help guide the design process toward positive user experiences. For some reason, we usually feel we must choose winners and losers, favorites or best of breeds.
Each approach has its strengths and weaknesses. But rather than tallying up the positives and subtracting the negatives we can embrace the diversity of the techniques. At the end of the day they all offer ways to think about design. Furthermore, each approach has a different job to do.
The user-metrics approach typified by anthropometry works well when it is necessary to accommodate users. It doesn’t work as well when we need to optimize for specific audiences.
Personas are useful communication devices. They can help to typify user goals. They help to make usage stories memorable. But they don’t tell you why one would buy your product or help you to consider design alternatives.
Activities and tasks enable us to describe and measure the effort required to reach a goal. They provide a context for considering user adaptation and learning with experience. But they don’t tell one why a customer might buy a product. I don’t buy a drill because I love to drill holes.
Jobs allow us to frame user needs and goals in a way that the other approaches don’t. They can encourage divergent thinking. But by themselves they don’t measure the effort required or the user attributes that would limit or encourage a tool to be used.
Furthermore, each of these approaches can be applied at different points on the ideation, design/development, and marketing timeline. Jobs can be a powerful technique for identifying needs and fostering ideation; personas can be helpful in communicating design ideas; activities and the anthropometric philosophy of accommodation are critical in fleshing out designs; and both personas and jobs have value when it comes time to market a product.
Design can be thought of as searching a multidimensional problem space to find a solution. Viewing the design space from multiple perspectives can only help.
Christensen, C.; Cook, S.; and Hall, T. (December, 2005). Marketing Malpractice: the cause and the cure. Harvard Business Review, https://hbr.org/2005/12/marketing-malpractice-the-cause-and-the-cure
Christensen, C.; Hall, T.; Dillen, K.; and Duncan, D. (September, 2016). Know Your Customers’ “Jobs to Be Done”. Harvard Business Review, https://hbr.org/2016/09/know-your-customers-jobs-to-be-done
Cooper, A. (2004). The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. Indianapolis, IN. Sams Publishing.
Cooper, A. (May 15, 2008a). The origin of personas, Cooper, Journal. https://www.cooper.com/journal/2008/05/the_origin_of_personas
Cooper, Alan (May 15, 2008b). Perfecting your personas. Cooper, Journal.
https://www.cooper.com/journal/2001/08/perfecting_your_personas
Cox, D.J.; Punja, M.; Powers K.; Merkel R. L.; Burket, R.; Moore, M.; Thorndike, F.; and Kovatchev, B. (November, 2006). Manual transmission enhances attention and driving performance of ADHD adolescent males: pilot study. Journal of Attention Disorders, 10(2):212–6. https://www.ncbi.nlm.nih.gov/pubmed/17085632
Davies, Rachel (2009). Non-Functional Requirements: Do user stories really help? DevOpsDays, https://legacy.devopsdays.org/blog/wp-content/uploads/2010/02/rachel-davies-nonfunctional-devopsdays.pdf
Eyal, Tal; Steffel, Mary; and Epley, Nicolas. (October 9, 2018a). Research: Perspective taking doesn’t help you understand what others want. Harvard Business Review.
https://hbr.org/2018/10/research-perspective-taking-doesnt-help-you-understand-what-others-want
Eyal, Tal; Steffel, Mary; and Epley, Nicolas. (2018b). Perspective Mistaking: Understanding the mind of another requires getting perspective, not taking perspective. Journal of Social and Personality Psychology, V.114 n4, 547–571.
Klement, Alan (November 12, 2013). Five tips for Writing a Jobs Story, Medium/JTBD.info,. https://jtbd.info/5-tips-for-writing-a-job-story-7c9092911fc9
Klement, Alan (January 7, 2016) Penn Jillette gets JTBD. Medium/JTBD.info.
https://jtbd.info/penn-jillette-gets-jtbd-4bdd9c4373c0
Massanari, Adrienne L. (2010). Designing for imaginary friends: information architecture, personas and the politics of user-centered design. New Media & Society 12(3) 401–416
https://pdfs.semanticscholar.org/a997/18ffa337daebf4f035ab7ba020aebed4b5e0.pdf
Norman, Donald (July-August, 2005) Human-Centered Design Considered Harmful. Interactions. ACM Press.
Norman, Donald (November 17, 2008a), Ad-Hoc Personas & Empathetic Focus. jnd.org
https://jnd.org/ad-hoc_personas_empathetic_focus/
Norman, Donald (November 17, 2008b). HCD Harmful? A clarification. jnd.org, https://jnd.org/hcd_harmful_a_clarification/
Peterson, Maggie (April 18, 2016), The Problem with Personas, Medium, https://blog.prototypr.io/the-problem-with-personas-82eb57802114
Ritzenthaler, Daniel (August 7, 2014). Asking why is not always the best strategy.
Medium/JTBD.info, https://jtbd.info/asking-why-is-not-always-the-best-strategy-b913ba46fcde
Saffler, Dan (August 17, 2005) Persona Non Grata, Adaptive Path, https://adaptivepath.org/ideas/e000524/
Thakkar, Vatsal G. (March 23, 2019). Forget Self-Driving Cars. Bring Back the Stick Shift. New York Times, https://www.nytimes.com/2019/03/23/opinion/sunday/stick-shift-cars.html
