This document discusses various techniques for understanding users' needs and perspectives better, such as conducting interviews, task analysis, and stakeholder workshops. It emphasizes the importance of listening to users but also notes that users will have different and sometimes contradictory needs. The goal is to gain insights into how users complete tasks and what issues they face in order to identify opportunities to improve products and services.
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 this is what they look like (The Dakota)
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 started by asked a local businessman who owned a transport company.
“What’s the problem?,” he asked
“I want faster horses,” said the business man
“Right, right - faster horses,” scribbled the planner
Next he spoke to a milkman.
“I want bigger horses, to pull more milk” said the milkman
“Ok, bigger horses…”
Then he spoke to a road cleaner.
“I want horses that don’t shit,” said the road cleaner
“Hmmm, no… defecation… ok”
Next the planner spoke 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 visited the Mayor’s office
“I want higher taxes on horses,” exclaimed 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!
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 1 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 shit less’.
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 general, 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.
Don’t get fixated on speaking to office staff only or having to be there in person. I was recently doing some research for a university. I had an interview call with a Geology professor who sounded like he was doing the call standing at the top of Ben Nevis. He probably had a satellite phone with one of those big dishes on top like you see in Jurassic Park 3. It was a little hard to keep him on topic - and make out everything he was saying – but, he was so passionate about his work and became very interested in the digital workplace project because of the way it meant he could connect better with others doing similar research.
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
I once interviewed someone who was really skeptical about changes being made to the intranet. She wanted to maintain the status quo – which was to basically store documents on the intranet as if it was just a network drive. As we got in to the conversation it became clear that she was just not comfortable with new technology. She was intimidated by it and wanted to just keep things as they were, because – although imperfect, she understood them. But, because she was involved in the process and taken on the journey and understood what we were trying to do – she was became open to learning new ways of doing things.
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 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
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 these do’s and don’ts is:
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.
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 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.
On one recent project, I ran some workshops that involved people performing the same role from different regional offices. Most of them hadn’t met in person before, and a lot of them had no contact at all. But, they’d travelled in to one place to do these workshop sessions with us. As it happened, one of the core objectives of the intranet ending up being about supporting a collaborative culture across the whole country. So, even the research activities themselves worked towards that objective – We were already creating connections and building relationships, before we’d even prototyped the intranet
A good structure for a stakeholder workshop is:
Ask them what they would fix in the business if they could. 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.
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.
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.
There was a project, some time ago now, where we held a kick off meeting with the project team and the senior stakeholders. About 10-15 people around a large meeting table. We were discussing the company and its brand values, which is useful context. But, somehow we slipped into solutioneering and the President, the HiPPO in this case, told us what we should put on the homepage. “We’re all about movement and dynamism, so we should have a character who runs across the top of the navigation and then dives off the end and falls down the page into some water at the bottom, making a big splash – This should happen every time someone comes to the intranet”. Remarkably there were a couple of people who seemed enthusiastic about this idea and started to try and build on it. Luckily, someone sensible piped up and said “It’s definitely a nice idea, but let’s not get ahead of ourselves. We have a set of research to do and we’ll come back with recommendations about where to spend the effort and get the biggest positive effect possible on the business”. We all breathed a collective, but inward, sigh of relief.
Another funny suggestion that seems to come up a lot is Easter Egg hunts. Where, in order to get people to look at content on your intranet, you hide something like a little character and ask them to find it. “So, to celebrate the new vastly superior intranet, let’s all spend hours hunting for things that are buried in the site” – rather like using the old intranet then. I mean, just the concept of grown adults spending hours pointlessly looking for virtual characters… I just can’t see it catching on.
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
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 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.
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