User research isn’t something that brands can merely pigeonhole into the beginning of the product development process. It is something that should be valuable before, during and after designing a product.
Conducting research before getting underway helps to ensure that both the product and your business goals match the needs of real target users. Continuing research throughout the stages of wireframing and design enables us to identify precisely how our findings contribute to the design. Furthermore, user research can validate designs through exercises such as usability testing, providing insights around how users naturally interact with the product.
Well-conducted research returns information about users and competitors, as well as producing insights into the latest UX/UI trends. Conducting research throughout all stages helps to give the product an advantage over its competitors, with a more developed understanding of long-term strategy increasing the product’s chances of success once released.
Members of our User Research team with Coglode's behavioural insight nuggets.
In his list of 18 mistakes that kill startups, entrepreneur Paul Graham said: “There’s just one mistake that kills startups: not making something users want.” Believe it or not, figuring out what your users want isn’t complicated. All you need to do is talk to them.
The importance of questions:
Too often, customers will present the product development process as a sprint to the finish. Customers arrive with a great idea and want nothing more than to see it visualised and replicated straight from their mind’s eye. It’s a common occurrence - customers believe they've found a solution and often consider it to be the only right answer. There's nothing wrong with this - I mean who doesn't like being correct? However, rushing to be right often increases your chances of being wrong.
Accordingly, you can't start a process with the answer - you first have to ask questions. In product development, a good question is always much more powerful than having an answer. Questions allow you to gain more information, all of which can be used to inform your future decisions better, and all based on data from those you are targeting.
Unfortunately, brands and product developers talking to users happens far less often than it should. Much of the time, brands will operate on a belief that they already know what their users want and need. In the case of startups for example, opinions will often be based on their own experiences of a problem they are trying to solve (though these communication issues are by no means limited to small businesses only, as we’ll cover later.)
However, your own experiences don't always provide an accurate validation of a solution. No matter how much subject matter expertise we hold, we may never have accumulated nor encountered the same experiences of users. All that we think we know about users are assumptions, and the reality is that you can't rely on solutions that have been created and based on these to meet the wants and needs of your users successfully.
Every decision throughout the product development process that isn’t validated by user research becomes an assumption. Because we can't sit with every user who decides to try the product after it is released, we can’t work through how features work, nor guide them through what to do during different stages of use. It is for such reasons that those assumptions become risks. Making assumptions isn’t always a bad thing - in fact doing so is a part of the working process, but assumptions become problematic when perceived as facts.
Here at hedgehog lab, we understand our duty to acknowledge real-world users and ensure they are represented throughout, carrying out user research at the start of and during product development. It is an approach that allows us to validate the assumptions of ourselves and our customers, ultimately mitigating needless risks.
The customer's customer is always right
"Embrace what you don’t know, especially in the beginning because what you don’t know can become your greatest asset. It ensures that you will absolutely be doing things different from everybody else." - Sara Blakely.
Sara’s words don’t translate to an expectation that users must describe in detail what they need as a solution. Often, users don't know what change is needed specifically but will know that something isn't right. Adding weight to this theory is former Hewlett Packard CEO, Carly Fiorina, who notes:
“Customers always know what’s wrong. They can't always tell you what they want, but the always can tell you what's wrong.”
Resultantly our job as user researchers becomes a case of taking such insights and working out how they can be used to positively influence the design to the benefit of the user while ensuring we are adding value to the product.
hedgehog lab designer Alex Poole making research-based design alterations.
There is nothing better than successfully developing a product which customers will not only use frequently but also one that provides them with a value that was previously non-existent. We cannot achieve this without research!
Designing and prototyping a solution straight off the bat without conducting any research can rapidly result in problems. The product itself might be delightful to use, loved by everyone and beautifully designed, but if it doesn't address key user solutions, is unlikely to succeed once released as the target market won't have the necessary need to use it.
Can you afford to give UXR a miss?
Further demonstrating how interacting with users can completely alter a solution are these words by experience designer, Victor Lombardi:
“If you only test bottle openers, we may never realise customers prefer screw-top bottles.”
The quote provokes thought into how users can completely alter the mindset of product designers in how to tackle a problem. But what happens when problems arise that go ignored?
There is, of course, the infamous case of Blockbuster. At their peak in 2009, the company had 5000 stores across the globe. By 2010, they had filed for bankruptcy and their assets had been sold. When companies like Netflix came along, Blockbuster dismissed them, believing they didn’t pose a threat and considering themselves as ‘too big to fail’. While customers started leaving stores for digital on-demand alternatives, Blockbuster was attempting to increase customer basket size with sweets. Despite having sufficient access to customers and information to know their customer behaviour was changing, the company failed to adapt and paid the price.
Another well-documented fall is that of BlackBerry. In an item for The Globe and Mail, an unnamed insider admitted the company had “stopped listening to customers”, instead persisting with their own idea of what customers wanted from a smartphone. Their chosen path took them from a market share of over 20% of all smartphones in 2009, down to 0% by 2016.
Such examples demonstrate why it is vital to start by understanding what people need, and not the solution that you're excited about building. They also show the value of continuing to conduct research well beyond the initial phases of a product’s development.
One size doesn't fit all
While we can learn lessons from countless unsuccessful startups and the failures of giants such as BlackBerry & Blockbuster, it's also important to note that no two projects are the same. At hedgehog lab we never approach a product with the same steps and methodologies as another.
To decide how we'll start, we first analyse the topic, purpose, time and budget of a project, as well as dedicating time to forming an understanding of the problem they are trying to solve, before planning what type of research will best serve dependent on these variables.
Our approach ensures there's never a reason not to do research. Excuses like “we don't have the budget” or “there isn't enough time” aren't acceptable as we can accommodate and adapt our methods for such circumstances, helping ensure we can still provide insightful outcomes.
When planning a user research study, it is crucial that it matches the research question and focuses on what we don't know to ensure we collect the right data and employ the most suitable research method at the right time. hedgehog lab’s team of User Researchers are there to guarantee any efforts we undertake are conducted following best practices. After carrying out the research, we’ll then analyse and draw key insights from the data that is produced. These findings help us align product strategy with the user’s real needs and desires.
UX Research is a continually evolving area
When it comes to what our UXR team can bring to the table for our customers, the benefits are clear:
- Helping to create a shorter product development time by providing our understanding of what is being built and who it is for.
- Providing a more informed and reliable way to solve differences of opinion by enabling decisions to be made based on data provided by real users.
- Preventing the need for costly problem fixes.
- Identifying problems to inform future decisions.
Members of our UXR team each bring different skills to the process, owing to our diverse backgrounds. Currently, the team are collating our varied knowledge to refine and optimise our process. Part of this is showcasing the importance of our work to both our team and clients from the off.
As researchers, we’re constantly looking at ways we can adapt our methods to increase the usefulness of our output. In such a role, we have to ensure we’re always learning. In addition to identifying and integrating rising trends in user research, we’re also looking to lead in effective UXR - and as such, we’re even making the decision to drop some aspects we don’t believe provide value to our customers, or more importantly, their customers.
However, to ensure we stay on top of industry trends, to allow ourselves credibility when we describe ourselves as a leader in UX Research and to ensure we’re improving our process to the benefit of end users, we have to abide by the same mantra we’d encourage any of our customers: don’t start with solutions.
Learn the five most prominent psychological cognitive biases in User Research and how to combat them...