Creating a flexible design system
Much is being written today on design systems, pattern libraries and guides, yet many teams find it hard to follow style and interface guidelines consistently for a prolonged period of time. As the product evolves, design system often clutters with increasing exceptions, and haunts the team with rudimental rules till they give up on maintaining it.
Why does this happen? Designing a digital product we often do not know where exactly it will evolve over time. And while we easily maintain the neat and shiny look of our UI kit, problems arise when we apply our guidelines in a variety of contexts, many of which we can’t envision designing the system initially.
How do we create a flexible design system which evolves with the product and yet is easy to maintain? Here are some rules I found universal.
Don’t formalize too early
Working on a new project, I prefer not to restrict myself with a grid, typographic scale or color palette till I understand the structure and content of the project well enough to formalize it’s design. It’s important to focus on problem-solving prior to thinking of overall consistency.
It’s better have less rules than many exceptions, so don’t formalize something you won’t be able to maintain. For the majority of small to mid-size products it’s perfectly enough to have a guide for colors, typography, and grid, with a set of UI components used most frequently.
Make exceptions part of your system
Problems with guidelines arise when we’re trying to fit our design into a fixed selection of styles which we consider to be final for now and in future. But as the project grows complex, we often discover that there are contexts for which our system is not prepared. I’ve seen grids which are left abandoned in half a year, and color palletes which grow three time bigger in an actual design.
In my experience, the key to designing a lasting system is not in settling on a tiny numbers of styles, but rather in organizing styles in a way which will make it easy to continiously make changes, adding, removing and merging styles together without losing control over the system.
Create a flexible spacing system & set a grid
The first step I with each new project is picking a base module: a square of 4px, 6px or 8px for web and 16px for mobile. This module will define spacing, typography, and grid of the project. This technique is inspired with the concept of 8pt Grids by Bryn Jackson.
A blank space, essentially, is just another reusable UI component, and it can be nested, or stacked to other components. As long as you stick to the module of choice, there’s often no need to formalize design further — the goal here is not in having as less types of spaces as possible, but is to create rules for spacing and organize the spaces used throughout the system.
The next step I take is setting a grid with columns and gutters-multiples of the base module. I often use 12, 16 and 24-column grid in my work, even if the current design requires less, to allow more flexibility in future.
While grids are essential to organize the layout, they often fail as the complexity grows — and that’s where a good spacing system comes in handy. Nested grids is the other solution I found useful, especially when working with responsive layouts.
One of the tricks which in many design systems would be an exception, is applying different rules to align labels next to squares and circles.
To balance the visual weight of a circle and a square, the circle usually needs to be slightly bigger. It also required less spacing to the label:
Using a 4px module, we can set our circle two modules bigger than the square, and make it’s distance to label one module less. The result is consistent within the spacing system and is easy to scale.
Formalize Typographic Scale
The next step is to define a typographic scale aligned to the base module.
I usually don’t align text sizes to fit the base module, but instead align only line-height for convenience of spacing.
In Sketch, rather than conventionally organizing styles by context, I sort them by unique properties, pretty much like it would look like in CSS:
The formatting is the following:
Size/Line-height — Weight — Color Code (see below)
While it may look messy at first, and probably won’t fit everyone, I found this approach convenient and use it from project to project. It provides a good overview of the styles used throughout the system and makes it easy to maintain, add and merge styles together.
Organize Color Pallets
Inspired with Google Material Design I organize my color pallete by brightness, where each color has a number and a clear positioning in the palette. It makes it easier to communicate colors to developers and organize components by color.
Another trick I do often is adjusting color of a text label to fit the color of an icon. Text often feels ligher than the nearby elements of the same color, so it usually needs to be a shade darker:
It easily becomes a rule with a color pallete organized by brightness.
Create a shared library of UI components
Setting flexible rules for type, color and spacing is a good step forward, but a great design system strives to optimize the front-end workflow on the whole.
Inspired with Atomic design, and working frequently with React JS, I organize my UI library in a way which will represent the structure of the components in the front-end. Whenever possible, with developers we decide on following a naming conventions (like BEM), allowing dev team to benefit from the design system as well.
It’s important to use GitHub, Slack or JIRA to sync and broadcast changes in the UI library, so all members of the team always have the most up-to-date version of it. I’m skeptical about “git for designers” software, and suggest you to learn the tool developers are already using. When design and front-end are truly in sync, you may also start to make changes to UI components directly in code.
Review your design inventory often
A great design system shapes the product, and in return is shaped by it.
Review your inventory of type, space, and colors often. Be listening to the needs of the product, make changes, experiment and soon you’ll figure out how much of formalization you can maintain with ease.
If you have any suggestions or found a mistake, feel free to ping me at firstname.lastname@example.org