Building the Picnic Component Library
In a growing company like Picnic, it can be hard to keep everything streamlined and structured. Especially in UI design where each designer has to be on the same page in order to create a pixel-perfect product. You might like the buttons to have a margin of 12 pixels, while someone else prefers 8. You might like your hairlines in #e5e5e5 but your colleague wants #f2f2f2.
To prevent these pixel-debates and hexadecimal-discussions, we decided to build a structured component library. By doing this, we not only make sure that everyone uses the same margins, colours and corner roundness, but we also speed up the process of converting wireframes and sketches into actual screens. Allowing us to quickly update designs for our user testing sessions.
A year ago, when I started at Picnic, the designs were still evolving and there was no UI library. During the start-up phase, there were many freelance designers working for short periods in the company. This meant there was no ownership over the categorised masterfiles. There was a complex process for selecting features, and new designers struggled to tell the difference between ideas and an actual design. This lead to many different interpretations of the Picnic design, and no-one was sure what the rules were behind building a cohesive UI. My first project at Picnic was to fix this problem and create a structured way of distributing and maintain the UI.
Let’s get started
To kick of this project, I had to formulate a set of rules to form the style guide. These rules are a visual representation of the Picnic brand. A great way to determine what should be in this guide is by using css properties, like:
1. Colour: First, the brand colours. At Picnic we have two colours, both with a darker variation. Purpose colours can also be added to the palette, e.g. red when something goes wrong. We finish the palette by adding a set of greys to be our building colours.
2. Shadows: To help us determine which shadow level to use, we have a set of two shadows that depend on the background colour. Alternatively, there is the option for a flat design and no shadow at all.
3. Font: Either pick a font that matches the brand identity, or build a custom one. At Picnic, we have a separate font for Android and iOS. We also determine what the font weight and size will be. In addition, you’ll need body text, headers, subheaders and button text.
4. Border radius: No border radius makes a product more corporate, whereas rounder borders are friendlier.
5. Grid: Pick a grid, but keep in mind that it has to be scalable. A 5 point grid will get you in trouble when scaling up to 1.5x. So, if in doubt, use an 8 point grid.
6. Easing curves: When elements move they communicate a lot to the user. If your product is robotic and mechanical you should use little easing. If you want to appear tough and daring, your elements should move quickly and be aggressive. Or maybe your target audience is kids, then you want to be more playful, and go for the bounce-curve.
“Our websites are fluid, so our processes and workflows need to match.”
— Brad Frost
Chemistry is the answer
Typefaces, colours, grids, etc., are important bases, but they remain subjective and leave room for interpretation. To prevent different outcomes of this style guide, they need to be translated into fixed components. These become the building blocks of the product, just like a big box of Lego. Web developer Brad Frost came up with a great way to build such a library. By comparing the structure of an app or website to principles found in chemistry and biology, he created Atomic Design. In this method, small components come together to create a big part. These new parts together create an even bigger part and so on. Brad uses the following steps:
1. Atoms: the smallest element, cannot be broken down into smaller pieces.
2. Molecules: a small set of atoms that already have a function.
3. Organisms: a bigger set of atoms and molecules that have a function.
4. Template: a complete screen without content.
5. Page: A template containing content.
By using atomic design reusable items are created. Atoms can be used in different molecules and may end up in a different page, but they will look exactly the same.
For example, the search icon from the search page also appears in the navigation header in the Picnic storefront. By editing the search icon atom, its appearance will change in both pages, making sure there are never two different search icons. This saves time and creates a consistent product.
Ease of use
UI chemistry is fine and dandy, but designers do not want to waste time digging through a pile of atoms, molecules and organisms to find the right component. Therefore, it is crucial to group and name the elements correctly. A common way of doing this is by naming them after design patterns. A pattern is a general, reusable solutions to commonly occurring problem, which can be used in different interfaces. For example, the tab bar in the Picnic app is a common way to structure pages, and is also used in other apps to fix the same problem. By naming the element tabbar in the library, a designer knows immediately what the component contains.
A single pattern can have many forms, depending on the implementations. E.g., a button is a common way to confirm an action, but it has several different forms. The visual appearance of that button communicates to the user if the action is primary or secondary. Furthermore, the rest of the molecule where the atom appears influences it’s appearance. For instance, on a full page you’ll see a raised button, but on a card a flat button is used.
For example, the slotselector, used to select delivery time, is a unique and very important item to the Picnic world.
Final step, put it in the cloud
To ensure that the library is working at its full potential, each designer must use the same version. I experimented with tools such as Craft from Invision, or by putting a Sketch template into dropbox. These worked, but they weren’t great. Thankfully, Sketch released ‘libraries’. This puts the different components straight into the cloud and onto the machine of the designer. This means that when a component is edited, all designers immediately have the latest update at their disposal. The library is alive, and components can easily be added or removed. To make sure that only the good stuff is in our box of UI-Lego, we only add components from features that have been developed and have survived the A/B test in our live product.
We love the library
Since building the Picnic component library our workflow has improved greatly. This is especially noticeable when the team starts working on a new project. It has become easy to add the existing screens from the symbols menu in Sketch, so the designer can check out the current design. When we decide what to build, we can start experimenting with building different blocks, or moving pre-existing ones around. Maybe the perfect brick is already there, or we can detach an element from the library and start changing it to our liking.
With the pre-set components, we are able to create prototypes much faster. We only have to think about the new stuff we create, because the elements that we reuse come from our library. This speeds up the process, and new designs are quickly converted into prototypes. This not only improves the speed of the workflow, but our designs have become more consistent. Picnic’s developers see more cohesive designs, and this translates into consistent and ultimately enjoyable products.
In conclusion: we love our component library ❤️
