Giving your users what they want need
Watch John Scott, one of our SharePoint and intranet experts, delivering his keynote at the Intranet Now conference, or read through the narrative. The slides are shared at the bottom.
There are two rules when conducting user research:
Rule number one: Listen to your users
Rule number two: Don’t listen to your users
Let me explain…
It’s 1898 and we are in New York City. The Empire State Building doesn’t exist – there are skyscrapers, but they are only about nine stories high. The Brooklyn bridge has already been open for 15 years – and there are around 1.5 million inhabitants. But there are also a lot of something else: Horses! About 150,000 of them, in fact – practically filling the streets, ferrying people from A to B, transporting various goods up and down.
But not everyone’s happy with the way things are, and complaints have been coming from a few quarters. So the town planner starts doing some research.
He begins by asking a local businessman who owns a transport company.
“What’s the problem?” he asks
“I want faster horses,” says the business man
“Right, right – faster horses”
Next he speaks to a milkman.
“I want bigger horses, to pull more milk,” says the milkman
“Ok, bigger horses…”
Then he asks a road cleaner.
“I want horses that don’t shit,” says the road cleaner
“Hmmm, no… defecation… ok”
Next the planner speaks to a shopkeeper
“I want cows”
“Cows? Ok, well we have cows available, but horses are kinda… better? … well ok, cows”
Finally, he had to wait a couple of months for an appointment, but he visits the Mayor’s office
“I want higher taxes on horses,” exclaims the mayor
“Great suggestion, My Mayor!”
So, the planner went away and prepared his recommendations. And this is what he came up with…
So, what did the planner learn from this research exercise:
- Everyone wants something different
- Everyone focuses on what they have already
- Some people make nonsensical suggestions
- The boss focuses on the bottom line
- I’m going to have to do this again.
And the next time the planner remembered not to ask people what they want – but to ask them about what what they do and the issues they face – and then understand these things in detail!
Get to know them
What we really want to do during user research is get to know them. Of course, I don’t mean their dog’s name and their favourite colour, but what they do and how they do it.
There are a lot of ways to conduct user research. Each have their own merits and are more or less useful in different scenarios. But, I’m going to focus on the ones that we really must do – and do well. These are the three techniques you should pick that will get you the most useful info for your average corporate intranet project. By average I mean the kind of intranet that covers a broad range of content and functionality. If you are looking at more specific scenarios, like a just-in-time buying portal for manufacturers, then other research techniques may be more important.
Interviews are good because they are efficient. You get an opportunity to really interrogate someone for around an hour and get all sorts of useful info. But it’s important to follow the correct line of enquiry, otherwise you end up with insights like ‘I want horses that don’t shit’.
What’s the point?
The point of interviews is to understand how different people in the business work. What are their common tasks, who do they interact with and how, what are the barriers that they come across? One of the things that you get from interviews is visibility of tasks or processes that are imperfect, and could be improved by an intranet. Another thing is a gradual build up of knowledge about the way the company works behind the scenes – a general sense/awareness that is almost subconscious. Thirdly, a by-product of doing interviews is that you can make people feel involved and consulted – this can have a powerful effect on adoption. Especially if you can bring the interviewees back in on the project at a later point.
Who should we interview?
It’s tempting to select people who you know are interested or already heavily engaged with the intranet or other digital tools. You can select one or two or these people, but the main priority should be to:
- Get a good cross section of staff.
Make sure you’ve got: Some who are junior, some who are middle management, some who are senior; Administrators, line of business workers; office based, field based, shop floor based; UK, France; Region role, country role etc. But that might still only be 10-20 users.
- Interview people who are cynical about digital workplace tools or intranets (especially ones who are known to have influence).
You won’t prove them wrong on the interview, but you can do it in the longer term by really listening to their problems and finding a way to fix them. It’s a win win to interview these detractors. At worst you won’t fix their problems, but will at least make them feel consulted. At best, you will turn them in to a believer
What to do and what to avoid
When interviewing people, here are some things you should do, and things you should avoid:
- Give them some context. Start off by explaining what you are working on and how this interview fits in to the general scheme of work. Make it clear that it’s really vital to the process and be thankful for their contribution
- Have a list of topics / questions. Just reading the questions out like a survey should be avoided – it’s important to naturally explore parts of the conversation more deeply and occasionally go off piste. You should ask open questions. However, it’s important to cover the same angles of inquiry with each of the users, so a list of topics will help
- Try to hone in on frequent tasks they complete, or interactions that they have. Really interrogate them about the detail – be persistent because some people won’t see the detail as important. Get a sense for how long things take and how often they occur
- Before you thank them for their time and hang up – always ask whether they would be happy to help further along the road – as part of usability testing, for example.
- Don’t ask them what they want. It’s not their job to invent solutions to the problems that exist. BUT – if they do suggest something, do note it down. Sometimes it is a well thought out solution
- Get trapped into talking about politics. Some context is good, but change the subject before going into too much detail
- Ask leading questions – deliberately ask open questions. “Do you agree that the intranet is an effective communications tool?” is a bad question. It’s vague and it’s a leading question
And, just to emphasise, the most important part of all of this:
Identify the tasks they complete frequently, or interactions that they have regularly.
And ask them to quantify these actions. How many times a day, how long does it take. And what value does it represent to the business?
In the interviews, we asked people about regular tasks and interactions. Task analysis is about going into the detail of those tasks. Mapping them out and hopefully identifying parts that can be made more efficient or easier.
To begin, we need to make a list of the tasks and interactions that came up across all of the interviews.
Then prioritise them based on which ones have a high frequency but also take a long time and what level of impact it has on the business. There’s no formula that I have for this. Just a general judgement on where it would have the biggest impact if the process was improved. You can also get a better sense of this by talking to managers and department heads – We’ll talk about that more later.
Once you have that list, you can contact the interviewees again and set up a session with them to go through the tasks in more detail.
Ideally, you should organize a time when you can actually sit with the person as they perform the task – essentially shadowing them. Just as if you were being trained to do the same job.
As you are doing this, make notes about what they do and the decisions they are making as they do it. Ask them to think out loud as much as possible. You want to understand the process, but also what they are thinking. You don’t want to end up just documenting what the existing system does.
Here’s an example process – this is real, but the company name isn’t:
Pipe Dreams is an engineering company that dig up roads and fix gas and water pipes all over the country
- At each site, a number of forms need to be filled out by the head engineer
- A guy in a van drives round the country collecting these forms from each site
- The van man drops off the completed forms to central office
- Central office scan the forms and upload them to a document management system
- The document management system outputs an inventory sheet
- The inventory sheet is printed, circulated and signed by various supervisors
- The signed inventory sheet is re-scanned and stored
After you’ve gathered this info, turn your notes into a flow diagram. Like this diagram, below.
Sometimes a task or interaction won’t happen within one continuous time frame. The user might start the task on one day and complete the next step a week later – say, after input from another party – if this is the case then just arrange to ‘attend’ each step in the process, including the ones that involve someone else. If you can’t be there physically then just jump on a call and use screen share software.
What you will end up with is a series of flow diagrams that show the process users go through to complete tasks or interactions. You also have an idea of how long each task and sub tasks take and the business impact of inefficiencies.
From this you can accurately identify problems that the user faces, or inefficiencies in the process. This is the basis for being able to come up with solutions that actually address real business issues.
What we’ve focused on so far is individual users and their tasks. But, we also want to get the bigger picture –the view from the management level and above. This is important for a few reasons:
- Getting managers and senior people, like department heads, involved makes them feel invested in the project. They’ll be more likely to make their staff available for other research like interviews and task analysis – and later testing and content work. If a department head is disengaged, then this can derail things.
- Managers can provide you with ‘the helicopter view’. They constantly get feedback from their staff about processes, systems, culture. They can relay this information to you in aggregated, high-level form. This is an efficient way for you to become informed on these matters.
- Managers will have their own tasks and processes that they will identify as part of the sessions. But, also, they may help you to understand the business importance of other tasks and interactions that users talk to you about.
However, with these groups it’s not just about conducting user research. This is an opportunity to give them visibility of what other organisations do, what best practice looks like and the kind of things that are possible. Doing this will also help with their buy-in – something that will be important throughout your research as well as the implementation phases.
A good structure for a stakeholder workshop is:
- Ask the ‘magic wand question’. Ask them what they would fix in the business if they had a magic wand. Don’t constrain this to the intranet. Invite them to talk about frustrations that are seemingly unconnected to the digital workplace, such as the lack of parking spaces at head office. Make a big list.
- Show them some case studies / examples from other intranets (there are plenty of case studies online and in reports like the Nielsen Intranet report). With each of these first highlight the problems that were identified in the research, then show how the intranet design addressed those problems.
- Come back to the list of things to fix that the group came up with. Ask them if they think an intranet could help fix the problems and if so, how?
- Next, go back over the list and, as a group, condense the problems into themes. For example, collaboration between different offices is a theme that could cover a number of the issues that were raised.
Depending on the size and make up of the business, and the scope of the intranet, it might be necessary to run several stakeholder workshop sessions. For example, one might be with heads of department, another might be with sales managers etc. Ideally you want to get good coverage across your research methods – in terms of the functions, seniority, location etc of the roles.
It’s never too late – take action tomorrow
There’s a problem with a lot of organisations in the way they approach intranets. The ‘big bang’ cycle of intranet projects and launches. Do some research, build an intranet, wait 5 years, do it again.
The ideal way to break this cycle is to do user research continually. This is always the first step, so just make a start and get things moving. As an intranet manager, you are the person best equipped to start the ball rolling. There are always new people to talk to and changes to process or legislation to understand and optimize for – The organisation will continue to evolve.
Continually having outputs and recommendations from user research is like a giant cattle prod for continuous development and evolution of intranets.
It’s true that time or budget constraints may limit what can be done. However, a small amount of the right research is better than none. And also, think of it this way, investing in research leads to improvements being made in areas that actually matter – where most can be gained. So, it really is a wise investment of an intranet team’s time and budget.
But it’s easy to fall into the trap of simply evaluating the current intranet. That’s worthwhile too, but don’t just ask people how they feel about the existing intranet. Pretend it doesn’t exist and ask them about what they do.
Gain support from the HiPPOs
Before you can start giving users what they need, you have to convince other people to back you. This is especially true of the HiPPO.
The HiPPO is The Highest Paid Person’s Opinion.
The HiPPO can derail you if you let it.
There can be very strong views about what the intranet should and shouldn’t do, and worse HOW it should do it (like, down to the level of what the buttons should look like). But, as clever as they may be, you have done the research and, on this subject at least, you know more! You are in a better position to advise on which decisions should be made and why. I don’t suggest that you point that out, but I do suggest that you emit this message in the way that you present your ideas.
Getting the HiPPO onboard with your recommendations – as well as other key stakeholders – is absolutely vital. The intranet will rely on their support for funding, but also promotion and culture shift.
When it’s time to approach the senior stakeholders, cap in hand, you should insist on a face to face meeting / presentation.
If you really can’t get face time and have to submit a report, consider doing it as a set of presentation slides. Not a rambling word doc. Include the lengthy notes and analysis as appendices only.
The key thing is to present the findings from the user research in a way that tells a story – take them on a journey through the research, but give them the highlights only.
If you can – have a prep session with stakeholders individually and sound them out on some of the information you will present. This will allow you to prepare for any challenges. Just one stakeholder challenging you on one small part of your report, and having no response, can change everyone else’s perspective on your credibility.
And, remember the Mayor of New York City? He was focused on the bottom line. So make an effort to include projections on money saved or earned. This can be difficult. However, it doesn’t have to be a water tight forecast. For example, you can highlight some common processes uncovered during the research. Identify how long they take on average, and how many people do them. Assign a cost to that. Then give an estimate for how long the process will take with the improvements you are recommending. Viola – a monetary figure that may convince them. And, also, a KPI – measure how long it does take people as part of the testing and you know if you are achieving the target.
Things to remember
- Listen to your users
Listen to what they do, how they do it and what their frustrations are. Listen to as many people as possible
- Don’t listen to your users
Don’t listen to what people say they want – they often don’t really know
- Just do it
Pick 2-3 techniques and get going, start the ball rolling – don’t wait for the next big bang
- Win support
Put your case forward in a succinct and convincing way that leaves no room for whimsical decisions