The company's first design system

MilesWeb is a web hosting company whose website is really several products in one: shared hosting, WordPress, reseller, VPS, dedicated servers, and domains, each with its own pages, plans, and checkout. By 2023 every team was rebuilding the same things slightly differently. Buttons came in a handful of near-identical blues, headings landed at whatever size felt right, and the header was copied and tweaked page by page. The result was a site that looked subtly off from one section to the next, and a design process that reinvented the wheel on every feature.

I was tasked with building the company’s first design system: one shared language, adopted across three products, so the team could ship faster and look consistent doing it.

How do you turn a sprawling, inconsistent hosting site into one coherent system that three product teams can build on without slowing down?

Before designing anything new, I audited what already existed. I went through the live products screen by screen and catalogued the drift, and the redundancy was the real story: the same components, rebuilt again and again with small, costly differences.

That audit set the priorities: lock down the foundations, then standardise the few components that appear on almost every page, buttons, type, and the header, first.

I started at the bottom of the stack with tokens, the decisions every component inherits. A focused brand palette replaced the scattered blues, with clear roles for each color, and the whole system was set in Open Sans for a clean, legible read at any size.

Type was the first thing to systematise, because it shapes every page. I defined one scale with explicit sizes for each breakpoint, so a heading steps down gracefully from desktop to mobile instead of being re-guessed each time. Designers and developers now reach for a named style, not a pixel value.

Each style carries its desktop, tablet, and mobile size plus a fixed weight. The same H1 is 48px on a wide screen and 28px on a phone, so the hierarchy holds and nothing overflows on small devices.

Buttons were the most duplicated element on the site, so they became the flagship component. I rebuilt them as a single reusable component driven by props: pick a variant, a size, and a state, and the styling is guaranteed. Below is the system itself, rendered from the same tokens.

One component, every button on the site. A new page no longer means a new button, it means choosing a variant, which is exactly what cut repeated design work.

The header appears on every page, so making it a single reusable component had the highest payoff. I rebuilt it as one piece with a clear anatomy, a utility bar, the logo, product navigation, and a primary call to action, so any page drops it in and a menu change is made once, everywhere.

From those foundations I grew the library outward to the patterns the products lean on most, into a set of 25+ reusable components covering actions, navigation, forms, content, and feedback. Each is documented with its variants and states so teams pull from one place instead of rebuilding.

A system only works if people actually use it, so I treated adoption as part of the design. Clear names, documented variants, and a single source of truth made the right choice the easy one.

• Documented variants

  Every component ships with its states and usage, so there is no guessing.

• Clear naming

  Predictable, role-based names so designers and developers speak the same language.

• Single source of truth

  One library feeding three products, updated in one place.

• Built to reuse

  Components composed from shared tokens, so consistency is the default, not the effort.

The system replaced one-off decisions with shared ones, and the effect compounded across the team.

Building a company’s first design system taught me that the hard part is not drawing the components, it is the discipline underneath: agreeing on tokens, naming things well, and making the system easy enough to adopt that teams choose it over their old habits. The biggest wins were the least glamorous, buttons, type, and a shared header, because they show up everywhere.

If I took it further, I would move the tokens into code so design and development stay in lockstep, add a dark theme from the same variables, and grow the documentation into a living reference the whole company can build against.