Help! We have no user requirements!
What to do when others are making things up
When you read UX text books, or watch talks by “Industry Leaders”, they generally talk about doing reams of generative research during their Discovery/Understand phase, long before thinking about any kind of design solution.
It can be surprising therefore to many newbie UXers when they are asked simply to start wireframing (or worse UI designing) screens from the outset.
It can be hard to get stakeholders to agree to research at the beginning of the design process, mostly because many believe they already know and understand the problem, and expect you to work with “insight” that is more or less made up.
But it’s essential that in some way, we crow-bar the user back into the process at the beginning. Otherwise, everything you design will potentially be based on ill-informed assumptions, and dismisses the need for user-centricity (or any research at all) from the entire project. From there it is just a gentle decent into UX project hell.
The requirements struggle
Often you can get teams to agree to a business requirements session or some stakeholder interviews because it feels like a “briefing” session, but then find that no one around you seems willing to sign off on research which involves actual users.
This feels wrong for good reason: if you’re not involving the user, in any way, whether primary quant, qual, or even good quality secondary research — then you are not doing user-centred design. Sorry, you’re just Making Sh*t Up for stakeholders.
But sometimes, they just absolutely refuse to do user research. Fuming.
Personally I hate it when people make up user needs. But I hate it even more when they pretend that the made up sh*t is based on research (hello former marketing colleagues 👋)
So what can we do?
First off, it doesn’t have to be that way. It’s not a binary choice of All The Research or Ignore the Users Completely. It’s just about client and colleague education.
So let’s think:
How can we get them thinking about the users?
How can we make them realise they know nothing about them?
How can we make them perceive risk?
User requirements workshop
There’s a quick and (relatively) easy workshop you can run at the beginning of the project to try and introduce your stakeholder (or internal) team to the idea that:
- Users exist
- They are not you
- You need a hypothesis before you start designing things
- And we must then conduct research to prove/disprove it
How to do this:
1. Find all the existing research
Most companies have something: analytics, voice of customer programs, surveys, unfeasible or fantastical old personas, even market research.
Go through everything — and find anything that is not embarrassingly invalid. Then chop it up, highlight anything that could be a need. Yes, you’re spoon-feeding your audience. Suck it up.
2. Map a user journey
In advance of the workshop, draw a basic user/customer journey on a big piece of paper (or whiteboard, or digital whiteboard). Make it super simple — one line — the journey stakeholders are most likely to agree on.
For example, for an eCommerce website it might be:
Search Google> land on our website> browse> add to basket > check out.
TIP: You don’t want anything too complex at this stage because it will derail your workshop; stakeholders can end up arguing about minutiae, based on opinions not evidence and that’s the wrong mindset to be teaching.
3. Run the workshop
Assign teams at the beginning
Make sure you’ve organised them into groups in advance. You want 4–5 people max in each group. In each group you need:
- One designated leader. Make sure this is someone who has a basic understanding of “user is not me/my wife”
- No more than one loud or very senior stakeholder.
Hand out research chunks to each team
You will have grouped these in advance so consider who is in each group, and how much help they’ll need. Example: don’t hand a load of page analytics to someone who is not a data head. Or if you must, do some upfront translation to make the information understandable.
Brief them on this task
Ask them to go through the research, and write user stories for each need they identify “ as a.. I want to.. so that”.
Note: This is why you highlighted bits in advance — there’s no point making the task too complex for stakeholder. You teaching empathy, not research methods.
The user stories should not be about any solution at this stage. It’s just about the user’s need, agnostic of any specific functionality or platform.
Regroup
Get each group to present all their user stories.
One at a time, each US is placed on the journey map.
As you go from group to group, you may find duplicates — so affinity map them as appropriate.
There will be discussion as you go along. People will disagree with user stories, just as people disagree with research when it doesn’t say what they want it to. So remind participants that all of this is a hypothesis that will be tested in user testing later in the process (look — you’ve just got them all to like the idea of user testing.. well done), and make a note on the post-it for yourself of any particularly contentious issues. Because you’ll have to navigate them later.
In some cases, I’ve had some issues be so debated that I’ve even secured budget to go and research the issue before the project moved forward.
Similarly, take note of any “user need” that someone is clearly making up, especially if they are senior project stakeholders. These are issues you will absolutely need to navigate later on, and/or integrate into future research.
4. Write user requirements
Once this session is complete, simply turn those user stories into user requirements documentation, but be sure to mark them as “hypothesis to be validated”.
Be sure to keep reminding stakeholders throughout the project and until actual users are involved in research, that these are interim user requirements. It keeps the need for actual research front-of-mind.
What are the benefits of this approach?
- It’s quick. You can do this workshop in 2 hours, with minimum a day upfront to deep-dive the desk research.
- It takes minimal stakeholder time — any additional rigour comes from your prep and desk research time up front
- It introduces stakeholders to the idea of the user as not-them
- It makes them think about people they’ve never met and connects user needs to experience design decisions
- It makes them question sources, and consider whether they are a reliable and adequate as a basis for this project — a simple introduction to the concept of evidence-based design
- It makes them ask questions about the users, which can be answered with future research
- It makes them aware of assumptions and risk. Note: if you have anyone in the room who is interested in reducing risk, that person is your future influencer for getting appropriate research budgets assigned. They can come from ANY department from finance to dev to C-suite.
- It makes stakeholders aware what is and is not opinion — and how insisting on opinion-based design makes them responsible for user outcomes.
- It forces them to take responsibility for the impact of relying on Things That Are Made Up, and any future project failures. (realising the impact of this responsibility often shifts decisions — no stakeholder really wants the project to fail, they just don’t understand the consequences)
- It starts to make user testing or future evaluative research something that is a sensible next step.
- Once there has been a feisty opinion-based discussion or two, they start to realise how much easier it will be to make decisions as a group when there is actual evidence to guide them.
What if there is no existing research, but the clients are willing?
Sometimes you get clients who are willing to do the workshop, but they insist that they know all the user needs, even though they have no previous research or evidence to back this up.
There is a way to engage clients around what they do/don’t know, even if there is no existing research.
In this scenario, you run the session with the stakeholders as user needs proxy.
- Put them in groups
- Assign each group a part of the journey
- Have them state the (ahem) “known” user needs at that part of the journey and map them as described above.
This really is close to the bullsh1t line, but you should at least get an idea of their assumptions about users. As you go through the UCD project, you might even validate some of those “known” needs later in the project. But most likely you’ll find that a lot of them are wrong, and this can be a really interesting discussion later in the project.
Either way, using this approach you can get them thinking about users, what they do/don’t know, and even more importantly, you’ll know what assumptions you’re dealing with on the project.
What if they won’t even do this?
Clients and stakeholders need to understand the risks inherent in all of their decisions — it’s your responsibility to make it their responsibility. After all, they may not have seen a project horribly crash and burn before due to lack of user consideration.
You can explain the potential outcomes to them. Stakeholders usually don’t want projects to fail before they start. If you clearly explain the risks to them and they still want to proceed, then to some extent that’s their decision. In my experience, an honest conversation around “things I’ve seen happen before when users/research is removed” can make them rethink the role of research.
But ultimately, you really can put your foot down. If they won’t even discuss users or research, but they have engaged you to do UX work, then it might be time for an honest discussion about whether they really need YOUR services. There are a lot of designers out there who will happily colour-in forever based on someone’s opinions in exchange for money. It doesn’t have to be a qualified, valuable UX person who could be making a real difference somewhere else.
It’s always worth fighting on behalf of users. However — it’s also important to know when you’re fighting a losing battle. If this is the case, there may be a point at which (in the interests of self-preservation) it is time to go and work somewhere where your skills are genuinely needed and appreciated.
If you found this useful, consider subscribing for free to get email alerts when I post new articles, or you can join Medium for full access to my article archive, plus everything else on Medium.