Why it matters:
- Personas are currently receiving a lot of attention; is the attention warranted?
- How can contextual data be used to create personas?
- How would personas fit with the Contextual Design process?
Recently I participated in a conference panel discussing and comparing methodologies. As a group we represented a variety of user-centered methods like scenarios, story-based design, goal-directed design, usage-centered design, and of course Contextual Design. Among other questions, we were asked what approaches we would steal from the other methods if we could. Personas were the technique of choice.
Personas, introduced by Alan Cooper, are a technique of goal-directed design that is meant to help designers gain clarity and provide focus during the design process. They describe the goals and activities of archetypal users in a 1-2 page description based on a few ethnographic interviews with real users.
Aside from the fact that personas are a current design trend, what makes personas interesting? Certainly they are seductive to design teams since they can be quick to create if they only require a few (2-3) interviews and a good writer. But good designers and managers know that reliable requirements gathering and design that meets the needs of the business, the market, and the user is not so simply constructed. So something else must be going on.
Personas Can Help Set Focus
Before a Contextual Design project we set the project focus. Too often a team defines the project focus as “getting the application onto the Web,” or “getting requirements for the next version of the product.” But the project focus is about what types of work or life practice a team wants to support with technology.
Setting project focus means defining:
- Who the players are that will be supported
- What the key activities are that need to be supported
- The overall scope of change that the team is willing to make
We set project focus based on talking with the design team and other stakeholders about what they already know about their users, what they suspect about how their users work, and what the business requirements are for this product. We use this starting point to decide whom to interview. Through the interviews themselves we refine our knowledge of the players and activities.
Insofar as personas help the team concretize the players and activities, they will help the team know what matters and what does not for the design. If the team does not know their users well, doing a little fieldwork and then defining the persona will again aid this first design step.
But personas do not seem to address scope. The team must know how out-of-the-box the team and the organization is willing to go. Is this shipment planned to be a user experience fix release? Do they want to identify 1-2 key feature sets to add? Or do they want to think of where this product or market segment could go if they took a wider look at the whole work practice? If the team doesn’t know what their business goals are, and how extensive the re-design can be to fit with their organization and delivery goals, they will not be able to design the right thing.
Personas Communicate
In Contextual Design we recommend putting together cross-functional teams to gather the data first hand. That means marketing, product management, engineering, UI design, user experience professionals, documentation writers, and so on will all have direct experience with the people they are trying to support. When that data is consolidated all members of the team have had direct contact with the users they interviewed, and they have been in interpretation sessions to hear stories about the users. Later looking at the consolidated data brings back the memories, and brings the models to life. The consolidated data now pulls together and focuses these stories so that the team can think about what the full user population needs, not just the individual.
But what about people who did not collect the data? What about managers who need to hear about the data? What about new team members, developers, or UI designers who are passed the data to design from? What about reusing the data by other corporate teams who never saw the data? And what about design firms like InContext that delivers data and designs to their clients?
Here we use personas to bring to life the key types of users in the customer population being supported. As such, they mimic first-hand experience for people who don’t carry the images and an understanding of the users because they did not collect the data. We recommend building personas from consolidated contextual data so we can create a rich description of the people, their activities, their values, their locations, and their things. Together with the full contextual data, personas form a strong basis for understanding requirements and focusing visioning and design conceptualization.
Build Personas with Contextual Design Data
Contextual data is a natural raw material for deep, rich personas that reliably reflect the archetype characters that make up the market being supported. By collecting enough data to really characterize the market, not just 2-3 interviews, your persona characterization will be a more complete representation of the people and issues you have to design for.
As archetypes, personas represent neither job titles nor roles as identified by Contextual Design’s flow model. I think of personas as job title slogans, collecting together standard patterns of job responsibilities that occur in the activities of people who have a generic job title. For example, when we studied developers and IT professionals, we identified the Hybrid Developer: an IT pro who both coded and supported applications in his organization. Hybrid Developer is not a real job title, but like traditional marketing characterizations of customer populations, the slogan evokes defining characteristics of key players in the market.
Once we define the persona we characterize their activities with contextual data. We use the consolidated data to drive these descriptions. For example:
- Roles and responsibilities from the flow model
- Tasks from the sequence model
- Values from the cultural model
- Issues from the affinity diagram
Because the consolidated data comes from actual people we can write up little stories or attach videotape clips of the actual users behind the persona to make it real. Since we deliver all our data online, if our clients get interested in having us develop full persona description we can link the persona description to the actual consolidated models and original data. In this way the persona becomes another way to access and structure the data
Contextual Design is a Process Backbone
Personas are now popular and people think they want them. They are one technique, just as usability testing is one technique or creative brainstorming is one technique. Throughout the history of software development people have created techniques that address a part of what is needed to do good design. One value proposition of Contextual Design is how techniques are organized into a practical way of working. As such, teams can add or take out steps depending on the need of the project.
Different techniques emphasize different aspects of the design process. Contextual Design has a step for setting project focus and personas can augment that step. Contextual Design uses the consolidated work models as communication devices and personas can augment that. And personas can provide quick overviews and windows into complex data.
Because Contextual Design is a design process scaffolding, it is robust enough to include new techniques and replace existing techniques without losing its coherence. So teams who want to use personas can still be guided through a customer-centered design process that works for the team, the organization, and the users.