Alavancando o DS: Como a nossa ferramenta de handoff otimizou a criação de componentes no Jusbrasil

Contexto

Nossa jornada de componentização no Jusbrasil começou muito antes do termo “Design System” se popularizar, especialmente no contexto brasileiro. Foram anos organizando partes de código para melhor reaproveitamento!

Foi com essa visão, e com o surgimento do Atomic Design, que alguns anos depois as guildas de design e engenharia juntaram vontade e força para criar nosso primeiro design system.

Após alguns anos sem um time dedicado, o DS enfrentou desafios significativos. Não abordaremos esses problemas neste post, mas eles fizeram nascer o time de Design System, novos processos e atualmente o Farol (novo design system do Jusbrasil).

Em 2021, quando o novo time dava seus primeiros passos, identificamos que o handoff era uma etapa que poderia consumir muito tempo na esteira de criação do DS com a qualidade que esperávamos. Foi nesse momento que percebemos que investir nessa ferramenta nos ajudaria muito na criação do Farol DS.

Hoje, em 2023, existem plugins úteis para o Figma, como o EightShapes Specs e o Tokens Studio, que podem auxiliar no processo de handoff. No entanto, para o cenário atual do Jusbrasil, o nosso modelo ainda faz mais sentido.

Neste artigo falaremos um pouco sobre o que motivou a criação da nossa ferramenta, como foi estruturada e o que aprendemos com ela até aqui.

Os problemas da etapa de handoff

Através de uma matriz CSD, o time de design system identificou alguns problemas que estavam relacionados à fase de handoff de componentes:

• A maneira como fazíamos o documento de handoff demandava alto esforço manual para escrever e reescrever tokens usados em todos os estados e variações do componente;
• O documento de handoff preenchido não tinha um padrão. Gerava dificuldades para a criação e para o consumo por parte das pessoas desenvolvedoras;
• Alta necessidade de assistência para auxiliar as pessoas desenvolvedoras na interpretação do documento final;
• Alta demanda de ajustes após o QA.

Com essas convicções na mesa, ficou claro que era necessário uma iniciativa para resolver esses problemas, especialmente dada a quantidade considerável de novos componentes que precisaríamos criar para o novo design system.

O que tínhamos como objetivo

Em primeiro lugar, buscávamos simplificar a experiência de criação e consumo do documento de handoff, inclusive para os team components no futuro.

Para alcançar isso, era essencial que o designer e o desenvolvedor estivessem na mesma página, falando a mesma linguagem, o que promoveria um melhor alinhamento com os tokens e componentes já existentes no Farol.

Além disso, nosso foco estava direcionado para garantir componentes acessíveis e minimizar a necessidade de QA, visando uma baixa quantidade de ajustes.

Nossa proposta de ferramenta de handoff

Nossa primeira proposta foi inspirada por um modelo de handoff utilizado pela Meiuca e também por muitas conversas e trocas de experiências com outros profissionais da área.

Após esse momento inicial de conversas e pesquisa de referências, era o momento de desenvolver nossa proposta, levando em consideração nossos desafios e objetivos.

Testes com os times de design e desenvolvimento

Ao longo do tempo foram criadas mais de três propostas, que foram submetidas a dezenas de testes de usabilidade com designers de produto e pessoas desenvolvedoras. Essa etapa, como qualquer teste com usuários, foi crucial para fornecer insights sobre pontos que não estavam completamente claros, tanto na fase de criação quanto na fase de consumo do documento.

Apesar de muitos ajustes e adaptações, percebemos ao longo dos testes que o novo modelo teria uma curva de aprendizado inicial, mas em seguida, apresentaria um grande potencial de melhoria de desempenho para atingir nossos objetivos. Foi então que chegamos na nossa proposta final da ferramenta de handoff e iremos apresenta-la abaixo.

Como estruturamos a nossa ferramenta de handoff

Nessa seção vamos abordar cada parte da ferramenta: do cadastro de tokens e componente à anotação de acessibilidade. Aqui não ensinaremos a usa-la; para isso, acesse nosso arquivo Figma.

Cadastro de tokens e componentes

Nossos tokens e componentes existentes foram pré-cadastrados, e sempre que algo é adicionado, editado ou depreciado no design system, o arquivo de handoff também deve ser atualizado para garantir o espelhamento.

Os tokens de espaçamento, além do cadastro inicial, também são apresentados na forma de componente visual para auxiliar na especificação na etapa de anatomia, que mostraremos mais adiante. Essa é uma parte opcional, embora acreditemos que seja de grande ajuda no processo.

Exemplos de pré-cadastrado de tokens e componentes

Anotações e propriedades CSS

Nessa etapa, foram criadas seções de anotações, divididas em dois tipos (shape e text) com as seguintes pré-definições:

• Título
• Numeração e nome do elemento
• Componente
• Motion tokens
• Propriedades CSS para shape + design tokens / ou / propriedade CSS para text + design tokens*
• Anotação extra

