I've been fixing UX for successful products and honestly - the mess is part of why they succeeded
by•
Uncomfortable pattern I keep seeing: the products with the worst UX debt are usually the ones that found product-market fit fastest. They ignored "best practices," shipped ugly-but-functional features, and got users anyway.
Then they scale and everything breaks. That's when they hire me.
But I've started wondering - did the rough UX actually HELP early on? Not despite being "bad" but because it prioritized solving the problem over looking good?
Meanwhile, products that follow all the UX rules from day one often look great but struggle to find users.
Am I rationalizing technical debt? Or is there something real here about the relationship between polish and PMF?
For founders here: Did you ship "ugly" on purpose or did PMF justify the mess later?
92 views
Replies
Cal ID
I could relate to this a lot - our messiest UX came from racing to fix what users actually needed, not what looked the best to our eyes. Cleaning up started when onboarding new users became painful and support tickets spiked. At an early stage, “ugly but working” wins. Later, clarity and polish matter way more!
@sanskarix This is the pattern I keep seeing - support tickets are the early warning system.
When the same confusing flow generates 10 tickets, that's not a support problem, it's a UX debt problem.
Question: Did you track when tickets clustered around specific features/flows? Or was it more of a general "everything is breaking" feeling?
Trying to figure out if there's a way to predict the cleanup moment before it becomes painful.
Cal ID
@tanya_donska Exactly! We started seeing clusters - certain features got way more complaints or confusion than others. That’s usually the signal to prioritize a redesign.
Patterns in feedback make it clear when patches aren’t enough, and it’s time for a real UX design.
General complaints are difficult to act on, but patterns helped us see exactly what needed fixing first.
@sanskarix This is so practical. "Patterns in feedback" vs. "general complaints" - that's the filter.
So the framework is basically:
Track which features generate support tickets
Look for clustering (same 3 features = 80% of tickets)
That's your redesign priority list
Did you use any tools to track this? Or was it more manual - just noticing patterns in your support system?
Cal ID
@tanya_donska It was mostly manual, the tools I used were PostHog and Clarity. PostHog gives a handsome amount of data, and its easy to spot patterns in there. Using any more tools wouldn't make sense to me as its limit your thinking in a way (happened to me)
This is a really good point. I’ve seen the same — the “ugly but useful” products often get traction first because they’re solving a pain point fast, not polishing pixels. In some ways, the mess is a byproduct of moving at the right speed.
@viktorgems Yes - the mess proves you're prioritizing learning over aesthetics.
But here's the tension: At some point, the mess itself slows you down. You can't move fast anymore because everything's so tangled.
@tanya_donska True, part of the journey
That’s a really sharp observation, @tanya_donska, & I think you’re absolutely right. In the early stages, function over form usually wins. When teams are chasing product-market fit, the goal is to solve a problem quickly and validate the idea, not perfect the interface. That kind of rough UX often means the team is moving fast, iterating on real feedback, and focusing on delivering value instead of polish.
I’ve seen a lot of startups spend months refining their design systems before they even have users, and they often struggle to find traction. Meanwhile, the scrappy ones with messy UIs tend to succeed because they’re focused on solving pain points first.
So I’d say the mess isn’t just a side effect, it’s part of the process. Once product-market fit is solid, that’s when it makes sense to bring in someone like you to smooth things out and make it scalable.
Curious to hear your thoughts on this: do you think the same approach still works today, now that users have higher expectations for polished interfaces even in early versions?
@invokker Great insights, Rajesh! You've articulated the core tension perfectly. The 'function over form' approach is indeed crucial in early-stage startups.
To answer your question: I believe the core approach still works, but the bar for 'acceptable ugliness' has definitely risen. Users now expect a baseline of usability and aesthetic coherence, even in early products. The key is striking a balance – solving the core problem quickly while maintaining just enough polish to not frustrate users.
The real skill now is in creating 'minimum viable polish' – interfaces that are functional, intuitive, and just polished enough to not distract from the core value proposition
Alai
Curious, are you seeing any interesting bad UX patterns emerge across AI-native apps (or apps where AI is a big part of their product)?
@krishna_gupta51
Definitely seeing some interesting patterns in AI apps, Krishna. The main UX challenges are:
Unclear input/output boundaries
Over-reliance on text prompts
Lack of clear user guidance
Most apps are still forcing AI into traditional UI models instead of creating truly adaptive interfaces. The most promising products are reimagining interaction from the ground up
Alai
@tanya_donska Interesting. As people are getting more used to ChatGPT i feel like everyone at some level feels comfortable writing prompts. Traditional UI models had deterministic buttons instead of prompts. However, sometimes I do feel that I'm just writing a prompt and nothing really is changing or its changing everything instead of giving me more granular control. Is that what you mean by over-reliance on text prompts?
Alai
@tanya_donska inspired by this I wrote some of my learnings building UX for AI apps. would love to get your thoughts: https://www.producthunt.com/p/alai-2/lessons-from-building-an-ai-design-tool