How to Fix Your Startup’s UX (Full Guide)

Daniel Andor walks through his three-phase Product Clarity Framework for fixing startup UX: diagnose problems through audits and data, define solutions with user testing and design systems, then refine through iteration. Most roadmap ideas deliver no customer value and need multiple rounds with real users before they work.
Chapters
Most founders I work with face the same challenge. They build products with powerful features, but users either don't know how to use them or can't even find them. And it's not because the product is bad. It's because nobody took the time to understand where users actually get stuck, test possible fixes before building them, and then refine things once they are live. I've been designing products for more than 15 years, and after working with dozens of tech startups, I've built a simple 3-phase framework that removes the guesswork from UX and helps teams fix the things that actually hurt growth. So in this video, I'm going to walk you through the entire framework step by step with examples from projects we've worked on so you can apply it to your own product. Let's dive in. Before I get into the framework, I want to explain why most startups struggle with UX in the first place. There are 2 uncomfortable truths when it comes to building products. The first is that almost half of the ideas that end up on a roadmap might not bring any value for the customer or the business. The second is that even the ideas that have the potential need multiple iterations to get them right. And this is especially true right now when companies are trying to reduce costs and be as efficient as possible. So the question becomes, how do you sort through all of those ideas and figure out what's actually worth building? Most startups skip this entirely. They go straight from, we think this is the problem, to writing code. And then months later, they find out that the feature they built isn't solving the problem they thought it would. Or worse, users don't even notice it exists. This is where product discovery comes in. Product discovery is the process of understanding what your customers' problems and needs actually are, and then validating your solution ideas before committing engineering time. As Marty Cagan puts it in his book Inspired, if you can prototype and test ideas with users in days rather than months, it completely changes the results. And that's true even if you're thinking about white coding and like launching something really, really fast. You still need user input. And that's the foundation of what I'm about to walk you through, starting with my Product Clarity Framework. The framework has 3 phases, and each one builds on the last. Phase 1 is Diagnose, where you figure out what's actually broken and why it matters. Phase 2 is Define, where you explore solutions and validate them with real users before building anything. And Phase 3 is Refine, where you design for production and keep improving based on what you learn after launch. The reason I structured it this way is that each phase solves a specific problem. Phase 1 takes you from guesswork to fully clear priorities. Phase 2 takes you from builds that are based on assumptions to validated ideas that actually gives you confidence. And phase 3 prevents what I call UX drift, which is when a product slowly gets harder to use over time because nobody's watching the experience after launch. So let's go through each phase in detail. But before I do, if you're a tech startup founder and your product's UX is causing friction with users or hurting your growth, This is exactly the kind of work we do at Duran. You can visit duran.co or click the first link in the description to learn more about how we can help. But let me now break down each phase of the framework. Phase 1, diagnose. The goal of this phase is to build a shared understanding of what's actually broken and what matters most right now. A lot of teams think they know what's wrong in their product, but when you dig in, the problems are often somewhere they didn't expect. The first step is running a UX audit, walking through the product and highlighting all the friction points that might might be causing problems. But it's not just about looking at the product ourselves. We also review support feedback, usage signals, and any customer data that shows where people drop off or get confused. For example, when we worked with an AI note-taker startup, the audit revealed that users were asking for features that were already in the product. They just couldn't find them. We then summarize everything into a clear report with key findings, pros, cons, and specific suggestions for improvement. From there, we run a strategy workshop with the founders and key team members. We through the product, the personas, the problems they want to solve, core features, blockers, constraints, everything the team needs to be aligned on before making changes. We also map out how the founder measures success, because if the team isn't aligned on that, every design decision becomes a debate. One thing that's really valuable here is surfacing assumptions, things that the team treats as facts but that haven't been tested yet. We also look at competitors, define user personas. Focusing on their needs, motivations, and frustrations, and then map the full customer journey. In the AI note-taker project, the journey map showed 2 major friction areas, one around onboarding and another one around using the core product, which gave us a clear focus for the next phase. In one of our medtech projects, we discovered that the onboarding was confusing and that a key part of the main process was missing, leading to lost revenue. Finally, we put everything on an impact-effort scale so the team knows exactly what to fix first and what can wait. The outcome of whole phase is a clear overview of the product, defined user personas, a mapped user journey, and a ranked list of priorities. Phase 2 is define. Phase 2 is about exploring solutions and validating them before you write a single line of code. This is where startups save themselves months of wasted development time because the biggest risk isn't building slowly, it's building the wrong thing fast. We start by bringing the wider team into the room— engineering, marketing, customer support— because each person sees the product from a different angle. We make sure everyone is aligned on the challenge, then we research how other companies solve similar problems. Both competitors and products from completely different industries. From there, each team member sketches their own concept of what the solution could look like. Just pen and paper, nothing fancy. And those sketches become the starting point for choosing a direction. We define the main steps customers will go through, test whether they understand the product and can use it, and collect feedback across different areas. We categorize everything into what's working, what's tricky, and what the biggest pain points are. With the edtech platform we worked with, where they had 650 schools and over 100,000 users, prototype testing confirmed the onboarding was too complicated for teachers. But it also uncovered something unexpected. Some teachers didn't have email addresses, so they were creating email accounts for their students just to get them on the platform. That's the kind of insight you only get by putting things in front of real users. Once we have validated insights, we turn everything into build-ready flows. This includes aligning UX decisions with technical constraints and defining a design system with all the elements developers need: colors, typography, buttons, input fields, and every screen and flow required. With the AI note-taker, we went from problem to development-ready design in about 5 weeks. Phase 3, refine. This is the phase most startups skip, and it's also why products slowly get harder to use over time. You ship a great redesign, everyone's happy, and then 6 months later the experience has drifted because new features were added without the same UX attention. So we stay embedded alongside development, designing and refining real screens and flows as they are being built. What looks perfect in a design file doesn't always hold up under real-world constraints, so regular check-ins with the dev team help catch problems early. After launch, we test the shipped experience with users and observe real usage to understand what works What breaks and what's missing. And then we translate those ongoing insights into clearly defined improvements and features before the next build cycle starts. Instead of the roadmap being driven by the loudest voice in the room, it's driven by what you are actually seeing in the data and hearing from users. This closes the loop and feeds right back into phase 1 for next iteration. Once we go through the framework once and everything is put together, the whole process is faster and smoother as we revisit just the parts that are needed for each stage. I want to be clear about why this framework matters, especially for startups in the growth stage. When you're early, you're moving fast, and that's fine. You need to ship things quickly to find product-market fit. But once you have users and you're trying to grow, the cracks in your UX start showing up as business problems. Low activation means people sign up but never experience the value of your product. Poor retention means users leave because the experience is frustrating or confusing. Inconsistent design slows down your development team, Because every new feature requires reinventing the wheel. And broken flows mean users literally can't finish what they came to do. The Product Clarity Framework addresses all of these by making UX decisions evidence-based instead of assumption-based. You stop guessing what's wrong and start knowing. You stop building features nobody asked for and start solving the problems that matter. And you stop letting the product drift after each launch and start keeping it tight as you scale. Working with early and growth-stage startups for 15 years, I saw the results of skipping these steps. Not spending time to understand the problem or the users, not testing solutions with users and just start building. Just because it looked faster or because we thought that it's just a small thing and we know it well enough. Most of the time this ended up in rework, spending double the development time needed to build it right in the first place. Not mentioning all the frustrated users that lost trust in the product. That's why it's important to keep in mind that testing and iterating on a solution in the design phase is exponentially cheaper and faster. So if you're a tech startup founder and your product's UX is creating friction for users, hurting activation, or slowing down your growth, click the first link in the description to head over to duran.co and get in touch with us. We'll dig into your product, uncover the friction points that are holding you back, and help you fix them using this exact framework so you're not wasting engineering time building the wrong thing. So again, click the link below and reach out to us. And if you want to see our full framework for building new features, then watch this video next.
More from Daniel

UX Insider: Product Hunt Roundup - E.19 - The Demo Account Is the Best Onboarding?

UX Insider: Product Hunt Roundup - E.16 - Too Many Features, No Idea What To Do Next