*Neste espaço, estabelecemos as conexões entre as propriedades CSS e os tokens relevantes para cada uma delas. Por exemplo, os tokens de border-radius já foram previamente vinculados à propriedade CSS border-radius, enquanto os tokens de cor estão associados a todos os elementos relacionados a cores, como background-color, border-color, color e fill.

Nossa folha de handoff

Esta é a folha que reúne tudo o que foi previamente cadastrado, criado e organizado. É o componente principal desta ferramenta e é usado para iniciar o processo de handoff de um componente.

Ela está estruturada da seguinte maneira:

1. Cabeçalho
Esta parte é onde preenchemos o nome do componente, a biblioteca de componentes à qual pertence (core ou team), a data da última edição, o autor, as partes que serão especificadas e o status do handoff.

2. Semântica
Essa é uma etapa preenchida em colaboração entre design, desenvolvimento e a pessoa responsável pela parte de acessibilidade. Nela prevemos quais variações o componente precisa ter e quais atributos serão importantes para os times de produto em desenvolvimento e acessibilidade.

Além disso, vocês devem ter notado que algumas propriedades têm um 🔗 e outras não. Esse é um hack criado aqui no Jusbrasil. Esse símbolo identifica, no Figma, as variants que estão diretamente espelhadas entre design e as props do código.

Esse espelhamento tem ajudado no dia a dia dos times de produto, principalmente aos desenvolvedores na hora de identificar quais variações aquele componente usa.

3. Anatomia, variações e estados
Esta parte da folha deve ser duplicada de acordo com a quantidade de variações e estados que o componente tem. Nela nós trabalhamos a parte visual do componente, informando os tokens que serão usados, se estamos usando outros componente já existente, além de anotações extras caso necessário.

Separamos este momento em: apontamentos; numeração; anotações(lateral esquerda). Quase tudo aqui já foi pré-definido, então precisamos apenas navegar entre as layers, relevar o que for preciso e editar através das variants e component select do Figma.

3.1 Anatomia
Ao final, cada etapa de anatomia terá essa aparência:

3.2 Variações e estados
Aqui é importante dizer que nós não repetimos todas as especificações informadas anteriormente no box de anatomia, mas apenas as propriedades que mudam naquela variação ou estado.

Partes como a de variações e estados podem ter essa aparência.

4. Responsividade
Aqui no Jusbrasil, nosso foco principal é web, por isso, nossos breakpoints também são tokens e temos uma parte do handoff dedicada para isso. Inclusive, o conceito de mobile-first é uma prática obrigatória no nosso processo, portanto, sempre começamos o handoff com a versão do componente para menor tela.

É nessa etapa de responsividade que informamos as mudanças nos breakpoints seguintes.

5. Acessibilidade
Essa é a etapa onde documentamos todas as necessidades que temos de acessibilidade para o componente. Ela está dividida em 3 partes:

5.1 Interação e controle
Nesta seção, informamos o comportamento esperado do componente para as interações via teclado. Aqui é importante dizer que não repetimos todas as especificações informadas anteriormente, mas sim apenas as propriedades que contém mudança.

5.2 Ordem de foco e leitor de tela
Onde definimos a ordem de navegação por tab (para itens interativos) e também a ordem para o leitor de tela.

5.3 Boas práticas de acessibilidade
É uma área mais flexível onde podemos especificar outras necessidades de acessibilidade, como por exemplo, atributos ARIA pré-fixados no componente e também os que são possíveis de serem adicionados pelos times de produto, para auxiliar na criação de interfaces acessíveis.

O que percebemos com o uso

Depois de aplicar a ferramenta no processo de mais de 40 componentes, percebemos algumas melhorias nos problemas que tínhamos anteriormente. Esses são os nosso principais aprendizados:

• Com tudo pré-definido, ficou muito mais prático especificar tokens e componentes. Isso tem garantido maior proximidade entre design e desenvolvimento, principalmente pelas associações com as propriedades CSS;
• Apesar de existir uma curva de aprendizagem para montar e consumir a folha de handoff, ao longo do tempo as coisas andaram muito mais rápido para os dois lados;
• Conseguimos perceber uma redução significativa da necessidade de suporte para desenvolvimento;
• Garantimos que os componentes passem pela acessibilidade;
• O controle de qualidade reduziu, significativamente, as demandas de ajustes.

Conclusão

Esse modelo de handoff nos ajudou muito na construção do Farol. Ao longo do tempo as coisas ficam mais práticas e consequentemente nos ajudam a atingir os objetivos que mencionamos no início deste artigo.

Olhando para o futuro, acreditamos que as variables do Figma irão evoluir, cobrir grande parte dos design tokens e consequentemente ajudar a automatizar grande parte desse processo. Como o EightShapes Specs já faz na sua versão paga.

Do nosso lado, é esperado que, em um futuro próximo, também consigamos automatizar parte do processo de relacionar tokens com propriedades CSS e componentes usados para a criação de componentes mais complexos, mas isso são cenas para os próximos capítulos. 😄

Confira o modelo de handoff de componentes já disponível na comunidade do Figma. Depois de usar, não deixe de nos contar como foi a aplicação da ferramenta no cenário de vocês. 😍

Até a próxima! 💛💚💙