Design System — um produto servindo outros produtos
O que aprendi no curso Design System Boost
Recentemente, concluí com o apoio da comunidade PretUX em parceria com a Pixel Cast, o curso Design System Boost, no qual aprendi os conceitos e aplicabilidade desse sistema que pode ajudar muito na escala das entregas e na comunicação do time de Design com todos profissionais envolvidos em um produto digital.
Mas afinal, o que é um Design System?
Há várias definições de Design System, algumas mais completas e outras mais simples. A que sempre utilizo para explicar a alguém que não tem ideia do que seria, é que “Design System é uma biblioteca de componentes de design ‘codados’, que servem para documentar padrões, e ser consumida pelos desenvolvedores e demais pessoas que atuam em um produto digital”. Mas a verdade é que ela pode causar confusão, porque um Design System é muito mais do que isso. A definição apresentada no curso é:
Um Design System é um produto que serve outros produtos. Com decisões semânticas tomadas e disponíveis para uso tanto de designers quanto de desenvolvedores.
Design System não é sobre organizar os arquivos de design, é sobre pensar em uma forma de conseguir conectar diferentes disciplinas, envolvendo as áreas de tecnologia, negócios e quais outras forem necessárias, ou seja, todos os stakeholders importantes para o produto. Precisa ser algo que é útil para todos e não apenas para o time de design.
O Design System é o local onde documentamos as decisões de design, uma plataforma capaz de ajudar a projetar produtos com experiências mais concisas. Porém, ele é um organismo vivo, nunca termina, sempre temos algo a adicionar, novas decisões a serem tomadas, decisões a serem revistas e, por fim, acabamos ficando com a impressão de sempre estar começando o trabalho.
É muito importante encarar o Design System como um produto e não como um projeto.
Design System não é um projeto, é um produto servindo outros produtos. Ele precisa de um MVP, um roadmap, atualizações e melhorias. Se possível até um time focado nele. — “Nathan Curtis”
Na prática, quando falamos em Design System, podemos pensar em dois pilares principais: os Design Tokens, que são as partes indivisíveis que uma interface carrega, e a Biblioteca de Componentes. A seguir vamos entender um pouco mais sobre cada um deles.
Design Tokens
O termo Design Tokens foi popularizado pela Salesforce, mais especificamente em seu Lightning Design System e desde então foi adotado como conceito básico para a construção de um Design System. Podemos considerar como Token a representação da menor decisão de Design possível, como por exemplo, um espaçamento, o peso de uma fonte ou uma cor, e os escrevemos de forma semântica atribuindo um nome ou um valor. Os Tokens definem as características visuais de um componente e são fundamentais na entrega do trabalho de design para os desenvolvedores.
Componentes
Depois de definirmos os Tokens, podemos começar a pensar nos componentes que integram um Design System. A partir dos Tokens criamos o que chamamos de base components, aqueles componentes que são indivisíveis e compõem as menores partes de uma interface. E a partir dos base components, criamos os components, uma junção de componentes indivisíveis que formam componentes mais complexos. Vale lembrar que os componentes possuem anatomia e cada parte dele tem uma razão de ser, e também possuem uma convenção de nomes, que mais uma vez, pode facilitar a comunicação entre o time de design e o time de desenvolvimento.
Bibliotecas
Os elementos de um Design System precisam estar organizados e devidamente documentados. A maneira mais usual de fazer isso é criando uma estrutura de bibliotecas. Um bom exemplo de organização dessa estrutura é o do Airbnb — usada como exemplo no curso — com a biblioteca Core, onde ficam todos os elementos globais, que todos os produtos podem utilizar, a biblioteca Team, onde ficam os componentes que são utilizados apenas por determinado time, e a biblioteca Not in DS, composta por componentes pontuais, usados em situações específicas, não respeitando, necessariamente, os padrões definidos lá na criação dos Tokens.
E quando precisamos de um Design System?
Agora que sabemos o que é um Design System, como saber se meu time ou produto precisa de um?
Em times de produto, é comum nos depararmos com algumas situações que causam gargalos e podem prejudicar o andamento, velocidade e qualidade das entregas. Muitas dessas situações envolvem interface (UI) e decisões de design. Vamos a algumas delas:
- O designer projetou uma interface, tomou decisões, entregou para o time de desenvolvimento e após o produto ficar pronto, percebeu que estava diferente do que tinha projetado. Ops! Designer e desenvolvedor não falam a mesma língua!
- Você atua em um time grande de design, onde cada um segue uma linha visual diferente, prejudicando a consistência visual do produto. Nada bom, né?
- Seu produto tem diferentes tipos de componente que servem para a mesma finalidade, mas com comportamentos distintos e você nunca sabe qual usar.
- O time de design está gastando muito tempo para construir as interfaces.
- Após a entrega do time de desenvolvimento, sempre é necessário fazer um processo de QA de design.
Se você se identificou com mais de uma dessas situações no dia a dia do seu time ou empresa, um Design System pode ajudar, e muito, a sanar essas dores e escalar as entregas.
E quais os benefícios? Bora convencer os Stakeholders?
Como já foi falado aqui, o Design System não é um projeto, é um produto, que exige a dedicação de um time e custa dinheiro. Sendo assim, convencer os stakeholders a investir em um Design System pode não ser uma tarefa tão simples. Um bom começo é mostrar os diversos benefícios que ele pode trazer para o time, como:
- Economia de tempo para designers, desenvolvedores e equipes de produto em geral;
- Economia de tempo significa economia de dinheiro;
- Mais tempo para focar no usuário e em problemas reais;
- Melhor comunicação e colaboração da equipe;
- Maior consistência no design, no código, na marca e produto.
E como convencer?
Um primeiro passo pode ser mapear as dores, encontrar quais são os principais problemas enfrentados pelo time, no contexto em que está inserido, e mostrar como o Design System pode ajudar a resolvê-los. É sempre bom ter em mãos um planejamento realista para esse tipo de conversa.
Encontre parceiros. Uma péssima ideia é fazer tudo de porta fechada, é necessário envolver pessoas. O Design System não é um produto apenas do time de design, é de todo o time. Então fale e alinhe com o máximo de pessoas possível, para que elas também te ajudem a defender essa ideia.
Venda a visão. Depois de encontrar parceiros é hora de vender para os stakeholders. Nesse momento é necessário ser realista, a construção de um Design System é algo complexo, leva tempo e dinheiro, precisamos ser honestos quanto a isso. E a partir disso, falar novamente os benefícios, a perspectiva de resolução de problemas, mostrar cases reais de sucesso, ver como outras empresas conseguiram escalar com um Design System, enfim, mostrar resultados.
E por fim, comece a fazer. Organize melhor a sua biblioteca de componentes, crie um roadmap, pense em métricas de sucesso, alinhe com o time. Com algo de concreto em mãos pode ficar mais fácil convencer os stakeholders.
Como adotar boas práticas de Design System, mesmo sem precisar de um!
Um Design System pode trazer muitos benefícios para um produto e consequentemente, para o time e a empresa. Mas a verdade é que nem sempre precisamos de um Design System. Anteriormente, citei nesse artigo alguns cenários que podem indicar que você precisa de um, mas se a realidade do seu contexto não condiz com nenhuma deles, provavelmente um Design System pode ser um exagero. No entanto, podemos seguir algumas boas práticas que vão refletir em um produto com maior qualidade e uma experiência mais concisa. Acredito que as principais são:
Style Guide
O Style Guide define alguns padrões como, paleta de cores, tipografia, grid, botões, entre outros, e serve como um guia visual que documenta as decisões de design e garante a consistência, oferecendo um bom ponto de partida para criação das interfaces. Em muitos casos, apenas ele já resolve o problema e atende totalmente as necessidades do projeto ou produto.
Ter um Style Guide bem definido é um bom começo. Ele vai ajudar tanto os designers a construir as interfaces com mais facilidade e consistência, quanto os desenvolvedores a entender melhor o que foi projetado, consumindo informações com mais precisão.
Handoff
É o momento em que o time de design entrega o trabalho para o time de desenvolvimento. Esse é uma etapa delicada, que pode se tornar crítica e até mesmo frustrante, pois nem sempre é fácil para os desenvolvedores traduzir com precisão o que foi projetado pelo designer.
Criar uma documentação bem estruturada que não dependa do Inspect do Figma é o melhor caminho. Aqui, é importante lembrar que o desenvolvedor também é seu usuário, que vai consumir seus entregáveis e transformar em código para dar vida ao produto. Então, é importante entender quais são suas necessidades definindo, por exemplo, como você deve entregar essa documentação, qual é o nível de detalhe, quais informações são primordiais. A partir dessas informações podemos criar um modelo de documentação e adaptar conforme as necessidades.
Desenvolver uma relação de confiança com o desenvolvedor é fundamental. O Handoff é algo que tem que ser construído de forma colaborativa e não em silos de designers. Então, sente junto com os desenvolvedores, esclareça dúvidas, faça combinados, passe as ideias de um lado para o outro.
Falar a mesma língua do desenvolvedor
Tão importante quanto criar uma relação de colaboração com os desenvolvedores é falar a mesma língua deles na hora de documentar a entrega de UI. Então quando estiver nomeando seus componentes, padrões e interações, que tal utilizar as mesmas nomenclaturas utilizadas no desenvolvimento? Com certeza isso pode facilitar, e muito, o entendimento do que foi projetado.
E no final das contas, o mais importante, tanto para o caso onde se opta pela construção de um Design System, quanto para quando ele não é necessário, é a colaboração do time. Um time que colabora sempre chega na melhor solução.
