Content area
Full text
Taking the time to solicit feedback from future Web site users on functionality issues is something we know we should do, but too often, we simply don't. We know that Product Development 101 is all about talking to potential users, regardless of whether we're building enhanced Web-based functionality or a new printer.
However, few of us fully engage in the planning phase required to get to an in-depth understanding of the specific needs and characteristics of typical users. With the product end goal already in sight-that new bright and shiny intranet site-we rush to confirm what we think we already know about our users, or we decide on what we think they want. The result is a product that may work for users who resemble the Web site development team, but may not address the nonobvious needs of other users, including those for whom the product was really intended.
Why do we shorten or sometimes even skip this most important planning phase? Perhaps it's because we lack a formal methodology to elicit this type of input from our users, analyze the findings, and then plow conclusions and insights back into the product during development. That's where developing personas may help.
Traditional product design relies on generating a long list of user requirements based on customer feedback. Including enough users to ensure a representative sampling of user needs is a problem with this approach. In addition, once a list is developed, how is it prioritized? In my experience, user needs are often informally collected (if at all) and then prioritized by the project team.
More formal approaches have members of a product advisory group (who may or may not include actual product end users) voting to prioritize requirements. This method relies heavily on individual customers vocalizing their needs, likes, and dislikes. Basing prioritization on the old adage, "The squeaky wheel gets the grease" is not the most effective way to guide product design and rarely represents the needs of specific subsets of a target user community.
USING PERSONAS
Persona-driven design does not attempt to generate a laundry list of requirements based on hundreds of interviews. This design approach identifies prototypical users and looks at each as a unique entity. Each persona acts as a composite to...