Outcome
With this design system, I was able to bring order to the chaos that existed in the company with the design specification, versioning, and sources of truth. The developers found it handy and useful, and it setup the foundation for developing components.
Files Structure
The Design System I set up in Autotrader and Carsguide was a revised version on the Design System I did in News Corp, which I call Experience Design General Architecture Repository. This one had 5 library files and several wireframe files:
- 📕 Styles.sketch
- 📕 Assets.sketch
- 📗 Elements.sketch
- 📘 Blueprints.sketch
- 📙 Components.sketch
- T-S Name.sketch (Wireframe files)
Styles
The most elemental file in the design system is the 📕Styles.sketch file. This file could even potentially have no artboards inside (however they are useful as a display of all the styles included in the file). The Styles.sketch is directly connected to Assets.sketch and Elements.sketch which helps icons and shapes in the design system to use the styles in them.
A preview of all font styles included in this file.
Assets
There are two kinds of pages in 📕Assets.sketch. Icons and Images. For example. Autotrader's File was organised in four different pages:
- Icons
- Cars
- Logos
- Ads
Elements
Elements.sketch is where the magic starts happening. It inherits 📗Styles.sketch and has access 📕Assets.sketch. And it contains basic shapes like:
Squared, semi-rounded and rounded
- Fills
- Borders
- Shadows
And also
- Label placeholders
- Icon placeholders
- Label + Icon placeholders
Each artboard is pretty atomic; they contain typically one layer only. These will become the layers included in blueprints.
Blueprints
Think of 📘Blueprints.sketch as an abstract version of whatever element you want to display in your designs. For example a button. A button may have a shadow or not. The shadow itself doesn't prevent the button to be a button. But for flexibility we create the component with that option. Designing for it in advance. For example. A blueprint in the design system typically has some of the following layers:
- State placeholder (hover, pressed, normal, etc.)
- Label placeholder
- Icon placeholder
- Border placeholder
- Inner shadow placeholder
- Background Image placeholder
- Fill placeholder
- Button shadow placeholder
To see more on how Blueprints work, jump to the Abstraction section below.
All placeholder layers in this file are symbols imported from Elements.sketch, and styles of course are inherited from 📕Styles.sketch through 📗Elements.sketch.
Components (or Implemented Blueprints)
📙Components.sketch is maybe what would typically resemble any other design system. It can for example contain a collection of buttons of different colours that are hollow or filled. All these buttons are a configured version of the button symbol in 📘Blueprints.sketch. And they are also symbolised for easy access by the wireframes.
This file can become big. So it is up to the discretion of the reader whether to split this file into multiple pages for the purpose of getting it organised.
T-S Name Files (Wireframes)
Wireframes for the purpose of this story are other files that use the design system file structure above. But conveniently, this design system is organised in such a way that the design system only inherit directly 📕Assets.sketch, 📕Styles.sketch and 📙Components.sketch for optimised consistency.
File Naming Convention
If you have been reading this portfolio, you will know that I'm a huge fan of User Story Mapping. In Design Operations I describe how I use the Story Map to track design system coverage. In Autotrader however, I actually created the system after the Story Map, which resulted in a really easy way to organise my files.
In a nutshell it is a sequence of two numbers divided by a dash T-S, where T are the Tasks and S the Steps in sequence in the Story Map.
Having agreed on a file structure and naming convention allows everyone to be on the same page at the time of finding where is what.
Inside Page Structure
When breaking down interfaces into Tasks and Steps is not enough, or when the files have a specific element that changes from state, I used pages inside the file to split it further.
Page Artboard Structure
For cleanliness, organisation and my stakeholder's sanity I try to have only one artboard per breakpoint page in Sketch (unless it is the symbols or the states page).
Versioning
To collaborate with my stakeholders and my two designers, I used Sketch and Abstract as my source of truth.
Shared Principles and Benefits with Object Oriented Programming
Inheritance
In an ideal world we could see it as: T-S Name.sketch (Wireframes) files inherit from 📙Components.sketch and 📕Assets.sketch, 📙Components.sketch from 📘Blueprints.sketch, 📘Blueprints.sketch from 📗Elements.sketchand 📗Elements.sketch and 📕Assets.sketch from 📕Styles.sketch. (Note that Sketch today doesn’t allow for selective inheritance).
This structure helps keeping the system minimal and really well organised.
Encapsulation
This layered structure also allows for encapsulation and suggests T-S Name.sketch (Wireframes) should only deal with 📙Components.sketch and 📕Assets.sketch, ensuring components are used in the way they were designed to be used.
Abstraction
A blueprint is an abstraction of a component (i.e. a button), this is, a generic component that can be repurposed in multiple ways. The blueprint layers of a button, is a series of (symbol) elements layered on top of each other as described below.
For example, using the blueprint above and different elements, I could easily create different buttons like the ones below.
At the component level, the blueprint structure is obfuscated to allow only for relevant overrides to be used (i.e. label and border or background colour are the only overrides available for these components).
Polymorphism
Polymorphism is definitely there. Since component families use the same blue-print, you can easily change say from a red round button with a centred icon to a green rounded square button with an icon and text.
Next Steps
One of the downsides of this file structure is that you need to cascade update a change in the deeper files of the design system in order to be materialised in the wireframe files. To efficientise this effort, I've been thinking on reducing the number of files in the system. For example 📕Styles.sketch and 📕Assets.sketch could easily exist in the same file, and maybe even📗Elements.sketch.
This design system has only been designed to work in Sketch. So I'm going to start looking into making these concepts available as well in Figma and Maybe Adobe XD in the near future.
