User-Centered Design: Specifying Requirements For a Project

Does a specification still matter for design? After the kick-off product workshop, some teams eliminate the stage of writing design requirements specification documents in favor of sketching.

However, sketching may not be enough for a common understanding of what has to be delivered in the end. Otherwise, when multiple alternative solutions are sketched, discussions can become endless, the project will split in different directions and in the long run, the need for specification documents will arise anyway.

In distributed project teams, when people are geographically scattered, it’s particularly crucial to have a specification that sums up the desirable outcomes of the project. Often stakeholders do not clearly explain what they want, not mentioning they rarely know what their users want.

The goal of this article is to tell you how to create a bigger picture of your project by crafting a requirement specification from a user-centered perspective. We’ll cover the following:

• how to structure design requirements as the first step of the project;
• how to focus on real end users and real tasks when creating such a document;
• how to create documents that every team member understands.

What is User-Centered Design?

User-centered design is all about making a product usable and interactive for uses. To name a few benefits, user-centered products enhance the user experience, increase customer loyalty, and reduce costs on onboarding and training.

There are a lot of user-centered design guidelines, though few of them are actually applied in practice. That’s why it’s critical to document a user-centered design process in the project specification and make sure that the outcome will conform to quality standards.

In our recent article, we covered six principles of user-centered design. The process of design requirements specification described in this article is based on these principles.

Stakeholders

What stakeholders are involved in the requirements specification process?

Invite project stakeholders early in the project, so that they take part in shaping the requirements for the work. UX/UI designer, salespeople, marketing reps, C-level executives — think of those people who make decisions and know users better.

Methods

The most effective way to specify design requirements is to facilitate workshops with designers and project stakeholders about project scope, objectives, and expected outcomes. What methods could be used for each stage of the requirement specification process? Just to name a few:

• Brainstorm.
• Interview.
• Observation.
• Paper prototyping.
• Storyboarding.
• Task analysis.
• Heuristic evaluation.

Each of these methods could be used for different steps of the process. Let’s see what these steps are.

Requirements Specification for User-Centered Design: Step by Step

So how do you create a requirements specification document, systematically focusing on the end user? There are some processes that help us better understand user requirements without cumbersome business analysis techniques.

1. User and Market Research

On the research step, you should determine the exact requirements to the product design. Following the user-centered approach, these requirements are shaped through the lens of users’ needs. In fact, user requirements are defined by the tasks that users perform when interacting with the product.

Market analysis

Review similar systems and products. Features of similar (possibly competitive) systems, which may need to be included or definitely excluded, are documented.

The next step is to work out the information about the competing products: what features they have, how users interact with them, what features should be considered to the inclusion to your product and which ones should be avoided.

User context

The next step is the system requirements elicitation with the help of a project brief or stakeholders’ interviews.

Identify who are the users and stakeholders of the product, what are their roles in the system. Specify their skills, demography, personal details, physical and social context of using the product. Write down this data.

Also, ask stakeholders what they or their customers like or dislike, what are their pain points, and, most importantly, what are their goals and how they usually achieve them.

Once user goals are specified, you should understand what tasks users do to achieve these goals.

User research methods for this step: interview, survey, observation, task analysis, card sorting.

2. Prototyping the Requirements

After general usability goals are stated in the previous stage, you can elaborate on the most complicated project requirements with the help of prototyping.

Personas

First, you need to create personas. A persona is a generalized portrait of a potential user of the product.

For example, that’s how the simplest user characteristics of a POS system interface design will look like:

• Geography: US
• Age: 25 upwards
• Gender: mostly female
• Language: English
• Education: no specific requirements for education
• Accessibility level: may include people with physical or visual disabilities
• Special skills: touch typing, multioperation  
• IT Experience: low to none
• Concerns: possible fraud, human-factor mistakes, system lags, complex interface.

User scenarios

Then, focus on the goals of personas. Identify task scenarios to shape the main requirements of the user. Think of at least one scenario for each user goal.

