HelloUI Case Study

HelloUI is a design system for a company running more than five product lines. The problem it solves is not visual consistency for its own sake, it is the cost of every team rebuilding the same interface twice.

I built the system: the token layer, the components, and the documentation that decides whether either gets used.

Multiple product lines were rebuilding the same interface patterns differently.

Not because anyone disagreed about how a button should work, but because finding the existing one and understanding its states was slower than writing a new one. Every release widened the gap, and the products drifted apart at the speed the teams shipped.

I audited the existing interfaces across the product lines first, cataloguing every variant of every pattern in use. The same button existed in a dozen near-identical forms, which is what made rebuilding cheaper than reconciling.

The audit is also the argument. A system proposed in the abstract is a preference; a system proposed next to twelve versions of the same control is a cost.

I audited the existing interfaces across the product lines first, cataloguing every variant of every pattern in use. The same button existed in a dozen near-identical forms, which is what made rebuilding cheaper than reconciling.

I built the system from that audit: a token layer for colour, type and spacing, components documented with their real states rather than their happy paths, and usage guidance written for the engineers who would consume them. Documentation shipped alongside the components, not after.

Documenting real states rather than happy paths is the decision that makes a system get used. A component library that shows the default is a gallery; one that shows empty, loading, error, disabled and overflow is a tool, because those are the states an engineer is actually stuck on at four in the afternoon.

Shipping the documentation with the components rather than after them cost time up front and is the reason adoption did not stall. A system nobody can read is a second system to maintain, not a saving.

200+ components · 5+ product lines · 40% faster UI build.

The first two figures are scope, not outcome, they describe how much was built and how far it reached. The 40% is the one worth interrogating: it measures build time after adoption, which improves partly because the system exists and partly because the second time a team builds anything is faster. I would still take it as directional, because the alternative to measuring imperfectly here is not measuring at all.