Creating a lean design system
I created a much-needed design system for the existing website, iOS and Android platforms. My goal was to keep things simple and flexible to ensure that it would actually be used.

I created a much-needed design system for the existing website, iOS and Android platforms. My goal was to keep things simple and flexible to ensure that it would actually be used.
Before being acquired by BetEasy, William Hill was a sports betting company with a website, iOS app and Android app. At first glance, each platform looked relatively polished, but upon closer inspection, it was clear that there were significant design inconsistencies throughout.
Designers were confused as there was no single source of truth. Developers were frustrated with creating duplicate components which slowed them down. Users were struggling to learn multiple UI patterns to perform the same task. These issues would only get worse as our product team grew. There was no budget or resources to create a dedicated design system team, so we simply chipped away at it as best we could, creating new components and styles incrementally. Some new Android components can be seen in the image above.
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.
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.
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:
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:
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:
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:
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:
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.
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 focussed 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.