Building a Design System
The Design System here was designed to simplify and unify processes, bring consistency in a multidisciplinary way and speed up creations and modifications.
Project: May to September 2023
My function: Product Designer PL. Process planning, methodologies to be used and research with developers. Furthermore, coordinating junior designers, we created and/or reformulated some of the components that now make up the Design System.
The team: Ysrael Santos (Product Designer Jr.), who provided exceptional help. I also had important support from Iara Leite (Product Designer), Ulisses Hein (Flutter front-end Dev) and Tiago Freire (Tech Leader).
Overview
Contexto e desafio
Em uma empresa de e-commerce, encaramos vários problemas de inconsistência de interface e lentidão no processo por falta de repositório de componentes. Evoluir a biblioteca para um Design System poderia resolver isso e mais.
Processo
Reunimos e redefinimos componentes, investigamos formas de facilitar integração com os devs e desenvolvemos design tokens. Validamos realizando testes em wireframes e provas de conceito.
Resultados ✨
O Design System economizou significativas horas em processos de design, que puderam ser realocadas para outras tarefas, e sucedeu bem nos testes com tokens, recebendo feedbacks positivos dos desenvolvedores.
The challenge: Evolve a poorly structured library into an evolutionary system
Building a system of components that would work for a team with little design maturity and help them improve development production time. This system should a) encompass the products and elements we already have, b) be built in a way that is easy to read for design and dev teams and c) that is also “scalable” for the company's current and future products.
Steps and processes
1. Review and classification of existing elements
There was already a library and several elements built from it, although they did not have complete consistency. We first gather these elements and classify them, then review every detail to document the new standards.
2. Scope reduction to starting point
From where we were, a library was already built, but to make it a DS as we would like, we needed to reduce the vision. Our team was small and we had few resources, this would have to be taken into consideration at each stage of the process.
3. Creation and validation of design tokens
Reducing the scope helped a lot to stay focused and test a process that worked. In a short time we created the token semantics and validated the first version with the devs. Here they had an essential participation in the project and the tokens really gained common language potential between devs and designers.
Most of the "core components" were already being used between us (designers) and the devs. Most of the adjustments made were related to standardization of colors, sizes and spacing.
Design Tokens
During this stage we had a special affection. The company is mainly made up of engineers and one of the project's priorities was to bring design closer to development, in addition to helping them compose the library they will use. Here, the idea is that design tokens are like a special language between the two teams and therefore were carefully thought out.
a) Token layers: Before starting, we understand our components and their formations; components that are formed by other components, which are formed by raw values. The image should explain it better, but imagine a sandwich, made up of bread and cheese, which in turn are made up of wheat and milk.
The biggest peculiarity of our system also happened at this stage. With the involvement of engineers, we were asked for special layers of tokens to meet our modelbusiness and thus emerged the"inside alias tokens", which are when alias tokens gain particularity because of a component token; in this way a detailAny button requested could be changed without changing them all.
b) Semantics: Semantics is basically logical meaning in the codes we create so that the system can be read easily. Once understood, just by reading the tokens you can have an understanding of what it is about.
c) Validation:As for validation, we have it for the design and engineering team. For design it was quick and definitive, since we were used to using the library. But for engineering, before taking action, we decided to do POC (proof of concept) testing, testing tokens and components in the smallest possible product before actually going to our published products. At the time of writing, the POC has not been finalized, so I cannot conclude here, but expectations are high.
And what could come next...
Reresult is continuous work.
We work on the Design System as an internal product that functions as a SaaS, with our objective of facilitating scalable and consistent product deliveries, but adaptable to our internal and external customers. An important part of this process was understanding business, design and engineering needs so that the pieces fit together and in the meantime evangelizing a team with low design maturity about the benefits that this system could bring.r.
Within the design team, DS brought immediate results reduced time producing and organizing high-fidelity parts, which allowed us to use more time for research and quality deliveries. In terms of engineering, the DS has gone through all the tests so far, but we are not yet where we planned, however now we have consistent deliveries.
Our expectation is that over time - whether in the short term, dedicating specific time to building the library, or in the long term, through deliveries and small changes - they will be of great use, making changes more practical and modular.
Doing this work with a low seniority team was a challenge.personal thread, but it worked well. In the end we were able to see an increase in the team's experience and a little more maturity in design in the tech area. Now we have to wait and see the next steps and results of this process. :)