In this post Andy Budd talks about the evolution of research, how the role of research develops as a business scales, and where the sweet spot for research typically sits along this path. He also shares his thoughts and recommendations around what it takes to be a great researcher in 2022.
We recently caught up with Andy Budd, internationally renowned design leader, speaker and author. With over 20 years of design and research experience, previously Founder and Managing Director at Clearleft and most recently Venture Partner at SeedCamp, Andy advises businesses on how to build, scale, and professionalise their design practice.
In this post Andy talks about the evolution of research, how the role of research develops as a business scales, and where the sweet spot for research typically sits along this path. He also shares his thoughts and recommendations around what it takes to be a great researcher in 2022, highlighting the importance of stakeholder communication as a key skill.
Well it's safe to say that five or six years ago, many companies didn't have much by way of design research.
Organisations would often have market research owned by the marketing department but not much in place to understand exactly what users and customers needed from the product.
In these early stages of UX design, a lot of people who started to self identify as UX designers had skills across a fairly broad range of areas - one of these areas being research.
So for early teams, you often find that the research aspect is shared amongst three or four designers. And I tend to find teams often don't have a dedicated researcher until they hit five or six designers.
Prior to that, every designer spends around 10-15% of their time doing research. Then once you've got five or six people doing this, that can roll up into a single researcher.
In the early days, dedicated researchers are often in high demand and overstretched. If you're hiring your first design researcher, they often tend to be generalists rather than specialists, which means they can end up struggling a little to create the overall shape of research for the company.
So as companies scale through Series A to a Series B level of funding, the research function tends to be slightly underdeveloped and slightly overwhelmed.
At a certain point, something starts to slip. Around the Series B to Series C size, when you've got maybe 30 or 40 designers, the research team often scales up rapidly. I've seen this happen time and time again, where companies go from one or two researchers to five, 10, or more, in the space of 18 months.
And so you can suddenly go from famine to feast. This is typically where the role of research operations comes in; to help with looking after all the administrative and operational areas that surround the research itself.
So in a lot of early stage startups it’s nearly always a visionary founder, who has felt the pain of the product they’re building, that has a really strong vision of what the first version of the product looks like.
And actually, going somewhat against my natural tendencies as a designer and researcher, I think you can build quite a credible first version of a product with minimal research if the people who own the roadmap come directly from the group of users they’re serving.
However, three or four years into their journey, the founding team of the organisation often become separated from the reality experienced by their end users.
This is where research really starts to come into play. In those early stages, once the founders have pretty much delivered all of the ideas that they had in their own personal backlog. At this point, the real benefit of research becomes finding new problems.
It's my opinion that research is best deployed around finding problems.
But unfortunately, once your company becomes really big and research becomes operationalised, a lot of executives are scared of making the wrong decision and research stops being used for this. Instead, it’s used to justify, validate, and prioritise strategy, and it very quickly becomes a mechanism for decision making.
Executives, rather than saying “I have a strong case for this” or “Here are a load of problems that research has found”, start to use research to prove which of a number of approaches is the best path forward. I think this starts to become somewhat problematic.
You ultimately want your decisions to be research-informed and not rely on research to tell you exactly what to build, which research can’t do - research can only inform you. Leaders need to have good product sense and decision making skills in order for this to work effectively. Research can definitely help executives hone this sense.
However If every single product initiative or slight tweak that you come up with needs to be validated before a decision can be made, you end up creating these really large research teams.
And the more people you add to a research team (or any team for that matter), the more technical debt or administrative debt you accumulate, and the more conversations you need to manage.
So there’s this sweet spot in the middle for research, this ‘Goldilocks zone’, where researchers don't have enough time to validate every idea but do have the time to talk to users and understand their biggest problems.
In this scenario, researchers are able to surface new problems and allow the product team as a whole to then figure out which one of these problems they’re going to solve for next.
To be a great researcher, you need to take a design approach to research. Research is a form of design, it's a higher form of design, and it’s ultimately about understanding the problems that people are faced with.
Products, user needs, teams, and the objectives that these teams are working towards are constantly changing. So you need to be able to constantly change the approach you're taking in order to serve the needs of the business and its customers.
Emma Boulton, who's a fantastically talented design researcher and a key figure in the ResearchOps movement, produced a really helpful article a little while back called the eight pillars of user research.
My recommendation to anyone conducting research would be to go and review Emma's article in detail, understand the key pillars and then focus on getting really good at executing in each of these eight core areas.
Sure. So one of the pillars in Emma’s article is around knowledge management and the communication of research findings, which is a big problem that most companies have.
This isn’t so much of a problem when a team is small because the sharing of research becomes tacit knowledge. The problem develops when you start to scale and need a way of sharing information with others who weren’t able to observe a particular experience first-hand.
The problem I see with all teams is that research happens once, an individual owns it, then it gets locked into and stuck in a PDF or emails. That person leaves the company, someone else comes along and then they can't find the previous research and valuable insights become lost along the way.
Having tools where you can easily capture and resurface research, and where insights don't always have to be owned by the research team but can be shared across a whole range of different stakeholders, is where things are heading.
If there's a way that you can tie insights into how a decision gets made, I think research becomes increasingly powerful.
One of the problems a lot of teams have is that design decisions often happen behind ‘closed doors’ and then somebody comes in later and asks people to justify why a decision was made.
Often the decision made was a really smart one at the time, but months later there are no receipts for why that decision was made and you end up having arguments around people’s opinions.
One way I’ve seen researchers successfully solve this is to write week notes for their stakeholders, where you're constantly explaining “Why we did X” and “Why we did Y”, providing people with the opportunity to ‘go back and look at the logs together’.
My old team at Clearleft started writing postcards each week for the rest of the team. They would literally create a little postcard for all of their stakeholders that was emailed out on a Friday covering what they did that week, the decisions that were made, and why, as well as detailing what was coming up next week.
This made people feel that they were involved in and engaging with what was going on. Rather than stakeholders not having a meeting for three or four weeks, then suddenly wondering what’s happening and starting to put pressure on people to begin communicating.
At any time if you’re asked “What's happening in the project?”, you’re able to quickly communicate this. The insights and your set of decision receipts are readily available to help you respond to these requests effectively.
If you can constantly feed your stakeholders with updates about what you're doing and why, it makes them feel safe that you and your team are in control. This tends to stop them suddenly jumping in to find out what's going on and kicking up a stink in the process.
Dualo is an insights hub used by digital product teams to get more repeatable value from their user research and insights, so that stakeholders can make informed and timely decisions across the organisation. If you're interested in learning more, please request a demo and a member of our team will be in touch.
I'm one of the Co-Founders of Dualo, passionate about research, design, product, and AI. Always open to chatting with others about these topics.
Join our growing community and be the first to see fresh content.
.svg)
Repo Ops ideas worth stealing
Interviews with leaders
.jpeg)
.jpeg)
.jpeg)
