The End of Catch-All User...

When I last picked up the The Inmates Are Running The Asylum, I was agreeing and disagreeing with Chapter 8, but now for Chapter 9, it continues off where Chapter 5 left off. In Chapter 5, we were talking about how it is important to design the software for desirability, but it did not provide a lot of substance on what to designed.

To create a successful product to be consumed by the masses, it is believed that you must create an application that has broad functionality as to meet everyone's needs. Alan Cooper's example product is of a vehicle, in which he describes three groups of people to satisfy. The first group is the mom's, which want a big, spacious, safe, and reliable vehicle; the second group is the carpenter, who wants a durable, spacious, all-wheel drive vehicle; and the last group is the executive, which wants a sports car. The problem is that if you try to create a vehicle that is a van, a truck, and a sports car, chances are that you will not please any of the groups. This reminds me of Eric Carle's The Mixed Up Chameleon, in which the Chameleon becomes a little of this and a little of that, but finally cannot catch the fly.

And so it is with products. If a product is too generalized for too many people, chances are that most people will not be satisfied with it, partially because it does too many things and is too complex. Instead of trying to please everyone in the world, Alan recommends that we limit our scope, because each function that is added to software will please some, but can act as a speed bump for other users of your application. In other words, to achieve 50% product satisfaction, you cannot do it by making all of your users 50% satisfied. Instead, you should limit the target, design especially for this group, and aim to make them 100% satisfied.

Some examples of this exist; Alan points out how the roll-aboard suitcase was originally targeted towards airline flight crews, and once proven in that target area, it expanded until today, when it is difficult to not have wheels and retractable handles on luggage. Another example that Alan points out is Art Fry of 3M, which designed the Post-It Note to solve his problem of paper falling out of his church choir book.

Software sometimes seems like a different beast than these, but it really is not. The recipe to success that Alan Cooper's design firm, Cooper, uses is incredibly simple: goal-directed design. Goal-directed design begins with the starting point of “developing a precise description of our user and what (s)he wishes to accomplish”. More specifically, this simple recipe focuses on two things, first the users and secondly the goals of those users.

While the obvious solution here is to simply ask your users what they want, this does not work, because users do not always know the solution of their problems. Instead, Alan recommends creating personas (or, personæ if you prefer), which, while not real people, are created based on product research and are created to be precise and rigorous. Alan even recommends that you give the personas a name, picture, and some personal details. They have jobs, cars, family, etc. The goal is to make the persona a believable person that design decisions can be made based on.

The problem with software development is that we generally have this elastic user. Each developer has a vision of what the user's abilities are and what they want to accomplish, but this vision is not shared, or precise. This imprecision leads to a two problems: software being developed for two completely different people, both of which will probably not be satisfied by the product, and worst, people on the project can easily choose what they want to do based on what the “user's interests” are, but as these are not really defined, these people suddenly becomes the user (another case of the self-referential design).

By giving more detail to a persona, the elasticity is lost, and we can start to identify skills, motivations, and goals. Alan argues that personas are better than real people because real people have anomalies and quirks that interfere with the design process and do not extend over a population. Because of this, it is more important that a persona be more precise than accurate, since the precision will prevent the persona from become an elastic user.

The personas are created by talking with the various people involved in a product. During the discussions, the similar skills are grouped together and a persona is created with the important information. Design personas should not be confused with marketing personas, which are based on demographics and distribution channels. Likewise, it is very important that this is based on the user persona, and not the buyer persona, as the purchaser will be more satisfied with the product if the users are satisfied with the product. When users are satisfied with a product, they talk about the product, and other people will at least know about your product, and this helps builds customer loyalty.

Many personas will be developed, but it is important to identify some primary personas that must be completely satisfied. Alan warns, however, that in his experience, each primary personas is a different interface, and therefore, if you have more than three personas, the goal that you are trying to reach is much too large, and defeats the purpose of using personas to begin with.

I find the personas very similar to a UML Use Case Diagram. In general an Actor (which Martin Fowler describes in UML Distilled as mistranslated from Swedish, and should have been Role) could become a persona, and only those use cases that the target personas use are implemented. Presently the Actor is given a generalized name, such as the “user”, instead, one could use the persona name instead.

Jim Fawcette recently indicated that Visual Studio 2005 is a creative departure for Microsoft, indicating that this is one of the first time that Microsoft has designed for a target group. Maybe they used personas. Maybe they did not. But making a target group extremely happy is a great idea no matter how you get there.