Just imagine yourself taking part in a lively discussion at some birthday party. Everybody is telling great stories about recent holidays. We ask some polite questions and at least pretend to share the same excitement. What’s wrong with it? Honestly, may not be much as long as everybody likes it. But this shouldn’t happen when the business owner explains the development team what he wants to achieve, what he needs. Unfortunately, too often the opposite is the reality. A thick fog remains, causing the business owner to feel understood (while that’s not necessarily the truth) and the developers being happy, because for some time they won’t be bothered. But how to clear, or even better prevent, the fog?
This post originally appeared at Goyelloblog. View original post.
Article Contents
How to notice the fog
The above might sound a bit black and white, but I’m afraid it happens more often than we would like to admit. We see it frequently happening in all kinds of companies, from small up to big ones. Sometimes, it’s even hard to notice it at the first sight. While taking part in such a meeting everybody seems to understand each other. Unfortunately, meanwhile you can feel something is going not quite all right.
Then, all of a sudden it becomes clear that not everybody is talking about the same thing. A definition appears to be completely differently understood.
And if this happens once, then it’s in general applicable to more definitions.
The fog is there and hopefully you have already noticed it , because otherwise it can cause dramatic accidents.
I believe this is one of the main causes of software projects failures. We think we understand each other, but cannot be sure about it.
Then it’s high time to ask questions!
Preventing or clearing the fog away
As mentioned before, it’s too often that we rely on a common understanding of definitions. But it’s not fair to believe that everybody understands the same when you define “For a user it has to be easy to find information about a product at our webshop”. Just some questions I would like to raise:
- Who’s that user?
- What kind of person is he or she?
- What kind of information might this user be looking for?
- Do we all know what web shop we are talking about?
- Etc….
A lot more questions could be raised and without the answers the fog won’t disappear.
From the experience we know it’s hard for users, business owners and developers to express what they (think) are looking for. We tend to use unclear verbs, assuming the others will understand what we mean.
Especially in case, when I do not fully understand the client’s business and/or needs, I request them to paint me a (virtual) picture of their world, because a picture paints more than a thousand words.
To do so, we have among others, already successfully used the personas method for several times. In fact it’s one of the default tools in our tool kit.
Visualizing who and what we are talking about by means of personas
A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype — whose goals and behavior patterns are well understood — you can satisfy the broader group of people represented by that archetype. Using personas prevents a lot of noise (fog) caused by personal preferences of the team members involved in the design process. If you want to start now we advise you to read this valuable introduction to personas and how to create them.
If you want to know more, there are lots of resources available, particularly the work of Alan Cooper and colleagues at Cooper Interaction Design. Alan is credited for having created the first persona for software development purposes back in the early 1980s.
In most cases, personas are synthesized from a series of ethnographic interviews with real people, then captured in 1-2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details (i.e. name, gender, age, hobbies, picture) to bring the persona to life.
It’s easy to assemble a set of user characteristics and call it a persona, but it’s not so easy to create personas that are truly effective design and communication tools. If you have begun to create your own personas, here are some tips to help you perfect them.
Introducing personas into your software development project will bring a number of benefits:
- Users’ goals and needs become a common point of focus for the team
- The team can concentrate on designing for a manageable set of personas knowing that they represent the needs of many users
- They are relatively quick to develop and replace the need to canvass the whole user community and spend months gathering user requirements
- They help avoid the trap of building what users (or even worse business reps) ask instead of what they will actually use
- Design and development efforts can be prioritized basing the personas
- Designs can be constantly evaluated against the personas, reducing the frequency of large and expensive usability tests.
Just give it a try!
Having some experience with the personas method, I must admit that at a certain moment the personas become close to living people. The whole team communicates talking about John, Lucy, Martin and Mary. And the good thing is that everybody instantly understand what we are talking about. Definition issues seem to disappear like snow in the sun. And when the sun is shining fog won’t have a chance!
Do you have any experience in using personas? If so, please share your opinion with us. What did work best for you? For sure personas are not the only method you can us to improve your design processes, there are many other (agile) methods. Which ones do you prefer?
