Personas: Competing or Complementary?
Summary: I wax philosophical about attributes of personas. These attributes can be competing or complementary and this tension (or harmony) yields different design challenges. I elaborate on this theory.
The other day, while working on the chapter for Personas, this thought popped into my head:
Personas’ motivations, needs, and goals can be competitive or complementary.
Here’s an attempt to explain this theory in more detail:
In a group of personas, each persona represents a collection of motivations, objectives, and behaviors. Let’s call these the attributes of the persona. Within a group, two personas may have attributes that are either competitive or complementary.
Competitive Persona Attributes
Competitive attributes yield different priorities in the design of a product. One persona needs one thing, and another persona needs an opposing thing, and the design must somehow accommodate both. One strategy is to prioritize one persona’s needs over another. Another strategy is to prioritize those attributes the personas have in common. Still another is to design separate products. Of course, the path of most resistance (though arguably the most successful) is to devise a product that somehow accommodates both needs without sacrificing another.
The litmus test for competitive attributes is pretty straightforward: take out one of the competing personas and you’d design a different site.
Imagine you’re designing a web site that matches dog-walkers with customers. The web site allows people to find a new dog walker, then handle the logistics of scheduling walks. It’s complicated: is this a regular once-a-day walk, or is it more frequent visits while you’re on vacation? Do you care which dog-walker comes, or can we send anyone? What kind of report do you want on your dog? Do we need to take care of other pets? So much to think about.
For this site, there might be two personas: regulars and vacationers. Regulars want to set up recurring visits and get quick reports on their dogs. Vacationers need infrequent visits and may want more detailed reports. The challenge is balancing the needs of these two customers in designing the service. How do you know that these personas have competing attributes? If you had to accommodate only one, you’d likely design a different site, right?
Complementary Persona Attributes
But there’s a third persona–the dog-walker herself. The attributes of this persona complement the other two. Her motivations and behaviors work in concert with the customer personas to achieve common objectives–a happy dog. Though she’d likely use a different interface altogether, you could imagine some cross-over screens that are used by both the customer and the dog-walker.
Conclusions about the Theory
Based on these assumptions, there are some conclusions that we can draw:
- Personas may have competitive or complementary attributes, but two personas don’t need to be 100% competitive or complementary.
- Any group of personas is going to composed of a mix of competitive and complementary.
- Competitive attributes are challenging because they introduce especially complex constraints.
- Complementary attributes are challenging because they can lead to scope creep.
Personas Relate to the Product, Not Each Other
The moment I had the thought, I posted this on Twitter:
A group of personas can have either competing or complementary objectives/motivations/behaviors. True or false? Does it matter?
Responses rolled in from @ebuie, @jmspool, @inkblurt, @katiewornson, @anaveca, @diesh, and EightShapes’ own @detzi. Jared’s response summed up all the feedback best:
It’s not about the relationships to each other. It’s the personas relationships to the design/experience.
Twitter is, of course, a lousy medium for engaging in theoretical discussion. Still, my interpretation of Jared’s 140-character thought is that personas are not meant to be compared.
Extending that idea, I see enormous merit in forcing designers to think about their audience as a contiguous whole with different attributes that pervade to varying degrees. Personas and other segmentation strategies raise artificial boundaries between users, corralling them into convenient buckets that allow us to summarize their needs. Further, such grouping encourages prioritization, allowing us to ask “Which set of user needs is most important?” Such comparisons paint a picture of our target audience as a quilt–big interlocking squares–and not as a heterogenous organism similarities and differences throughout. This conclusion raises a useful methodological question: Should project teams prioritize personas?
But…
But I’m not interested in addressing that big question here and now. I’m more interested in looking at the range of attributes of our target audience (whether we assign them to a particular group or not) and recognizing the inherent tension or harmony in them.
At a practical level, the theory gives designers another way to analyze personas and user requirements. It allows us to look at how much a product needs to balance competing needs or how much it needs to facilitate complementary behaviors.
Still, if we wanted to zoom out, the theory yields another interesting methodological question: Can we represent target audiences by collections of needs and behaviors without further segmentation? Can we create a picture that shows the range of attributes and the degree to which those attributes operate at odds or in concert?
This probably won’t make it into the book (too new, controversial, and untested) but I may integrate it into our next user research project.
Reader Survey 1
I need 3 minutes of your time for a 4 question survey.
Many thanks!
Application Maps and Frameworks
One of Luke W‘s live-tweets of the Web Applications Masters Tour caught my eye. The speaker, Hagan Rivers, described a technique called “application maps.” From Hagan’s original blog post on it:
When I look at an application I look for it’s hubs. The hubs are the work areas – the place where the user creates things and does things to them. In this application the main hub is the List of Addresses and Groups. From there the user can add an address, edit an address, add a group, export – a whole host of activities. In the end, though, he always returns to the hub when he’s done. In complex applications (one with hundreds of screens, for example) there may be dozens of hubs and their relationships may be complicated.
This description reminded me of my description of “frameworks” — a technique that I’ve been using as a more robust flow chart. A framework is less about how users get from point A to point B (a flow) and more about an application architecture that allows users to complete multiple tasks around a given set of objects (what Hagan might call the “work areas”).
I’d love to see more examples of these–evolutions of flow charts that provide both a sense of navigation (as in Hagan’s example) as well as task completion.
Here’s an excerpt of my draft with a description of frameworks:
Web sites are looking and behaving less like a sequence of pages and more like applications you’d find on your desktop. Through this maturity, we find that typical point-A-to-point-B flows are insufficient for representing the range of features in our web applications. The screens making up our web applications can support more than one scenario at a time. A framework, therefore, is a network of screens that permit users to accomplish multiple tasks, or one task within the context of many scenarios.
With this approach, your flow might look more like a site map–a set of connected screens. What makes it more flow-like, in my mind, is:
- It represents a change of state (eg: the transaction of a donation)
- It has a starting point and ending point, though the framework may capture multiple starting and ending points
- Its connections represent a progression through time, not through a hierarchy, taxonomy, or other series of categories.
The donation flow isn’t a good example for a framework. Though users may all have the same larger objective (helping the organization) the nuances in the flow are driven entirely by the user. Compare that to, for example, programming a DVR to record a television show. While users control many of the settings, there are several other variables that can affect how they accomplish the task:
- where and how they trigger the recording
- what else they have scheduled to record
- and the nature of the show they want to record
Figure 34: A framework doesn’t prescribe a particular starting point, or ending point necessarily, but there remains a sense of progression. The relationships between the nodes aren’t hierarchical in the sense of belonging. A screen that points to another screen isn’t a larger category as it might be in a site map.
Generalizing about this flow, processes that might lend themselves to a framework exhibit many of the same properties.
| Processes that lend themselves to a framework… | For example… |
|---|---|
| have multiple possible starting points for a single objective | When programming a DVR, users can initiate the process by browsing the show grid, conducting a search, or recording the show currently playing. |
| focus on a single objective but can have multiple outcomes within that objective | A “program” can mean a show scheduled to record once, a show scheduled to record in episodes, or record something right now. |
| have variable inputs to the application logic depending on the starting point | Hitting “record” while watching the currently playing show yields specific data points (where, when, and what to record). While starting on the search doesn’t provide as much information as a starting point for creating the program. |
| usually follow a hub-and-spoke model, where the application is structured around a central screen or set of screens | I’ve structured the experience around two main screens: the one describing the program and the one with the schedule of shows to record. There are a number of secondary and tertiary screens, but those two constitute the central structure. |
Telling the story with a framework can be complicated. You need to be able to show how the framework successfully supports all the possible scenarios. For most applications, this is impossible: no amount of research will be able to anticipate all the different situations the application will need to support. That said, research and stakeholder knowledge will be able to anticipate several crucial or frequent scenarios, and these are the ones you should show.
Flow Charts, First vs. Second
So, here’s how the rewrite is stacking up:
| First | Second | |
|---|---|---|
| Words | 11,039 | 15,000 |
| Figures | 15 | 48 |
| Sidebars | 1 | 4 |
| Tables | 0 | 9 |
| Exercises | 0 | 5 |
Excerpt: Flow Charts, Decision Points
Here’s the text for the new section on Decision Points in the Flow Charts chapter. Recall that each artifact is described in terms of the elements that make it up, and those elements are assigned to layers, with the first layer being the essential aspects of the artifact. The second and third layers show increasing depth of detail and embellishment to the story. Decision points are positioned as layer 1 elements of flow charts.
Decision Points
No process is free from conditions. Even the simplest processes require some “if…then” logic to determine which branch to follow. The sample flow tests for the condition, for example, of whether the donor is making a contribution on someone else’s behalf, as a gift.
These conditions are usually expressed as yes-no questions, like “Is the donation a gift?” The typical approach for representing a decision point, the diamond, is suited for branching flows based on the yes or no response.
Decision points don’t usually explicitly represent elements in the interface exposed to the user. That is, the diamond that says “Gift?” next to it doesn’t represent a dialog box in the interface that asks “Is your donation a gift on someone else’s behalf.” But decision points do describe conditions based on some user input. In the case of the sample flow, there is no indication of where users tell us whether the donation is a gift or not, but it is clear we need to collect that information somewhere.
Yes-no (or “binary”) conditions are useful for thinking through the potential branching in a flow, but may not be ideal for communicating the user experience in a holistic way. (See page XXX for other ideas on how to represent conditional logic.) Your use of decision points should be based on the purpose of the flow and your target audience. If it makes sense to represent conditions in this explicit, binary way, however, consider a couple guidelines:
Stack ‘em up: I like lining up the decision points so that the branching logic is all focused in one place. This makes the story more explicit and can help facilitate understanding.
In this flow, we’ve addressed an additional requirement (letting users make a donation in memoriam) and recasted the flow to line up all the decision points. The overall narration of the flow makes more sense: determine type of flow, collect payment information, deal with potential exceptions, offer donation options, and then conclude.
Format decision points the same way: When you start playing with the decision points, you’ll realize the you can phrase them where either a yes response or a no response yields the exception. For example, the condition determining whether the donation is large enough for giving users donation options may be expressed as either “>$500” or “<$500”.
Throughout the flow, however, we have used Yes responses to take users off the main process. Yes answers to “Gift?” and “Planned?” take users to additional screens to deal with those exceptions. Therefore, we formatted the “donation size” decision as “>$500”, for which a Yes answer yielded additional screens.
Some decisions can’t be expressed in a word or two. Having the text of the decision float next to the diamond gives you room to articulate it however you see fit. Don’t even try to fit labels inside the diamonds, even with short questions. The Y/N work nicely in there anyway.
Chapter Exercises: Flow Charts
To support the use of Communicating Design in the classroom, I’m adding a handful of exercises at the end of each chapter. Their purpose: to help people apply the lessons learned from the chapter even if they don’t have an immediate design problem in front of them.
Here are the exercises I devised for the chapter on Flow Charts:
- Create a flow chart for your morning routine, up through leaving your house. Incorporate the decisions you make about various inputs (like the day of the week or the weather).
- Interview a friend or colleague about their work or hobbies. Identify a task and create a flow for a new application to support that task.
- Add a branch to the sample flow in the chapter to support an additional scenario. [I'll be more specific here when I flesh out the sample further.]
- Create a parallel flow to the example throughout the chapter to describe the internal business process for supporting the transaction.
How can these be made more useful? In addition to the basic premise of the exercise, is there anything else I can include to make it a better teaching tool?
Second Edition Underway
The first half of 2010 promises to be busy. Besides my duties as co-owner of EightShapes, a father and husband, I’ve decided to embark on a new edition of Communicating Design. The book is (over)due for some updates.
My highest priorities for the second edition are:
- More examples and illustrations
- Updated content on select chapters, aligning the book with my current thinking on wireframes, flow charts, and other artifacts
- Additional content describing documents beyond the original 10
- A new chapter on creating meaningful narratives with your documents
I’m starting with Flow Charts. Admittedly, I haven’t read the chapter in years and my initial pass yielded some cognitive dissonance. On the one hand, I was pleased to see how much I could embellish and add to what’s already there, and on the other I’m incredulous at how much I can embellish and add to what’s already there.
My process so far has been organic, just reading the chapter and marking where I’d like to add or remove content:
Chapter on Flow Charts, marked up
In parallel I’m sketching out the sample flow I’ll be using throughout the chapter to illustrate the points:
Rough sketches of sample flow chart
Those chapters getting the biggest revisions will have more robust illustrations. I’ll be using a single example in the chapter, allowing me to explore different ways of addressing the design challenge.
