Design gets treated as the layer you add once the "real" software is built — a coat of paint applied by whoever's available near the end of the timeline. That framing costs businesses real money, and it's worth being specific about exactly where the money goes, because "good design" is vague enough to be easy to deprioritize under deadline pressure.
Every point of confusion has a measurable cost
A checkout flow with an unclear error state doesn't just annoy a user — it produces an abandoned cart. A settings page that buries a commonly-needed action produces a support ticket. A dashboard that doesn't surface the number a user actually needs produces a phone call to your team, or a churned account. None of these show up in a bug tracker, because nothing is technically broken. They show up in conversion reports and support queues, which is exactly why they're so easy to under-invest in: the cost is diffuse and delayed, while the cost of design work is immediate and itemized on an invoice.
Onboarding is where design ROI is easiest to see
If you've ever looked at a product analytics funnel and watched a large percentage of new users drop off between signup and first meaningful action, that drop-off is almost always a design problem before it's a features problem. Users don't abandon a product because it lacks capability in the first five minutes — they abandon it because they can't figure out what to do next. A well-designed first-run experience that gets a user to one genuine "aha" moment quickly is consistently one of the highest-leverage investments a product team can make, and it's measurable: track activation rate before and after a redesign of that specific flow, and the number moves.
Design debt compounds like technical debt, and it's harder to see
Inconsistent patterns across a product — three different ways to confirm a destructive action, buttons that mean different things on different screens — don't just look unpolished. They increase the cognitive load of using the product every single time, and they increase engineering cost too: every inconsistency is a decision a developer has to make from scratch instead of reusing an established pattern. A real design system (not a Figma file nobody opens, but a maintained set of components with clear usage rules) pays for itself by making both design and engineering faster on every subsequent feature.
The counterargument, and where it's right
It's fair to push back that not every project needs a lengthy design phase. An internal tool used by five people on your own team doesn't need the same design investment as a consumer app competing for attention. The right question isn't "should we invest in design" as a blanket rule — it's "what's the cost of a bad experience here, multiplied by how many people will hit it, and how often." For a public-facing product or anything with a sales or retention motive attached, that number is almost always larger than teams initially assume.
What good design investment actually looks like in practice
- User research before high-fidelity design work starts, even if it's five conversations with real or prospective users rather than a formal study
- Prototyping and testing key flows — checkout, onboarding, the core workflow — before they're fully built, when changes are cheap
- A living design system that engineering actually uses, not a static reference document
- Treating design and engineering as one continuous process, with designers involved through implementation, not handed off and gone
The businesses that get the most value from design are the ones that stop asking "how much will design cost" and start asking "what is our current experience costing us in conversion, retention, and support load." Once you can answer that second question, the design budget usually justifies itself.
Comments (0)
No comments yet. Be the first to share your thoughts.