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: Dont listen to your users

Let me explain…

Its 1898 and we are in New York City. The Empire State Building doesnt 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 everyones 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.

Whats 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 dont 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 Mayors 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:

1. Everyone wants something different
2. Everyone focuses on what they have already
3. Some people make nonsensical suggestions
4. The boss focuses on the bottom line
5. Im 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 dont mean their dogs 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, Im 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

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 its important to follow the correct line of enquiry, otherwise you end up with insights like I want horses that dont shit.

Whats 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?

Its 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 youve 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 wont 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. Its a win win to interview these detractors. At worst you wont 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:

Do:

• 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 its 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 its important to naturally explore parts of the conversation more deeply and occasionally go off piste. You should ask open questions. However, its 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 wont 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.

Dont:

• Dont ask them what they want. Its 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. Its vague and its 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?

Task analysis

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. Theres 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 Well 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 dont want to end up just documenting what the existing system does.

Heres an example process this is real, but the company name isnt:

Pipe Dreams is an engineering company that dig up roads and fix gas and water pipes all over the country

1. At each site, a number of forms need to be filled out by the head engineer
2. A guy in a van drives round the country collecting these forms from each site
3. The van man drops off the completed forms to central office
4. Central office scan the forms and upload them to a document management system
5. The document management system outputs an inventory sheet
6. The inventory sheet is printed, circulated and signed by various supervisors
7. The signed inventory sheet is re-scanned and stored

After youve gathered this info, turn your notes into a flow diagram. Like this diagram, below.

Sometimes a task or interaction wont 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 cant 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.

Stakeholder workshops

What weve 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:

1. Getting managers and senior people, like department heads, involved makes them feel invested in the project. Theyll 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.
2. 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.
3. 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 its 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:

1. Ask the magic wand question. Ask them what they would fix in the business if they had a magic wand. Dont 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.
2. 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.
3. 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?
4. 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.

Its never too late take action tomorrow

Theres 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.

Its 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 teams time and budget.

But its easy to fall into the trap of simply evaluating the current intranet. Thats worthwhile too, but dont just ask people how they feel about the existing intranet. Pretend it doesnt 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 Persons Opinion.

The HiPPO can derail you if you let it.

There can be very strong views about what the intranet should and shouldnt 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 dont 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 its time to approach the senior stakeholders, cap in hand, you should insist on a face to face meeting / presentation.

If you really cant 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 elses 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 doesnt 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

1. 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
2. Dont listen to your users
   Dont listen to what people say they want they often dont really know
3. Just do it
   Pick 2-3 techniques and get going, start the ball rolling dont wait for the next big bang
4. Win support
   Put your case forward in a succinct and convincing way that leaves no room for whimsical decisions

Championing the user – presentation