The Beginner’s Guide to Capturing UX Requirements
As we move away from the deliverables business, we become susceptible to the poor planning.
In order to continue designing great products with less of a paper trail, we must make sure to create the right documents, instead of more documents — especially in the early stages.
Let’s explore the documents that help us better understand user requirements without bogging us down in busywork. All these documents are simply artifacts of collaborative UX activities, which is where the real value lies.
1. Gathering Early Requirements
As explained in the free e-book UX Design Process Best Practices, the first stage of the process should be research, which is divided into collecting data and organizing it.
But even before that, you must know why you’re collecting data. Every UX project has its own unique requirements, and research is used to determine what they are. We can divide the requirements into three categories: business, user, and technical.
i. Business Requirements
What the product hopes to accomplish for the company/sponsors. Startups and smaller companies might be able to summarize these in a business model canvas.
Larger companies will usually have more requirements, sometimes completed by business analysts or product managers. In either case, these requirements can be better understood through stakeholder interviews.
Business requirements include overall project scope, rough timelines, and business goals (e.g. “Increase new user sales conversion by 20% without affecting retention”).
ii. User Requirements
What the user wants is central to design thinking, so these requirements should have an enormous influence on the UX design. While using your own empathy will help, you shouldn’t guess at user requirements — these should be gathered through user interviews, surveys, field or diary studies, etc.
iii. Technical Requirements
We can separate technical requirements into functional and nonfunctional categories.
The functional specifications outline what the product should be able to do, such as authentication and administrative functions, and can be organized into a specs document like this one from Product Hunt. Nonfunctional specifications describe how well the product performs, such as usability, performance, data integrity, and maintenance.
The entirety of the design process will be shaped around these requirements, so the better you understand them from the onset, the more precise your final product will be in satisfying them.
Join the world's best designers who use UXPin.Sign up for a free trial.Try it for free!
2. Conducting Thorough Stakeholder Interviews
One of the best first steps to any UX project is to interview your stakeholders.
Kevin Hoffman of Goodkickoffmeetings.com even suggest doing this before the initial kickoff meeting so that you have a better “behind the scenes” understanding by the time everyone comes together.
If your company has a Product Requirements Document, jotting down notes from this is a good starting point before composing the questions.
As Kim Goodwin suggests, breaks up the types of questions based department:
- Marketing Stakeholders — brand promoters looking for new, viable markets.
- Engineering Stakeholders — design engineer, system architect, or GUI, if applicable. For hardware, heads of manufacturing and electrical or mechanical engineering.
- Sales Stakeholders — in addition to a marketing head, it’s advisable to talk to a sales head, as the two often have different goals.
- Executives and SMEs — the decision-makers with authority over the different branches.
Pay particular attention to the following:
- Lists of requirements
- Prescriptive solutions
When these are brought up, probe with follow-up questions. These areas tend to be complicated, so extra effort is needed to clarify them.
3. Interviewing Users Carefully
As described in the free e-book UX Design Process Best Practices, user interviews also validate the other areas of research. Here you can either confirm or deny the problems and potential solutions that arose from stakeholder interviews or brainstorming sessions.
Every project will have different goals, which means the actual questions should be different. However, there are some general guidelines that can apply to all situations.
- Instead of asking what users like and dislike, ask what they do, how they do it, and what frustrates them. Asking open questions, such as “why?” questions, give the user the opportunity to expand on their thoughts and feelings and yield data that simplistic “yes or no” questions cut short. An appropriate amount of silence on the part of the interviewer will also gently encourage the user to elaborate.
- Remember that users don’t always tell the truth. Triangulate the interviews against quantitative research (like reviewing analytics and running surveys)
- Just as with the stakeholder interviews, keep it casual and light. Since the user is likely a stranger, helping them relax will give you better, more honest responses.
- Also like with the stakeholders, record of the interview to share with the team.
4. Surveying Users Correctly
You can think of user surveys as “user interviews light” — if you’re short on time or resources, they’re the next best option for understanding your users. While their data is not as in-depth or reliable as interviews, they can still shed light on your customer base.
Surveys are generally low maintenance — your involvement is limited to writing the questions and analyzing the data.
While surveys are a time-saving option, you should still be diligent when writing them to get the results you want.
- First, shorter is better, so only ask the questions you need to. Users will give better data to a 3-minute survey than a 20-minute one. Try creating a list of all potential questions, then editing them down to 5. If you have 8 questions, that’s fine, but any more and you should start cutting.
- Pay attention to phrasing. Closed questions (yes/no, multiple choice) will give you data that’s easier to analyze, while open questions allow you to discover new information — however, Jonathan Kochis, partner at Treble Apps, advises to be highly selective with your open questions.
- Consider the order of your questions, with the most important first. If you’d like to follow up, mention this at the end, after they’re more familiar with you.
5. Documenting Just Enough Specifications
Some UX documents collect and officialize data for reference. If you’re trying to streamline the process as much as possible, you can cut them out, but if you have the time, they’ll prove valuable.
- Specs Document — Lists concretely the product requirements and technical requirement. Treat specs documents as a knowledge portal rather than encyclopedia. To learn more, check out our practical How-To article.
- Style Guide — organizes all the project-wide choices for areas like color, typography, brand usage, layout, etc., and can even include bits of code. Download the free Critical Components of Web UI Style Guides for best practices.
- Mood Boards — Showcases more abstract mood of the product, usually through collages, and sometimes with minor style guide elements. Great for communicating a consistent product atmosphere during the early stages.
- Change Log — Somewhat of a relic from the waterfall days, but occasionally useful for settling disputes or general record-keeping.
Since the less documentation the better, ask yourself whether or not these will actually help you generate better designs before committing to any of them.
For example, some of our customers use a hybrid approach that combines lightweight requirements documents with annotated UXPin prototypes. Instead of prescribing every requirement in the document, they describe the guidelines and then link to the user flows and prototypes for the most up-to-date visual representation. Designers and developers can then both annotate the prototype to map out the technical implementation.
Card sorting, field studies, participatory design — these all lend their own type of insight to the process. The methods we mentioned above, however, are what we consider the bare minimum. They are the proven methods that any company can implement.
For more real-world advice on improving UX design, check out UX Design Process Best Practices. The free 100-page guide provides tips on the whole UX process from gathering requirements to testing designs.