How to painlessly integrate research into product development
Samokat.tech designers began conducting product research internally within the team. “What came of it” and “How to implement such an approach” – we look at specific examples from the first person.
Hello! The product design team from Samokat.tech is in touch. Imagine: users do not notice the block with the “Select delivery address” and “Login” buttons.
We think that the picture will attract attention, but in reality the illustration gets in the way and provokes the effect of banner blindness.
Designers working on the service would really like to know about such problems, right? Harsh reality: in practice, research that helps identify such difficulties is carried out by specialized researchers from a separate team. Designers and everyone interested have to wait for research results.
At Samokat.tech, we integrate research into the development process through our product design team. We study user needs, test hypotheses, test designs—on our own.
We are convinced that this approach helps to better solve user problems, create truly useful features faster, and do less rework. This also increases the professional value of line specialists – by acquiring new skills and broadening their horizons.
In this article, we want to share our experience in conducting product research by non-researchers – let’s remember the hardware and look at examples. We hope it will be useful for designers and all people from product teams who do not specialize in research, but would like to be able to learn product insights through experimentation.
Research? With your own hands?
It seems that it is not difficult for a product designer to imagine a situation where it is necessary to deal with abstract technical specifications, poorly formulated task statements and expectations of a result that was “needed yesterday.”
The attitude “there are no requirements, let’s go design and we’ll figure it out” is something you expect to see more likely in a startup than in a mature company. But in practice, business growth rates often lead to similar things in organizations that have long ago found their product-market fit. If you do it measuredly and gradually, you can go to the other extreme: “first six months of research, only then the team will start something.”
We at Samokat.tech also went through this stage. When at first the release takes a long time, and then there are a lot of edits and reworks, it hurts.
Our transition to a qualitatively new level was not overnight. First, we began to meticulously interview all stakeholders to identify needs. Then they began to research tasks through CJM, interviewing users and teams. And only after that they began to conduct research and decided to invite members of the product team to meetings, ask questions and involve them in the process.
Many companies do without any research, while others order or conduct them with the help of dedicated specialists. We have identified the following reasons for ourselves to still do research, and precisely with the hands of product designers:
More certainty and understanding of what to do
It can be quite uncomfortable to work in conditions of uncertainty, when you constantly have to think and guess. Research data informs decisions, and the process provides a better understanding of details and context.Less rework
It is risky to make a product based on untested hypotheses. The solution may turn out to be unsatisfactory for the user, and time and resources will already be wasted. Research is an opportunity to better understand your target audience, not force users to endure inconvenience, and save on development costs (do what you need faster, do less redoing).Easier to present a solution
Based on research, you can argue to customers and stakeholders why it was done this way.
Of course, integrating research into a team does not come without challenges. The team may be embarrassed by increasing design deadlines. New processes can be difficult to accept – it’s unusual to work differently, it seems that it was “normal as it is.” But as soon as the team gets involved, at least as observers, and sees the first results, things begin to go noticeably more vigorously and easier.
At what stage of working on a task should research be implemented?
Anything. There are different research methods for different stages of work. In our opinion, the universal rule here is: a designer should be involved as early as possible.
Possible scenarios:
Before starting a new task
If a business needs a new feature or product, it will be great to get more data before starting. For example, when creating the web version of Samokat, we conducted an in-depth study to check how much users need a website at all, since everyone already uses the application. After launching the MVP, we did several more case studies and short studies to help test the product’s performance. The site is live, but research is ongoing to investigate potential issues and improve the user experience.In expensive and important projects
There is more responsibility and risk here, and research will help you work more accurately and efficiently, and reduce the number of inconsistencies with the expectations of users and clients.When detailed technical specifications do not yet exist
It happens that we want to do things for which we don’t always have time to work out the requirements in detail, for many different reasons. In this case, research is the way to reduce uncertainty.When the team is fragmented or there are communication difficulties
Active participation of colleagues in research can increase interest in the product, creativity and overall cohesion.
Choose the right moment based on your needs and the specifics of the project. The research method largely depends on this.
How to choose the appropriate research method
There are many approaches: in-depth interviews, UX tests, surveys. After the research, there is a stage of systematizing the results. There are also various frameworks for this, for example, the person method and Jobs To Be Done, CJM. Using this data, the designer can start designing.
When choosing an approach, we rely on three factors – the subject of research, the amount of time and common sense.
At the start of a project, in-depth interviews are the most useful when we collect information to solve a problem → We can discuss and agree on a solution using the Customer Journey Map → UX tests help collect user feedback on the finished design.
You can’t do without in-depth interviews when there are a lot of questions and you want to understand how people act, why they choose one way of behavior and not another. When you listen to people, you begin to understand their way of thinking. And you consciously make decisions about implementation. In-depth interviews help you find out things you didn’t initially expect.
And if you just need to understand how convenient a block or button is made, there is no point in collecting third-party respondents and conducting hour-long interviews. You can organize an unmoderated UX test on company employees and collect data literally in a day.
Using the example above, we tested with colleagues how clear and convenient it is to use the right module of the Scooter baskets. They called out to the internal chat and within 24 hours about 100 people passed the test. We thought that there might be problems due to the unusual implementation – the cart appears in the right module as a pop-up on top of the site. But it turned out that most people can do it in 5 seconds without any problems.
It happens that users themselves do not know what they want – it is useless to ask what and how to do it. A/B tests are suitable here, where you can immediately check what works best.
Or in some areas problems are obvious, but their causes are not. Then we collect all the problems together, rank them and decide what to do with them. For example, users do not complete a certain scenario or do not pay for an order – this is an important problem that needs to be resolved urgently. We analyze it ourselves, put forward hypotheses and test it in circles until we find a solution.
And then there’s just analytics. For example, how many people click buttons or go through scenarios. Based on it, you can draw conclusions and collect hypotheses that you want to test.
How we solve problems using different studies
There are things that affect overall satisfaction with the service, and there are those that affect indicators: conversions and money. At different stages of work there are different tasks and each has its own approach. Here's how we combined various parts of the equipment described above to solve specific problems.
Case: in-depth research of website users
For example, we wanted to understand why people come to Samokat, what they like and what they don’t, what problems and difficulties they have. The sequence of steps here was classic:
collected a brief to record our agreements on the goals of the study;
compiled a sample and wrote a guide to conducting the study;
found respondents (the group included those who ordered on the mobile and desktop web);
conducted 10 interviews of 45-60 minutes each via Zoom on the entire grocery ordering scenario.
And we received a detailed answer to the fundamental question: when is the site used?
During the interview process, we identified a number of problems of varying levels of criticality.
For example, on the main screen everyone understands how the navigation bar, central block and search work. But there are difficulties in finding the right product in our selection categories – it’s clear where to look for milk, but with sauces it’s more difficult. And respondents did not even notice the right block with the “Select delivery address” and “Login” buttons. We expected that the picture would attract attention, but due to banner blindness, on the contrary, we did not notice it.
We were afraid that it would be difficult to work with the curtain of the product. It turned out that no one had any difficulties. Instead, the problem was a large description of the composition – for some reason, products with a long description are bought less often, even if all the ingredients are natural.
A separate story with the delivery address: when respondents reach this stage of the order, everyone spends a few seconds realizing what they see. In the web version, unlike the mobile application, no one uses a card to select an address; it is simply entered manually.
In the block with the basket and the profile as a whole, there were no problems, except for one rather serious one: not everyone understood that the catalog on the main page contained a demo version of the entire Scooter assortment. And products are delivered to different addresses from different dark stores. And when choosing a delivery address, people did not understand what happened and why part of the selected product was not displayed in the cart. This needed some work.
And all people logged in only after collecting the basket. At the same time, half of the respondents thought that they were asking for a phone number to contact them just in case, not assuming that this was authorization.
The study showed that there are no blocking problems on the site. We removed the most critical ones immediately, and we solved the moments that cause discomfort or irritation and increase the time it takes to complete tasks.
Case: unmoderated UX tests on employees and users
We conducted the first click test first on Samokat.tech employees, and then on real users. We checked how quickly and successfully users solved basic tasks:
authorization;
selecting a delivery address;
change of delivery address;
viewing the order status;
search for previous orders.
It turned out that the results are approximately the same, but it must be taken into account that the number of respondents was small, so we cannot talk about the statistical significance of the results.
It turns out that sometimes testing hypotheses on employees is quite acceptable and can significantly speed up and reduce the cost of the research process. The main thing is to find a sufficiently large number of respondents who are not involved in the development of the features for which you are testing hypotheses.
Case: physical research while working in a warehouse
Before the pandemic, almost all usability tests were conducted in person. The respondent was invited to the office, given a phone or computer, and the cameras were set up. In some cases, eye trackers were used – cameras to record eye movements; they can be used to track where the respondent looks most often, and what he does not pay attention to at all.
But the pandemic showed the possibilities of online tests, despite all the difficulties and limitations: the location of the respondents ceased to matter, so their circle became wider, and the meeting became easier to organize. Now face-to-face testing is carried out much less frequently. However, there are times when you cannot do without them.
For example, when the context in which the user works is important. This is our case! Among our products are those that digitize and automate the process for warehouse workers. There, a person doesn’t just look at his phone – he scans barcodes, sorts goods, rearranges boxes, and pushes a cart.
How to conduct such a test? The procedure will be the same as for the online test.
First, we write a brief and indicate the purpose – why we are conducting the test. Then we write down individual hypotheses that we want to test. We write a test script and prepare a clickable prototype in Figma.
We reach an agreement with the warehouse management and ask them to provide us with respondents. On the day of testing, we come to the warehouse, meet with the respondents one by one and give a brief briefing: who we are, what we need, and how long it will take. We give the person a task and ask him to voice all his thoughts and intentions – we can’t get into a person’s head, but we want to know more information. After this we begin observation.
Warehouse employees use data collection terminals – essentially a mobile phone, only very durable. The employee begins to complete the task, walks around with the device, scans something, moves it, and we observe and note which of the hypotheses was confirmed and which was not. If a person experiences difficulties beyond the allotted time, we suggest, mark the hypothesis as a failure, and move further along the scenario.
We conduct the event with several respondents → we put everything together in one table → we analyze and find the most problematic areas → we think about how they can be improved → we present the results to our team → we think about what we can take from this into work.
Based on the test results, we decided to redo the reject acceptance process.
No researchers needed?
The introduction of research helped us see the consequences of our decisions faster, draw more accurate conclusions, and also show our colleagues that designers are guided by data, not feelings.
It turns out that if you do product research yourself, then professional researchers are not needed?
Needed.
One of the components of success in our case was that fellow researchers organized a three-month training for designers. Everyone was able to learn how to properly conduct interviews, usability tests and create surveys.
Now we try to plan the loading immediately taking into account the tests, which help to understand the direction of actions and the scale of changes in the products. And the main thing is to make conscious decisions, more accurately meet the expectations and needs of users and rework less.
The general principle here goes something like this: as designers, we have not become as competent in research as professional researchers, and furthermore, we do not have such a goal. We have accumulated expertise, which is enough to decentralize and thereby speed up the process – there are studies that we can conduct independently. And fellow researchers act here as a center of expertise and help us improve.
So the whole story above is not about how to eliminate a role, but how to find a more productive way to work together.
How is product research organized in your company and team? Who is responsible for them? Tell us in the comments!
