Design System
Being the lead for kick starting our Design System I was responsible for some things:
- Facilitate ideations to define our Design Principles and our Design System name;
- Build an Interface Inventory, in order to scan for inconsistencies in our web app and websites;
- Build the Design Tokens: define and organize the colors, typography, grids and spacings;
- Start the main Components, predefined by our team, to apply in our first project.
May 2020 - Ongoing product
UX Process
Discover
- Desk Research
- Interview with Users, Builders and Stakeholders
Define & Develop
- Interface Inventory
- Design Principles
- Design Tokens definition
Deliver
- Design Components;
- Implementation of our MVP
Goals
- Reveal the disparity between product platforms, website, mobile website, and mobile app
- Empower the team with resources that help drive a unified experience between the website and app
- Improve the experience across all devices by creating a consistent visual language;
Team Structure
A Design System is never done by a single person from a single team. Although our team is pretty small compared to other organizations, we did a good job joining forces to build a cohesive product for our brand iq.As a team we defined two leads for this: Ítalo Fontes (Front-End Developer) and I (Product Designer). The rest of the team, 5 Front End Developers and 2 Designers, would help to build the Components in the future, after we built the Design Tokens.
Desk Research
The three main goals with the Desk Research were:
- To understand how a Design System is built and its best practices, what is the definion of it, what is the impact in a company.
- To use this information to present the concept to the team and sell it for the stakeholders.
- To understand if this product was a good fit for our needs...
After this research I made a presentation to the team. And Ítalo, my Front-End partner, gathered some information on his side, to understand what technologies we could use.
Interviews with Users, Builders and Stakeholders
I interviewed three groups of people, following the script that Brad Frost made available on his blog:
- Users being the people who will use the design system, for example, Designers and Front-Ends from other squads.
- Builders being the people who are going to build the Design System, for example, Designers and Front-Ends responsible for the project.
- Stakeholders, being the people who will buy the idea and give time to build this product, for example, PO's, PM's, Directors, Vice-President...
Finally, I discovered that the Design System was something viable and necessary for our team, which was growing fast and wildly. Here are some pain points:
- iq had several designers, so they created some patterns and legacies;
- The product was growing and the demand to create new things was coming, so a lot of things were duplicated and it was running out of pattern;
- A lot of new elements were built in the code because there was no design system. So, often the Developers looked up in the Sketch file to see if it had something similar.
- More time to code a component and less time to think about the experience.
- iq doesn't has a defined process.
Interface Inventory
I put three examples below to show some discrepancies in some of our components and tokens, like in Buttons, Icons and Colors. You can see different styles, different icons being applied in components and a lot of color variants with no standard.
Design Principles
I facilitated an ideation session with all members of the Design and Development teams in order to think and build ours Design Principles. This will be the core of our Design System and how we build our products for our users.
I brought some examples of Design Principles from renowed companies, like Airbnb, to inspire them. In addition to this, I also explained the meaning of this and how it is used in a daily basis.
The ideation session
Like I said before, I brought some examples of Design Principles and I extracted some words from the interviews and created a word cloud to guide our participants in the ideation. They thought about some words that would best represent iq and our Design System. The words were:
Consistent, Reliable and Customizable.
After our Top 3 keywords were defined, we explored the meaning of each of them to iq. For this, I suggested an exercise of Mindmapping, in which each keyword became the core and the phrases became the stems. One side of the stem should start with ”As user, I must...” and the other was ”Our projects must...” Therefore we formed intern and extern perspectives. See the example below:
With this we created our Design Principles together:
Consistent
Each piece from the system and its actions should be easily and quickly comprehensible. Good design works
for everyone, everyday.
Reliable
iq makes roads safe and useful. We
make sure that the interface is uncluttered and easy to read. Our products should be clear and
accessible.
Customizable
Design with an eye towards the future of our products, but keep in mind that iq must be recognizable even if this product is originated from a partner.
Design Tokens
As Adobe says:
"Design tokens are all the values needed to construct and maintain a design system — spacing, color, typography, object styles, animation, etc. — represented as data. These can represent anything defined by design: a color as a RGB value, an opacity as a number, an animation ease as Bezier coordinates."
The first thing we did was to "fix” our issues with our current Design Tokens: a legacy of different shades of colors, non-standard typography, a ton of different and non-standard icons and a lack of grid and spacing determination. Here are some of our Design Tokens:
Design Components
After designing the Design Tokens, we finally started to create Components section: a series of standalone UI elements designed to be reusable, like a button. And we specified its functional behaviour by building instructions that would allow developers to use these components in a logical and consistent way.
The components helped us to create the new section of our iq app, called New Architecture:
Learnings and how it is going
Building a Design System is a non-linear process. Sometimes it was difficult to know if we were building the right thing, but it was satisfactory to see it being applied and things starting to connect and make sense. Both the Front-End team and the Design team noticed:
- Time saved with Components and Design Tokens ready to use;
- More time to focus on the experience in general;
- Less time fixing bugs and coding.
- Greater proximity between the Design and Front-end teams;
- Knowledge acquired during the process;
Next steps
- Keep building and improving our Design Tokens and Components;
- Measure impact quantitatively to inform our stakeholders of the gains of the Design System;
- Build the library in the ZeroHeight platform, so the rules can be easily disseminated.
RamenGo
