How to Create UX Design Requirements

Firstly, I always want to understand what I will be designing and secondly, I always want others to understand what I am designing.

5 min readFeb 10, 2022

This may sound like a very small ask, but it is usually the hardest part of product design. The start of a project is like a new relationship. You stay up late at night wondering what the project is up to. Will the project become successful over time … Can I spend all my time with this new project? … Does it love me back, but I digress.

I have worked for many types of companies in my design work-life including mom and pop shops, startups, mid-sized companies, SAAS and getting proper design requirements has always been one of the toughest parts of the job.

Not all designers work with product managers, or project managers. For those of you who work in a pure design silo, I’ll try to write a companion article about how to work with non-product type stakeholders as a follow-up.

Lets kick this off and start with one of our best work friends: The product manager.

Getting started and using templates for project intake

I am sometimes confused by developer language and also by the many differing ways that product managers write. Some write crisp requirements that are easy to follow, some write in a very technical manner as they may be former engineers, some write abstract bullets, and others… Well, they don’t write. Don’t get me wrong, I am not trying to knock product managers. They have extremely difficult jobs, are always up against the clock and are usually under the gazing monocle of the CEO.

In the best case scenario, you kick off a project with a product manager, your lead developer for the project and go through the requirements together. You then decide on a direction and go off on your merry way knowing exactly what you are building. That has happened to me very few times over my product design career. Here is a list of things that can get in the way of that:

The product is a very technical nightmare, such as designing an AI engine.
People go on vacation, take leave, or leave indefinitely.
Product priorities may change over time.
Disagreements on what to build.
Teams work in silos.
High level stakeholder(s) disagrees with the direction.
The product is held up because of connected initiatives.
Technical development limitations thwart a good design.
On and on and on…

Don’t get mired down in the bog. Here is a little guidance on how you can move forward:

Set an hour long meeting to understand what the product manager wants to build and why.
Have a template of questions that you ask the PM.
Invite the lead developer.
Have them lead you through the existing feature and create a very low-fi journey as they talk. Writing bullets works as well.
Take screenshots and important notes.
If no existing feature, take crisp bulleted notes around what they are trying to build and why.
Ask if there are any current features in the offering that are similar. This can help with thinking about the flow design.
Who are the users of this product (or intended users) and does the PM have direct feedback from them?
Size the project to the best of your ability.
IMPORTANT!
What does this initiative mean to the organization. How will it generate revenue? In essence, what is the priority?

What happens if your PM is unresponsive?

Don’t sit back and wait for them to come around. I have been guilty of it like any other designer. Instead, judge by the sense of urgency for a specific project and move forward if you can’t get a meeting, or if communication is at a standstill and the timelines are getting short. Not as good as a PM intake meeting, but here are some ways to get similar information.

Request a meeting from the lead developer
Get access to and start contacting sales leads
Get access to and start contacting customer success leads
Try to find anyone inside the organization that understands the asks and interview them
Let your boss know you are blocked

For existing features: Test it yourself and often!

Overall, you should be able to start formulating some ideas around the needs and understanding of what you are being asked to design.

Next, journey map and decipher where in the journeys the issues exist and at what point(s) this new feature request could be designed into.

I did this recently for a feature named SAR (Subject Access Request) for Egnyte, the company I currently work for. Here is a look at how it ended up looking (Some blurring due to privacy policies):

This happened organically starting with journey bullets during the PM meeting. Then, I created this Kanban view with the journey broken out visually. After that I looked through all my meeting notes and started putting them in as crisp bullets where they were in the overall journey.

This is literally the inception point of UX requirements.

After it was completed we sat down with our PM and decided what was priority. We created a ticket in JIRA (Project management software) and sectioned out all the bulleted notes into our release cycle so we could complete the work in phases over time since it would be too much for MVP.

Summary

This may seem like a lot of work and sometimes it is, but I’ll tell you that there’s nothing worse than designing some beautiful UI, crisp flows, micro-interactions, use of an awesome presentation and then management tears it to ribbons because it doesn’t meet organizational product direction. Hope this helped some of you out on becoming a better UX Designer.