The team behind our online accounting software and website are a talented bunch. As part of our Tech Blog series, Lead Front-End Developer, Ben Herbert, continues his look at how we’ve adopted style guide driven development.
The aim of a style guide is to provide a toolbox of “ready-to-go” UI components that can be used for any given application. Achieving this can be challenging and must be purpose-driven. It’s called style guide driven development (SGDD), and is something we’ve taken to heart at Crunch.
A frequently used analogy to describe Atomic Design and SGDD is “building with Lego”. Instead of seeing a web page as one solid chunk, you should aim to see it as many independent parts (i.e. Lego bricks).
Taking the analogy further, a Lego set has a mixture of bricks. Some are generic, others are more specialised. Crucially, most aren’t specific to the set they came in and can, therefore, be used for other builds too – the only limit is your imagination!
Sharing a common language
Having a common language the whole team uses and understands is essential. It makes it super easy to explain the way we work to each other and those outside of Crunch.
A great example of common language being used at its best can be found in the way we name each component (a component can be anything from “tooltips” to “pagination”).
Naming components might sound inconsequential, but it’s actually hugely important. If you cannot settle on a name, it might be because the component is too complicated, too specific, or just plain useless.
For example, a prolific feature of the Crunch website is a large, full-width image, with bold typography and a call to action. We called this the “Billboard” as it reminded us of the supersize advertising boards placed on the sides of buildings.
When your marketing, design and engineering teams are all using the same language as you, you’ll be cooking on gas!
In search of patterns
In an ideal world, you’d start by designing in a style guide driven way. However, this is not always in your control.
Translating a visual design for a web page into reusable components involves looking for common patterns in the design. It can appear a harsh process and you may feel like you are being mighty inflexible. In truth, the outcome you are looking for is total flexibility.
You’ll need to start by identifying components. At Crunch, we like to print out the designs, stick them up on the walls, and then go to town on them with a packet of sharpies.
When presented with a component to critique, I ask myself four questions.
- Is it similar to a component that already exists?
- Is it unique or can its meaning be generalised?
- What’s causing it to be special and is that cause superficial?
- Can it be broken down into smaller components?
Efficient, maintainable and scalable
Front-end developers work closely with visuals, translating designs into code. But the aims and principles of SGDD are ultimately the same as any best coding practices: Making efficient, maintainable and scalable applications.
Want to get involved? We’re hiring!
Ben Herbert is Lead Front-End Developer at Crunch. Ben has a background in fine art and photography, before finding a new creative outlet as a front-end developer. When not developing, he still enjoys visiting art galleries and shooting landscapes.