Knowing who will use your software is important to the software development process. Having the end-user in mind helps you develop features that fit the user's needs. And, figuring out your end-user, as Jeff Patton reveals, is indeed easy. In this column, Jeff details stereotypes to avoid, questions to ask, and how to implement this pragmatic persona in your development process.
A "persona," when used in software development, is a simple, valuable, concrete example user of your software. Here, I explain how to create pragmatic personas quickly.
You are Not Your User
"You are not your user" is the cautionary mantra used by people who do user-centered design work. It's a good one, because it's so easy to ask yourself what you would like when making choices about features to put in a product, as well how those features look and behave. "Self-substitution" is the most common trap we fall into when making software functionality and UI decisions.
The next most common trap is simply asking users what features they want and building them. That story often ends with users' getting what they asked for and still not being satisfied with the product. The software team then grumpily complains that the users "always change their mind" or "never know what they want." If your user community is sufficiently large or diverse, you're likely to get many contradictory messages when asking users what they want.
Ultimately, we as software professionals, equipped with an understanding of what software can do and how to build it, should be making some good decisions about what software to build based on understanding what users really value.
That's where the idea of a persona comes in.
A persona is an example of a specific user written into a document whom those making choices about the software can use to evaluate decisions about software features. It's not based on one user, but a synthesis of information about many users. So, even though a persona may look like it's describing a real person, that person is fictitious. Having this fictitious person helps us not get hung up on ourselves as the user or any single user's opinions. It's a neutral "design target"-the person we're trying to satisfy. The hope is that making this persona happy will result in making all people like the persona happy.
While it is true that personas should be built on rigorous research, this notion is exactly what stopped me from making good use of personas for many years. I used to get hung up on the term "research" because it sounds science-y, and I'm not. I later found that the great deal of time I generally spent talking with users and watching them work counts as research. There are more rigorous ways to plan, execute, and make sense of research results—all ways are valuable—but, at minimum, it's good to observe users first hand.