Is it possible to build an app in a few days with no programming skills? We have conducted UX research within the scope of product discovery for a low-code application that allows creating one’s own software. Which users are most likely to benefit from such a solution? Read the case study below to find out how we researched the market and identified potential target groups and key functionalities in 7 weeks. 

This case study explains:

• how to determine a target group for a new product,
• why exploratory research is so important,
• how to conduct a market analysis tailored to your needs,
• what to do in case your solution is already on the market,
• and how to quickly determine the direction of further research and basic project assumptions.

Project context:

In July and August 2021, we conducted UX research for a low-code application to identify potential target groups for a new product. By low-code, we mean a solution that allows users to build applications without programming skills (e.g., using diagrams, graphs, or forms).

A client approached us with pre-developed software and the need to determine which users might want to use the application in their work. Would they be young developers? Or maybe office workers who want to create a tool for their department? We didn’t know that. Nonetheless, we faced the challenge of quickly identifying and researching potential groups to validate the idea. 

Given the 7-week timeline, we divided the tasks to validate the initial design hypotheses as quickly as possible, leaving space for in-depth research with specific groups. The exploration before the in-depth research proved to be crucial in the case of this project. Why? You’ll learn that later in the text. 

Challenges faced by the client:

• the ready-made solution, not tested with users,
• need to determine the potential target groups of the application,
• determining main functionalities and prioritizing their implementation,
• the undefined direction of solution development.

Sprint 1 and 2 – Kick-off and Exploratory Research

Kick-off workshop

As in any research project, the starting point was the analysis of available data (the so-called desk research) and a kick-off workshop. This activity is an inseparable element of almost all our projects, as it allows us to fully understand the needs and goals that the client comes to us with.

The talks began with setting rules and defining mutual expectations in terms of cooperation. What values are important to us? How to communicate most effectively? To find answers to these questions, we used Team Canvas, the tool we use for team building. The first arrangements made it possible to move on to the next stage, i.e., the joint completion of the Lean Canvas, where we learned about the history of the idea, the initial design, and business assumptions and had the opportunity to see the solution.

Apart from highlighting the main hypotheses and research questions, one of the activities during the workshop was the initial prioritization of functions that the team thought the solution should have. This task involves highlighting key application functionalities and determining the order of the implementation – from necessary (must-haves) to less important (nice-to-haves). Each functionality is described on a separate sticky note and placed on the vertical axis.
With this simple task, the research team got the opportunity to learn about the client’s priorities and directly juxtapose them with the information gathered in the course of the research.

Figure 1 

Prioritization and summary of tasks

Research in Product Discovery typically results in the emergence of even more questions and hypotheses. Because of time and budget constraints, it is essential to prioritize activities at the beginning of the process not to lose sight of the core research objective. It also allows to clearly define the common goal in the team and minimize possible misunderstandings. Thus, during the kick-off workshop, we placed priorities on a 3-level scale.

First, high priorities, i.e., goals or hypotheses that should be the focus of the research. Depending on the priority weight, the particular elements can be ordered internally to allocate an appropriate amount of time to each issue. In this case, internal prioritization consisted of assigning 1 to 3 stars (3 stars as the highest priority, 1 star as the lowest). Finally, we determined other important objectives (to be addressed over the course of the study, but not the core of the study) and additional objectives (to be addressed if time permits, as they are outside of the core scope). 

Figure 2

Acquired information, coupled with preliminary exploratory research and desk research activities, enabled the identification of a list of main questions and hypotheses, which served as the basis for developing the research plan.  

First research – surveys and exploratory interviews among potential users

Having defined the hypotheses, we faced a dilemma – what next? We had an enormous number of questions and research activities, but we didn’t know which ones should come first. The solution was simple – we asked the users.

In the case of exploratory research for new software applications, the initially identified target groups often differ a lot. It was exactly the case in this instance. After analyzing and regrouping the potential users, we obtained the division reflecting their needs and skills. It revealed the necessity to conduct two different surveys, as the questions and hypotheses for each group were different. The question scheme was based on an approach that allowed us to probe opinions about the solution without suggesting any answers. Why is it important?

When creating a survey or an interview scenario for a new product, it is important to avoid a situation where respondents answer key questions after reading a description of the solution because it may negatively influence the results of the survey. If you describe the solution before asking the main questions, the respondent may (unintentionally!) provide an answer that confirms your hypothesis.

To avoid this, we first elicited answers related to the main hypothesis (e.g., frequency of specific problems indicating the need for a solution). Next, we elaborated on the topic with more specific questions (e.g., solutions used so far). Eventually, we briefly presented the solution and asked for opinions.

Figure 3