What does this mean? You need to identify the basic steps that a user takes to complete each goal. To specify these steps, you need to think about possible events, problems, and obstacles that emerge on the way of completing them.

Here’s one of the possible scenarios of using POS system:

A user payment wasn’t accepted: insufficient funds. This leads to the cancellation of the purchase, partial payment of the purchase, payment with another card, putting a customer on hold while he’s looking for another card and working with the next customer at the time.

High-level considerations of this scenario may include the danger of robbery and the discomfort of other customers.

Some of the scenarios wouldn’t represent problems. Instead, they will generate ideas for design improvement.

At this step, you have to define usability criteria to measure the success of completing the task and estimate the usability of the product.

Testing

No matter what type of prototyping methods you use, you’ll need to test your hypotheses on real users. Wals them through your prototype or discuss each step of the storyboard in groups and estimate whether the tasks could be efficiently completed.

Research methods for this step: task observation, brainstorm, creating personas, storyboards, use cases, task analysis, paper prototype, usability testing.

3. Requirements Definition For a Document

After conducting user research, such as a task analysis, surveys, interviews, and observations and prototyping user scenarios that may occur while interacting with a product, you should have enough information to develop a set of requirements for the system.

What kind of requirements are there?

Functional requirements

Functional requirements are all about what the product does. They include the features and interface elements that are necessary to support user tasks. They are often documented in the form of use cases or user stories and outline the goals that must be achieved with the system and the approach for implementing the system.

Business requirements

Business requirements specify why the company needs this product and what benefits the product is supposed to bring to the company. In this part, you need to specify the needs of a product from a commercial point of you: for, example how many users should download an app within the year of launch.

User experience requirements

User experience requirements affect all the other requirements as long as it focuses on users and tasks that should be completed with the help of the product.

As we are talking about user-centered design requirements, user experience should be at the core of the specification document. User experience requirements have an impact on all other requirements. This is because, in a user-centered design (UCD) process, users come first. What types of UCD requirements can be there?

• The efficiency of use:  goals are easy to accomplish quickly and with few or no user errors.
• Intuitiveness:  the interface is easy to learn and navigate; buttons, headings, and help/error messages are simple to understand.
• Low perceived workload:  the interface appears easy to use, rather than intimidating, demanding and frustrating.
• Accessibility: you need to support design for people with impaired vision, hearing, or motor skills. That usually means adjusting the font size, color combinations, etc..

Technical requirements

In the end, you need to specify how the product will achieve its functions and data structure from the technical standpoint including software, hardware and exact technologies to be used.

You also should mention technical constraints to limit design activities to a reasonable level.

4. Writing a Specification

During research and prototyping steps, you will produce a lion’s share of the defined requirements for the specification. The final step will include structuring everything you’ve got. What should the document consist of?

Introduction

The introduction will prepare the team for what is going to be next. It may include the following parts:

• How to use the document
• A brief overview of the requirements
• Specialized terms glossary
• List of content

Main part

The main part includes requirements themselves that are structured under different headings:

• Functional requirements
• Business requirements
• Usability requirements
• Technical requirements

Diagrams & appendices

Various graphic elements such as flow charts, user flow diagrams, task flow diagrams, or pictures are usually put in the context within a document. However, the final requirement diagram which is meant to show sets of requirements and their relations can summarize everything that was stated in the specification, and therefore, is placed at the end, together with other appendices and references.

Some pro tips to make it better:

• Make the document easily editable: the process of requirements documentation will be iterative, so you’ll have a lot to change.
• Use simple language in writing, add schemes and illustrations whenever they help understand the meaning.
• Add prioritization tables which include all the requirements and rate the importance of implementation.

What is the Outcome?

The outcome is a documented set of user requirements for the future new system or revised system which serves as a guideline for design and development. If this is the first time you make a user requirements specification, and more projects are about to come, define standard templates for describing requirements.

In the end, make sure that:

• every team member understands what is written in specification.
• the stated project outcomes correspond to the stakeholders' expectations.
• the expected product focuses on users.

Designing a product from scratch? Let’s start with the requirements specification—fill in the form and we’ll develop one for you.