4 coisas que estamos fazendo para evoluir o Tangram, Design System da RD Station

O processo de construção e manutenção de um Design System é constante e desafiador, principalmente quando o produto já existe e está em evolução. Esse é um dos grandes desafios que temos no Tangram, o Design System dos produtos RD Station.

Quando começamos a desenvolver a nova versão do Tangram (recomendo a leitura deste outro artigo), já havíamos mapeado a maioria dos componentes necessários em todo o produto, entendemos que esses elementos seriam os componentes base para tudo e vimos que fazia sentido começar a construção do Design System por eles. Foi isso que fizemos.

Começamos então a criar, no Figma e no código, esses componentes base (Button, Input, Select, Table, etc) e que, posteriormente, seriam utilizados para criar componentes mais complexos, como o Autocomplete (também conhecido como “Combobox”) por exemplo. Hoje, o Tangram conta com mais de 50 componentes e continua crescendo.

Como criamos novos componentes

Quando criamos um componente ou uma definição para o Design System, levamos em consideração os casos de uso já conhecidos. Não temos como ter conhecimento de 100% das coisas, então é normal que surjam solicitações de novos componentes. Identificamos que no nosso cenário existem dois fluxos em que a necessidade de criação de novos componentes pode surgir:

Solicitação externa

É quando um time (designers ou desenvolvedores) utiliza ou desenha um componente que ainda não existe no Design System. Para facilitar essa solicitação, nós criamos um formulário que a pessoa preenche e automaticamente é criado um card na nossa lista de tarefas.

Identificação interna

Estamos sempre presentes nas cerimônias de discussão sobre desenvolvimento de soluções e ficamos de olho caso algo novo seja proposto. Quando nós, do time do Tangram, identificamos que há a necessidade de criação de um novo componente ou a criação de uma nova definição, criamos um card na nossa lista de tarefas.

Independentemente se é uma solicitação externa ou identificação interna, ao analisarmos a necessidade sempre questionamos se aquilo deve ser um componente novo ou se podemos atualizar um componente já existente para atender um novo caso de uso (use-case).

Se entendermos que faz sentido aquela componente estar no Tangram seguimos com o nosso fluxo de desenvolvimento, caso contrário, alinhamos com as pessoas de que o componente pode ser feito localmente seguindo nosso padrão de design.

Como atualizamos os componentes

Essa é uma etapa sensível, mas essencial para a evolução de um Design System. É preciso lembrar que todo componente criado pode já estar sendo utilizado em uma tela ou fluxo (afinal, esse é um dos objetivos de um Design System) e que, dependendo das atualizações do componente, essas atualizações não podem afetar negativamente essas aplicações.

Atualizando no Figma

Realizar essas atualizações no Figma (ferramenta utilizada pelos designers) é relativamente fácil, pois não temos regras de negócio muito complexas e não envolvemos código, então sempre que necessário fazemos os ajustes necessários e publicamos as alterações no Figma para os designers atualizarem nos seus arquivos.

Atualizando no código

Já no código é um pouco mais complicado, pois a utilização é diferente, há mais complexidade envolvida e muitas vezes fazer a atualização é mais trabalhoso. Por isso, seguimos uma estratégia de versionamento do Tangram (faremos uma publicação explicando mais detalhes), em que cada aplicação pode atualizar para a versão que mais atende às necessidades.

Em ambos os casos precisamos fazer uma comunicação sobre as mudanças, para que todas as pessoas que estão utilizando o Tangram tenham conhecimento do que está acontecendo e possam levantar a mão caso haja algum problema nas suas aplicações.

E a comunicação e a documentação?

Temos um conceito no time do Tangram de que qualquer dúvida deve ser respondida com um link da documentação. Entendemos que ter uma documentação clara e de fácil acesso é essencial e que, assim como os nossos componentes, a documentação está em constante evolução.

Nossa documentação consiste basicamente em uma explicação breve do componente ou definição, boas práticas de design e de código, além de exemplos (com código) de como utilizar. Essa estrutura de documentação veio através de uma pesquisa qualitativa que fizemos com os usuários do Tangram - e tem funcionado bem para nós.

Sempre que realizamos a adição de um novo componente, ou fazemos alguma mudança em um componente já existente, nós comunicamos para toda área de produto. É importante que todos (PM, designer, desenvolvedor…) tenham o conhecimento do que o nosso time está trabalhando. Comunicação nunca é demais.

E quando uma alteração afeta um time?

Quando realizamos alguma mudança mais radical, como a remoção de uma propriedade ou algo que mude o comportamento de um componente, nós damos um tempo para que todos que utilizam o Tangram se adaptem e nos deem feedback. Não removemos as coisas da noite pro dia.

Também existe a possibilidade de uma alteração não ser aplicada no Design System. Isso acontece quando entendemos que essa mudança é utilizada apenas em um time ou feature específico e aplicar ela no Tangram fará com que o componente ou definição fique engessado. Se isso acontecer, alinhamos com quem solicitou que não há problema e que a alteração deve ser feita localmente, desde que siga as nossas definições gerais, a famosa foundation.

O tempo para essa remoção é muito relativo: depende do nosso roadmap, da complexidade das alterações e dos feedbacks que vamos recebendo ao longo do tempo, mas por definição esse tempo não deve ultrapassar 3 meses.

Pensando no futuro do Design System

Existe um momento na criação de um Design System em que não existe mais aquela necessidade urgente para criar novos componentes. Essa necessidade se torna atualizar os componentes existentes para atender novas aplicações ou resolver bugs. Esse é um fluxo totalmente normal e não é porque não estão sendo adicionados novos componentes que o Design System não está evoluindo.

Como comentei em alguns parágrafos acima, quando criamos um Design System nós desenvolvemos componentes ou definições para resolver os casos de uso conhecidos e, conforme o tempo passa, novos casos de uso vão surgindo e precisamos resolvê-los. Durante esse processo é normal novas definições surgirem e chega um momento que precisamos fazer o que chamamos de “arrumar a casa”. É um momento em que paramos para analisar o que foi feito no passado e alinhar o que precisamos alterar para que tudo fique de acordo com o cenário atual.

Também é nesse momento que começamos a pensar no futuro do Design System. Agora que estamos em um nível estável, pensamos no que queremos fazer a mais, onde queremos chegar, o que as pessoas que utilizam o Tangram estão precisando que ainda não temos.

A coleta constante de feedback é de extrema importância para a construção e atualização de um Design System. É com ajuda de todo nosso time de produto que conseguimos mantê-lo atualizado e definir o futuro do Tangram.

E você, utiliza algum processo diferente para manter o Design System evoluindo? Ou tem alguma dica? Deixa aqui nos comentários e vamos trocar uma ideia :D