Rebuilding an undermaintained design system

01

Three products, three currencies, one set of rules

StoreHub sold a point of sale system to merchants across South East Asia. When I arrived there were three things to work on: the POS itself, the Backoffice behind it, and a rough first version of an online store. I looked after the experience for Backoffice, the online stores and the StoreHub Manager app.

Prices in the documentation are written in ringgit, baht and pesos, so whatever we made had to hold in every market at once. The hardware pulled in its own direction too. A table in a desktop report and a table on a tablet POS are not the same table, so the system had to hold the shared parts firmly and let the rest differ.

02

A system that had fallen behind

There was a design system when I arrived, and it was undermaintained. It had drifted away from the product it was meant to describe, and the team had stopped reaching for it. An undermaintained system is worse than an absent one, because it still looks like the answer right up until you open it.

The screens showed it. Whoever needed one drew it in whatever shape suited that day, which made every screen a fresh set of decisions about colour, type and spacing.

So I rebuilt it, and set the whole thing up again in Sketch. Until there was something current to design against, we could not work.

The Add/Edit Product screen in StoreHub Backoffice, shown in two versions side by side. The earlier version on the left packs every field into one dense column of tight rows with hairline dividers. The rebuilt version on the right groups the same fields into spaced cards with clearer labels, more white space, and a distinct panel for product details, pricing and store credits. — The same Add/Edit Product screen before and after. On the left, the version that had drifted; on the right, the same fields rebuilt on the system.

03

Atoms first, and leave the fixed parts alone

I did not redraw what I could not change. The engineers had fixed the generic frames of the product, headers and navigation among them, and those were not going to move, so rebuilding them in Sketch would have bought us nothing. I made one when a piece of work needed it, and not before.

The time went into atoms and variables instead. Colour, type, spacing, the small parts that everything else is assembled from. That is the layer that lets you keep building, and it meant the library grew in the order the work demanded rather than sitting there as a complete set nobody had asked for.

The Backoffice form atoms board from the Sketch library. Rows of input fields drawn in every state they can take: default, focused, filled, disabled, error, with leading and trailing icons, with currency, distance and unit suffixes, and with a country flag for phone numbers. Below them sit textareas, dropdowns, checkboxes, radios, rich text editors for desktop and mobile, and the image uploader in its default, uploading, uploaded, hover and error states. Each symbol carries its library path as a label. — The atoms first, for Backoffice and then for the storefront, and the molecules built out of them. Every field is drawn in each state it can take, so nobody had to invent what an error or a disabled control looked like.

The ecommerce and Backoffice form atoms board. The same field types drawn again for the storefront: inline units for ringgit and kilometres, date pickers, tag autocompletes, bank name autocompletes with live result lists, country and promotion dropdowns, card number fields with Visa and Mastercard marks, expiry and CVC fields, and phone fields with country codes. — The atoms first, for Backoffice and then for the storefront, and the molecules built out of them. Every field is drawn in each state it can take, so nobody had to invent what an error or a disabled control looked like.

04

What stood by the time I left

By December 2020 the libraries covered Backoffice on web and mobile, the online stores and the Manager app, sorted into atoms, molecules and organisms, with a master file of 201 variables underneath them. Under all of it sat the foundation file: 143 icons, and the logotype in each of its permitted variants with the clear space rule built in as a symbol rather than left in a document for someone to measure by eye. The files hold over 1,250 symbols between them.

I documented it as I went. The foundation covered the logo and its clear space, the monogram, naming, fonts and the colour ramps. Backoffice got its own pages for typography, buttons, tables, filters and calendars, and a set of rules for how numbers are written, down to the space between a currency symbol and the figure in three currencies. The tables page was the one I cared most about, because it described how to decide what belongs in a table rather than what a table looks like: list every field that is already there, ask why each one earned its place, and talk to product managers, merchants and support before drawing anything.

The documentation, from the brand down to the rules for writing a number. The tables page is the one I would still defend: it describes how to decide what belongs in a table, not what a table looks like.

05

If I had to do it again

I would build it in the front-end framework the engineers already worked in, rather than in design software. Only designers could open a Sketch library, so the component in the product and the component in the library stayed two descriptions of the same thing instead of one thing.

I wanted the whole company using it. That is easier when the thing you are asking people to adopt already sits in their codebase.