How to actually build a succesful product (from a UX standpoint)

5 min read

May 21, 2025

Image credit: Alisa Zahoruiko

As someone who spends 2+ hours a day on LinkedIn—and works as a UX Designer—how many of you have experienced this too? Your feed is flooded with new AI tools and endless tips on how to integrate them into your workflow.

Don’t get me wrong—I love using AI to speed up my process. It’s exciting to see breakthroughs that bridge design, development, and business. But I’ll admit, it can get overwhelming.

That’s why in this story, I wanted to take a step back and revisit what really matters as a UX designer—what it actually takes to build a successful product.

Early in my journey, I learned about the Design Thinking framework and used it consistently. But as I took on more projects, I realized there’s often a gap between theory and the practical strategies needed to build a great product—especially in ambiguous environments.

While I’m still growing in this field, I wanted to share my takes on what it truly takes to build meaningful products from 0 to handoff.

Step 1: Start with the problem, not the feature

Every successful product starts by deeply understanding the problem. Skip this, and everything downstream suffers. I always start with:

Every successful product starts by deeply understanding the problem. Skip this, and everything downstream suffers. I always start with:

  • Surveys to specify problem scope and statement

  • User interviews and observational research to uncover pain points

  • Market scan + competitor benchmarking

  • Any existing research on the problem / similar situation 

  • Surveys to specify problem scope and statement

  • User interviews and observational research to uncover pain points

  • Market scan + competitor benchmarking

  • Any existing research on the problem / similar situation 

At this stage, I use a method that I call a Problem Terrain: pain points, motivations, blockers, and current hacks users rely on. This becomes the product foundation.

At this stage, I use a method that I call a Problem Terrain: pain points, motivations, blockers, and current hacks users rely on. This becomes the product foundation.

Fall in love with the problem, not the first solution idea.

Step 2: Define Clear Outcomes

Once the problem is validated, I frame it into a clear How Might We statement and map out:

  • Success metrics (both user and business)

  • Long term vs short-term goals

  • Guardrails (e.g., team scope, time constraints, resources)

Example: For a Gen-Z audience, I framed: "How might we help young adults explore and understand the long-term outcomes of their career decisions to reduce anxiety, build confidence, and support more intentional choices?”

If a team doesn’t have a shared vision of what success looks like, you'll iterate endlessly with no alignment.

Step 3: Shape the Solution (Not Design Yet)

Shaping is where we explore possibilities without overcommitting. I love using:

  • Collaborative ideation session.

  • Sketching with devs, PMs, and other stakeholders.

  • System-level thinking (will this scale? Where does it fit in the ecosystem?).

The output here is a feature wishlist, a few promising directions, and early storyboards.

Step 4: Prototype and Validate

Only after shaping do I move into design tools. I create:

Only after shaping do I move into design tools. I create:

  • Lo-fi prototypes in Figma (linked flows only).

  • User test scripts based on top tasks.

  • 3-5 usability testing sessions per prototype version. 


You can start polishing visuals here but the goal isn’t pixel-perfect yet. It’s to learn what works and what doesn’t. I typically use moderated Zoom tests to gather real insights.


Ensure consistency and accessibility before development by running a quick UX audit.

  • Lo-fi prototypes in Figma (linked flows only).

  • User test scripts based on top tasks.

  • 3-5 usability testing sessions per prototype version. 

Only after shaping do I move into design tools. I create:

  • Lo-fi prototypes in Figma (linked flows only).

  • User test scripts based on top tasks.

  • 3-5 usability testing sessions per prototype version. 


You can start polishing visuals here but the goal isn’t pixel-perfect yet. It’s to learn what works and what doesn’t. I typically use moderated Zoom tests to gather real insights.


Ensure consistency and accessibility before development by running a quick UX audit.

You can start polishing visuals here but the goal isn’t pixel-perfect yet. It’s to learn what works and what doesn’t. I typically use moderated Zoom tests to gather real insights.

Only after shaping do I move into design tools. I create:

  • Lo-fi prototypes in Figma (linked flows only).

  • User test scripts based on top tasks.

  • 3-5 usability testing sessions per prototype version. 


You can start polishing visuals here but the goal isn’t pixel-perfect yet. It’s to learn what works and what doesn’t. I typically use moderated Zoom tests to gather real insights.


Ensure consistency and accessibility before development by running a quick UX audit.

Ensure consistency and accessibility before development by running a quick UX audit.

Only after shaping do I move into design tools. I create:

  • Lo-fi prototypes in Figma (linked flows only).

  • User test scripts based on top tasks.

  • 3-5 usability testing sessions per prototype version. 


You can start polishing visuals here but the goal isn’t pixel-perfect yet. It’s to learn what works and what doesn’t. I typically use moderated Zoom tests to gather real insights.


Ensure consistency and accessibility before development by running a quick UX audit.

Step 5: Build With Your Engineers

I don’t throw designs over the wall. Instead:

  • Annotate interaction states thoroughly.

  • Pair weekly with devs to walk through user flows and asses technical limitations.

  • Use a shared design system or help create components in Figma for handoff.

  • Annotate interaction states thoroughly.

  • Pair weekly with devs to walk through user flows and asses technical limitations.

  • Use a shared design system or help create components in Figma for handoff.

Design should anticipate implementation, not just deliver artifacts.

Additonal:

  • Give and receive feedback intentionally: Be specific (“this interaction feels too hidden for a primary task” vs “I don’t like it”), Frame feedback around goals, not taste, and Ask for the kind of feedback you want (“I'm not sure about the clarity of this flow—thoughts?)

  • Copywriting matters – A lot: Good UX isn’t just about layout—it’s also about language.

  • Back your design with data and story: Oftentimes, It's not about convincing stakeholders with the design itself, it’s about proving the impact and how.

This is just what’s worked for me so far—Not saying it’s perfect, but this mindset has helped me build better.

Copyright © 2020 Enrico Soputra. All rights reserved.
Copyright © 2020 Enrico Soputra. All rights reserved.