Design without research: several anti-cases and conclusions from them

Today, a designer does not make decisions based solely on his experience and taste. The most important criterion for the success of a future project is research data. With their help, the designer understands which product metrics will be affected by the layout, whether it will be convenient for the user to work with updates, as well as what business tasks will be solved with the help of a beautiful design. 



However, audience research is still not always done - sometimes it is economized or considered unimportant. Oleg Rudakov, Director of Analytics Development at AGIMA , shared his experience and told why it is important to conduct research and what happens if you neglect it. Oleg is a lecturer of the Interface Design course .



Small disclaimer



First, "all characters are fictional, and any coincidence with real life or living people is accidental." Moreover, they have never been associated with the work of the author of this article.



Second, not all products need research, and not 100% of the time. For example, if the project is faced with the task of "making beautifully" and there are no criteria for the effectiveness of the product, then there is no need to spend time on research, it is better to spend it on discussing the problem and finding out what "beautiful" is.



What I mean by audience research



Qualitative and quantitative methods of obtaining information about users and their behavior or interaction with products.



Examples of quantitative methods:



  • Data analysis of web and mobile analytics systems.
  • Online and offline surveys of product users or panel respondents.
  • Card sorting.


Examples of qualitative methods:



  • In-depth interviews with users.
  • Moderated or non-moderated usability testing of respondents.
  • Diary research.


The value of the research is in identifying the real reasons and difficulties of users when interacting with the product. By correcting the found deficiencies, it is possible to improve the efficiency of the product in a controlled and meaningful way. 



It also provides an opportunity to prioritize the product backlog to focus on completing tasks that will have a greater impact on the final product performance.



Why the user is not always researched before design



Designers and designers have their own techniques and very often their work is based not on the results of research, but on their experience, observation or a sense of beauty. However, all team members have their own experience, their own observation and their own sense of beauty. So without research, in any team debate about how a particular functionality should look, the winner will be the one with the most weight. Not a single participant in the dispute has objective data, and therefore no arguments.



Another common behavior pattern in product development is copying existing and well-known products. On the one hand, it is logical to reuse common patterns of user behavior. For example, place the shopping cart of an online store in the upper right corner of the page or move the main sections into the tabs of the mobile application and place them at the bottom of the screen. On the other hand, there is no need to mindlessly copy all the solutions - they may not all work.



Because of this, situations occur when projects with ambiguous solutions are released - non-working, inconvenient. This is usually found out at the stage of collecting data from web or mobile analytics systems in an already finished product, when there is no point in turning it off or deleting it, because money and effort has been invested in it. 



Therefore, a kind of suitcase without a handle remains in the product, which wanders from version to version of the product because "users are used to it."



I'll tell you about a few fictitious examples when a ready-made solution turned out to be inconvenient or unnecessary for the user. My goal is to help you think about the fact that a designer or designer often needs research to create a truly quality product. 



Unnecessary functionality



Anti-case # 1 - the ability to compare products in the same category and advanced filters for an online store



Let's imagine a classified site. Users start their ads, enter basic information on the product and add a photo. Surely, you yourself used similar sites or just went to see if there is something interesting from the goods.



One such site decided to get better and give users more options to simplify the selection of products. To do this, the team developed and added two features to the site: the ability to compare products in the same category and advanced filters, in which users could select a dozen additional criteria for selecting products, in addition to standard ones (color, size, price, year of production, and others).



The decision seems to be quite logical, since all major online stores offer the same opportunities. And the same goods are sold both there and there. Plus, it seems that technically complex products are convenient to select using a comparison list.



After the launch of the features, they were marked with analytics systems and, according to the events of applying filters and lists of products in advanced e-commerce, Google Analytics saw that almost no one was using the new functionality. 



Then we decided to conduct a study - an online survey of the audience on the site about their goals and objectives of working with the store, the experience of shopping for product categories and generally using the site. 

The survey showed interesting results: the key segment of the site is those who already know what they want to buy and what product they need. Therefore, from all the products presented, they choose by price and condition, considering literally a couple of models. They don't need complex filters to select these products, and they don't use the comparison function. 

Of course, nothing bad happened. The added options were left on the site, since they did not bring harm. Only now the teams spent time on the development, and the business indicators of the store did not improve. 



What could have been better



The team could find out the attitude of users to changes at the stage of making a decision about development. This could have been the same online survey on the site. It would provide insight into the experience of previous purchases and user needs for new functionality. 



The format of in-depth interviews with site users would also be suitable, but in comparison with a survey, it would allow to find out the motives and requests of users in more detail. But I like the survey option better, because it is a quantitative research method that allows for richer data. 



Anti-case # 2 - a mobile application for bank clients



In the wake of digital transformation, an investment company (the name is not in tune with any bank and does not consist of three letters) decided to develop a mobile application for clients. In it, they could view information about their portfolio, conduct transactions and study news on a topic of interest from the company itself. 



The company's competitors already had mobile applications, but the difference is that competitors have always worked with a less solvent audience, which is the majority. These audiences are new to investing and find additional content on the topic important. 



After the transfer of the application to industrial operation, an advertising campaign was launched to promote it among current and potential customers. Based on the results of research and analysis of the return on investment in advertising, it was determined that attracting new customers is completely unprofitable. The cost of acquisition is high due to competition, and the income from clients is low, since they conduct few transactions and the commission from them does not pay off the acquisition. 



