Why We Still Ship Bad Products: A Designer’s View from the Inside
Big beautiful design teams, but the products still suck, why?
While we have come a lot farther in the world of design, and we do see revolutionary changes in the way interfaces are being delivered, but there still exist a lot of mediocre products and services out there, that have big beautiful design teams, but the products still suck. Why?
There is no short-answer to this, as a lot depends upon the company priorities and dynamics.
When there are many decision makers, there is a higher chance of ambiguity, and that further leads to poor decision making, or sometimes — a situation where no decisions are being made at all, and everyone is only moving in loops.
This further brings us to —
A Confession from the Inside
As a designer, I have worked in start-ups, scale-ups, and even in fast moving growth and acquisition environment. I’ve had my moments of panic, fear, and anger.
I’ve handled disagreements within teams, and I’ve also celebrated hard when a feature launched successfully.
I have seen a lot in the past 8 years of my career as a product designer, and now I recognize the feeling. The feeling of something not being right, even if I am not able to point out what.
When you become a seasoned professional, you know what gives you the ick. And for me, it is the gut feeling I get when I dive into the details of a project, and when I get that sinking feeling of shipping something that I know, will be frowned upon by most of our users.
No, not visually or aesthetically, but product requirement wise it will be frowned upon. I have always worked in complex B2B SaaS platforms, so most of our users are rather power users. Users who know the product more than a general internet wanderer. They know what they want, and they’re familiar with our most common user journey flows.
I can tell when our users probably won’t even need a complex sh*t that we are forcing them to accept, but the higher management is after everyone’s life to push that feature into the product just to impress investors.
For example — AI.
I agree that artificial intelligence is great and all, but if you push it down everyone’s throat without understanding if it is even needed in that place or not, there’s a higher chance that it will backfire harder than you can handle. I have seen clients churn and cancel their contracts (literally) because they felt that the platform had become harder to use and their specific use-cases were not being solved.
In such moments, one way to handle ambiguity is to be honest. Be honest with the higher-ups, the management above you, and tell them that you don’t think this will work because of all the reasons that pop-up in your head.
Bring your experience into the discussion, without blaming anyone, be rational about the market condition, and acknowledge the emotional dissonance that users will feel if they see random features popping up, slowing down their work or making it more complex, or introducing a new learning curve for them to understand.
Despite all these discussions, the bigger question will still remain —
“With all our knowledge, tools, and teams — why do bad products still get shipped?”
It’s Not Because Designers Don’t Care
Many badly designed products have some great designers working in the teams, and have decent-sized teams taking care of design. But when we talk about SaaS products to be specific, there are many pieces that have to come together for the whole ecosystem to function seamlessly. And that’s where the challenge is, from design point of view.
Bad products don’t get shipped because designers lack skill, empathy, or effort. But because, there are — misaligned priorities, unclear ownership, too many hands, and not enough conviction.
I’ve been a part of a design team where we all worked hard, reduced confusion and brought clarity into chaos, and still ended up shipping a broken feature.
Well, not exactly broken, but something that would break in a majority of the cases. We knew that it would. We had tested it. But the decision makers were adamant because it worked in 50% of the cases. And for them it was good enough to ‘get started’.
While, I also agree that something needs to be shipped otherwise the teams will stay stuck only building and not shipping anything at all, but at the same time, we need to define the minimum viable standards (MVS) for shipping a product.
In my team, we later came up with minimum requirements that a feature had to fulfill in terms of research and testing, for it to be qualified ‘fit’ to be shipped.
The System Is Set Up to Prioritize the Wrong Wins
When we talk about product roadmaps and features that need to be shipped, it is often political, and not strategic. Strategy does come into play, but only after the political movers are satisfied with using their powers into changing things the way they want them to be.
Success is often measured in ‘deadlines met’, and not ‘outcomes achieved’.
If your design team is also more inclined towards meeting deadlines all the time, rather than zooming out, and seeing how many outcomes they actually achieved, you know that the way success is being measured in your team is flawed, and that you need to change the lens.
Teams are pushed and incentivized to move, but not to pause and analyze if the direction that they’re moving in, is right or not. This is a classic case where PMs optimize for speed of delivering things, leadership chases market parity features, and design reviews are more focused on UI perfectionism, rather than user impact.
Everyone Owns a Piece, But No One Owns the Whole Pie
When responsibility is fragmented, people don’t want to own the whole thing. Nobody wants to do that. They’re happy with their piece of the pie, and that’s it.
This is where leadership needs to recognize how the employees perceive their roles and responsibility. Do they need to perform certain actions as a part of their job, and sign off? Or do they need to evaluate, time and again, if their actions are meeting the larger objective? If yes, how often is such a practice encouraged within the organization?
Mostly within companies, the product owns the ‘what’, and the tech owns the ‘how’, but have you ever wondered, who owns the ‘why?’
In all honesty, the ‘why’ should be owned by everyone to some extent. The product should own the why as they should be able to answer why they proposed a certain feature, and why they advocated for a certain outcome?
The tech should own the ‘why’ as they should be able to answer why they used a particular tech stack to build something? Was it sustainable and easier to maintain?
Design owns ‘how it feels’, but at the same time, design should also own the ‘why’ along with product, asking foundational questions.
Strategic vacuum leads to fragmented, disjoint decision-making. This is why strategy should include different voices, from different departments. Design in particular, can lead to bringing clarity in chaos, and clearing the air when it comes to feature-confusion.
Designers often feel the impact, but by the time the decisions reach them, it is too late to react, and that is why it is more crucial than ever for designers to be involved in early stage product planning, and not last minute UI refresh.
The Quiet Ways Designers Compromise
If we have to talk about a death by a thousand cuts, that’s where design in most orgs comes in.
Designers compromise in a lot of quiet ways and the product suffers, users are churned, and in turn, it is the designers who face the heat of redundancy and irrelevance within a product team. Design is often the first one to be targeted when the turbulence hits.
Either onboarding is cut short to hit a sprint, or usability testing is cancelled to save time. Sometimes poor edge-case flows are accepted because engineering is blocked, and at other times small compromises lead to systemic erosion of the product experience.
All these seemingly small and harmless initiatives lead to accumulating a larger UX debt that later causes panic in the product team when addressed.
Real Design Impact Requires Strategic Courage
Building great products isn’t about perfect execution, but it is more about intervention and courageous push-backs at the right time.
Designers need to be involved in strategic planning to spot the problems early on. They help the team zoom in and zoom-out when required. More designers need to speak up in roadmap reviews, question briefs and risks early.
It’s not about ego, but more about responsibility and owning the whole pie, not just a piece of the pie.
What ‘Designers’ Can Do Better (Without Waiting for Permission)
As a designer, you can always —
Start conversations earlier: Don’t wait for your management or leadership to push you to speak. Speak when you feel like you should be heard. Raise your voice with logic and rationale.
Reframe problems, not just solutions: Talk about whether the problems that the company is aiming to solve, are even the real problems that the users are facing? Define and re-define problem statements. Validate them using real data from real users.
Build metrics into your design thinking: When you are advocating design thinking and design led outcomes, bring in metrics to support your argument.
Create visibility for design trade-offs: If there have to be alternate solutions for a problem, always discuss the design trade-offs, talk about the debt that the team will have to later consider in the future.
Don’t just be the voice of the user but also be the voice of outcomes: Always consider the larger picture, the broader mission and vision of the company that should ideally be your north-star metric. You will always know which direction to follow, and which metrics to measure. This will also save you from measuring fluff.
Hi, I’m Mehekk, a Senior Product Designer with around 9 years of experience, based in the Netherlands. Follow me on Medium or subscribe my Substack newsletter to never miss a story. You can also follow me on Instagram or connect with me on LinkedIn.
See you around.
—
MB ❤️