Importance, stages and practical application

Alexander Efremov

Product designer at Yuztech Group

Hi, I'm Sasha. I've been in product design for over 6 years. I've worked in small startups as well as large products in the B2B and B2C segments, and I also I run a channel about design.

In this article, I will share my experience of conducting the Discovery phase on several projects. The article will contain checklists, examples and links to some resources. If you are too lazy to read, you can watch my online lecture.

Introduction

When a product is just starting its life and is floating around in the minds of stakeholders, it has many options for implementation and development. We, as designers, want to quickly roll up our sleeves and start creating something new. Something that will “change the world.” But before we start doing something, we need to understand what we want to do, and the discovery phase is ideal for this.

What I'll tell you about

  1. What is the Discovery Phase in UX Design

  2. The Importance of the Discovery Phase

  3. Real life examples of application

  4. Stages of implementation

    1. Understanding Goals and Metrics

    2. Preparing a knowledge base

    3. Conducting competitor analysis

    4. Conducting an interview

  5. What do we get as a result?

Definition

Let's start with the definition given by Maria Rosala in the article NNG: The Discovery phase in UX design is a preliminary design stage that involves deep exploration of the problem space, identifying the problems to be solved, and collecting sufficient initial data. This phase is not about testing hypotheses or solutions, but lays the foundation for successful product design and development.

The Importance of the Discovery Phase

Discovery plays a critical role in the success of a product. It helps to understand the need for the product in the market, understand the cost of the service, avoid costly mistakes in the subsequent stages of development, improve the understanding of user needs and form a clear vision of the project.

CBInsights analyzed 101 startups with the aim of finding out the reasons why entrepreneurs failed.

In my understanding, a correctly conducted phase of market research, users, their needs and expectations helps to understand the need for a product, save the company's resources, plan its development and even obtain investments.

Real life examples of application

Let's look at a few cases that demonstrate how a properly executed Discovery phase contributed to product success.

Case 1: Airbnb

Airbnb started with the idea of ​​creating a platform for renting homes from locals. However, in the early stages, the company had trouble attracting users and hosts. During Discovery, the Airbnb team conducted numerous interviews with potential users and hosts, which allowed them to gain a deeper understanding of their needs and problems. They found that users had trouble trusting the platform and were afraid of risks. As a result, features such as reviews and ratings were introduced, which significantly increased trust in the service and led to its rapid growth.

Case 2: Spotify

Spotify had an extensive Discovery phase before launching its streaming platform. The team conducted numerous interviews and research to understand what users wanted from a music service. They found that users wanted access to a huge library of music, but they also wanted ease of use and quality recommendations. These insights helped Spotify develop a product that has become incredibly popular around the world.

Case 3: From personal experience

While working at EPAM, I managed to be part of the development team, where we tested the idea that creating a platform for teaching business English is in demand in the CIS market. We analyzed competitors, interviewed guys from different countries, found out prices, conducted surveys and even managed to test the first prototypes, but then we realized that it would not be profitable for the company to open this direction at the current stage. Thus, we helped not to waste unnecessary resources of the company and redirect them to other projects.

Stages of design discovery

In my understanding, the Discovery phase includes several key stages, each of which is important for creating a successful product. Let's look at them in more detail.

Understanding the goals and metrics of the future product

The first step in the Discovery phase is to understand the project goals and establish key success metrics.

To do this, meet with stakeholders and find out their goals regarding the product.

Understanding product goals involves identifying business goals, user needs, and technical constraints. It is important for the team to have a clear idea of ​​what they want to achieve and how they will measure success.

  1. Defining business goals: What does the company want to achieve with this project? What business objectives need to be addressed?

  2. User needs: What user problems and pain points need to be solved? What user scenarios need to be supported?

  3. Technical limitations: What technical resources and platforms will be used? What limitations need to be taken into account?

You or the PO can also organize a kickoff meeting where team members can talk about their experiences and how they can help the product. Who knows, maybe one of the team members already has a similar experience.

Example of product goals: In a project to develop a new product within a bank application, business goals may include increasing the number of users and improving the customer experience. User needs may include obtaining additional benefits. Technical constraints may include integration with the bank's existing systems. Laws and compliance must be taken into account.

Preparing a knowledge base

