As one component in a customer data gathering project that involves many on our team, Pat Litherland and I are working on a task to create Windows SDK-specific personas that represent our customer base in future planning activities. With over a million downloads of our SDK for Vista and .NET Framework 3.0, we have a huge customer base engaged in vastly different development scenarios. By designing for an archetype whose behavior patterns and goals are understood, we hope to satisfy the larger group of developers represented by that persona.
Persona-based design is just one component of our development process. Our best information comes directly from real users and our overall customer data gathering project is looking at many different ways we can we incorporate more direct customer involvement throughout the engineering process. We’ll use personas to complement, not replace, a full range of quantitative and qualitative methods covered in our overall plan. We’ll be sharing more on our customer data gathering project in the future, and want to hear your ideas and input about how we can best create and validate user abstractions.
The persona wheel has already been invented many times at Microsoft. The use of abstract representations of users originated in marketing, but Alan Cooper, often called the father of Visual Basic, was the first to use personas, their goals and activity scenarios in the design phase.
Pat and I talked about leveraging the existing DevDiv personas. In Developer Division, we have developed three main personas that represent the developer role. These personas were developed through on-going interactions with our user community and carefully refined over time. These personas appear in specs, designs, emails, conversations and posters in the hallways and help us see scenarios through the user’s eyes. It would be handy to use the famous DevDiv personas when talking with others groups. We all get a clear picture of that user type as soon a persona name is mentioned. But Pat and I agree that the SDK personas will need to be specific to our design problem if they are to be truly useful. We need personas that are context-specific, focused on the behaviors and goals related to the specific domain of the Windows SDK. As Alan Cooper, says in The Inmates are Running the Asylum, “personas are defined by their goals and the goals are defined by the personas…” We’re starting from scratch in defining our users’ goals and will develop personas from those goals.
For an in-depth explanation of how personas are used at Microsoft, Personas: Moving Beyond Role-Based Requirements Engineering by Granville (Randy) Miller and Laurie Williams is an excellent place to start. This research paper explains how and why personas were developed and used in DevDiv, and provides a very complete reference section and this persona template:
Microsoft Solutions Framework Agile Persona Template
· Name – Enter a respectful, fictitious name for the persona.
· Status and Trust Level – Favored or disfavored and level of credentials.
· Role – Place the user group in which the persona belongs.
· Demographics – Age and personal details optional Goals, motives and concerns.
· Knowledge, skills and abilities – Group real but generalized information about the capabilities of the persona.
· Goals, motives, and concerns – Describe the real needs of the users in the user group represented by the persona. If multiple groupings exist, write a persona for each grouping.
· Usage Patterns – Write the frequency and usage patterns of the system by the persona. Develop a detailed understanding of what functions would be most used. Look for any challenges that the system must help the persona overcome. Note the learning and interaction style if the system is new. Does the persona explore the system to find new functionality or need guidance? Keep this area brief but accurate.
John Pruitt and Jonathan Grudin of Microsoft Research published a great paper on the psychological theory behind why personas are more engaging than design based primarily on scenarios, and how personas can engage team members very effectively. Personas: Practice and Theory describes two projects at Microsoft in which personas were to help a team identify and understand its target audience as well as aid in design and development decisions for a specific product release.
Pruitt and Grudin discuss how humans use partial knowledge to draw inferences, make predictions and form expectations about the people around us, and learn from our misjudgments. Personas invoke this capability and bring it into the design process. Once engaged with a well-drawn persona, we can easily project them into new situations. Fiction has a power to engage. A fiction based on research can be used to communicate well. So why not just use real people? Using a real individual excludes or complicates the use of other data, from usability testing, market research, etc. Team members need to recognize that a persona represents a group of people.
We hope that our personas will do more than just help us focus our design efforts. We plan to use our personas to provide a shared basis of communication to help us really get inside the heads of our users. We’ll keep you posted on our progress.
K a r i n M e i e r
Windows SDK | Samples & Community PM