As a result, advertising was quickly stopped and the flow of users to the application became equal to the flow of new customers to the company. The current clients began to send mailings and tell about the application in offices and on the website. Thus, instead of a convenient and interesting feature for attracting, the application has become just a tool for working with current customers.



Was it possible to foresee such a result - yes. 5% of the company's clients provided 95% of the income. Moreover, these clients never carried out operations themselves and interacted only with their managers on the side of the company. All reporting for them was brought by managers and shown in printed form. It is logical that with this model, the new application did not affect the main money-making customers in any way. And even less would it attract the same new customers.



What could have been better



In this case, there is no need for audience research in conventional ways. To begin with, I would not divide the audience into new and current customers as part of creating an application. Any product has new and current customers. And I see the goal of developing an application rather to create a convenient tool for retaining current customers, so that they do not try what competitors have.



Before developing the application, the company needed to analyze the structure of the receipt of funds by type of customer.


Then the team would see that the application does not affect the loyalty of current, money-making users. 



In addition, calculating the unit economy of attracting new users would help to see the convergence of the economy, taking into account the media plan. 



Inconvenient functionality



Anti-case # 1 - unsuccessful landing page structure



Let's imagine a conference landing page. Landing page structure from top to bottom: 



  • a large banner with a logo, title and dates; 
  • top 10 speakers with photos (known to everyone in the subject);
  • banner;
  • 30 more speakers with photos;
  • ticket purchase application form;
  • full program of the event;
  • road map;
  • ticket purchase application form;
  • partners' logos.


The arrangement of the blocks on the page seems logical: first, users must study important information and only then sign up for the conference. In fact, it turned out that the structure of the site is categorically inconvenient. With such an arrangement of blocks, after the launch of the landing page, it turned out that the conversion to an application was too low to have time to collect a full room in the time remaining before the event.



The work on the project was divided into two parts. One team analyzed traffic to the site, and the other analyzed the interface itself. We looked at the data in Yandex.Metrica, which raised doubts about the effectiveness of the page structure, and the scrolling map caught my eye. 



Then we decided to conduct A / B / N testing, in which the application form was swapped with other content blocks on the page. Why did you start with the form? The landing page was easy to navigate and didn't cause any difficulties. It was too late to change the speakers themselves and their topics. Of the possible options, only the page structure itself and the location of the application form remained. 



In the study, we looked at the form from which users submit an application for registration. As a result, the landing page with the following structure had the highest conversion rate: 



  • large banner with a logo, title and dates of the event;
  • top 10 speakers with photos;
  • ticket purchase application form;
  • all the rest.
 

The audience was interested in listening to the top speakers, and it did not matter to them who else would speak and what topics of the reports would be. Therefore, on the conference landing page, the registration form was raised higher, after which the conversion increased greatly.


What could be done better



? The organizers of the conference could conduct research on the results of the last event. For example, along with useful materials, send out a survey among the participants in which they would ask about the reasons for making a decision to buy tickets. 



Additionally, at the start of ticket sales, such a survey could be conducted with past customers by phone in order to ask more detailed questions. The study is simple, but it would yield good results for understanding the structure of future conferences.



Anti-case number 2 - calculator for calculating the amount of insurance



Imagine a website for a small insurance company (not in the top 10 in sales). More precisely, we will present a calculator for calculating the amount of insurance for those traveling abroad. After the logic and design of the calculator are worked out, we understand that it is necessary to write hints to the fields and work out the errors of the input fields. This will help users understand and increase the conversion for which everything was done.



Since some of the details of the insurance process are clear only to a professional, the texts of tips will be written by the product manager of this calculator - he understands the product best of all. Because of this, the words appear in the texts "work with increased risk", "early return of the insured to the country of permanent residence", "sports" or "accident insurance". 



And for some of the points, there are no tips, because the person who writes them immediately understands what is meant by the age of the traveler, and he precisely separates the โ€œageโ€ by the date of purchase of insurance and the date of travel. Unfortunately, ordinary users do not understand these formulations or are mistaken in their interpretation.



After the tips were published, some customers wrote to technical support, and someone swore heavily when an insured event occurred. And there were mistakes in the policy due to lack of information when filling out. 



We conducted A / B testing and, after analyzing user requests to technical support, added hints for complex fields. As a result, due to the painstaking study of the text tips, it was possible to increase the conversion by 10%.


In this case, a comprehensive study was not required. It was immediately clear to the design team that complex points needed to be explained in detail. So we ran A / B tests to see how best to describe the clues.



What could be done better



? The creators should immediately think about how to give users clear prompts everywhere. The problem is that developers are usually very deeply immersed in the topic of the product and it seems to them that everyone around them also understands everything. But they are not the target audience of the product - it was necessary to conduct usability testing of prototypes. Or at least come to your senses when such questions began to pour in support.



Let's summarize



Research done prior to design and development can help you get the desired result, or figure out what needs to be developed or not and how to make the functionality more user-friendly. 



There are times when research is unnecessary: โ€‹โ€‹there are no resources, no time, or the task does not affect critical business indicators. However, even in such cases, it is better to conduct at least a minimal study, even a corridor survey, to check the result. When the usability of the product depends on the design, it is better to rely on objective data that was collected before starting work. 



I hope that these examples will encourage you to learn more about user experience research for design problems and to use them more often in your work. Good luck! 



All Articles