This is the most difficult, but also the most necessary part at the beginning of working on a project.

Even if the project has already started, it is better to create a knowledge base at the current stage.

What is the knowledge base for:

  1. Recording agreements between team members: This could be either your general agreements regarding the completion of a task or a record of team decisions, since verbal agreements are very easy to forget.

  2. Storing information in one place: Competitor analysis, interviews, reports, meeting summaries and links to team meetings. All of this will help to create a unified picture of the product world.

  3. Fixing all possible paths: These are user paths, personas, roles, information architectures, diagrams, and so on.

  4. Simple onboarding of new team members: It’s simple here – it’s a reduction in the team’s communication costs.

What I posted in knowledge bases:

  1. Useful links: Prototypes, files with explanations, file versions, your frontend UI library, frontend plugins used, dev environment, fonts, illustrations, etc.

  2. Contacts of managers/developers, etc.: This seems like an obvious point, but I have often found that it can take half a day to get a contact for a particular person. It is easier to just place it in the database once and describe its scope of tasks.

  3. The goals and metrics described are: It's best to document and describe them. They will be needed for onboarding and adjusting the product vision in the future.

  4. Product vision from the design team: All teams have a shift in vision for their profession. Designers are better at talking to designers, so write down the vision for the product from a designer's perspective and get it agreed upon with the product owner.

  5. Competitor analysis;

  6. Interview results: Both with users/implementers and interviews with stakeholders.

  7. Research results and everything related to it: Hypotheses, scenarios, UT metrics, interview recordings with notes, etc.

  8. Future features and wishes: Create a separate file with all the wishes of the team, clients, grandma and everyone else. Then you can separate the wheat from the chaff, but it's always good to have something to separate.

  9. Flow of designers' work: How does a task come in, who assigns it, who checks its readiness, what should be in the task, how does the review take place, how to transfer it to development, how to conduct research, etc.

Conducting competitor analysis

Competitor analysis helps you understand how similar products solve the same problems and identify best practices and shortcomings of existing solutions.

You can learn a lot from your current competitors. Find out what their ups and downs were. Study their market and even find out your approximate market, reach and profit (since you will be competing with these guys, among other things).

In the worst case, you will find “mammoth bones” and understand where the previous products burned out.

Application example: In a new e-commerce development project, competitor analysis might include researching the largest online stores, their features, user experience, and customer reviews.

A standard example of competitor analysis that I have used in my work:

  1. Competitor name and their website (or product);

  2. Visits: Gives you an idea of ​​how popular the product is. You can also use various research company ratings if we are talking about big players. Each industry has its own ratings, so just do some research.

  3. Users: You can find them in product descriptions or competitor vision statements. You can also gain insights about your users.

  4. How a competitor solves a user problem: Big players often write articles about the benefits of their product, while small ones simply show their advantages somewhere on the pages of the site or product. You can look for presentations for investors or integrations with other products.

  5. What features or products does the platform offer: This is one of the most important insights. Here you describe all the services that your competitors offer. You may realize that you have not added this or that important functionality or have come up with something that your competitors do not yet have (and this is definitely worth intensively researching).

  6. Comparison of features of each competitor: If possible, you can always group them logically. This will help you understand which features are present in everyone and are most likely the main ones.

  7. Price of product/service (revenue or investment for products without prices): Many companies offer different payment methods and make different service packages. Try to find the price for similar features or find the minimum and maximum.

  8. Advantages of a specific competitor: These can be articles written by them, as well as reviews from real clients or users. It will be very cool if you find users of a particular service and find out from them in an interview what they think about the service. The main thing is not to violate ethical and legal aspects during the interview.

  9. Product disadvantages: It's simple. Look for negative reviews, interview clients and ask what was so-so (remember not to break the law).

  10. Information about the platforms on which the product works: Important when understanding the specifics of developing a solution. Your design and development time may also change depending on the approach.

  11. Interface: If you have the opportunity to “feel” a competitor’s product, be sure to attach a link or take screenshots. If a competitor does not provide access to their product, search Google for images or tutorials on setting up the client’s product (this works).

  12. Additional insights: At your discretion.

  13. Conclusion: It will be useful later to refresh your memory of key points.

You can add fields with information depending on your product or expertise. Consider this example as a base.

