Workers in warehouse from Shutterstock.
Before embarking on any intranet or website design project, it is important to understand the needs of your users. It is then possible to identify the features and functionality that will make the intranet or website a success, and how the design can support users with different goals and levels of skill.
There are many ways to identify the needs of users, such as usability testing, interviewing users, discussions with business stakeholders, and conducting surveys. However one technique that has grown in popularity and acceptance is the use of personas: the development of archetypal users to direct the vision and design of a web solution.
This article explains what personas are, benefits of using personas, answers to common objections about personas, and practical steps towards creating them. It is meant as an introduction to personas, and provides enough information to start creating your own. 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 with having created the first persona for software development purposes back in the early 1980s.
Personas act as stand-ins for real users
What are personas?
Personas are archetypal users of an intranet or website that represent the needs of larger groups of users, in terms of their goals and personal characteristics. They act as ‘stand-ins’ for real users and help guide decisions about functionality and design.
Personas identify the user motivations, expectations and goals responsible for driving online behaviour, and bring users to life by giving them names, personalities and often a photo.
Although personas are fictitious, they are based on knowledge of real users. Some form of user research is conducted before they are written to ensure they represent end users rather than the opinion of the person writing the personas.
Below is a sample persona for an intranet project. This persona describes Bob, a 52 year old mechanic that works for a road service company. From Bob’s persona you can start to get a feel for his goals when using the new intranet. He wants to avoid feeling stupid, would like to retain his status as a mentor to his younger colleagues, whilst seeing the potential of the intranet to make him more informed when interacting with customers.
Bob is 52 years old and works as a mechanic with an organisation offering road service to customers when their car breaks down. He has worked in the job for the past 12 years and knows it well. Many of the younger mechanics ask Bob for advice when they meet up in the depot as he always knows the answer to tricky mechanical problems. Bob likes sharing his knowledge with the younger guys, as it makes him feel a valued part of the team.
Bob works rolling day and night shifts and spends his shifts attending breakdowns and lockouts (when customers lock their keys in the car). About 20% of the jobs he attends are complex and he occasionally needs to refer to his standard issue manuals. Bob tries to avoid using the manuals in front of customers as he thinks it gives the impression he doesn’t know what he’s doing.
Bob has seen many changes over the years with the company and has tried his best to move with the times. However he found it a bit daunting when a new computer was installed in his van several years ago, and now he has heard rumours that the computer is going to be upgraded to one with a bigger screen that’s meant to be faster and better.
Bob’s been told that he will be able to access the intranet on the new computer. He has heard about the intranet and saw once in an early version on his manager’s computer. He wonders if he will be able to find out want’s going on in the company more easily, especially as customers’ seem to know more about the latest company news than he does when he turns up at a job. This can be embarrassing and has been a source of frustration for Bob throughout his time with the company.
Bob wonders if he will be able to cope with the new computer system. He doesn’t mind asking his grandchildren for help when he wants to send an email to his brother overseas, but asking the guys at work for help is another story.
Benefits of creating personas
Personas enable intranet and website teams to stand in their users’ shoes. They focus the design effort on supporting user goals, rather than being driven by the ideas of team members or senior executives.
Introducing personas into your intranet or website 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 ask for rather than what they will actually use
- design efforts can be prioritised based on the personas
- disagreements over design decisions can be sorted out by referring back to the personas
- designs can be constantly evaluated against the personas, reducing the frequency of large and expensive usability tests.
Personas are not stand-alone
Although personas have many benefits, they alone will not ensure the success of your intranet or website. The goals of the business must also be considered, because if the website or intranet does not meet business needs, then the solution is not a viable one. For example, an intranet may aim to reduce organisational costs and increase staff efficiency, while an ecommerce website aims to make sales.
Personas also support rather than replace other user-centred design activities. There is still a need to conduct task analysis to understand the detailed tasks your intranet or website is to accommodate. There is still value in usability testing the site, and many user-centred design activities are conducted to gather input into the personas, such as user interviewing and observation.
Roadblocks to introducing personas
Introducing personas for the first time is not always a smooth ride. You may come across any one of these objections.
Personas are no different from market segments
Market segmentation is an invaluable tool for identifying the groups of people most likely to use a website and why. However market segmentation is not designed to provide insight into how the website needs to work and how it is best designed.
Market segmentation might identify that 37% of women aged 25-35 want to book their next holiday online, and that competitive prices and access to quality accommodation will affect their purchasing decision. A persona, on the other hand, would show that Sally aged 27 wants to book her next holiday online, but is concerned that the accommodation she chooses won’t look the same as the brochure, that they won’t be close to restaurants and bars, and that her online booking might not be accepted when she arrives. Sally also wants to be assured that she can cancel her booking 60 days prior to her departure date without penalty.
Market segmentation is a great input into persona development and can help identify the types of users to profile. However it rarely provides the richness required to write personas.
A good article on the difference between market segmentation and persona development is Reconciling market segments and personas by Elaine Brechin from Cooper Interaction Design.
Personas have no place in the serious world of IT
Personas make some people feel uncomfortable. Talking about hypothetical users with real names and personalities can be too much for some, and the storytelling nature of personas just does not fit with some organisational or team cultures.
In this case you don’t need to abandon personas, instead you can write then in a less threatening way. Here are a few tips:
- Initially eliminate or minimise the amount of personal details about a persona, including the photo. You can introduce these later on if people start to warm to the concept.
- Give the persona a title rather than a name. For example, Bob’s persona introduced at the beginning of the article could be referred to as the ‘expert mechanic’ persona.
- Write the persona as a list of bullet points rather than a narrative. Keep the bullet points to short statements about the user’s goals, behaviours, likes and dislikes.
An example of how Bob’s persona can be modified is shown below. Although this does not have the richness of the narrative persona, it still does the job of focusing the team on the needs of the user.
|Length of time in job||More than 10 years|
|Daily tasks||Attends jobs (most simple, approximately 20% complex and has to refer to manuals)|
Shares technical tips with younger, less experienced mechanicsLikesBeing seen as the expert and sharing technical tips with less experienced mechanicsDislikesBeing unable to find out what is happening in the company before customers do
Learning new technology and the potential of looking stupid in front of colleagues
Using technical manuals in front of customers for more complex jobsGoalsStay informed about the company
Dont look stupid
Retain status of expert
How can a small set of personas represent the user population
When explaining for the first time that an intranet or website can be designed around only a handful of personas, some people will look at you with disbelief. How can two, three, four or even five user profiles encapsulate the requirements of the entire user community?
Traditionally user-centred design involved researching the needs of as many users as possible and collecting all of their requirements. This resulted in a long list of needs with no sense of priority. This lack of direction typically translated into designs that tried to serve all users but ended up serving no user particularly well.
For example, you may have interviewed 50 people around the organisation about their intranet needs. You have compiled a list of requested content and some ideas about the functionality users’ desire, such as a phone book linked to the organisation chart and the ability to check how much annual leave they have left. You also know that the call centre users need access to a range of information very quickly if their call response times are not to be adversely affected. Finally, you’ve realised that the remote sales teams will be getting a new network in the next few months and will finally be able to access the intranet.
What do you do with all these needs? Do you design the intranet so it meets the needs of the call centre staff? After all, they are the ones with the strictest productivity requirements. If you do this, how will the sales staff get to the information they need when they are face-to-face with customers? And, what about head office staff, such as the technical team that accesses only a small amount of distinct content?
Personas cut through this confusion. They allow you to identify discrete sets of users and create typical users to represent each group. Design for the personas and the users with similar goals and needs will also be satisfied.
Design for a discrete set of personas and satisfy all users with similar goals
By defining primary and secondary personas you can also work out who to design for first and whether you need to design more than one user interface. The needs of a primary persona will not be met if you design for someone else, whereas others are likely to be satisfied with the primary persona’s interface. For example, if you design for the call centre staff, the remote sales staff and the head office technical team might also be satisfied. However if you design just for the head office technical team, the call centre and sales staff are unlikely to be happy.
The call centre staff persona is a primary persona, whereas the head office technical team is a secondary persona. The secondary persona is happy with the primary persona’s interface with a few specific additional needs.
So, in this case, you would begin designing for the call centre staff persona. This is a lot easier than facing a 10 or 20 page list of user requirements.
Interview real users and business people that interact with users
How to create personas
Decide on a research method
The purpose of the research is to identify trends or patterns in user behaviours, expectations and motivations to form the basis of the personas. One of the best ways to gather this data is to interview real users. This is usually achievable when designing intranets but becomes harder when you need access to users of a public website.
If you have access to users, decide who to interview by listing the groups of people that might use the intranet or website. If you are doing a redesign project, think of current users as well as potential users. Trends are usually seen after talking to around 10 or so users, however you may need to speak to more if there are a lot users with vastly different needs. Once you hear the same thing over and over again, it’s time to stop.
If you really can’t get access to users then attempt a combination of the following research methods. Try not to rely on a single method, rather use at least two avenues of research. Also, if you interview users, consider supplementing the interviews with one of the research methods below. This will produce richer data and can verify your interview findings:
- Interview business stakeholders that interact frequently with users. These people have had hundreds if not thousands of interactions with end users and are already conscious of users’ behavioural patterns. Respect the wealth of knowledge your business stakeholders hold and get them involved early on in the persona research. This helps to build their buy in to the persona technique.
- Review market research and interview your organisation’s market research specialists. Once again these people have frequent interaction with end users and are trained to pick up patterns in attitudes and behaviours. They may not have created personas before, but if you ask the right questions you’ll gather useful information to add to your research data.
- Survey users and business stakeholders using quantitative methods. This is a good way to gather large amounts of demographic data and to identify trends in skill levels and tasks performed. However it cannot replace direct interaction and observation with interview subjects as there is no way to tap into the users’ subconscious beliefs and attitudes.
- If you are designing a web site, talk to friends and family that are users of the current website or potential users of the new website. Chat to people over dinner parties or at the pub. This is not rigorous research, but some research is better than none.
Conduct interviews in the user’s environment
Conduct the research
Now that you have decided on your research methods, carry out the research. If conducting interviews, plan to spend about one hour per interview. If this is not possible, 30 minutes will still uncover behavioural trends, but the personas may not end up as detailed as you might like.
Interviews with users are best conducted in the environment in which they will use the intranet or website. This provides the opportunity to observe what users do as opposed to what they say they do.
Stay away from asking opinions about the design of the intranet or website, or asking users what they want. Rather gather information about the areas listed in the table below. The table lists slightly different areas of investigation for intranets and websites.
|INFORMATION TO GATHER DURING INTERVIEWS|
|Basic demographics such as age, job title, length of time in position, and length of time with the organisation
Job responsibilities and what a typical day looks like
Tasks that take the longest, are the most critical or are performed most often
Major frustrations with the job and the organisation
What the person likes best about their job
What teams or people within the organisation the person interacts with most
Skill levels relating to the job as well as technology
How time poor or rich the person is
Goals, attitudes, beliefs (conscious and subconscious)
|Basic demographics such as age, job, family, hobbies and interests
What a typical day looks like
Common questions or tasks in relation to the website’s domain
Major frustrations when trying to achieve goals related to the website’s domain. For example, if it is a travel website, what frustrates the person most about researching and booking travel (online and offline)
What the person likes best about the website’s domain. For example, what does the interviewee like best about travel
Who does the person interact with most when completing tasks. For example, does the person rely on the travel agent for advice or do they like to make their own travel decisions.
Skill levels relating to tasks as well as technology
How time poor or rich the person is
Goals, attitudes, beliefs (conscious and subconscious)
Prepare a list of interview questions, however, remain open to an alternative path of questioning if it leads to uncovering user attitudes and behaviours. Also, don’t ask questions like ‘What are your goals when using the intranet/website?’. You will need to infer the goals from questions like ‘What things frustrate you the most?’, ‘What makes a good working day?’, and ‘What will help you
to do your job better?’ Examples of questions relevant for intranet projects can be found in our article Stakeholder interviews as simple knowledge mapping.
Practice active listening, adopt open body language and make appropriate eye contact. Most of all respect the opinions the user is providing. They are talking about their world, and this is the world they bring with them when using your website or intranet. Your respect will build trust and openness, and this is when the true motivations, attitudes and beliefs of the user are revealed.
Stay tuned to what the user is not saying – take notice of body language and tone of voice
Analyse research data and identify persona set
Review all the research data and look for patterns in attitudes and behaviours. For example, if you interviewed people about travel, you might find patterns like users who are price driven as opposed to quality driven, users who travel frequently as opposed to infrequently, and users who prefer to research their holiday rather than asking others for suggestions.
For an intranet project, users who need to access information under strict time pressures, users who spend a large amount of their time researching, and users who like to be seen as the experts in the organisation.
Whilst listing these patterns, you will begin to see clusters of attitudes and behaviours that make up different personas, such as the frequent traveller that is skilled in researching holidays and finding the best prices. This persona is motivated by keeping the cost of each holiday down so they can travel more in the future. The persona’s goal is to go on as many holidays as possible.
Once you have defined these clusters of attitudes and behaviours, give each persona a brief description, such as ‘independent traveller’ or ‘bargain hunter’. There is no ideal number of personas, however try to keep the set small. Four or five personas work as effective design tools, whilst over ten personas may introduce the same confusion as a large user requirements document.
Start writing the personas by adding details around the behavioural traits. Select details from your research, such as working environment, frustrations, relationships with others, skill level, and some demographics. Give each persona a name and a photo, unless your organisational or team culture is better suited to the more generic personas, like Bob’s persona listed as a series of bullet points.
Here are some tips to follow regardless of whether you write your personas as narrative or bullet points:
- Keep your personas to one page, so they remain effective communication tools and can be referred to quickly during design discussions.
- Add personal details but don’t go overboard.
- Include goals for each persona. This can include experience goals as well as end goals. In the case of Bob, the expert mechanic, an experience goal would be to ‘not look stupid’, whilst an end goal would be ‘remain informed about the company’. To find out more about writing goals, refer to the article: Perfecting your personas
- Identify the primary and secondary personas (explained earlier on in this article) to help direct design priorities.
Once your personas are written, review them to ensure they have remained realistic and based on your research data. Check that you have a manageable number of personas, and if two personas seem close in behaviours and goals, see if you can merge them into one persona. Finally, to ensure you have a polished product, ask someone to review the personas for accuracy in spelling and grammar.
There are many and varied ways that personas can be used. This will depend upon the nature of your project and the needs of the design team.
Here are some common ways to use personas:
- identify the features, functionality and content to develop for an intranet or website release, ensuring that value is delivered to users from day one of the release
- determine whether one user interface will meet the goals of all users, or whether there needs to be two or more user interfaces developed
- communicate to senior executives the vision for the new intranet or website and how it will meet the needs of the staff or customer base
- make design decision about how a piece of functionality will work or about the creative design of the web solution
- guide the content development so that content supports the goals of the users and answers their common questions
- focus additional user analysis activities, such as task analysis
- guide an expert usability review of the existing intranet or website
- develop scenarios for usability testing
- contribute to the marketing efforts for the intranet or website
Understanding the needs of users is one of the most critical success factors for any intranet or website project. Understanding these needs in a rapid fashion has arisen as project timelines have shortened and the pressure has mounted to deliver value early and often.
Personas allow you to identify and communicate user needs efficiently and effectively. By developing ‘stand in’ users, based on real user data, the design team can concentrate on designing for these archetypal users with the confidence that the needs of the broader user base will be meet.
Personas are a useful tool to use throughout the project, from deciding upon the functionality to include in a release to evaluating the end product. Teamed up with other user-centred design tools and techniques, such as task analysis and usability testing, personas will place you in good stead to deliver a useful and usable solution.