Hefesto Design System
Sobre o projeto
O Design System, batizado com o mesmo nome do deus grego da metalurgia, foi criado para ser acessível, escalável e criar consistência através de produtos da empresa Gerdau.
O Problema
Os produtos dentro da empresa possuem cada um sua própria linguagem visual e usabilidade, gerando inconsistências e criando fricção e uma curva de aprendizado maior para o usuário que utiliza mais de uma ferramenta.
O Desafio
Criar um Design System que, como produto, atenda as necessidades de diferentes ferramentas, projetos e squads, além de:
• ser escalável;
• ser reutilizável;
• ser acessível.
O Processo
Devido a falta de dados de uso, como por exemplo, quais plataformas e como os usuários acessam os produtos, decidi seguir padrões de mercado e regras de usabilidade e design estabelecidas.
De acordo com o site Statcounter, quase 90% dos usuários no Brasil utilizam a plataforma Android em dispositivos móveis, e Windows em plataformas desktop. Assim, o Design System teve como base o Material Design (versão 2) da Google, e o Fluent Design System, da Microsoft. Outras linguagens de Design também utilizadas no estudo foram a Human Interface, da Apple, e a do Ant Design.
A base para a construção dos layouts utiliza os padrões de grid e breakpoints do Bootstrap.
Outro ponto importante foi trazer desde o começo desse projeto as regras de acessibilidade de acordo com a WCAG.
As ferramentas
Para a criação dos componentes, utilizei o Figma, pela facilidade em distribuir uma biblioteca que pode ser utilizada em diversos projetos.
Para a documentação, a plataforma escolhida foi a Zeroheight.
A biblioteca
A primeira ação para a criação da biblioteca foi capturar telas de algumas das ferramentas dentro da empresa. A partir daí, fiz um levantamento de componentes utilizados, que serviu como lista para o desenho dos componentes da biblioteca.
A segunda ação foi buscar no manual de marca quais as cores e famílias de fontes utilizadas; essas cores foram desdobradas em três paletas: primárias, secundárias e apoio.
Para as fontes, usei um teste de acessibilidade para definir se há uma diferença clara entre os caracteres I (i maiúsculo), l (L minúsculo) e 1 (um). Como as fontes utilizadas no manual de marca não passaram o teste, selecionei duas fontes do Google que atendem os requisitos. Também defini nessa etapa os pesos permitidos para uso nas interfaces, eliminando principalmente a versão light dessas fontes.
Com as paletas e textos definidos, o próximo passo foi definir as cores de superfícies e componentes, utilizando testes de contraste para garantir a acessibilidade dos componentes, tanto no modo claro quanto no modo escuro.
E, com as cores definidas, foram criados os componentes para as plataformas móveis e desktop. Para facilitar o uso pelos Designers ao montarem protótipos, defini as variações possíveis de cada componente, utilizando as funções de variantes e grupos de componentes do Figma, criando assim, uma biblioteca mais enxuta.
A documentação
A documentação foi criada pensando em atender não só os Designers e Desenvolvedores que utilizam o Hefesto, mas também Product Owners, Stakeholders e quaisquer outras pessoas interessadas em entender as regras e diretrizes do Design System.
Por isso, a documentação contém seções direcionadas a boas práticas de usabilidade, acessibilidade, e mais.
Para cada componente, a documentação mostra como construir, as regras de uso, exemplos e o código em React. Assim, temos tudo o que é necessário para projetos que têm a necessidade de criar componentes de time.
A flexibilização
Para que a biblioteca seja flexível e atenda as necessidades de cada projeto, dividi os componentes em duas categorias:
• Componentes CORE - são os componentes que devem ser utilizados da forma que foram construídos, e não podem se visualmente modificados.
• Componentes TEAM - são os componentes flexíveis, que podem ser modificados, mas devem considerar as regras de usabilidade e acessibilidade. Visualmente, devem utilizar as paletas de cores e tipografia definidas no Design System.
A distribuição
Como dito antes, a biblioteca é distribuída para os times através do Figma. A documentação serve como suporte durante a construção dos protótipos dos projetos.
Como parte da estratégia de flexibilização, no início do projeto o Product Owner pode escolher entre três opções de uso:
• Adotar, utilizando os componentes CORE e TEAM da biblioteca, e o código em React;
• Adaptar, utilizando os componentes CORE, com o código em React, e criando os componentes TEAM (de acordo com as regras da documentação e as necessidades do projeto) e o código em React;
• Criar, aonde somente a documentação é utilizada para manter a consistência e usabilidade dos componentes, além de garantir que os produtos sejam acessíveis. Nesse caso, o código pode ser criado ou em React, ou em outra linguagem que se adapte ao projeto.
Cada uma dessas opções tem, obviamente, um custo e tempo diferenciado - por exemplo, se o projeto decide seguir com a opção de adotar, não vai gastar horas criando código ou componentes; já a opção de criar vai demandar um custo maior.
Também há o suporte aos projetos, em que eu, como Design Lead, faço um onboarding explicando como utilizar a biblioteca e a documentação, acompanho o projeto e recebo feedback de uso da biblioteca e dos componentes. Opcionalmente, ofereço também webinars sobre design e acessibilidade.