What you can do with competitor analysis:

  1. Analyze all the information received and form an updated vision of the product within the design team;

  2. Create a presentation with graphs and key insights for senior managers or stakeholders;

  3. Showcase within the team and share insights;

  4. Create a backlog of possible features (or at least think about them).

Additionally I want to share an example of a competitor analysis table in Notionto make it easier for you to fill in data about them.

Conducting an interview

Interviews with users and stakeholders help to gain a deeper understanding of their needs, expectations, and problems. This is one of the most effective methods of collecting qualitative information.

Example of use: In a project to develop a new fitness app, you might interview current and potential users to understand their expectations of the app, problems with current solutions, and feature requests.

But what if it’s not a fitness app, but the same fintech, where you can’t just come to users, especially if these are high-status users or B2B operators?

You can:

  1. Contact your manager and ask to find respondents: You don't have to do everything yourself. Your software will help you allocate a budget for research, or sign a contract with a recruiting company, or pay for research services. There are many options, you need to communicate.

  2. Use the services of a recruiter from your company: If you have it.

  3. Search yourself: Remember that you can always do it “for free”. It all depends on your expectations, ambitions, and the time you have allocated. It will definitely take longer and take more effort, but communicating with even a few respondents will help you better understand the product and user needs.

Before conducting an interview, I recommend that you familiarize yourself with the general principles of conducting it:

  1. Allow no more than an hour for the interview: This way, neither you nor the respondent will get tired. And don't conduct more than 3-4 interviews a day (this applies to those who don't work as researchers).

  2. Ask to record the interview: This will help you when filling out your interview details.

  3. Be kind and calm;

  4. Don't interrupt;

  5. Don't push: Here, researchers may disagree with me, but I believe that if a person does not have the desire or time, it is worth letting him go, and not pressuring him. You will be able to get information from another person, and with the current respondent you will simply finish a little faster. But I understand that this case will not work if you have very few respondents.

Approximate interview plan: In interviews with users, of course, it is much more difficult to present a unified list of questions, but the main points can be highlighted:

  1. Acquaintance: You need to lighten the mood and make the person feel comfortable. Introduce yourself, tell them about your research (you can distort it a bit), about yourself and something funny. Talk about the weather or your hobby, this will make the person feel comfortable and less tense. Here's another one a small checklist on how to relieve tension from your interlocutor.

  2. Find out a little more about your respondent: Place of work or study, position, what are the duties. This helps to tune in to the interview and helps to build a portrait of the audience.

  3. [Здесь блок специфичный для каждого продукта, но мы можем назвать его «пристрелкой»] Find out what product the person uses/used to solve the problems on which we are building a hypothesis: Maybe the person hasn’t found such a tool yet, then everything is a little simpler – we ask them to describe it.

  4. How the respondent makes decisions: Maybe he is not the final link in making decisions. Clarify what criteria are used for making decisions.

  5. [Снова специфичный вопрос для каждого продукта. Назовём его «Флоу»] Ask about how the person currently solves his problems: What is the solution? It can be quite long, and that's okay.

  6. Find out what the pros and cons are of the current or previously used products: Maybe something was especially memorable (Give them time to think. People need to immerse themselves, remember, decide).

  7. Time to fantasize: What is the ideal product for solving the respondent’s problems?

  8. Additional insights that you didn't ask about, but wanted to share with you.

  9. Thanks for participation: This can be either financial or any other gratitude.

What do we get as a result?

At the end of the Discovery phase, you will have documented your core product hypotheses, competitor analysis, and interview results.

You will be able to rely on them when creating:

  1. User portraits

  2. Person

  3. Working out CJM

  4. UJM development

  5. Choosing a development platform

  6. Development prioritization

  7. Development of new functionalities

  8. Release planning

Conclusion

The Discovery phase is an important stage of the UX design process that lays the foundation for successful product design and development.

This stage helps to avoid costly mistakes in subsequent stages of development, improves understanding of user needs and forms a clear vision of the project. A properly conducted Discovery phase significantly increases the chances of product success in the market, which is confirmed by numerous cases from the lives of successful companies, such as Airbnb and Spotify.

That's all for now. I hope this article helps you organize your initial research phase correctly. For more useful materials (and memes), you can find on my channel and other resources.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *