Introducing CYB’s research philosophy
Research is a vital part of the work we do at Caution Your Blast Ltd (CYB). From understanding our clients to learning about their users, detailed research brings us the knowledge and empathy we need to build innovative, user-friendly products and services.
So I’d like to tell you more about how we do that - and introduce you to the CYB research philosophy.
Our research philosophy is a tool designed to communicate the way CYB researchers think, and how we approach research projects. It was important that it was called a philosophy rather than process, as we feel passionately that this is a way to articulate the rationale behind the way we do things - the outcomes we’re trying to achieve rather than specific mechanics of research.
The philosophy visualises how we combine qualitative and quantitative data to provide rich insights that allow teams and organisations to:
Solve the right problem for the right people
Design and test innovative concepts
Evaluate and measure the usability and efficacy of solutions
As our research team scaled from a team of one user researcher to a team of user researchers and data analysts, we needed a way to bring our worlds together. It became important to detail our combined approach to research.
We wanted to detail the approach for a few reasons. Firstly, we needed to ensure that CYB researchers worked in a consistent way. With every researcher joining our team, they bring a wealth of knowledge and experience of ways of working. However, to ensure our clients continuously received the highest quality research, we needed to standardise these approaches.
Secondly, we wanted to communicate to clients exactly what research is, how it works, and what the benefits are. As researchers, we’ve all experienced reluctant or sceptical clients when it comes to research ideas. By documenting our approach, we aimed to empower our researchers to talk confidently about our approach and why it works.
Finally, we felt there was a gap in the research field, where we wanted to address limitations in other research processes. We found some research processes to be too:
Full of jargon
We believed that these formulaic approaches to research limited researchers' ability to sense and respond appropriately to the context they found themselves in.
Before starting our research philosophy, we first agreed on a set of principles that underpinned it, to help us guide its development.
Our research philosophy is focused on being:
Efficient - maximising productivity while minimising waste
This is drawing inspiration from Lean approaches, where we believe in taking a pragmatic approach to research. This means not doing research for research's sake, and prioritising the riskiest and most impactful research to ensure we're a productive member of the team.
We firmly believe that research is a finite resource. We can’t and shouldn’t research everything - our time and efforts need to be strategically deployed.
Responsive - utilising team and business knowledge and feedback
A good researcher is able to sense and respond to the world around them, spotting signals from the team, organisation and users to make decisions. Often we’ve seen teams only use insights they’ve gathered first hand, which is not only wasteful but neglectful. There is so much we as researchers can learn from knowledge already inside an organisation - and we should be leveraging that within our research.
Collaborative - democratising research approach and insights
Research cannot have impact when it remains within the research team. For research to be useful, it needs to be utilised and understood by everyone in the wider team. This means that everyone needs to feel ownership of the knowledge gathered from research. It also means bringing people along to the research approach
The core - starting research well
Fundamental to the success of any project is understanding the “what”, “why” and “how” of the research.
Firstly we start with the “why”. Drawing inspiration from the likes of the Lean UX canvas, we ask questions like: why are we doing this work? Why is this a problem worth exploring? Why now? Essentially we’re trying to understand the business problem and motivation behind the work. Importantly, this work doesn’t happen in a vacuum - this is teamwork to establish the context of the work.
Then we move on to the “what” - what do we already know about this problem, these people and existing solutions? What quantitative and qualitative data do we have to evidence what’s currently happening? This step is so important in reducing research waste, and leveraging pre-existing insights. Without this step we risk re-learning the same things time and time again.
Problem clarity, solution availability and complexity
Finally, we move on to the “how”. We ask ourselves - how are we going to proceed to answer our unknowns as a team? Using what we know about what and why, we critically assess three key concepts:
Problem clarity: What and how much do we know about our users, their lives, and what they’re trying to accomplish.
Solution availability: What solutions already exist that solve this problem - we ask if this is a problem that’s been solved lots of times before, and if there are industry standards that tell us how best to solve this problem.
Complexity of the problem space: Taking inspiration from the Cynefin framework, complexity in this sense can come from how stable and predictable a problem space might be. How complex a space is can impact the reliability and readability of the patterns we see in explorative research, and may mean that we need to take a different approach to understand a complex problem space.
An example of this is Artificial Intelligence (AI). In this space with low problem clarity and low solution availability, it is natural to employ explorative research. However, as this space is so quickly evolving, the complexity is so great that taking an intervention and measuring the response is much more likely to yield more robust research data and insights.
Once we have understood the “what”, “why” and “how”, we then choose how best to proceed. This takes in one of three approaches: explorative, generative, or evaluative.
We take this approach when we know very little about anything. This is typically when we don’t know much, if anything, about the users of the service, what problems they’re trying to solve and how they’re currently trying to solve them.
The outcome here is to dig deep into the user's world to understand who they are, what motivates them and their context. This foundational research is what sets you up to come up with innovative ideas of how to solve problems for users.
We take this approach when we feel confident in our knowledge of the people we’re building for. We understand their world, what they’re trying to do and the difficulties they face in achieving their goals.
However, we’re not sure how to solve the problem; in this scenario, it might be that we need to come up with some concepts of how we may even approach the problem, all the way down to more specific detailed solutions.
The most important element of this approach is getting feedback early and regularly - de-risking concepts and ideas through regular experiments and testing with users.
The outcome of this approach is having confidence in how to solve the problem for a user, so that you can start providing them with the solution.
Finally, we take the evaluative approach. This is when we both understand our users and their problems, and are confident in how we can solve their problems. This confidence in the solution may come from this being a solution that’s been used before, or an industry standard solution - meaning it’s not risky to implement.
Here, we’re thinking about measuring the impact of solutions in the wild, observing how behaviours change as a result of our intervention, and making changes based on any feedback.
The outcome of this approach means that we’re continuously improving our service, rapidly responding to feedback from users, as we observe them using the solution for real.
As with everything we do, we’ll be evaluating and then iterating our research philosophy as we continue to use it. We have already seen the benefit of having our thinking written down - it has helped to not only align the research team, but also our service designer friends. There is so much overlap between how researchers and service designers think, we believe our next iteration may also include some service design approaches. Watch this space…