Summary

As the first designer in a startup on track for exponential growth, the core design principles I believe will lead to long lasting success are collaboration, consistency, and speed of execution. Thus creating the backbones for our Design System with the Engineering team was a core priority.

In this article you’ll see a summary of the process from start to end, a brief overview of the UI library, and what it resulted in.

I will only briefly touch on the philosophical difference between Design System, UI Library and component library, etc. but will point the curious reader towards valuable resources.

Check out our 🧨 TNT here 👇

Problem

As mentioned in the Brand Refresh project, when I joined, Foodbomb was two years old 🐣, and before then most of the branding elements were more of an emergent property of the system than a planned effort. This was even more visible across the 3 core products we are building (that at the time I joined were actually 5 products).

The biggest problem I’ve identified at the root of them all was the conflicting Information Architecture, with information flowing in a million directions.

Team

For this project, I worked closely with the Front End team, consisting of 3 Engineers, as well as consulting with the Head of Engineering and our customers (yes, our customers are part of the team!).

Process

As a small team with a good spread of Senior and Junior Engineers, none of whom with any formal Design education or experience working with a Designer, I saw my role not only as that of a Designer, but foremost as that of a Design promoter.

This is why the UI library I developed is a tool to make developers lives easier by minimising their decision making fatigue with simple, atomic solutions out of the box. My starting point to ensure I’d achieve this mission was to setup some principles that, if followed, would be constraining my urges to add more, and oblige me to keep less.

SASSY principles

For the Foodbomb UI library, and with an acronym SASSY worthy of our brand, (as well as self-referential just for fun) I’ve set 5 principles to drive this goal:

Simple

Accessibile

Scalable

Sassy

Yummy

These guiding principles helped me to make otherwise tough decisions, especially in regards to things such as typography, colour, and the use of illustration.

Having setup the whole Engineering team on Figma where we agreed to share the journey together before to move to production, I listed the mammoth amount of elements and patterns that I would need to tackle at one stage or another, going back to my principles and ranking them accordingly. I thus ended up with a nice ordered list of to-dos.

---

With the list nicely sorted, I was able to go through each item and get it done, going back to the previous ones to tweak if needed. Here’s a little breakdown of each of them.

I also want to share this useful table to ensure you are covering every component state in terms of visual accessibility. I use it every time I touch a new component as a simple checklist.

Here’s what the list looked like as I worked through them

Layouts

For the layouts I started by defining a 4px grid system (where everything, no matter what is a multiple of 4). Awesomely, the super-engineer Adam Love is the ultimate master of CSS Flex so we immediately agreed that everything we’d do would be fully responsive using the most popular device Media Queries.

For Desktop devices, I’ve restricted the page width 1060px and setup a 12 column in order to keep information clean and avoid pages stretching out to infinity.

For Mobile devices, I’ve devised 4 columns, center-aligned vertical grid with 12px gutter and 12px side margins (following Android guidelines).

I didn’t define tablets layouts as responsiveness would take care of most of them (Simple) and only 3.8% of our user-base (across all 3 platforms) use tablets to access our products.

Colours & Shadows

Our colour palette is fully SASSY. To start with, I’ve only defined 5 hues, each of them with just 4 variations (Shade/Tint/Tone).

This seems quite drastic but it reduced both the number of choices that need to be made at any point in time (thus Simple and Scalable) as well as, if the palette is picked thoughtfully, the chances of non-accessible colour combinations to almost zero (Accessible). On top of that, as a designer I need to do heaps less work as Engineers get to make decisions independently. Admittedly a pretty Sassy move. As per the Yummy, I’ll let you be the judge.

Here is the original palette.

Naming convention

Each colour is simply named $Hue-Variation in our. So for example the Greens are:

• $Green-Darkerst
• $Green-Standard
• $Green-Light
• $Green-Lightest

Simple Rules

The simple set of rules to follow for this colour system is:

1. Never mix two hues
2. Only use Lightest variation as a background
3. If you need to combine two variations always go two up or down

• 

• 

• 

• 

• 

Typography

As far as typography goes, I’ve deviated a tiny bit (some will say) from the simplicity rule as I’ve opted to use not one but two fonts! 😱 THE HORROR!

As mentioned in the Brand Refresh article, until we can spend 500K on an agency, we’ll be using these popular fonts:

• Montserrat (for headings, bold af)
• Source Sans Pro (for body, readable af)

And here are all the variations we have for each of them with the parameters they share with our beautiful .scss file.

Buttons

As one of the first atomic units, and always aiming to respect the SASSY theme we only use a few buttons with even fewer sizes (all of which ensure Accessibility by default).

• All buttons use our body-bold text style (16pt)
• We only use 3 dimensions for the height
  • Small – 34px
  • Standard – 44px
  • Large – 54px
• When we started with the system, we heavily relied on Material UI components for the buttons states
• We have only 5 types of buttons

Icons

Our icons are a selection of the Material UI icons. Mostly because I am only one designer and even though I’d love to dedicate 4 weeks in remaking them all, the tradeoffs with other more important product work (e.g establishing a user research function) would be too high at this stage of the company.

Illustrations

With illustrations the story is similar to that of the icons, but because I am super picky, as well as not really great at creating illustrations, we only have 3 of them through the whole platform.

Emojis

As both a brand element and a great way to focus user’s attention and reduce cognitive load (especially for returning users), I’ve included emojis as part of our vocabulary.

Here is an example of how we embedded them in our product.

Results

6 months after the successful implementation of the UI by the incredibly talented front-end team, we took half a day to perform a UI review across the 3 products.

With a focus on consistency and accessibility, each team member went painstakingly through every single product page, tasked with screenshotting any inconsistency with the design system.

Gladly, we only discovered 4 instances of colour mismatch across the whole platform!! This was such a great feeling for the whole team, especially since engineers, if not for a design review performed before larger projects, have been completely free to deploy their work without going through a design bottleneck.

Continuous refinement

Whilst results have been phenomenal, as the team grows new challenges will surely arise. With this in mind, we’ll keep on reviewing our work at more regular intervals (quarterly for now), and make sure to dedicate at least 4h of the newcomers onboarding delving into the ins and outs of our system. Both for designers (on the Figma side) and for developers (on the bit.dev site)