At its best, UX research surfaces insights and enables progress; at its worst it just gets in the way.
There are many objections to conducting UX research, but the most common I hear is ‘We don’t have enough time.’
I can certainly sympathise with this inclination to ‘just get it done’.
With the move away from overly managed waterfall projects, to cross-functional agile teams, it can be hard to find where in the process research best fits.
Is your UX researcher part of the cross-functional agile team, or are they split out as their own separate business function?
How is it possible for a team to be simultaneously researching, designing, building and testing the same feature?
How can we be deciding what to build, while we are in the middle of building it?
Embedded but blocking
One popular compromise is to embed UX research within an agile team, but have the researcher work a few sprints ahead. A sensible-sounding solution, however it often has the unwanted consequence of creating tension between the rest of the team and the UX researcher.
A team can only work as fast as its slowest process — so it can find itself continuously blocked by a single UX researcher trying their best to follow a best-practice design process.
Another issue with this approach is that you have essentially just created a terrarium-sized waterfall process within your agile team.
Lastly, this doesn’t work because good research takes time. You need time to get out into the field; you need time to understand users; and you need time to follow as many insights to dead ends as it takes, before you find that one core insight that unlocks product genius.
This kind of research can’t be locked away in a single sprint or two.
Non-blocking but abstracted
Another option is for UX researchers to be in their own separate department, split from the agile teams they support, and often working weeks and even months in front of the developers.
The clear failure here is that research is at its best when it is fresh and relevant. User research is only beneficial if it leads to great product experiences for users. The further research insights are from their practical use, the less impact they are going to have.
The biggest weakness of this model is that, separated from the hard pragmatism of the developers and testers, designers can get a little too creative.
There becomes a chasm between the ‘ideal experiences’, and what can be pragmatically built. Designers get frustrated by developers who always say no, and developers fatigue by constantly failing to realise the dizzying heights of a designer’s wild imagination.
How to embed UX as its own parallel process
As you may have gathered, what we need is a best-of-both-worlds solution.
We need to decide which UX activities should remain embedded within the agile team structure, and what activities are best spun out into their own timeline.
The parallel UX process
A good way to visualise this is by splitting research activities into two distinct camps: foundational research vs. directional research.
Foundational research is the user interviews and ethnographic research that creates a solid foundation for decision making.
Directional research is the pointed usability experiments you run that answer specific user questions to shape the day-to-day direction of the product.
Directional research
Directional research is pointed and has a short life span. It is conducted to answer specific usability and product desirability questions.
Directional research lives within, and is directed by, the agile team. For this to work well, experiments need to be kept small and self-contained. Experiments should answer one specific question, or validate one specific hypothesis.
Directional research gets communicated within the team and to the wider business simply. The output should be a specific yes/no answer, or a ready-to-implement recommendation — not a 14-page report.
For example:
Question
Should the button label be ‘Submit’ or ‘Register and Continue’?
Answer
We ran an A/B test of 500 visitors, and ‘Register and Continue’ performed 20% better.
Question
Are there any usability issues with the current screen designs?
Answer
We conducted a usability test with 6 participants and found 4 potential issues. We recommend that you (1) make the registration button more prominent, (2) change the format of the address field to accept P.O. boxes, (3) move the …
Question
We believe that by adding a new feature, our first-time users will find the product more helpful and upgrade to the payed version.
Answer
We ran a usability test on an early prototype and found that first-time users were overwhelmed by features and did not upgrade.
Foundational research
Foundational research is the user interviews and ethnographic research you conduct to understand your users’ wants, needs, goals and motivations, and to get a well-rounded picture of your users.
Note that in the diagram below the value of this foundational research does not stay static. You can’t just talk to your users once and call it a day. The market changes, technology trends change, your users change and hopefullyyour product changes. Your research becomes less relevant and more stale the older it gets.
This means that foundational research should be ongoing. Insight builds over time and you should never finish talking to and learning from your users.
Foundational research needs time to be conducted well. Teams need time to get out into the field and observe user behaviour. The team needs time to ask countless questions of countless users until you uncover that gold nugget of insight that so many companies before you have missed.
Examples
Discovery or ethnographic research
User interviews
Personas
Journey maps
Empathy maps
JTBD
Bringing foundational and directional together
These two streams of UX research can run independently of each other, allowing for both fast and slow research to exist side by side.
So how do I get it working with my teams?
If you’re a regular reader of Medium and the 1000s of articles on here that cover UX and product process, you’d already know that there isn’t a one-size-fits-all answer. You need to find what works for you.
So instead, here are 6 tips to help guide you through implementing your parallel UX process:
1. Your agile team is always the central and guiding force
For teams to be successful in an agile environment, they need to be truly self directed and autonomous. They need research to help inform their decisions, but they shouldn’t mindlessly do whatever the UX research says.
This means the agile team should feel empowered to both initiate research, and conduct it.
2. Be clever with batch sizes and time boxing
Testing one user early in the project is better than testing 50 near the end.
— Steve Krug
It can be tempting to want to conduct all your research at the start. It can be tempting to want to have the answer to every question before committing to any code.
This isn’t realistic. You can never know ‘everything’ there is to know about a specific topic. You may have noticed that the more you learn about something the more you learn you need to know.
You need to be able to break down your research into small, manageable, time-boxed chunks, and use what you learn to inform where you should research next.
3. Use the power of the team to experiment
You are a cross-functional team. Act like it.
The best way to understand user behaviour is to build something, release it and see how users use it. Again, start small: ask yourself what is the smallest thing you can build to answer your key user question.
Will customers buy my product?
Develop a landing page, and see how many users click ‘Buy Now’.
Will customers use this feature?
Create a button for it and see if they click it.
Should the button say ‘Register’ or ‘Sign Up’?
Run an A/B test and find out.
Developers and testers can be a UX researcher’s best friend.
Once you have finished your experiments, make sure you take time to learn from what you have discovered, then implement it.
4. Find time to re-factor
(Good) developers take time to constantly refactor and clean up their code. We should take the time to do the same with our experiences and interface design.
Spending time removing technical debt makes code more reliable and sustainable; removing our UX debt does the same thing with our experiences.
Developers and product owners: if you spend a small time each sprint tidying up interface issues rather than charging ahead with more and more newfeatures, you will find that your UI and UX designers will relax and start working with you instead of against you.
5. UX is a true cross-functional skill and responsibility
It is too important to be limited to just one team member.
You can’t just hire a ‘scrum master’ and call yourself an agile business. In the same way, you can’t just hire a single UX designer and call yourself human-centred.
Everyone on the team needs to be thinking about the user. The UX designer needs to be the facilitator of that effort. Not the owner.
6. When in doubt, embrace the Lean UX principles
In summary, UX research can’t be rushed but it also can’t be uncapped.
Some research activities will take longer than others, but it’s most important to differentiate between research that provides specific value in the moment vs. research that pays off strategically in the long run.
Foundational research methods will help you decide where you want to go, while directional methods will give you turn by turn directions for how to get there.
