Lições aprendidas com nosso Design system

Embora já esteja entre os trending topics há alguns anos, o tema Design System não parece que vai sair, tão cedo, das discussões entre designers e developers. E existe um por quê.

A construção de um Design System envolve muito mais do que criar uma biblioteca de elementos de UI. Ele é um processo que deve considerar muitos outros fatores, como o propósito, as ferramentas e as pessoas que irão utilizar aquela biblioteca. É como poder refletir todos o valores da empresa, cujo Design System irá servir, em uma documentação que deve ser inteligível a quem se destina. Saber que existe a possibilidade de deixar produtos e experiências mais coesas, e fluxos mais consistentes é um dos grandes motivos para este ainda ser um tema quente e com muitos cases por ai afora.

Aqui na Labcodes, acreditamos que, para alcançar uma boa entrega, precisamos ter domínio do processo. Usamos como base uma metodologia ágil e melhores práticas de design e desenvolvimento, e nesse projeto não foi diferente. Prezamos que tanto o time de Design quanto o time de Desenvolvimento, que iriam se envolver com essa tarefa, participassem das etapas e estivessem cientes de cada decisão. Como os designers também participaram da implementação da UI, a necessidade de comunicação entre os dois times era irrefutável.

Quando começamos o nosso próprio DS, pensamos em quais passos iríamos seguir para garantir que nosso resultado não fosse apenas mais uma coleção de componentes, afinal, qual seria o nosso diferencial se fosse assim? Começamos, então, definindo os nossos princípios.

Quando você tem guidelines conflitantes, você precisa voltar aos princípios e decidir quais são mais importantes.
Tradução livre

Lori Kaplan - Atlassian

Esse foi um passo importante para que não nos perdêssemos durante a execução. Ter essas diretrizes tão bem amarradas foi o nosso norte para muitas tomadas de decisão. E, sim, teria sido muito fácil se perder quando começamos a crescer nossa lista de componentes que gostaríamos de construir para a versão alfa¹. Ainda assim, em muitos aspectos, acabamos aprendendo com os nossos erros (uma maneira bem eficaz de se aprender, não?), e eu gostaria de dividir 5 lições que tiramos da criação do nosso embrionário Design System.

Um quadrado pra mim é um quadrado pra você.

Acredito que design e desenvolvimento funcionam melhor juntos quando as nomenclaturas, ferramentas e modelos estão em sincronia. Quando reduzimos a sobrecarga mental, as equipes não precisam comprometer a qualidade, mesmo enquanto criam e finalizam features de forma rápida.
Tradução livre

John Choura - Designer e developer

Documentação é uma das coisas mais importantes num projeto como esse, sendo muitas vezes o que o separa de uma simples biblioteca de componentes. Se queremos facilitar o uso dos assets, devemos dar uma indicação clara de qual o seu propósito e como deverá ser utilizado.

Para que a documentação não se perca nos termos próprios de cada parte envolvida no projeto, é importante que todos falem uma mesma linguagem. Quando estávamos pensando nos botões, por exemplo, o que estávamos chamando de Primary não trazia o mesmo entendimento para o time de Devs. É incrível como um simples termo pode mudar o contexto e a interpretação de uma documentação, então se certificar de que todos estão na mesma página em relação às nomenclaturas é um bom começo para que o resultado dela cumpra satisfatoriamente a sua finalidade.

Priorização: Se não vai ser usado, para quê criar?

É muito fácil a gente se empolgar quando começa a trabalhar numa tarefa nova. Passamos semanas bebendo aquele conteúdo e vislumbrando as mil possibilidades que podem ser geradas. Nesse contexto, querer começar fazendo algo robusto pode parecer um caminho sedutor.

Saber priorizar pode ser difícil quando abrimos mão de atividades que gostamos. Definir o escopo no início pode ser o divisor de águas entre ter um primeiro entregável que, como todo Design System, irá crescer e passar por iterações, ou ter um projeto que nunca sai do papel.

Clientes, colegas e stakeholders devem abraçar a natureza flexível do mundo digital para criar Design Systems vivos que se adaptem à natureza mutável do meio, às necessidades do usuário e do negócio.
Tradução livre

Brad Frost - Autor, Atomic Design

É difícil finalizar algo se tentamos prever todas as situações hipotéticas que queremos contemplar. Um spoiler? Você nunca vai adivinhar todos os cenários, e quanto antes testar o que já tem, mais rápido vai descobrir isso.

