Creating and Maintaining
Design Systems
and Style Guides
Or did I hear you say "giving colours cool names and organizing everything in aesthetically pleasing way"?
Please sign me up!
It all started with creating style guides…
The very first style guide that I have built from scratch was for Bright Minds – the app concept that I have designed as a part of my Google UX course.
But why create a style guide for one off project, if you most likely to never use it again?
Ummm.. many reasons actually!
Its value is pretty straightforward when it comes to reusing the same UI components again and again and not having to design things from scratch every time but I found immense value in having a design system even for one project.
First of all, whatever I am working for I always have a section for main components.
Having an easy reference for typography is also a must. Putting them together in an easy system to navigate is only making things easier as you are adding more pages and interactions.
.png)
I also love to have all the design elements side by side to each other, this way I can ensure in certain aesthetic coherence. I might have felt that a certain component look worked well on one of the pages, but looking at it in tandem with the rest of the design, sometimes helps me to identify the divergencies in style and minor visual improvements that can be done.
But as we all know a lot of cool things together doesn't always equal a cool thing...
Although sometimes they do...
_gif.gif)
Ta-da!
Another style guide!
Unlike the previous one, this style guide evolved. Including spacing and sizing reference, for instance, have been immensely helpful to keep my designs consistent (ensure UI is not cluttered) but also making it easier for developers to have a reference to the spacing system I am using.
As you can see some components here also have dark/light mode. This is something I am closely familiar with in more extensive design systems but also in the design systems of others, such as IOS from which I often pull specific components.
In this case, I was aiming to recreate a holistic experience for testing so adding the native IOS components made the experience more realistic, but also helped to test features like subscribing to calendar and user’s behaviour with that interaction end-to-end.
But what about design systems?
It may seem a daunting task to create a design system or even more so when you have different components floating around different files.
Creating and dealing with instructional documentation is not new to me.
As a Research Operations Coordinator at MURAL, I have worked to develop a Playbook for Research and Recruitment best practices. To me it was very much a design system… well, without design components.
.png)
I have transferred that knowledge in developing and creating a toolkit of ExDesign resources (from story mapping to Jobs to Be Done to some cool activities for feature prioritization) for a client with extensive documentation on best practices, organized in the way that is easy to access for all.
(Unfortunately cannot share - NDAs, but more than happy to chat about it!)
Now back to design systems!
....Or not?
The most important thing about maintaining a design system is not about the design system itself but the mindset you adopt when you approach building new components.
.png)
If we think of components in the same way we think about building new features for users, first and foremost we want to identify the problem we are trying to solve (starting with user needs) and assess if we already have a component that does that.
Building a lot of components without assessing what is already there and what problem it will help to solve is a similar pitfall that is in the Waterfall approach to development
(Read more about it here).
It is all about the mindset, and if yours is grounded in Design Thinking, maintaining a design system comes naturally.
The way Spotify thought about theirs and brought it altogether is one of my favourite examples.
And here are a few that are my go-to for inspiration:
 |  |  |
|---|