Every designer has to understand UX requirements to create awesome user experiences. Here are 6 simple steps to capture UX requirements
Capturing UX requirements takes a lot of research, a thorough understanding of what sort of project you’re embarking on and a handful of patience. But with a little help, with these 6 steps, you’ll be much closer to capturing those all-important UX requirements great designs.
Let’s make your projects a breeze and get into it.
What are UX requirements?
Before we drill down into capturing UX requirements, let’s unpack what they are first. If you’ve ever been looking for a job, you’ll have most likely read hundreds (possibly thousands) of job descriptions. You’ll usually get some back story about the prospective company, but most job descriptions get right into the nitty gritty: the requirements.
These requirements normally arise out of identifying a problem. That means, the business has a problem (it needs a new employee) and it has identified the solution to that problem (hiring a new employee). And for the company to solve the problem, they looked at their business needs, had discussions and then created the job posting with the specific requirements.
UX requirements are like these statements you read in job postings but applied to products and services. Just like job requirements focus on who they want to hire, UX requirements should focus on who will be using the product or service.
In brief, UX requirements are what is needed for a product or service to be successful.
UX requirements should be user-centered. This means they must be clear; there is no room for ambiguity. Now let’s show you how you can go about capturing UX requirements.
How to capture UX requirements in 6 steps
Capturing UX requirements can be an uphill struggle, especially for new UX teams or team members with little leverage. Often, gathering UX requirements turns into meetings about one stakeholder’s opinion over another or whoever has more clout in the business getting heard louder. Not fun.
Let’s look at 6 ways you can efficiently capture UX requirements. Put down the painkillers, pain relief is here:
Brainstorming and ideation
No ideas are bad ideas should be the mantra for your brainstorming and ideation sessions. While it’s true that many brainstorming sessions generate terrible ideas, it is still a hot bed for bad ideas to ferment into brilliant ideas. The important thing here is to get everyone involved so that the ideas can flow.
Brainstorming sparks creative thinking and is a good method of generating requirements early on. What is great about this part of the UX requirements process is that it doesn’t rely on any research.
At this stage you can get everyone involved from executive team members to directors.
When you start hearing ideas that have been repeated or sound ridiculous, it’s probably best to wrap up the ideation session.
After you’ve scanned through the requirements that are needed from the brainstorming session, you want to capture further requirements with stakeholder interviews. This is more formal than a free-for-all brainstorming session so should be treated with more severity; however, the conversational tone should be maintained.
Here you can coax information from key stakeholders to generate more substantial requirements. You can ask questions such as:
- How does this product fit into the overall strategy?
- Who are our biggest competitors?
- Who are our customers today and how do you want that to be different in 5 or 10 years?
- What qualities do you want our users to attribute to our product?
- How might we meet this or that business need?
- Who will use this feature?
Sherif Amin gives a good run down of all things stakeholder interview, including more questions, over at UX Collective.
According to Kim Goodwin, you should listen to all ideas from your stakeholders. There may be value in what they say but also telling your boss that you don’t want to listen to their ideas may not go down so well. It’s also important to hear them out so that you can explain why certain ideas just aren’t going to work later down the line.
What you really want to be doing in your stakeholder interview is asking what problem their solutions solve, as this can help you identify any major issues much sooner.
Create a low fidelity prototype or sketch
At this early stage in the game, you might be wondering why you’d be prototyping at all. Well, a low fidelity prototype or a Sketching wirefame can help other stakeholders understand a few important things:
- Basic functionality
- Notable constraints
The reason your prototype at this stage ought to be low fidelity is because anything more and you’ll be inviting critique and attention for the wrong reasons. It’s also cheap and a big time saver – only a drag and drop in Justinmind and you’re on your way.
When you’re attempting to generate UX requirements, having as few distractions as possible in a low fidelity prototype can help keep stakeholders focused on the game at hand.
Remember, that you should continue to iterate prototypes as you go through the design process for better refinement – don’t just create one prototype and wash your hands of it. It’s also possible to generate specification documents from your prototypes.
Through showing basic functionality and the constraints involved in the project, you’ll be able to generate more focused and relevant requirements, which will help as you move on to the next step.
And if you add team members to your prototypes, they can stay on top of any changes throughout the process – including adding their own comments. How’s that for early collaboration?
Now it’s time to step out into the wilderness and get information from people who aren’t already involved in your project: strangers.
A user interview is much like a stakeholder interview in that it should be light and conversational. This stage usually involves a UX researcher and a user, with the researcher guiding the user through the interview. Recording or videoing interviews is useful if you’re short on additional researchers.
From user interviews, you will gain an understanding of the ethnographic data of your user. You might also get insights into:
- Using the product
- Understanding users’ pain points
- Knowing users’ objectives and motivations
- How users interact with the technology
You can of course go in more detail to get deeper knowledge from your interviewees. A handy script can guide you along the interviewing process and keep you on track, so you can extract the information that you need.
Try and keep this interview short because if it is too long then interest may wain and data may prove unreliable.
Often users will be great at identifying problems but not so great at suggesting solutions. Help them by asking pertinent questions such as:
- What do you hate most about this interface?
- Where were you wasting your time?
- Where did you create errors?
Need more on conducting user interviews?
Scenarios and personas
After you’ve gone through the process of ideation, interviews and prototyping you can put your information into practice using user scenarios, stories and personas.
- A user persona is a character that represents a potential user of your product or service.
- A user story is a short abstract that identified the user and their goals – who is the user, what do they need and why do they need this product or service.
- A scenario is a situation that captures how users perform tasks on your product or service.
When you do the above, you’ll hopefully be able to extract the correct functional requirements. You can couple scenarios and personas with empathy maps to further identify key insights which can be iterated through prototyping.
Why not try your hand at creating your user personas with our free template? Go bananas!
The final step is preparing documentation. Now that you’ve captured the requirements after going through the following process, it’s time to put that hard work onto paper with actionable insights.
You’ve already prepared a lot of documentation throughout the previous 5 steps but the final step is the cherry on the document cake. It’s where you bring specifications together cohesively.
In your documentation you should list both technical and product requirements, any stylistic choices that have been made and then you’re done. Requirements captured!
Capturing UX requirements is a valuable and necessary stage in the design process. Getting it wrong from the get-go can have a devastating impact on how the final project turns out. The above methods can help you achieve a smoother, more successful requirements stage so that you can design better and faster.