How to Fix Your Startup's UX (The Full Framework)

How to Fix Your Startup's UX (The Full Framework)

How to Fix Your Startup's UX (The Full Framework)

A three-phase system — Diagnose, Define, Refine — for fixing the UX that hurts growth, without burning engineering time on the wrong things.

A three-phase system — Diagnose, Define, Refine — for fixing the UX that hurts growth, without burning engineering time on the wrong things.

A three-phase system — Diagnose, Define, Refine — for fixing the UX that hurts growth, without burning engineering time on the wrong things.

Daniel Andor

Daniel Andor

Daniel Andor


Most founders we work with build products with powerful features that users either can't find or don't know how to use. It's rarely because the product is bad. It's because nobody took the time to understand where users get stuck, test fixes before building them, and refine things once they're live. There are two uncomfortable truths behind this: almost half the ideas on a roadmap may bring no value to the customer or the business, and even the good ideas need multiple iterations to get right. That's especially true now, when everyone's trying to be more efficient. So the real question is how you sort through ideas and figure out what's actually worth building. That's product discovery — understanding your customers' real problems and validating solutions before committing engineering time. As Marty Cagan puts it in Inspired, being able to prototype and test in days rather than months changes the results.

That's the foundation of our Product Clarity Framework. It has three phases, each building on the last.

Phase one: Diagnose

The goal is a shared, evidence-based understanding of what's actually broken and what matters most right now. We start with a UX audit — walking the product and flagging friction — but we don't stop at our own opinion. We review support feedback, usage signals, and customer data showing where people drop off. (With one AI note-taker startup, the audit revealed users were asking for features that already existed; they just couldn't find them.) Then a strategy workshop with founders and key team members: product, personas, problems, core features, blockers, constraints, and crucially how the founder measures success — because if the team isn't aligned on that, every design decision becomes a debate. We surface untested assumptions, look at competitors, define personas, map the customer journey, and put everything on an impact/effort scale so the team knows what to fix first.

Phase two: Define

This is where you explore and validate solutions before writing a line of code — where startups save themselves months, because the biggest risk isn't building slowly, it's building the wrong thing fast. We bring the wider team into the room (engineering, marketing, support), research how others solve similar problems, and have each person sketch a concept on paper. We define the main steps customers go through and test whether they understand and can use it. With one edtech platform serving 650 schools and over 100,000 users, prototype testing confirmed onboarding was too complicated for teachers — and uncovered that some teachers didn't have email addresses and were creating accounts for their students just to get them on the platform. That's the kind of insight you only get from real users. Then we turn validated insights into build-ready flows and a design system developers can run with. With that AI note-taker, we went from problem to development-ready design in about five weeks.

Phase three: Refine

This is the phase most startups skip, and it's why products slowly get harder to use. You ship a great redesign, everyone's happy, and six 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 as they're built, then test the shipped experience with users after launch. Those insights become clearly defined improvements before the next build cycle — so the roadmap is driven by what you see in the data and hear from users, not the loudest voice in the room. That closes the loop back into phase one.

Why this matters: when you're early, moving fast is fine. But once you're growing, UX cracks show up as business problems — low activation, poor retention, inconsistent design slowing your devs, broken flows where users literally can't finish what they came to do. The framework makes UX decisions evidence-based instead of assumption-based. Skipping it usually means rework — double the development time, plus the users who lost trust along the way. Testing in the design phase is exponentially cheaper.

If your product's UX is creating friction or slowing growth, head over to durran.co and get in touch — we'll find the friction points and fix them using this exact framework.


Most founders we work with build products with powerful features that users either can't find or don't know how to use. It's rarely because the product is bad. It's because nobody took the time to understand where users get stuck, test fixes before building them, and refine things once they're live. There are two uncomfortable truths behind this: almost half the ideas on a roadmap may bring no value to the customer or the business, and even the good ideas need multiple iterations to get right. That's especially true now, when everyone's trying to be more efficient. So the real question is how you sort through ideas and figure out what's actually worth building. That's product discovery — understanding your customers' real problems and validating solutions before committing engineering time. As Marty Cagan puts it in Inspired, being able to prototype and test in days rather than months changes the results.

That's the foundation of our Product Clarity Framework. It has three phases, each building on the last.

Phase one: Diagnose

The goal is a shared, evidence-based understanding of what's actually broken and what matters most right now. We start with a UX audit — walking the product and flagging friction — but we don't stop at our own opinion. We review support feedback, usage signals, and customer data showing where people drop off. (With one AI note-taker startup, the audit revealed users were asking for features that already existed; they just couldn't find them.) Then a strategy workshop with founders and key team members: product, personas, problems, core features, blockers, constraints, and crucially how the founder measures success — because if the team isn't aligned on that, every design decision becomes a debate. We surface untested assumptions, look at competitors, define personas, map the customer journey, and put everything on an impact/effort scale so the team knows what to fix first.

Phase two: Define

This is where you explore and validate solutions before writing a line of code — where startups save themselves months, because the biggest risk isn't building slowly, it's building the wrong thing fast. We bring the wider team into the room (engineering, marketing, support), research how others solve similar problems, and have each person sketch a concept on paper. We define the main steps customers go through and test whether they understand and can use it. With one edtech platform serving 650 schools and over 100,000 users, prototype testing confirmed onboarding was too complicated for teachers — and uncovered that some teachers didn't have email addresses and were creating accounts for their students just to get them on the platform. That's the kind of insight you only get from real users. Then we turn validated insights into build-ready flows and a design system developers can run with. With that AI note-taker, we went from problem to development-ready design in about five weeks.

Phase three: Refine

This is the phase most startups skip, and it's why products slowly get harder to use. You ship a great redesign, everyone's happy, and six 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 as they're built, then test the shipped experience with users after launch. Those insights become clearly defined improvements before the next build cycle — so the roadmap is driven by what you see in the data and hear from users, not the loudest voice in the room. That closes the loop back into phase one.

Why this matters: when you're early, moving fast is fine. But once you're growing, UX cracks show up as business problems — low activation, poor retention, inconsistent design slowing your devs, broken flows where users literally can't finish what they came to do. The framework makes UX decisions evidence-based instead of assumption-based. Skipping it usually means rework — double the development time, plus the users who lost trust along the way. Testing in the design phase is exponentially cheaper.

If your product's UX is creating friction or slowing growth, head over to durran.co and get in touch — we'll find the friction points and fix them using this exact framework.

Design Process

Product Strategy

Startup

subscribe to our newsletter

subscribe to our newsletter

Get the latest articles straight in your inbox

Get the latest articles straight in your inbox

Practical product and UX insights to help SaaS teams ship with confidence before users get confused or features go unused.

Practical product and UX insights to help SaaS teams ship with confidence before users get confused or features go unused.