G U I D E
Getting started: user research for rapid digital innovation
How to find the balance between knowledge and time investment
Tips from the field
How much do we need to know about the people we design for to make a confident decision about what to build? I help organizations find their sweet spot of certainty through user research when innovating at high speed.
In 2020, the teams I worked with have conducted qualitative research with over 140 people. Many of the sessions I have facilitated myself. Including 1:1 interviews, diary studies, contextual inquiries and usability tests. All teams have launched MVPs within a matter of weeks, improving them ever since through a tailored, lean way of user research.
The following recommendations are the essence of what I have learned. They aim to help you find an actionable balance between knowledge and time investment.
This way of approaching user research will enable you to gain the speed you need to in order to compete in the unforgivingly fast software industry.
Why does speed matter? One of the biggest risks for any software is the risk of delay. A major shift in the industry? A sudden change in management? If your product has not yet launched and proven to be valuable, even after months of development, it is at risk to be abandoned. It happens all the time. Also, whilst you take it slow, others won't. Don’t be the organization missing out on opportunities because you’re too hesitant to act before you know it all.
Is it an actual problem worth solving?
Many people, when they think of user research, they think of testing ideas. But the most essential form of user research happens before teams decide what to build in the first place. It‘s that powerful moment when you investigate the problem space to find opportunities worth acting upon.
Ideally, this is how innovation starts. In reality, it almost never does. In one way or the other, someone (usually higher up the food chain) will have an idea about how to fulfil their business targets.
What follows then is the one, often overlooked step, where designers are most needed. Particularly when you seek to truly innovate. You need to validate whether business hypotheses are rooted in an actual need from real people. This step needs gut. At some point, it will involve telling powerful people their idea isn’t worth pursuing and offering a better alternative.
My best advice: before you start writing one line of code, go talk to people who you believe are your target audience. Observe what they struggle with. Ask open-ended questions. Listen with the intention to change your mind rather than confirming what you already believe to know. This step will help you form a proposition hypothesis that is based on first real-world evidence. It will have a significantly higher chance of success.
Start simple, do it yourself
Don’t rely on external partners or other parts of the organisation to do user research for you. Upskill your product teams. This will save you a lot of time and money and will give you the flexibility you need. Get started by learning how to set research goals & map assumptions. Learn how to pick the right method and how to conduct and synthesise the research, bias-free.
Are you just getting started with user research? In that case, I recommend reading Erika Hall‘s 📓 Just enough research.
Qualitative 1:1 interviews with self-sourced participants are a great way to get started. Read how to find potential candidates aside from friends & family to get unbiased insights here. 1:1 interviews will provide your team with the why’s behind people’s behaviours. Running them on a regular basis will reduce the stress to get everything right the first time. It will give your team the freedom to experiment a little.
Whilst working remotely can limit the methods, there are plenty of great ways to run user research remotely. Plus: talking to users in their known environment (aka home, these days) might help them to behave more naturally and open up more.
Make user research a habit
User research is like brushing your teeth: there is no point in doing it for an hour before leaving the house. 3 mins are sufficient, as long as you do it regularly. If you don’t do it, phew… fixing teeth hurts and it will cost you a small fortune.
I encourage teams to ditch massive up-front research and run research at least every second week instead. If this shocks you, let’s talk about the scope. A frequent cadence means a smaller scope than the research an ‘old world’ UX designer might have run every couple of months.
Test whatever you have. A paper sketch, a rough wireframe, a prototype, the product of a competitor. If you don’t yet have something tangible to show, observe how people get the job done now. Ask open ended questions.
Also, stay curious. Exploratory research isn’t just for the start of a product. It’s not like you ask openly at the beginning, and in later iterations you only validate ideas. I like to ask a couple of exploratory questions at the start of every 1:1 interview. Regardless of the stage of product development.
Replace big studies with real-world experiments
I see organizations do excessive user research mainly when it is a separate discipline, away from the product teams. Often with a dangerous lack of speed, business thinking & connection to the real world impact of their work. Sometimes research departments have fought hard for their existence and tend to over-do the job in order to prove their value. I am an advocate for balanced software teams. Having a user researcher embedded within each team will prevent them from going off on a tangent.
Some people worry that user research with 5 people per week will not provide teams with enough certainty. You could set up a big, quantitative study with thousands of participants. This is likely to take you a couple of weeks, if not months.
The reality is: businesses simply cannot afford to spend months on studies in order to decide whether they should start to build a product. They need to validate their ideas as fast as they possibly can.
Now, what do you do instead to get data on a larger scale? In software, big, time-intensive studies are replaced with ‘beta versions’ or ‘minimum viable products’. They are experiments that take as little effort as possible to run. They aim to test whether an idea will actually work in the real world. These real-world experiments can take many shapes and forms (a video, a landing page…). They deliver more relevant evidence than a study, faster.
Make research a team responsibility
Do you know anyone who gets excited by reports? I don’t. Designers: don’t go away, interview users and then present your team & stakeholders with the synthesized results. You’re the masters of designing experiences. I’m sure you can find a better way for your team to learn about user needs and build empathy. Inviting the team to do user research with you is a great way to start.
At VMware Tanzu Labs, alongside the designer, we also have product managers and engineers run user research sessions. They are also great notetakers and take part in the synthesis. It’s an invaluable skill to truly listen to people and get them to open up. It’s a powerful provider of „why“. When synthesizing, more diverse brains will help prevent bias. And you can skip updating your team because everyone has been part of the process.
It’s also a very powerful way to engage stakeholders. Get sponsors to experience what people actually worry about. Let them hear first hand what they don’t care about. Let them see how people sigh, smile or struggle when using your product. Invite them to a little dip into reality.
Keep documentation lean
Have you ever heard of minimizing waste in the context of lean software development? It means that teams ruthlessly prioritise work that will benefit a user over all else. For the sake of efficiency.
There is also a lot of waste in classic UX and UI work. Documenting user research excessively is a good example. Think of it: instead of building that dreadful slide deck or cumbersomely transferring insights to a wiki, the designer could work on something that actually delivers value to users. A way to reduce documentation efforts that has worked well for me in the past: I like to use Miro for the team to take notes and synthesise.
The great thing about tools like Miro is: at the time you finished synthesis, your documentation is done, too.
There is one exception to my self-inflicted rule of not leaving Miro. My dear friend and designer Wal Gedeon introduced me to the concept of the Slack-snapshot: a list of 3–5 top-insights. I post them in a common Slack channel, the very evening after synthesis. I like to use it with bigger teams or when working on a high profile project with a high interest across the organization. Creating the Slack-snapshot should only take you 5 minutes.
Thinking of long-time insight documentation: I like to have design artefacts like personas or jobs to be done also live in Miro. That way, I can easily update them with evidence. People’s behaviours and interaction with software changes over time. That’s why I’m hesitant to create huge user insight databases. I would not want to risk building a product on the basis of 1-year-old insights.
Create a culture of genuine curiosity
I believe that user research can only flourish in an environment where failures and successes alike are humbly analysed and taken for what they are: an opportunity to grow. For software and people alike.
UX standards and the designers’ expertise are a great place to start but can never replace getting actual feedback from people. Today’s challenges in software are way too complex and unpredictable to be solved purely based on best practices or past experience.
Users don’t care about what deciders and experts think or want. If you do not provide them with the most helpful way of getting a job done, they’re likely to get the job done differently, without your software.
This article started with how user research will help you innovate at high speed. It ends with how user research will improve your work culture and ultimately make you a better person.
Practising evidence-based design will help your team to adopt a growth mindset. It starts with the product. But it will eventually create a culture that values interpersonal feedback, too. People will become more supportive of their individual growth.
Start listening to people with humble curiosity and the genuine intention to have your mind changed by what they say. It will make you have better conversations, professionally and personally. Ask open questions, get behind people’s motivations. I guarantee you it will show new perspectives you didn’t know could move you.
TLDR; Summary
- User research isn’t just testing ideas. Start with investigating the problem space to find opportunities worth acting upon
- Don’t outsource user research. Upskill your team instead. Learn how to plan, conduct and synthesize research together
- There are plenty of research methods you can try, most of them are working well when remote working
- Conduct user research weekly or biweekly with 5 participants. To keep up with that cadence, reduce your scope
- Replace big, time-intensive studies with real-world experiments. They deliver more relevant evidence than a study, faster
- Involve the whole team in user research. It will help to build empathy for users and it helps reduce bias in the results
- Minimize waste through lean research documentation. Use a collaborative whiteboard to take notes & synthesize to replace slides
- Create a culture of feedback and learning. Embrace failures as well as successes as an opportunity to grow
How do you balance getting the user evidence you need with maintaining a high speed when building software? I’m curious to start a conversation with the genuine intention to have my mind changed 🙏 Find me on LinkedIn.
A big thanks to Wal Gedeon, Anna Shausmanova, Jana Lasser and Erin Cobb for sharing your thoughts and feedback. They form the basis of this article 💚
