Minha experiência com meu segundo Design System
Acho que antes de qualquer coisa eu queria dizer que pra mim Design System é o projeto que você desenvolve pra ter sustentação para outros projetos, eu considero um Design System um produto e portanto ele pode ser desenvolvido como consumo de qualquer pessoa envolvida, sejam pessoas desenvolvedoras, designers, writers, etc.
Essas pessoas consomem seu produto estando em qualquer estado: se ele possui somente uma documentação simples no Figma, se ele possui apenas componentes, ou se ele já está implementado centralizadamente numa equipe de Design System com as habilidades necessárias para se criar componentes tanto em design quanto em desenvolvimento.
É válido ressaltar que essa é a minha opinião, já que um Design System sofre evolução constante e nenhum projeto em andamento tem realmente um final. Um DS está sempre em sendo reinventado, mantenido.
Isso dito, eu gostaria de trazer minhas experiências trabalhando com meu segundo Design System, na Hotmart, onde aprendi com meus usuários — pessoas de tecnologia em geral — tendo também bagagem de necessidades que já observava no outro DS que tinha trabalhado.
Discovery Component
Quando troquei de empresa a primeira coisa que eu fiz foi estudar o Design System do qual iria trabalhar, lógico. Mas eu não só abri as bibliotecas, vi os componentes no Figma ou no GitHub, uma das tarefas que eu realizei foi tirar print de tela por tela de Product Designers dos outros times.
"Como esse cara usa esse Input Text?"
"E essa aqui, como que ela ta usando o mesmo componente?"
Essas indagações viraram um projeto de estudo do qual chamei “Discovery Components” com todas as formas de disposição dos componentes na plataforma.
❗️ Problema:
De alguma forma dava pra perceber que alguns Product Designers usavam alguns componentes de forma inconsistente, seja por não tirarem dúvidas ou adaptavam da melhor forma que se encaixava no projeto, e sabemos que infelizmente isso gera uma inconsistência absurda entre os projetos.
💡 Solução:
Minha parte prática a partir disso, foi gerar uma planilha com as dependências de cada componente. Por exemplo:
Componente de Input Text precisa desses componentes adicionais:
- Label (texto e cor);
- Caixa de entrada (cores, bordas e espaçamentos);
- Texto de ajuda (ícone, texto, cor e espaçamentos).
Inclusive: em breve quero disponibilizar no Notion uma planilha para auxiliar como check list de Design System.
Tendo isso em mente eu consegui criar uma priorização de componentes menores (a partir do conceito de Design Atômico do Brad Frost). Pesquisava no Discovery Component como Product Designers estavam fazendo cada componente. No nosso exemplo do Input Text, ele precisava de "componentes menores" de texto, cor, borda, espaçamento, ícone, entre outros.
Na criação de uma nova biblioteca fui puxando esses insights e formas de disponibilizar o melhor UI/UX possível de cada componente, respeitando as etapas de cada processo como Ideação e UI, Teste de Usabilidade, Handoff com Desenvolvedores e enfim o tão esperado Done/Release, para que enfim todos pudessem usufruir do componente.
Foi assim que surgiram minhas ideias de disponibilização dos componentes de forma que a gente pudesse obter o máximo de consulta da documentação e menos gargalos esperando soluções a partir do contato com o time de DS.
E é a partir daqui que vira uma "aulinha", um "how to do your DS". 🤓
Variações inteligentes
Sabe quanto você tem uma ideia de disposição de um componente que poderia fazer um milhão de coisas em um cenário e mais simples em outro cenário? Pois é, isso acontecia bastante.
São os famosos "Moléculas" ou até "Organismos" no conceito de Design Atômico. Minha primeira versão foi disponibilizar o que chamava de "minhocão", um componente com todos os componentes internos possíveis para cada necessidade. Para cada uso do componente o Product Designer deveria copiar o componente raiz (com tudo dentro visível) e ir ocultando as camadas que não precisava.
❗️ Problema: os usuários efetuavam muitos cliques até encontrar a camada que gostaria de editar/ocultar; se o componente sofresse atualizações isso reverberava no import do Product Designer e atrapalhava todo seu projeto, pois o componente também atualizava textos e adaptações; e o Figma com muitos componentes importados e ficando lento.
💡 Solução: Criar vários componentes adicionais separados, como no caso do Input Text, cria-se um componente do Label, outro para o Input e outro para o texto de ajuda. Mais tarde com um update do Figma foi possível criar Variações Aninhadas (Nested Instances), que permite exibir o painel de Variants para cada componente interno, eliminando os problemas que foram citados acima. 🥳
Documentação
Apesar de ser uma pessoa comunicativa também gosto de trabalhar no meu cantinho, portanto, como reduzir esse contato para que eu consiga focar e realizar meu trabalho? Como evitar contato desnecessário com algo que eu sei como resolver e outras pessoas também querem saber como resolver sem precisarem tirar dúvidas o tempo todo?
Simples: escrevendo! ✍️
Escrever como algo funciona, mesmo que você não tenha o "dom da escrita", é importante e nos dá uma convicção do real funcionamento do que estamos desenvolvendo. Para dentro do Design System isso é imprescindível e é uma das coisas que eu mais faço questão que um DS realmente tenha, ele precisa ser descritivo.
Questões como:
1. Como esse componente se comporta?
2. Quais variações ele possui?
3. Em quais casos eu não posso usar esse componente?
4. Quais variáveis estão disponíveis?
5. O que posso alterar do componente para se adaptar no meu projeto?
6. Quais contextos utilizar?
7. Existe algum cenário excludente?
Eu sei que as vezes parece ser muito longo ter que ler a documentação de todos os componentes, mas na necessidade do dia-a-dia você só precisaria ler sobre o que você está usando ali naquele momento.
PORÉM… Mesmo sabendo disso eu quis facilitar ainda mais o processo para meus usuários, trazer de forma visual as opções e variações daquele componente. Levei uma documentação visual para que a pessoa que lesse/visse pudesse bater o olho e saber como seria o funcionamento daquele componente (eu sei, eu sou especial demais! 💁♀️).
Anatomia
Quando o componente passou por todos os passos do processo de construção, eu costumo puxar as variações mais discrepantes e vou desenhando em cima do componente.
Get Natasha Kaweski’s stories in your inbox
Join Medium for free to get updates from this writer.
Pera, vou desenhar pra você entender:
Mas no Figma não tem a aba Inspect? Sim, mas como eu disse: disponibilizar visualmente a solução é muito melhor do que ler a documentação. O mais simples que pudermos deixar para quem for consumir precisar somente bater o olho e entender o que precisa ser feito, melhor.
Do's & Don'ts
Foi disponibilizada várias formas visuais de como um componente pode ser utilizado e como ele não pode ser utilizado. Variações simples e que eu precisei pensar como Product Designer e a partir do Discovery Component em como construir esses exemplos visuais utilizando o componente em questão.
Diferente do que encontramos em muitas documentações publicadas, eu tentei trazer pra realidade do PD como o componente deveria ser comportar em seu projeto. Isso também auxilia os desenvolvedores a entenderem a lógica do comportamento do componente.
Interaction Design
No Figma, depois do Auto Layout o Prototype é minha ferramenta preferida, porque é com ela que a gente faz a mágica acontecer.
Sobre o usuário, como ele vai se sentir quando interagir com meu componente? O que ela está pensando? Será que isso aqui vai facilitar a vida da pessoa? Tirando as questões de regras de negócios (onde não tem espaço dentro do Design System), isso atende ao usuário?
Não é segredo nenhum que uma Pessoa Designer empática tem uma grande virtude, portanto, é criando a interação do componente que entendemos como nosso usuário vai interagir com aquele componente.
É muito importante mostrar o funcionamento do componente, com cliques simples e com o básico é possível trazer clareza para o funcionamento de tudo.
Releases & Branches no Figma
Na minha primeira experiência com Design System eu sempre tinha problemas com os Product Designers que reclamavam que o DS sofria alterações o tempo todo.
Não façam isso! 🚨
Aprendi com a experiência que isso não é de todo agradável. Além do Figma notificar cada publicação nova da biblioteca, dependendo da alteração faz o projeto "se quebrar todo".
Passando por várias situações como essas, eu identifiquei que precisava focar num componente completo, trazendo-o mais inteligente possível e que não precisasse de manutenção tão cedo. Isso faz com que hoje eu consiga evitar alterar um componente já construído e em produção, evitando futuros reajustes de quem esteja utilizando uma específica versão.
Válido ressaltar que estipulando metas e definindo bem as sprints eu sabia quantos componentes eu precisaria desenvolver num período de tempo. Como trabalhar com isso na prática? Vamos ao Figma:
- Cria-se um arquivo onde se coloca os componentes ainda não prontos, que estão “estacionados” (gosto de chamar de Parking Lot);
- No desenvolvimento dos componentes em Parking Lot, após passar por todos os processos de aprovação, costumo “taggear” os componentes com um ícone de “Done” pra facilitar a transferência pra biblioteca: ✅.
- Cria-se uma branch da biblioteca core (pode ser com o nome da versão da release, tipo v1.0-Pitanga) — lembrando que Branches só estão disponível para Organizations;
- Na branch nova criada se coloca ali os componentes com a tag “Done”;
- No final do período essa branch é “mergeada” na branch “master” da biblioteca core, e o componente fica disponível para uso dos PDs depois da publicação e propagação da Biblioteca Core.
Pair Design
E pra finalizar com chave de ouro, o mais importante como Designer de Design System: ver o usuário do seu produto utilizando o seu produto pra construir algo incrível. Tomei a liberdade de chamar de Pair Design porque é bem semelhante ao Pair Programming que a área de desenvolvimento tem, é realmente fazer uma funcionalidade usando seu DS com o conceito e necessidade junto com outro PD.
O passo mais importante, as vezes um pouco maçante pelo tempo e pelo empenho num só componente, mas muito importante pra entender como as pessoas estão se comportando utilizando algo que você construiu.
Além de ajudar a pessoa Product Designer a utilizar o seu produto, você também mantém a consistência do seu produto, tendo o Design System atuando desde a prototipação de uma funcionalidade, no uso correto do Design System e entendendo ali na íntegra quais as dores e soluções tem a pessoa que está usufruindo do seu Design System, te dando feedbacks ao vivo de como ela vai trabalhar com o que você produziu.
É muito importante manter essa consistência de Pair Design, porque é nesse processo que mantenedor e ajudador conseguem fazer os projetos se adaptarem ao Design System.
Acredito que é tudo isso, galera! Continuo aprendendo cada vez mais sobre os processos de mantenedora e owner de um Design System tão robusto quanto o que trabalho hoje. E esperem que trarei mais conteúdo por aqui.
Ah! Segue link do site novo: https://kawe.ski, é meu cantinho na internet onde quero postar minhas mil coisinhas que gosto de fazer.
[]’