Collaterally to the distribution and supervision of the survey, we conducted additional exploratory interviews based on a very similar structure as in the survey, but with supplementary questions that allowed us to go a little deeper. Even very short, 10- or 15-minute interviews can provide a lot of information and answers. Additionally, they are a chance to observe users’ emotions and behavior when talking about a specific thing.

Sprint 3 – Competitor analysis and verification of initial version of the low-code application

Completor analysis

To broaden the information on the solution’s potential, we used an indispensable analysis of competitors and available market reports. To structure the collected knowledge, we used, among others, Competition Canvas individually tailored to the needs of the conducted research. In total, we analyzed 14 solutions selected during the workshop and further exploration through the use of netnography, information from exploratory interviews, market reports, our own experience with the application, and analysis of publicly available materials – all in accordance with research ethics.

To validate the hypotheses, we used graphical comparisons that enabled a quick check of how the competition addresses a given issue. Among other things, this measure makes it possible to quickly spot the space for development. The comparison of companies referred to the main hypotheses and was based on a scale related to:

• the size of the company,
• the complexity of the created solution,
• intuitiveness and ease of use,
• and type of solution (mobile, desktop).

Figure 4

Negative verification – what’s next?

Early verification of a solution’s potential is a primary goal of market exploration and analysis (e.g., competitive analysis). In the case of negative verification of hypotheses, you save resources that would otherwise get invested in an unprofitable solution. In the case of positive verification, you obtain data confirming the project validity (e.g., for investment presentation purposes) and new information related to user needs.

The information gathered during the research indicated a high level of market penetration by competitors and moderate interest in the target groups defined by the client. Does this situation mean the end of the project? Absolutely not!

Lack of initial interest in the market does not necessarily mean that the solution is bad – it is targeted at the wrong group or solves the wrong problem. An inseparable stage of the product design process is the so-called pivot, i.e., a significant change in the business model affecting a product. In the case of startups, this is actually quite normal. Making a significant change does not diminish the concept – it’s just another stage of product evolution, serving the purpose of better matching it to the real user and market needs. You can learn more about a pivot in a startup from another case study.

And so we faced a serious question – what next? In order to determine the future direction of the research, we took two actions. First, we labeled all negatively validated hypotheses to separate them from potential opportunities. Next, we prepared a flowchart detailing possible product directions, identifying the general product type, potential target audience, threats, opportunities, and main competition.

Figure 5

Having arranged the information, we could see all possible paths and determine with the client which ones presented the greatest potential (in line with the business objectives). Then, we formulated an action plan to deepen the information about the chosen direction.

Sprint 4 – Market analysis to select a new research direction 

Analysis of industries and market potential

How do you pre-screen over 60 industries in a week to narrow them down to the most promising? You need a plan first! We divided the task into two main pillars: additional analysis of industries based on competitive solutions and a general market potential check in each industry.

Using the information gathered earlier, we prepared a table to match each of the 53 solutions to one or more of 60 specific industries to determine the most and the least developed market areas.

Figure 6

At the same time, an abbreviated market analysis of the industries was conducted to quickly identify the areas most likely to implement the solution (e.g., due to demand). The analysis looked not only at opportunities and threats but also at the major “jobs to be done” that the solution enables for a user. It allowed for a preliminary assessment of which industries are likely to use the solution in many aspects, and which only in one. All activities were based on netnography and analysis of available data presented in the reports.

The identified industries and a summary of market development allowed us to pick 5 industries for further investigation.

Potential industries and the decision on a new direction

The shortlisted 5 industries were subjected to additional analysis using a method called mind-mapping. To speed up the process, we presented all the collected information in diagrams, which made it easier to describe or mark them graphically. We also took into account trends in each industry in order to determine the possible direction for the development of new features.

After analyzing the opportunities and threats for each industry, we identified three with the greatest potential: education, law, and furniture production. Additionally, in order to ensure the possible development of other industries, a universal direction was set, which was to form the basis for further industry development.

Figure 7

Sprints 5 and 6 – Deepening on the information – qualitative research

Preparation for further UX research 

Narrowing down the possible development directions enabled us to prepare and conduct further research aimed at additional verification. Since we wanted to explore user needs (including functional needs) in detail, we chose individual in-depth interviews as our research method. We prepared separate scenarios for each direction of development in order to best fit it to each industry group and the universal group. Similar to the research conducted earlier, we used a structure that does not suggest anything to the recipient. However, in this case, we focused not only on the hypotheses verification but also on discovering specific needs to define basic functionalities. 

Individual in-depth interviews

Because we had established contacts with potential research participants at earlier stages, we were able to conduct interviews in 1 universal and 3 industry-specific groups despite a considerably limited time. In the end, 26 interviews provided us with a wealth of essential information. While transcribing the information, we used a simple spreadsheet to compare the statements of individual participants and post-it notes on a virtual whiteboard in Miro. By using both methods simultaneously, we managed to transcribe and analyze such a large amount of feedback material in less than a week.

Figure 8

Setting the directions

We defined a universal direction of application development, which was a base for the particular industrial directions. It did not refer to any particular industry and allowed for easy adjustment of the solution to a new target group should the need for a pivot arise. 

This direction stems from one of the most valuable conclusions obtained during the individual in-depth interviews. It turned out that the problems identified during the workshop are present in companies, the solutions should not be limited to tools, and they should account for certain activities within the organization. This conclusion led to a complete redefinition of the current product vision and addressing the needs beyond the scope of the software. 

Based on the collected information, we validated the researched industrial directions and singled out specific potential target groups and solutions that had the greatest potential to win over early adopters. 

Sprint 7 – Compilation and summary of results 

Target groups and personas

We developed 9 target groups and 10 personas corresponding to the most distinguishable users. Presenting the findings in the form of personas was intended to make it more comprehensible for the stakeholders and highlight significant differences within one target group.

When characterizing the groups and personas, it was important to determine demographics, channels, main objectives, and special characteristics. It was crucial to identify the characteristics that were opportunities or threats to the development of the project. It allowed the final compilation of all the findings and the preparation of recommendations for the final direction.

Figure 9

UVP and additional values

The information we gathered about real user needs and problems made it possible to identify a potential unique value proposition focusing on the problems that the competition had not yet solved. We had to go beyond looking at audiences in the context of the tools they use and look holistically at all the problems they face in their work. Also, the UVP itself was about highlighting an emerging problem, rather than the solution in the form of a tool.

Due to the initial stage of the product life cycle, we also highlighted additional values. Although some overlapped with the values offered by the competition, clear articulation helped narrow down the assumptions about what the company should offer apart from the UVP to actually stand out from the competition and maintain a high level of service. 

Main design assumptions

When creating a new product, regardless of its form, it is helpful to define the main design assumptions of the solution. They are a kind of determinant and direction for designers. It is critical that they are not based exclusively on key business assumptions or resource availability and they define all other necessary factors or assumptions that will allow for a better understanding of the idea. In the case of this project, we identified 5 main assumptions that formed the basis for further work on the application.

When creating assumptions for the first time, it may be helpful to divide them into:

• conceptual assumptions – i.e., related to the main application of the tool,
• technological assumptions – i.e., guidelines and technological limitations,
• functional assumptions – i.e., guidelines related to functionalities that a solution will have,
• aesthetic assumptions – i.e., guidelines concerning the visual aspect of a tool,
• business assumptions – i.e., guidelines related to main business goals.

Figure 10

The categories of assumptions should be chosen and created in accordance with the specificity of a given project. It is important to organize and write them down to ensure easy transfer of knowledge to other team members who take the project over in further stages.

Key functionalities of the application

We distinguished two main groups of features: features that enable work in the tool and features to be built in the tool (in the developed application). This division clearly defined which features were necessary to make the tool available to users and provide intuitive operation and which could be implemented over time.  

Due to the early stage of development, it was necessary to prioritize the functionalities to define the scope of the MVP (Minimum Viable Product) and the subsequent product versions according to the internal roadmap. For this purpose, we used the basic MoSCoW prioritization tool and Use Cases, i.e., examples of how specific target groups could use the product. In addition, we presented exemplary applications that could be developed in the application we worked on. 

Summary:

Incorporating exploratory research into the process to validate the key hypotheses can be critical for further business development and resource management. Negative validation of an idea does not have to result in project termination. It can actually lead to creating a new product for the same target groups.

The development is continued based on the acquired knowledge of the user needs and according to the schedule of implementing particular functions. 

Project team, i.e. who was responsible for what

Author of the Case Study

Agnieszka Zygmunt Lean UX Researcher, Industrial Design & Service Designer

Agnieszka performs analyzes, conducts research, and experiments. She specializes in Product Discovery research and helps create solutions focused on the real user needs.

She takes a holistic view of the design process accounting for t all factors that may affect the final user experience. In her work, she combines her analytical skills with a high level of empathy and love of science.

Co-creator of the Proste Rozmowy podcast. Privately involved in non-profit projects supporting those who need it most.

Other members of the team

Laura Piwowarska UX Researcher w Project: People

She believes the best way to find out how well you know yourself is to try to describe yourself in a few sentences.

Who am I? This question determined the choice of her career path.

She is a researcher and supports clients in making decisions about product creation and development. She emphasizes the ethical dimension of research and UX.

Laura is also a Design Thinking Moderator who loves creative methods of knowledge transfer.

. She enjoys exploring new places, countries, and continents. She looks for diversity in people, cultures, languages, and food.