A dor e a delícia de escolher as ferramentas

Na Labcodes, usamos o Figma para desenvolver a UI dos nossos produtos, então foi fácil a decisão de o usar também para o Design System. Nele, os arquivos criados ficam na nuvem, permitindo que toda a equipe tenha acesso live à versão mais atualizada do projeto. Existem inúmeras vantagens no uso do Figma, mas controle de versões não é bem uma delas. Acredite, para um sistema que deverá crescer constantemente, esse é o tipo de controle que é essencial.

Para a nossa gestão das versões dos arquivos, achamos melhor criar um fluxo interno próprio, que será tema de um próximo post.

Homem de terno, sorrindo, dá uma volta ao redor do corpo e para apontando os dedos para frente

Para construir e documentar, escolhemos o Storybook, que já é bem popular e abriga muitos outros Design Systems. A ferramenta ajuda a organizar de forma prática o visual, o código, e as informações de uso dos componentes, sendo uma mão na roda para testar o que foi criado em um ambiente de playground. Essa foi uma opção em que pudemos ter um único local para construir, revisar, testar, documentar e posteriormente difundir nosso resultado.

Embora seja popular, tivemos muitas dificuldades ao estilizar a ferramenta e percebemos que existe uma deficiência de documentação mais específica sobre alguns tópicos. À princípio, pensamos que os problemas surgiram por estarmos "subvertendo” a sua função, mas a verdade é que a ferramenta se propõe a fazer tudo o que demandamos dela. Apesar da relação de amor e ódio com o Storybook, resolvemos bancar nossa escolha e tirar o máximo que ela pode nos oferecer. A verdade é que nenhuma ferramenta será perfeita. É importante saber o que é realmente necessário e o que é apenas desejável na hora de fazer essas escolhas e lidar de forma leve com as limitações.

Regras não são escritas em pedra

Design System deve ser uma ferramenta de empoderamento e sincronização de um time, não um meio de criar verdades absolutas. Embora muito se fale que a documentação do DS deve ser a “fonte de verdade da empresa”, essa fonte pode e deve ser contestada sempre que necessário. Por isso dizem que este é um projeto vivo, mutável sempre que algo apontar que assim deve ser.

Não estou dizendo que deve-se sugerir mudar algo apenas porque sim. Considerando que o que foi criado deve se adaptar aos mais diversos cenários, é OK não ter levado em conta um contexto X e ter que revisitar algumas decisões para que os componentes sejam mais versáteis e reutilizáveis.

Lembrem-se: as decisões tomadas no projeto devem ser feitas com o intuito de facilitar o trabalho de Designers e Devs, não transformá-los em prisioneiros delas.

Front-end também é Design?

Ilustração de unicórnio com anatomia humana, em pé, rodando um bambolê na cintura

Durante grande parte da minha experiência enquanto Designer, trabalhei com impressos. Quanto mais experiente eu ficava, mais eu entendia que de nada adiantava criar ideias mirabolantes se não teria como executá-las graficamente. Conhecer papéis, métodos e custos de impressão era imprescindível.

Trabalhar com produtos digitais não é assim tão diferente. Por que propor algo, se aquilo dificilmente será implementado, ou se o custo para implementação não justifica os seus ganhos na experiência? Saber se comunicar com o time de Devs pode ajudar muito na hora de gerenciar o projeto do Design System. Essa provavelmente é uma premissa que serve em todos os contextos de produtos digitais, mas vale lembrar que o DS bebe da natureza funcional da programação.

A programação, por natureza, é funcional, reutilizável, extensível e tem controle de versão. Os Design Systems modernos visam alcançar essas qualidades e ir além e, sendo assim, podem tomar como base a forma como a programação já é trabalhada.
Tradução livre

John Choura - Designer e developer

Dito tudo isso, é importante lembrar que cada cenário tem as suas particularidades. Esses foram alguns aprendizados que tive e que fizeram sentido para mim e para o meu time, fazendo parte de uma experiência pessoal. De toda forma, tenho um palpite de que muitas equipes envolvidas em um projeto de Design System, sejam empresas grandes ou pequenas, se viram em situações muito parecidas. Espero que essas lições aprendidas possam servir a vocês o tanto que têm me servido :)

Referências

Notas

[1] Primeira letra do alfabeto grego. É normalmente usada para denominar a primeira fase de um produto, ou seja, uma fase de testes antes do lançamento para o público geral. ↩