November 15th, 2007
Yesterday, I gave my Virtual Seminar on Building Robust Personas in 30 Days or Less. If you missed it, you can watch it on demand.
The session went well, but we ran tight on time and I didn’t get to all the great questions. Brian and I were just talking and we’re planning a followup podcast on some questions.
Meantime, one attendee, Pamela, couldn’t wait to ask me some of her questions. Here they are and my responses:
Do you have tips on how to convince subject-matter managers (decision makers) why you have adopted personas and what the benefits of using them are? The use of personas as a methodology for the creation of new products is a new concept for [our organization]. This is my biggest challenge at the moment.
My first reaction is to avoid trying to convince anyone of their benefit. If the “subject-matter manager” (a term I’m not completely familiar with) believes they know everything there is to know about how users will use the product, then there is probably nothing you can do to convince them otherwise.
Instead, I’d look to finding someone who is feeling pain because they are discovering they don’t know everything they should’ve known, usually because users aren’t reacting to the product’s design they way they’d hope. Typically, when you have a poor experience, it reflects somewhere in the organization’s bottom line (lost revenue, increased expenses, and work being redone are just a few symptoms). Find the person responsible for reversing those bottom-line effects and you’ve got your champion for doing something different.
I wrote about this in more detail in The Cost of Frustration.
Is the use of personas useful for product review? Alan Cooper tells us that throwing away original code/design is unlikely. Therefore, what is the best option for reviewing products that were not originally designed with user goals in mind?
One thing you can do with a set of well-defined personas is walkthrough the design and role play their behavior. (“How would Mary respond to this question?”, “Is Pierre likely to remember his password at the login screen? What if he doesn’t?”) This can quickly point out many potential risk areas on the current design.
It can also help you argue for more usability testing. When a walkthrough shows many potential risks, usability testing with people who match those riskiest persona types will likely yield a ton of insight into the design and potential improvements.
Given that the gap continues to grow between the power user and the non-technical user, will the power user in your opinion become growingly frustrated by having products primarily designed with the non-technical informant in mind?
For most scenarios, there is little use between what is referred to as power users and non-technical users. They will be happy with the same designs.
What we typically mean when we talk about the difference between power users and non-technical users are two things:
1) The power users have very different current knowledge — they know more about the tool and its usage. (More about this in my article, What Makes A Design Seem Intuitive? and a Virtual Seminar on the same topic.)
2) The power users may need an interface that’s optimized more for efficiency than learning.
In these cases, developing personas for your power users may be an important tool. It’s often possible to create designs that adequately service both types of personas (but not always). Having both types covered in two (or more) separate personas will help experiment with potential designs and keep the team’s awareness of the distinctions.
In the set of questions developed for ethnographic interviews (Stage 1 of your seminar [conducting field interviews]), is it important to include questions asking informants what their user goals are and what their vision of the perfect product description is? Or, are these questions answered by the design team based on final persona descriptions (Stage 3 [Building the Personas and Scenarios])? Having a vision of what the final product will look like prior to product development, I would think, would be beneficial to serve as a benchmark for product developers who will be able to determine when the product is “done”?
User’s goals have to do with their personal and business needs. For example, a user may be tasked with keep track of changes in consumer purchasing patterns, so they can inform their organization’s strategic planning committee on shifts in the marketplace. Their goal may be to someday be part of the that committee, so accurate data collection and projections are a key part of their needs.
We’ve found it’s not useful to ask them what their vision of the perfect product is. At best, they can only tell you what they have seen elsewhere. (If I were to ask you what improvements you’d like to see in cars coming off the production line in 2012, what would you tell me that wasn’t part of today’s existing technology or some part of popular science fiction?)
Instead, you want to watch them do their work and learn about their goals. From that, you can figure out a vision on how to optimize the user experience to better meet their needs. You know what the technology and team’s potential are — you can match that to the needs you observe.
Also, I’d like to suggest there is no such thing as a “final product” (unless the entire development team is going to suddenly die or quit). Once developed, products continue to live on in one form or other. Therefore, you can’t have a vision of a final product.
You can, however, have a vision of what the product will be in the future, say 5 years from now. That’s an extremely useful exercise to help the team focus and understand what the short-term priorities should be.
I’ve written about this in these places:
We’ll post more answers to the great questions we received shortly. Stay tuned.Tweet