Every feature works. They don't work together

Each feature made sense when you shipped it. A different team, a different quarter, a different customer asking for it. Now users move between parts of your product that look, behave and sound different, and they notice.

It rarely shows up as one bug. It shows up as slower releases, repeated support questions, and a product that’s harder to explain than it should be.

Signs your product is fragmented

• The same action works differently in different parts of the product.
• Every new feature is built from scratch, because nothing existing fits.
• Sales and support explain the product around its inconsistencies.
• Designers, developers and the content team each work around a different set of constraints.

An example: one content format at Blinkist

Every content format in the Blinkist app had its own UI, its own logic and its own maintenance overhead. Adding a new format meant building from scratch. Users noticed the inconsistency, the content team wrestled with format-specific constraints, and developers dealt with format-specific bugs.

With two other designers and the development team, I unified all content formats into one flexible system. Not a reskin: we defined layouts flexible enough to support new formats and rigid enough to keep the content team from breaking things.

The result: content maintenance time dropped 24%, and the unified format unlocked six new content types that weren’t possible before. The gap between designers, developers and the content team got smaller too.

How I approach a fragmented product

1. Map what exists. Go through the product the way users do and note every place where the same job is done in a different way.
2. Find the decision underneath. Fragmentation is usually a structural problem, not a styling one. At Blinkist the fix was one content system, not a new coat of paint.
3. Design the system, then the screens. Define the patterns new features have to fit into, so the next one doesn’t add to the problem.
4. Stay through implementation. I work closely with engineering and contribute to the codebase when useful, so the system survives the first release.

Questions founders ask

Do we need a full redesign?

Usually not. The fix is often a shared structure under the features you already have. A redesign that keeps the old structure tends to bring the old problems back.

Is this the same as building a design system?

A design system can be part of it. But shared components don’t help much if every feature still has its own logic. The work starts with how the product is structured, and the interface follows.