I see it all the time. Something new comes on the market and suddenly everyone wants the latest thing, even if what they have is working already.

A big project gets underway to iterate it. With no clear objectives, little changes that make the project easier to deliver start to compromise the original design. By the time the projects over, users are left stranded with a version 2 that doesn’t work for them but they’re forced to use.

These failed iterations are caused by a lack of a clear requirements. But if the customer doesn’t know they’re own requirements, how can you help them figure them out?

The worst kind of start

How many times have you heard this one?

Customer: “We want what we’ve got now but with these cool new tools added. Oh and we also want it to be somewhere that everyone comes to for everything”.

You: “So what does your current site do?”

Customer: “We originally created it to provide X. Nowadays we use it for messaging about Y.”

Getting back to the beginning

Oh dear. Start by going all the way back to the beginning of the original design. Dig into what the goals were and don’t stop until you reach clearly defined answers.

  • Why was the product created?
  • What problem was it looking to solve?
  • What did it offer for users?
  • What did it expect users to do with it?
  • What did a great result look like?
  • What measurable outcomes would it deliver?

These are often difficult for a customer to define because they’ve seen something that already exists, assumed that would work for them and now have difficulty stripping functionality back to really understand what their users actually need (or even want).

Pulling everyone together

You’ll start saying phrases like:

  • “But you can already do that by enabling your X function”
  • “You seem to be wanting your users to do a lot of different and unrelated tasks”
  • “What’s the business need for them to perform that action?”

At this point your positions will start to diverge. You’ll keep moving towards “I need you to define what it is you’re needing done” while they’re moving towards “can you just build it as we’ve asked” . There’s a real danger approaching and you’ve got to ensure you’re both aligned before you proceed any further.

Understanding their users

It’s time to take it back to basics, which starts with analysing the end user. Organise some testing, surveys, feedback or other data driven learnings to find out how users are currently using the site and what they expect it to do – the two are often different. Take those learnings and profile those users, where they work, the type of work they do and what their behaviours are. These profiles are known as personas which I’ll be covering in latest posts.

Start telling stories

You’re going to need to educate your customer towards what a great experience looks like. Fill them in on the hard realities of your user feedback and ask them if that’s what they want their users to be doing.

If their users are doing exactly what they want already, don’t change it!

If they’re not, design a user process that gets users as close to their requirements as possible. This may or may not include the functionality they had their eyes on. Avoid all functionality that isn’t necessary and / or distracts from the key objective. Focus on getting users to their end goal as easily as possible.

If their requirements are so unclear that you can’t even do that, find one thing that you believe to be the most valuable for their business and propose a design around that.

Tell them stories about how a user following the new process will result in direct action towards their requirements through easy and logical steps. Here’s an example of a site that helps the business save on travel costs:

John from accounts needs to book a train. He goes to the travel site and receives recommended trains for travel time and cost savings. He also receives details of bus times and a walking route to the office from the station.

He arrives at the station on the bus, avoiding the need for a taxi. At the office he follows a recommended walk that avoids the need for public transport from the station.

Now tell the story of how it will work for them personally:

You: Nicola, where do you work?

Nicola: I work in the Newcastle office.

You: Great. Let’s look at how you’d get there using the site…

Closing the loop

End by summarising the process against their requirements and ticking them off one by one. The next conversation will likely be:

Customer: “But what about X functionality, we were wanting users to be able to do Y”

You: “Does X make it easier for them to fulfil your requirements?”

Customer: “Well no, not really”

You: “In that case we’re going to leave it out for now. Let’s focus on getting the simple things right and we can iterate later if we need to”

If you need to, add “let’s focus on getting the simple things right and we can iterate later if we need to.” – that can help leave customers looking forward if the solution doesn’t include the functionality they had their eyes on.

User first = success

Now prove how what you’ve designed is successful. Get users in and retest the process – if it needs changing, then do, but remember to keep the focus on the key objective you want users to complete, not what functionality is available.

If you need to bring in more functionality then that’s ok, but keep it as streamlined as possible to get the job done. This helps reduce costs, focus minds and deliver real business benefits.

Share your worst moments

What was the hardest requirements gathering process you went through?