Creating a lean design system

Buttons, buttons, and more buttons

As a first step toward design system nirvana, we needed to conduct an audit of the current styles and components. To tidy things up, we took a Marie Kondo approach, which basically meant piling up all of our existing styles and components on the bed and discarding those that didn’t “spark joy”. We collected and documented screenshots of all the different types of styles and components and grouped them into categories including: text styles, colours, icons, buttons (as you can see from the image above, we had quite a few), navigation, headers, footers, cards, forms, lists and other UI blocks.

With all of our styles and components grouped together into categories, it made it much easier to see what we had and where we could cut down. Unnecessary styles and components were removed and similar ones were merged. We decided collaboratively on what should stay and what should go, based primarily on heuristic evaluation. Old unwanted styles and components were mapped to new ones in Google Sheets to help the development team transition.

Defining global style guidelines

After tidying things up, it was time to lay the foundations of our lean design system, so I created global style guidelines that applied to all platforms. Designers could use these guidelines to create new components (as seen in the images above) and expand the design system further.

Style guidelines have a tendency to be unnecessarily complex, taking hours or even days to read through (ain’t nobody got time for that). In my experience, less is definitely more when it comes to guidelines. If you want your product team to actually use and understand the guidelines, it’s important to keep them concise so that they’re easy to consume and remember. Concise guidelines keep things flexible enough to allow for creative freedom while also maintaining an acceptable level of consistency. I’ve outlined the style guidelines below.

Colours

We had many very similar colours which was unnecessary and confusing, so I merged them into a smaller colour palette for simplicity and created brief guidelines around colour usage (seen in the image above). For most projects, I find that you only really need a colour for the following 5 elements: heading text, secondary text, borders, backgrounds and actions. Colour guidelines include:

• Colours should be used sparingly, have a functional purpose, and be accessible.
• Rather than using shades of grey, use shades of navy to create a more cohesive aesthetic.
• Associate blue with actions (green for actions relating to payment).
• Yellow should be used sparingly on dark backgrounds as a highlight.

Typography

There were numerous text styles and fonts being used across platforms, so I reduced them dramatically and decided to use our custom brand font, Hoxton (seen in the image above), across all platforms for simplicity and consistency. Typography guidelines include:

• Use only regular and bold font weights from a single font family, Hoxton.
• Always use sentence case.
• Keep use of ALL-CAPS to a minimum and only use it at a small size.

Voice and tone

Typography is important, but so is the actual copy. Keeping the copywriting consistent helps users understand the interface and perform tasks more quickly and easily. Some very basic voice and tone guidelines include:

• Write short sentences.
• Use headings and bullets to make your content easier to scan.
• Avoid jargon and always choose a short, simple word over a long and complicated one.
• Calls to action on buttons and links should start with a strong verb that describes the action.
• Be consistent with the vocabulary used.

Shared styles

The interface of a betting app is often quite number-heavy and complex, so I removed any unnecessary styles and moved towards a more minimal aesthetic to help declutter the designs. Shared style guidelines include:

• Use styles sparingly i.e. don’t use lines or borders unless they have a functional purpose.
• Use an 8 point grid (because they’re awesome).
• Use 1 point borders.
• Use 2 point border radius.
• Use 2 types of shadow styles (small and large).

Iconography

To save time, I’d usually use an existing icon set like Streamline icons (my fave). Luckily, we already had our own custom icon set (seen in the images above) that just needed a few tweaks. Iconography guidelines include:

• All icons should be 24pt x 24pt with bounds and no padding.
• Icons should consist of lines and not be filled.
• Icon stroke weight should be 2pt.
• Icons should sit on full pixels for clarity (not fractions of pixels).
• Icons should have square corners (not rounded).
• Icons on light backgrounds should be navy.
• Icons on dark backgrounds should be white.
• Category colours can be assigned to icons.

Creating a component library

After auditing the existing components and setting the global style guidelines, the next step was to create a component library. To keep things simple initially, we created a component library for each platform in Sketch (seen above is the Android component library still in the process of being simplified). In the future, I was planning to merge the iOS and Android component libraries to create a consistent mobile experience. This may seem a bit controversial to the purists out there, but I think it’s fine as long as you do usability testing to validate the designs. Depending on your team and tech stack, it can be a great way to decrease design and development costs.

In addition to components, we also started creating templates of the main screens (seen below) to show how components were grouped together for different use cases. It also made it faster for designers to mock things up.

Use it or lose it

There’s no use having a design system if nobody’s using it, so it’s important to get the word out and encourage the product team to use it. The first, and easiest step, is always to get the design team on your side. I conducted a few workshops to get the designers up to speed on how to use and contribute to the design system. I also synced the design system Sketch file with Invision, so that it could be shared with the greater product team and to allow developers to inspect the components.

Since there simply wasn’t enough time or resources to rebuild everything at once, designers worked with developers to apply the new styles and remove old components as they came across them in their day to day work. We focused on updating the high impact elements first, like colours, headers, footers and buttons. Slowly but surely, we moved closer toward a more consistent experience for our users across all platforms.

Building a coded design system with usage guidelines was the next step, but we never got around to it as the company was acquired and restructured. It was definitely a great learning experience though, which only intensified my love for design systems.