Personas are commonly used by analysts in collecting requirements for building new software, so that the essence of the needs of different users can be distilled and transferred to a group of developers who have never had contact with those end-users. A persona is a profile for a common type of user the software is catering to, and tries to embody not just the fixed requirements (it must calculate my travel expenses exactly), but also the experience, personality and working practices of different types of end user (the software needs to be used by my dad, who types with two fingers, occasionally, but still manages to book vacations to far-away places online).
Personas allow an analyst to engage just a little right-brain creativity to the process of requirements gathering, by writing a fictional biography of the type of person being targeted by the new solution. The bio (always accompanied with a stereotypical photo snagged from some website or other) adds a human element to the requirements, which is supposed to help people understand not just what the requirements are, but why they exist, who they relate to, and how.
Wow, you might be saying to yourself. Those software guys are smarter than we thought. We just assumed that software was churned out by a bunch of geeky hackers sitting in a room, surrounded by glowing monitors, half-empty pizza boxes and Diet Coke cans. Well, appearances can be deceiving, and you may walk past a software developer on the street without realizing that he fits the geek profile, but most of the rest of it is true. The real nuts and bolts software does come out of some creative juggling of code. The personas are just there for the analysts and product managers to believe that they are transferring some additional useful information to the software developers. In fact the personas are just giving the analyst a creative outlet for the fact that they are supposed to NOT suggest a solution to the requirements they are writing, for fear of limiting what is produced by the developers. Yes, the developers are really going to come up with a better solution if you don't restrict what they produce!
Perception is clouded by experience. We can't expect the personas, the human faces we add to our requirements to be meaningful to anybody who does not have experience in what we are trying to explain. We need somebody with experience of business requirements to translate. That person, and I would hate to give them the title 'Usability Expert' knows enough of what the personas really represent, and enough credibility with the software developers, to be able to bridge the gap and state in solid terms, "put a single text box and a big button on the screen that says Search". Nope, the persona with the picture of my dad, and a bio discussing how he plays golf on weekday mornings (because its cheaper) and types with two fingers, did not result in Google. It just took a very creative 'somebody' with some profound creative thought to say, "this is how we are going to make web-search usable by the masses", and enough credibility with the software developers to convince them that it was worth the effort of writing extra code to make things easier for the end user, and that they wouldn't miss all that other stuff that was previously just cluttering up the screen.
So personas have been absorbed into the marketing of software more successfully than the building of it. Therefore I'll suggest that we should not use those picture-profiles of our intended end users as a cover for the fact that we have no real idea what will work for them. Two options remain: make lots of excuses and just accept that we are going to have to do a lot of training of our end users, or; get ready to refine our software a lot after we release it and start getting feedback from end users on how much it sucks!
A post from the Improving It blog
Let us help you improve your business today. Visit www.consected.com
2 comments:
I agree with your assertion that personas do not magically translate into an effective user interface. However, from my perspective it appears that you are frustrated with personas because your company is not using them appropriately.
In most companies, the analysts that you refer to are not 'usability analysts,' but rather 'systems analysts.' They create use cases and define requirements to make sure the software will fulfill the needs of target users. They are not designers and should not be designing the user interface.
Developers should not be designing the UI either though. Very rarely will you find a developer that has had any usability training. It's not necessary for the tasks they should be focusing on; that's why they are called developers and not designers.
So, if personas are being passed to developers in your company, then your process is broken. You are skipping the design phase. When used properly though, personas *can* be helpful.
Hi Brien,
Thanks for your thoughts. I think they are valid. It is interesting though that the product management school of thought does not really differentiate between developers and UI designers. The most appropriate roles need to be added into the mix as needed when it comes to developing a product (software or otherwise).
Interestingly, you spotted my frustration. It is more based on previous experiences and companies than the current one (I'm the owner of the current one, so wouldn't put up with stuff that is not working).
Either way, there are times when personas should be passed to developers, since they can help come up with different solutions that we would not have otherwise considered. But when it comes to user experience, we need a mix of talents.
Thanks again for your thoughts.
Phil
Post a Comment