Part 2: A feasibility study to act on – how to do it

A few years ago, a car manufacturer discovered that customers were asking and searching for information on fuel consumption. The car manufacturer acted in the usual way, clarifying the information in the specifications on its website and providing a more thorough explanation of how consumption was calculated. Nevertheless, users did not seem satisfied. The explanation was that fuel consumption was only one indicator of a broader need: sustainability. Sustainability includes the manufacturing process, life-cycle perspective, choice of materials and much more, and therefore cannot be boiled down to fuel consumption alone.

On one intranet (actually on all intranets), one of the top needs was to find colleagues. That particular intranet met the need with a well-functioning and updated phone book, but people still complained that it was difficult to find each other. The intranet managers had not asked themselves why users wanted to find a colleague - they did not support situations where someone is on the phone with a customer and needs to know quickly who the contact person is, or for an employee to put together a work group with the right roles. In other words, the phone book lacked information on responsibilities, roles, product knowledge and skills.

So step 1 is to identify situations or underlying drivers

Your main challenge is to avoid the too high and the too low; you have no use in knowing that "People want to be more efficient". Nor is it helpful to know that "People need to find document X". You are going to make them more efficient by understanding in what context they need to find that document.

Methodologically, observations – following the target group in their daily lives – are your best option, but far from always feasible. Interviews, workshops or data collection surveys are other options. Visitor and search statistics are relevant sources to dig into, and depending on your industry, there may be anything from research to YouTube videos that provide the clues you need.

Step 2 is to process the needs

With clues from all of these places, it's going to be a healthy spread. That's okay, but it's not useful, so you need to take responsibility for bringing them together into clearly expressed needs/needs clusters. At this stage, a well-executed step 1 will make you understand that "fuel consumption" is about the needs "technical specifications of car X", "sustainability profile of car X" – and maybe also "economics of owning car X".

The reference groups that often become hostage or opinion machines in development projects have a deeply productive and crucial role to play here – together with the target groups, of course.

Step 3 is to prioritise the needs

You will not build the perfect site. It doesn't exist; your perfect site is not my perfect site. Sure, we work on segmentation and personalisation, but ultimately you're making a lot of decisions that affect all your users. You could then decide for yourself which needs are best supported. Maybe with the help of a small project team, maybe by asking management. But of course that won't be good, you are all too far from the target group's reality to say what is most important. So again, the target group or groups need to be heard, and they need to be heard in a way that provides an insight you can trust.

So forget the focus group or workshop at this point. It's a good old-fashioned survey that counts. Give people the list of needs/clusters of needs that it is reasonable for the site to meet, and let them choose the ones that are most important to them. Set limits, ask them to choose a small number so that you can really see what is essential, of little interest or actually superfluous.

Step 4 is the priority insight and foundation of your feasibility study

Through this, you know that people want to get around faster and more conveniently. Now it's your job to find out whether you should trim the horse or produce a car. You have asked about needs – you take responsibility for the solution.

The list of prioritised needs will support you through the project and beyond. It shows what is most important, and this should be prioritised in navigation and search; what is most important should be easiest to reach. The list also shows what you should put your supplier or agency on and it shows how to prioritise in a limited budget (focusing on the top needs, and what matters least may be a pdf). It also shows the tasks that editors will be working on and provides a basis for how they need to be organised.

Moreover, the list will show all this for a long time to come, because very few needs are easy to meet. And it is much better for your target audience that you go back in three or four years and think "Can I make top need number three even faster, easier, better?" than going after need 97 because a fun new module became available.

Doing a feasibility study that says what your users need is extremely valuable. So take the opportunity to do it properly.

In part three of my mini-series, we'll take a closer look at how we can measure impact, not just usage.