Why Discovery and Design Define Digital Product Success

In any serious digital project, the first steps determine everything.
In more than a decade as a designer, I’ve had the opportunity to work with a variety of teams and clients – from startup enthusiasts with ideas on a napkin, to large enterprise companies looking to add new functionality to an existing system. Regardless of the initial conditions, one thing has always been clear: if we skip Discovery and poorly set up the Design phase, everything later becomes more expensive, slower, and more uncertain.

In this article, I will cover the exact steps and scenarios that can help any designer or product stakeholder understand the ways of how a good product base is set up in the initial stages, and how it can have a positive impact on the future of the product.

Discovery phase: more than just research

The discovery phase is, in my experience, the most important step in any product development. It's not just market research. It's a collaborative moment where the team and client together define what we're trying to solve, for whom, and why it makes sense.

The core of the team that initiates this phase would usually be a Product Designer, a Product Manager, a Software Engineer, and the Stakeholders. This team can significantly outperform the concept if they structure the project correctly, following strict deadlines, scope of work, and all smaller details as a foundation for addressing future problems that might arise.

When a project begins without clear answers to these questions, what I've often seen happen is a lack of focus, conflicts among team members, and ultimately, a product that no one uses.

Three scenarios that we encounter most often

1. Client without documentation or clear direction

In these cases, we have a clean slate, and these are the most fun to work on.
Through conversations, research, and workshops, we define:

Who is the target audience and what problems do they have?
What would a solution really mean to them?
What is currently available in the market and where is there room for differentiation?
Would any type of target audience actually need such a product
...

There should be a set limit to these types of questions we are looking to answer. Having too many of them might clutter the ideation process, so we always ask the most important ones that are connected with what we are doing and serve as a basis for the whole duration of the project.

Through a structured process, user interviews, competitive analysis, and user journey mapping, we build a clear picture of the product before we draw a single screen.

It is crucial, in cases as this, that all questions are answered as soon as possible. Sometimes the client might be in need of a fast MVP scope, which needs a detailed design, and we need to cover all questions to make it as the client wants, but especially following industry standards and our structures to make it happen.

2. Client with existing documentation

When a project comes to us that already has documentation, we often find ourselves with a lot of assumptions. That’s when we step into the role of detective: we analyze, validate, and, where necessary, correct direction. Our mission is not just to “implement the design,” but to ensure that we’re doing the right thing in the right way.

Iterating based on the documentation we have is one of the first steps we can take in this type of scenario, since we do have materials to work with, it is on us as a team to validate do these requirements that are set from the point of view of the client, actually in the right direction this product should take.

In this process, the client might have an idea but the documentations are not valid to something we can build, or build in the way that they want, and in these instances, we validate the document, do as much research as we can and provide clear goals towards the client and the team of managers that handle this part with us designers.

3. Existing product, new feature

For companies that already have a product, the Discovery phase helps us understand the existing ecosystem: how users currently use the product, what they are missing, and where the new feature can add value. In this context, we work with data, user feedback, and often take a step back to ensure that we are not introducing complexity without a clear purpose.

Getting to know the product is a must in this phase, and we might cover many aspects of what the client already has which might have some inconsistencies and we work together to resolve these “mistakes” and deliver a better visual appeal and much more importantly, a functional design that will upscale their feature and the product itself.

Keep in mind that continuing the work from an existing product has its boundaries, and we as designers need to thoroughly understand what the product is about, what it offers, how we should approach a new feature, and where our work can benefit the client in the long run.

Every client/project has it’s own story and growth vision.
It is our goal to take it onto the next level.

Key activities we carry out

Discovery is not a checklist, but a process that adapts to the project.
However, some elements are constant:

• User research – Interviews and questionnaires give us direct insights into the needs and behaviour of users.
• Competitive analysis – Not to copy, but to learn from others' mistakes.
• Defining personas – I always work to ensure that users do not remain an abstraction. Real faces, concrete habits.
• User journey mapping – A clear visualisation of which points users pass through.
• Hypotheses – We set them and later test them through design. This is the foundation for making decisions based on knowledge, not gut feeling.

