This entry is about using imaginary friends to help you develop better software.
I am reading “The Inmates are Running the Asylum” by Alan Cooper. It is not a new book but the particular parts that I am interested in are as relevant today as they were in 2004. Specifically, Cooper’s premise is focusing on “who” we are developing software for as the quintessential component of the design process.
The key tool is the development of personas. A persona is not a real person but is representative of a specific type of user for the product. The idea is to build a picture of a typical user in a specific role. Depending on the software you are building, you might end up with personas for the end user of the product, the system administrator, the IT coordinator and a C-level person.
For each of the personas you will describe them as an individual; the personal traits, age, marital status, their career path, their work goals. Cooper says that it is more important to be detailed in their description than it is to be absolutely correct. I think that the idea is to build out an image of a real person, even if that person is not absolutely indicative of the target user.
Having built them out you need to select one to be the primary persona. This is the user whom you will satisfy above all others. The general premise is that if you can meet 100% of one user’s needs you will be successful. This might seem counter-intuitive until you think it through…if 100% of your users get 30% of what they need then they’ll all be unhappy. If 30% of your users get 100% of what they need then they will love your system and will be on your side when evangelizing the use of the system. Remember, giving 30% of your users everything that they need does not mean that the other 70% get nothing at all.
Before we address how to use this practically let’s just address something that I found particularly difficult at first…the voyeuristic aspects of creating personas…
The Personal Lives of Fictitious People
The idea of building out all of the personal, seemingly superfluous, details of each persona seemed odd to me at first. In fact, in my first attempt I added comical traits and odd peccadillos rather than realistic hobbies etc. My British cynicism stopped me taking this seriously. However I realize now that the reason for adding non-work-task-related traits is to bring the personas to life. It is much easier to imagine a fictitious person’s wants when you can identify with them. It’s harder to identify with the one-legged, kite-surfing, amateur-def-poetry-reciting, head of cloud services that I described.
Practical Application
If you only did one thing with the personas it would be to stop anyone on the team using the word “user”. Have a swear jar for each time anyone says user(s)…instead be specific. Say “Bob” or “Doris”.
Why? If I say “a user might want to approve the requisition from a mobile device” then it is hard to argue that this is not realistic. It is true…some user, somewhere, sometime will want to approve something from the 10th hole. The question is whether your primary persona, the person you are designing for would. If Bob represents a customer service function and is desk-bound in a call center then Bob has no need to have a mobile interface. The fact that other ‘users’ might want to is irrelevant.
With a clear primary persona you can have a well-formed discussion with the team without arguing your position – you are arguing Bob’s position.
There are two specific and related things to watch out for when assigning wants to a persona. 
1. The first is what Cooper calls “elastic users”; in this case, you are “stretching” what the user might want. This might be because you really want to add something to the design and are trying to convince everyone that the primary user would want it. It might also be because you have not fully formed the user and there’s some wriggle room around their wants, needs and desires!
2. The second is building for the non-primary personas. It is OK to design something that a non-primary user might like but only if the primary user needs it.
I struggle with the second, supposedly immutable rule. It seems like there are a lot of times that a feature might appear to make a product easier to sell, easier to manage, easier to integrate, the feature might meet an internal, strategic initiative. If your primary user is the end user then they may not care about any of these but as the product owner it is hard to resist temptation to add “just one more” of this type of feature.
Authors typically write in absolute terms (or should I say that they always write in absolute terms) but really the personas should be a guiding principal not an immutable truth. As a tool to get everyone focused then I think that personas are very valuable.
Bottom line, I’d commend the use of personas across the entire R&D team to any software (or hardware) developer.
Comments