Original version of Wine-Searcher's 'Find' page (scrollable)
Creating a Design System for Wine-Searcher
Designing a system of components and styles that worked across Wine-Searcher's web and app ecosystem
Background
Wine-Searcher has historically functioned with a code-first approach, the product originally built by a team with development backgrounds. While this did have its advantages (speedy reaction time, quickly-implemented projects), after over 2 decades without design oversight, there was no uniformity or cohesion throughout the web ecosystem. There was also almost no crossover between the web and app team, which resulted in 2 separate products with completely different component sets without any common ground.
My Role
I was hired to fix these inconsistencies and create a functional design system so Wine-Searcher could finally have a set of common components and design instruction to not only make the developers' lives easier, but also develop and sense of brand identity and improve user experience.
Challenges & Process
When I was first brought onboard, I learned the app designer had recently left the company due to health reasons, so I was tasked not only with creating this design system, but also filling her shoes. This was in the midst of the COVID-19 uncertainty, so the company wanted to see if we could make it work with just me doing both roles before searching for a permanent replacement (there was also a chance she would return). This turned out to be both beneficial and challenging – this system would have to be built in tandem with the app projects that had been stacking up in the pipeline, but due to this I got to see first-hand where all the inconsistencies lied and what we were missing.
Gathering Inconsistent Components
To illustrate the component inconsistency, I had to document the state of the product. Throughout the years, there had been many different styles implemented by both designers and developers for the sake of speed. Putting together an interface inventory helped organize what all currently existed and document what needed to be included in our new library:
Pushback
With the company never having worked like this before, there was some initial pushback about why we were turning this small, seemingly simple task into something much bigger involving multiple teams that have never collaborated before. I had to advocate for why it was so important and necessary to establish these components and how it was going to be annoying at first, but it would actually make things much easier for everyone in the long run: No more guesswork and devs having to create things from scratch because the component we need would already exist.
I spent a lot of time in meetings with upper management explaining why certain decisions were being made and that there was a big-picture reason for why that [insert component/element] looked different and that there was a plan in place to roll it out site-wide alongside the other projects in the pipeline. This wouldn't typically be an ideal way of implementing a new design system, but given the resources we had, it was the only way it was going to happen while also addressing the app project backlog.
Back to Basics
The building blocks of a design system lie in the spacing/grid system. Rather than adopt a traditional 8px grid, my colleague and I opted for a slightly more minimal approach to a 4px grid: we used a finite number of spacing values consisting of multiples of 4, with the addition of 2px due to the complexity of our product and the need to fit large amounts of information into small spaces in certain contexts. We removed certain values from our system (e.g. 20, 28, 36, etc.) that we didn’t believe were necessary and to keep things as clean and simple as possible.
The finite spacing value system
Example of a Wine-Searcher "offer card" using spacing system. Desktop on the left, mobile on the right.
Example of adapting button & icon button height for all three platforms while maintaining visual consistency
Components Across Platforms
Since Wine-Searcher functions as both a website and an app on iOS and Android, our system needed to encompass all 3 platforms. Since I was also working through the backlog of app projects, iOS and Android seemed a logical place to start.
The app team much smaller than the web team, so to make development as seamless as possible, I tried to maintain as many iOS and Android (Material Design) system defaults as possible while maintaining design consistency and a visual synchronicity across platforms.
Demo of how I set up the master library in Figma to easily swap all component platforms and variations to make mockup creation seamless
I decided it best to keep system default fonts on all platforms, so components like button sizes would be relative to font and line height. Material Design proved the most challenging for our Android developer to customize, so I had to slightly adapt padding values for their system.
This meant that all other components that could potentially be inline with buttons would need to match height to maintain consistency (e.g. icon buttons, dropdowns, form fields), so that was taken into account.
All cross-platform button variations in the Figma master library
The Switch to Figma
The designers were using Sketch when I first came onboard. While there's nothing inherently wrong with Sketch, it also requires the use of several other pieces of software for prototyping and dev handover. The company was paying for:
- the Sketch license
- Abstract for version control
- InVision for prototyping
- Zeplin for development handover
The number of platforms being used made collaborating with other teams confusing and difficult. It was hard to keep track of where the most up-to-date version of a project lived. Did someone forget to upload their latest iteration to Abstract? Has the design system been synced lately? What changes were made since this this prototype was uploaded to InVision?
I have been preaching the benefits of Figma since we made the switch at a previous company I worked for – it made life so much easier to have one tool for creation, collaboration, prototyping, and handoff. Since it's cloud-based, a design system can live in a master library that is updated in real time and syncs with components in every file the library is linked to.
A snippet of the master component library in Figma
A sample of the design system documentation and instructions accessible to the whole company
It was a hard sell at first and I get it, nobody likes change and it is a pain to switch everything over from Sketch (as much as Figma tries to make it seamless). Since we were essentially creating a design system from scratch though, it seemed like the perfect opportunity to show how this could benefit everyone, so I started creating the new components in Figma and transitioning the Sketch files.
I tested a project designed in Figma with the app team and they were very receptive to the change. After determining that we could seamlessly complete a project using only Figma, everyone started getting on board. Not long after, New Zealand went into lockdown due to COVID-19 so we were all forced to work from home and since Figma is cloud-based, it proved to be instrumental in the collaboration process when everyone was working remotely.
Result
Wine-Searcher now has a functioning cross-platform, WCAG compliant design system – with documentation – for the first time. The changes have been rolled out through most of the website and app, but development is still ongoing for some portions of the website.
I scroll!
Above from left to right: Web, iOS, Android