Birth of our new design system - Part 3
To ship and the way forward
Don’t like reading? You can check out the video to my recent talk about building a design system here.
We know that the products are getting bigger in size, and more complex at the same time, therefore, the design is also becoming more complex in such projects. We need stable governance sitting right in between as the core for design management during the process of building a product. And here is what the Qubole design team believes.
You can’t innovate products without first innovating the way you build them.
The design system is more than your UI kit, it’s about bringing culture and design language in your organization.
It’s not about the UI Kit
When you think about design systems, the first inclination as to what a design system is is that it’s a UI kit. That’s not what a design system is. That might be part of a design system, but just having a Sketch UI kit or a Photoshop UI kit or Studio UI kit, those are just tools. That’s only one piece of the design system, which is only accessible by designers.
Part of a good design system is that it’s a tool that everyone on a team can use, and the fact that a UI kit is locked up in a certain tool that other people aren’t familiar with means that it’s not accessible to everyone. So, by definition, it’s not really a design system. It’s a part of one. It could help you make one, but really, we should be liberating all of our design tools from outside of a particular environment where it’s locked down and, instead, work on something that everybody can touch.
Let’s get started
In the last post, we talked about how you get a definition for your design system and how you try selling the idea of a design system across the company. In this article, I will try to create a step by step understanding of how to build operations through your design system and adopt it as an internal product.
Write up your pilot show to validate your idea
We, at Qubole, knew that we needed a design system since the team was growing and we were looking at how to bring in modern software design to a 7-year-old software which was majorly engineering driven.
Since each team has it’s own budget, the teams invest their time and resources in projects accordingly. I joined as an intern in the design team and we decided to take up this project and I was assigned to work on it. It was also of my interests as in my college days, I wanted to work on creating a UI library where I could inherit components that could be reusable.
Working on a basic set of components and creating a mock product helps the broader team visualize the impact. We, at Qubole, redesigned a set of most used features using the initial ideas and documented it. This helped our team understand how the design system would change the way we build in the future.
Keep in mind not to rush at this point. We are still far from working out the details.
Here are a couple of explorations done during the initial phase.
Make Key Decisions
Involving all the stakeholders proves essential now because there are some decisions that you need to make and get sign-offs to ensure that this initiative becomes successful.
Depending on your needs, decide whether
- You need to build the system from scratch v/s take the current product as the base and refine it
- Introduce a new technology to build the system v/s build it with your current technology
- What are the goals of this system? To improve consistency, better interactions, faster development, etc.
Getting answers to these will come handy in the long run.
Create an Interface Inventory
This is a fun activity! Involve as many design team members as possible and grab screenshots of all the elements that make up your product. Categorize this dump of screenshots into components, states, etc., and review it. You’ll be amazed at the number of inconsistencies you’ve had in your product.
You might also discover a few elements that you didn’t know existed! ;-)
Putting elements that are similar, yet different, together on a sheet highlights the need to bring in consistency and also opens up discussions on how to achieve it.
Shape your Movie Crew with Building Blocks
A thoughtful process in setting up the basic ingredients that make up your product — color palette, typography, icon library — will help you to kickstart your design system.
Color Palette
Use your inventory checklist to identify your primary/base colors if you’re using your existing product as the base. Otherwise, explore different colors for your re-branding. We went ahead with our brand colors.
Next thing that you can do is decide on a naming convention.
Our primary color is #049EE0.
Now, who understands hex codes? You won’t know what color I’m referring to with just the code — it’s simply not human! So we decided to name the hex code as ‘space-azure’. Naming sets up a common language between designers and developers. We named all the hex codes we are using in ways that can be adapted easily.
Typography
The part of the system that affects all the other parts is typography.
Choose a typeface. In our case, it was Helvetica Neue.
Setup a naming convention with detailed specification about how the scale and typography are to be used.
Apart from deciding which typefaces will be the standard, you also have to build a consistent scale.
We highly suggest having a CSS mixin either in SCSS or SASS or any CSS preprocessor to create a naming convention around your type scale.
Build a consistent type scale where you have a base, and then increase or decrease it by 2px as need be. For example: our base was 14px, so we set the scale as 10px < 12px < 14px > 16px > 18px. Hence, set the min and max of your typescale.
Iconography
Icons are a very important part of the visual language and should become a part of the system.
Try out a few variations to test if your icons are clear to the end user. You can choose the style of your icons depending on what you want them to reflect.
Icons that are hard to understand are of no use and contribute to the clutter. Finalize the library, choose the implementation method, and make sure they are rendered well on all platforms.
Along with these, also define other properties such as spacing, grids, and other UI elements, so that you’re ready from the atom and molecule level to finally work on your templates.
Design Components using Atomic Design
For me, atomic design is a method to build and test components that talk to each other. Since most of the components that you’ll be designing will be done individually, eventually you’ll need a method to test these components to see if they work together.
Atomic design is a methodology composed of distinct stages working together to create interface design systems in a more deliberate and hierarchical manner.
Atoms
If atoms are the basic building blocks of matter, then the atoms of our interfaces serve as the foundational building blocks that comprise all our user interfaces. These atoms include basic HTML elements like form labels, inputs, buttons, and others that can’t be broken down any further without ceasing to be functional.
Molecules
In interfaces, molecules are relatively simple groups of UI elements functioning together as a unit. For example, a form label, search input, and button can join together to create a search form molecule.
Organisms
Organisms are relatively complex UI components composed of groups of molecules and/or atoms and/or other organisms. These organisms form distinct sections of an interface.
Templates
Templates are a group of organisms stitched together to form pages.
Here are some screenshots of how our components look like individually.
Test, Iterate, and Test Again using Accessibility
Before thinking of taking the new system to production, it needs to undergo an accessibility test.
There are many ways to understand accessibility and why it is important.
Here’s an example. We were testing our list view and one of our users happened to be colorblind.
In the image below, the list view on the left shows circles indicating the command status through two variations of the colors, red and green, where red indicated a failed command while green indicates a successful command. In this case, our user was unable to tell the difference. So we modified the circles ( list view on the right) to show a tick or cross mark to indicate the status.
Here is a small list by Jess Eddy who runs a side project called UI Goodies. She has compiled a list of accessibility resources that you can go through for your reference to make your product accessible to all.
Align your Tools
In our case, we use Sketch and Zeplin to sync our design and engineering team. The team wanted to continue using the same tools. We chose to go ahead with Sketch as it has a solid base on the symbol system, it worked for us, and it was what our team was comfortable using.
Use the Power of Sketch Symbols
Symbols are a powerful feature in Sketch that allows you to reuse elements easily across your document’s Artboards and Pages, or even multiple documents.
A symbol is made up of two parts: a “master”, which takes the appearance of an Artboard — and an “instance”, which is a flattened representation of the master.
A common example of a symbol is an element that is re-used throughout your design, such as buttons, or a cell in a table view.
Here is a short example of how we automated our forms with the power of Sketch Symbols.
Using Zeplin to Sync our Design System
The Final Step - Documentation, the Heart of the Design System
“Write as much as possible, coz if you don’t document it, it doesn’t exist.”
Write as much as possible because that will help you tackle a lot of queries coming your way on how to use this, that, and things around it. Things which are not necessary but are still a part of the design system also have to be written well. The documentation will give a clear picture to developers and designers in your company to understand every aspect of the component designed. If you don’t document it, it doesn’t exist. This should be one of the core values while you are building anything.
We used a simple node.js based documentation generator called Docsify.
We chose Docsify because it gives a lot of flexibility when compared to a well-built documentation site or app.
Here is how it looks.
Before you go!
This brings us to the end of the series. Hope you guys liked it! 🙂
If you missed out on Part 1 and 2 of this series, check out the links below:
Birth of our new design system - Part 1
Birth of our new design system - Part 2
And here’s the video to the talk I gave on Qubole’s Design System.
👏 50 Claps if you enjoyed this article, this will encourage us to write more!
🤔 Comment your thoughts about this series and let us know what else would you like to read from Qubole Design.
