The Vital Guide to Capturing UX Requirements

Pilots will tell you that being off course by just one degree, after flying 60 miles, you will miss your target by a mile. That’s called the 1 in 60 rule.

For UI/UX design, getting the right UX design requirements at the very beginning is just as important as for aviators. The further you move the wrong way, the more remarkable your mistake gets. Finally, the difference between a successful product design and a miserable fiasco often comes down to a tiny error made on a stage of requirement elicitation.

By failing to prepare, you are preparing to fail

Requirement elicitation simply means a process of information transfer between a client and a designer. Neither designers nor their clients want a misunderstanding to occur at this stage, but…

39% of failed projects fail because of inaccurate requirements gathering.

So why does requirement elicitation so often go painfully wrong?

It won’t probably go wrong with in-house designers on board. The client will just explain to their fellow designers what the app needs, and high chances are they will understand. Because they’ve been to hundreds of team status meetings, they’ve read miles of Slack discussions on topic and they already know what the app is about.

In other words, in-house specialists understand the context.

When an agency or freelancers come into play, they start as strangers with expertise in UI/UX but no knowledge of the niche and product.

For designers, it’s like driving a car in a new city without GPS. They will have to ask questions. Sometimes the clients may or may not realize the number of questions they will ask. They come with a request that sounds something like this:

“Help me to design/redesign this MVP/app/website”

That’s not enough to open a graphic editor and start wireframing. Designers also need to:

• Understand the idea of the product, its goals, and objectives;
• Cover the project’s scope;
• Check what have been already done;
• Define the audience;
• Explore the competition;
• Set the approximate schedule;
• Agree on production control;
• Determine the budget.

Start with the overview of the project

When you don’t know what to start from, start with the project overview. Figure out the app’s function, the idea of the product, its goals and objectives, its future functionality.

Another primary aim is to lay out exactly what your project scope is. In other words, what you or your team are going to do for the client.

Check what have been already done

In most cases, you don’t start designing from the ground up. Take inventory of what you already have and can use in your work so that you don’t reinvent the wheel. Maybe the app has an MVP version for you to start from, or a collection of reusable components that are used in layouts? Pretty sure, any existent product has its brand colors and types, and some other creative and analytical assets.

These assets have a direct impact on the design project, so make sure you take inventory of all relevant information beforehand.

Define the app’s target audience

People ignore design that ignores people. User experience design, as the name suggests, is focused on creating stuff that never ignores people. The cornerstone of UX design is understanding who are the users, what are their pains and gains. Which is never an easy task.

To move closer to understanding the customers, you need a tool that sits somewhere in between the synthetic term “audience” and the fractional reality of 1,123,654 different users all of whom are not like the other.

That tool is buyer personas.

User personas are somewhere in between

If you’re lucky, your client might already have drafted personas for their target audience. If not, you will need to create them on your own. Later, personas will become a basis for user flows.

Explore the market competition

Except for some rare cases, products don’t live in a vacuum. They are born to compete with another product or a bunch of products that operate in the same market segment. So basic understanding of the competitive landscape is a must for a designer to start.

Moreover, understanding the competitors’ strengths and weaknesses helps to decide on the angle of your design project, its identity and possible competitive edge.

A fragment of competitors’ review

Decide on some basic schedule

Two things in life are certain: death and taxes. A design project plan is not on the list. Because the product design process often looks like navigating through the fog of uncertainty.

Yet precision is what clients often seek from designers. From day one, they want to know how long the whole process would take and how each step would look like.

What a designer can do here is to compare the new project to the prior ones. It helps to roughly estimate in a cursory glance whether the UX scope of work is going to be large (6+ months), medium (2-5 months), or small (a couple of weeks).

At the beginning of any project, you never know how long this is going to take

As you learn more about the project, you can specify the terms better. Usually, after a few iterations, a designer can speak about the schedule confident enough.

Wrapping up the UX requirements gathering

There’s a quote widely attributed to Abraham Lincoln, saying “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”

Gathering UX requirements is no small task, but it creates a solid foundation for your further work. It allows us to round the obstacle and shape the expectations for both customers and designers.

The art of requirement capturing becomes especially important now, as we’re entering the work from home revolution. Maintaining a dialog becomes exponentially more difficult as we’re separated by screens and miles. Consistent, meaningful and clear communication is now important more than ever before.