Not all projects actually need all of these, and there are many more we could name here. Setting up the initial phases should mainly revolve around good research, key outcomes we are pushing towards, and especially where the product will benefit from their customer.

Why do I insist on this approach?

I’ve had projects where the Discovery phase was skipped. Then the client comes in when the product doesn’t work, the users are confused, and the budget is spent. In these cases, we often have to reset the project, which is painful, slow, and expensive.

That’s why I still believe that Discovery is the most worthwhile investment in any project. It doesn’t prolong development, ​​it saves it.

If the client doesn’t want this phase at all, it is up to us to explain in detail as clearly as possible why not having this discovery phase will have grave defects for later iterations on the product. It’s not a typical part of a product process, but having worked on many of products that didn’t include any type of discovery phase, I can’t recommend it more!

Design phase: When the research takes shape

After we created all that we neededproposal in the Discovery and agreed, we moved on to Design. My approach to design is not just “make it look pretty,” it’s: make it make sense, solve a problem, and guide the user logically through the interaction.

Creating a V1 proposal

The first proposal (V1) the client sees must reflect everything we’ve learned:

• It must be visually compelling to demonstrate quality
• Structured to demonstrate functionality
• Through prototypes, show user journey flows
• And open enough for feedback and further development.

It is this version that often helps the client "click" with the idea. To see how their product could look, but also how the logic, research, and user behaviour lie behind every detail.

Iterations on this V1 proposal are a must. If we have to do 5 different versions, so be it. A crucial part of the whole process that we are setting up with this way of work, is to iterate and reiterate everything we are designing, until we all agree that it looks/works/feels the way we envision this product to be.

Design system and consistency

All projects I manage get their design system.
A set of rules that ensures consistency across all screens, but also efficiency in communication with developers. This way we protect the brand, speed up development, and reduce errors.

In today’s design industry, we can always find new ways of building this system, and we shouldn’t redo it every time. Any kind of design system has its elements that can repeat for hundreds of different products and still have the same ones over and over again.

Try having one system that serves as a basis for all systems you are building for the future, and just re-use elements as much as you can to save time when trying to finalise the discovery phase. They are all usually the same anyway.

When do you end this discovery phase?

You could say - never!
As we went through all aspects of how this phase helps your client and your team to get on the same page, it doesn’t have to end at all.

Here is an example that reflects this, which happened to me recently:
We were building a large onboarding flow for one client. In this onboarding process, we wanted to portray how the app works, what it looks like when the user logs in, what the key features of the app are, and how the user could/should navigate when they create the account.

We assumed that users would benefit from having a big “15-screen” flow of the onboarding, but we still wanted to allow them the option to skip all of this and start using the product itself. We created at least 10 different iteration flows for this onboarding (even before the release), and when the actual users started using the app, over 60% skipped the flow and started using it already.

What happened, you might ask?
Well, the “onboarding flow” was adapted from marketing strategies on social platforms.
Users already knew what the app is and how they can benefit from it.

The primary point of the story would be - you never stop discovering!
The discovery phase should only have a beginning, not the end. Every product or feature you build should always be expanded upon from the research phase. New trends and “tricks” are being created daily, and if you had a discovery phase for your product 5 years ago and set it in stone, now your product probably lacks in some areas, which you can investigate by redoing this phase.

For fellow designers and companies that develop digital products

If you are developing a product and are thinking of starting design "as soon as possible", stop. Invest time in clarifying the problem, user, and context. Don't wait to get feedback when it's too late - work with users from day one.

This type of process in design is something my team and I implemented in numerous products we have built successfully. Trying to incorporate this into your work model might not work to the full extent, but it will certainly help you, your client, and your team to create a great way of collaboration and future goals for which the product will move towards.

And don't forget:
Discovery and Design are not just phases, it's a philosophy of work.
A curiosity-based approach. If you think of it like this, every new product you are working on, will have a positive outcome, no matter the industry, software or functionalities you are building.