This post was written for UW's HCDE 517, Usability Testing, in response to one of the course readings
Personas: Practice and Theory, a 2003 paper by Microsoft's John Pruitt and Jonathan Grudin, describes the persona creation and utilization techniques that their user research team derived in part from Cooper's well known persona process. Pruitt and Grudin first make a case for their method of persona development, describing both its inherent advantages and the success to which it has led their team, then deconstruct the steps in their process to highlight some of its unique features. They conclude by discussing the benefits and risks of persona techniques, then comment briefly on the theory behind their success.
The authors' method focuses on thorough and continued data aggregation, as well as the power of their personas as a communicative tool deeply integrated throughout their development process. While certainly recognizing personas' ability to focus designers and aid in design justification by grounding the otherwise-abstract user base in realistic characters, they argue that personas' greatest utility is in establishing a common and shared reference for communication across the entire team. To develop the best personas possible, they particularly focused on making sure their characters were more believable, better communicated, more actionable, and better supported by management – qualities that were historically deficient in other persona development efforts. Ultimately, after a rocky first attempt, the team found their stride, firmly establishing their persona-based approach among the team and even receiving requests from company executives for further efforts.
Pruitt and Grudin provide a description of their process, and while it doesn't stray too far from typical persona development processes, they include several points worthy of mention. They describe that they collect as much existing market and user research as possible with which to build a basis for their personas, in contrast to Cooper, who seems less interested in ongoing data collection. They create "foundation documents" – available to their entire development team – that contain numerous details about each persona, focusing particularly on connecting characteristics to specific data points. In an effort to raise awareness and especially mindfulness of the developed personas, the research team bombards the rest of the team with (surely costly) internal promotional materials that are designed to be fun or interesting, such as posters, educationally-decorated swag, and fictional email campaigns. To drive home the point of their extensive use of personas, the authors include several examples of these personas being applied across multiple product development tasks. For example, when prioritizing features, the team uses a feature matrix weighting the utility of each feature with the importance of that persona as a potential end user.
Next, the authors discuss both the benefits and risks of their persona approach. In general, they received very favorable reactions to their integration of personas throughout the development process and note a significant increase in awareness across the organization. They feel that it gives a much more relatable basis for communication in that team members can use the personas to refer to an individual they feel like they personally know. On the other hand, they are careful to note that personas are not without their risks. In particular, they highlight the risk that persona advocates become overzealous, wanting to use personas to answer every user research question and foregoing other user-centered design techniques. They also advise careful consideration in deciding to re-use previous personas, a practice that can lead to inaccurate portrayals of users for different situations.
Finally, the authors touch on the theoretical basis by which they believe personas to work. They emphasize the theory of mind, or the capability of humans to empathize. Personas allow empathetic individuals to extrapolate the characteristics of the representative users, while other techniques like scenarios merely let individuals interpolate within their respective bounds. They also make a comparison to method acting in describing the extrapolation of characteristics, highlighting the effectiveness of such immersive techniques.
My reading of Pruitt and Grudin's paper wasn't without doubts. For example, in contrast to Cooper, they emphasized that they turn to heaps of existing user and market research first instead of beginning with their own research. I'm hesitant to support this technique of gathering existing data because it seems difficult to be able to confidently rely upon data whose collection may have been for an entirely different purpose; I would be concerned that the data might be shaped by its original intent. It seems possible that researcher bias might bleed through, especially if the persona team starts from research findings rather than raw data. Another concern is the thoroughness of the personas, even going so far as to try to link every persona characteristic to a specific user quote. While admirable, the amount of effort involved seems superfluous, especially when teams are trying to meet deadlines.
Despite my hesitations, it's clear that the authors are adamant about the strengths of their persona process, and perhaps rightly so – personas are deeply ingrained in their team's culture by way of extreme immersion. I imagine many teams would aspire to attain the same level of commitment to personas, but it sounds like a lofty goal. Microsoft has pockets far deeper than other companies, especially since they embrace user-centered design, but the expensive and time-consuming nature of this level of integration doesn't seem to be worth the effort for leaner companies. The authors' efforts call to mind the Pareto principle, or the approximation that 80% of results are obtained by 20% of the expended effort. I have to question whether going above and beyond the more conventional persona processes would yield a high enough ROI to justify what I perceive to be a much greater effort. Would smaller companies exhaust their resources just to secure that theoretical remaining 20%? Is a traditional persona approach ‘good enough' in the sense that it gets teams most of the way there, certainly farther than they would get without any user-centered practices?
Having said that, I think there's still something to be said about the fact that the team found something that has been remarkably successful for themselves, a result that is surely much more important than abiding by someone else's prescribed persona process. Perhaps the more important takeaway is that, like Pruitt and Grudin, research teams need to identify shortcomings of standard approaches in the context of their own team, then evaluate options for improving them. Getting the entire team deeply ingrained with personas through promotional material and email campaigns may not be feasible for many smaller companies, but design teams of varying sizes can certainly use the lessons described in this paper to begin developing a work culture that is more enthusiastic about and mindful of personas.
- How might teams with smaller budgets adapt their intensive process? What corners could they cut to get the same results?
- What did you think of the Feature x Persona weighted matrix as an example of applying personas? What might its strengths and weaknesses be?
- How else could personas be applied beyond the examples (like the matrix above) that they described?
- Are there any parts of the product development cycle that wouldn’t benefit from personas? Why?
- Could a persona-based approach ever detract from a team’s efforts?