Ano
2023
Tipo de projeto
Design System
Minha atuação
UX Design, UI Design
Reestruturando um Design System
Contexto
O Greenstone DS teve sua primeira versão desenvolvida em meados de 2018 e em 2021 passou a ter um time dedicado a sua evolução, manutenção e governança. Com uma equipe olhando exclusivamente para o DS, enxergamos a necessidade de reestruturar sua arquitetura e rever fundamentos antigos, assim como componentes e toda a parte de documentação.
Desafio
Revisar e reestruturar um Design System já em uso, com componentes e fundamentos definidos e disponíveis para uso. Neste cenário, precisaríamos estruturar uma mudança gradual e consistente, com o menor impacto possível nas aplicações que já estavam consumindo os componentes, tokens e fundamentos do Greenstone.
Solução
Foco na revisão de todos os fundamentos, que habilitariam a evolução de componentes já existentes e na criação de novos. Melhor documentação de componentes, tokens e processos, aumentando assim a adoção do Design System.
Processo
Entendendo possíveis dores e atritos da versão atual
Antes de mapear as iniciativas que iríamos trabalhar, precisávamos entender quais problemas teríamos pela frente e qual caminho adotar para uma melhor resolução dos mesmos.
Café com DS
Criamos uma cerimônia chamada Café com DS, onde batíamos um papo com Designers e Desenvolvedores sobre como utilizavam o Greenstone, o que funcionava, o que não funcionava, principais dores e sugestões. Esses papos foram importantes para que tivéssemos um ponto de partida e um objetivo mais concreto de onde queríamos chegar.
Principais dores
As principais dores eram muito mais ligadas aos fundamentos, como paletas que não atendeiam as necessidades de uso, espaçamentos confusos e falta de documentação dos componentes e boas práticas.
Revisando a paleta de cores
A paleta de cores do Greenstone era composta de 9 tons neutros, 4 tons primários, 3 tons secundários e 3 tons de feedback.
Neutrals
Os tons neutros não necessariamente se encontravam no mesmo espectro de cor, o que deixava a escala desbalanceada. A quantidade de opções também refletia inconsistência na hora do uso por conta do Paradoxo da Escolha: Quanto mais opções, mais difícil e pessoal se torna a tomada de decisão
Primary
Os tons primários eram muito próximos na escala do verde. Não possuíam contraste entre si, dificultando a aplicação e principalmente falhando nos critérios de acessibilidade.
Secondary
Por mais que existisse na paleta, praticamente não era utilizada. Salvo em casos muito específicos, os times nao tinham o hábito de aplicar os tons secundários.
Feedback
Os tons de Feedback eram bem limitados, sendo apenas uma cor para cada caso. Isso acabava limitando as possibilidades de uso e a criação de componentes específicos.
Solução
Revisão dos tons
Revisamos a quantidade de variações necessárias para cada categoria, de forma que as paletas suprissem as necessidades de uso e aplicaç˜ão.
Mudança no sistema de cores
Buscando tornar a paleta acessível, experimentamos outros padrões até chegar no CIELAB/LCh, que é um sistema de cor que utiliza coordenadas tridimensionais para descrever cores de forma perceptualmente uniforme.
O CIELAB tem três componentes principais: L para luminosidade, a* e b* para posição no plano de cores.
LCH é uma versão polar de CIELAB, onde L é luminosidade, C é a saturação da cor e H é o ângulo de tonalidade.
Essas representações permitem uma descrição mais precisa e comparativa das cores em relação a modelos como RGB ou CMYK.
Taxonomia dos tokens
Contextualizando a nomenclatura
A versão atual seguia o padrão Google Material, onde a escala é definida numericamente de 0 a 100, evoluindo em múltiplos de 10. Na nova versão, ela é baseada na incisão de luz sobre a cor base, enfatizando a interação entre ambas e destacando a importância da percepção visual na seleção de cores.
Regra de contraste mínimo
Para garantir que as interfaces atendam aos critérios de acessibilidade e ofereçam uma experiência visual confortável para todos os usuários, estabelecemos um contraste mínimo de 3:1 para cada salto de 2 tons.
Essa diretriz foi cuidadosamente implementada para assegurar que, independentemente da tonalidade utilizada, o contraste entre os elementos visuais seja suficiente para garantir a legibilidade e a distinção clara entre diferentes componentes da interface.
Seguindo essa regra, conseguimos harmonizar o tom Base com tons mais claros e mais escuros de maneira que todas as combinações mantivessem a acessibilidade necessária. Esse processo não apenas contribui para uma melhor usabilidade, mas também reforça o compromisso em criar interfaces que sejam inclusivas e eficazes para um público diversificado. Além disso, a adoção desse padrão de contraste ajuda a evitar potenciais barreiras de percepção que possam surgir devido a limitações visuais, proporcionando uma experiência mais uniforme e intuitiva para todos os usuários.
Resultado final
Nesse processo, revisamos a quantidade total de tons de cada paleta, excluímos a paleta Secondary, definimos um novo sistema de cor, alteramos a taxonomia dos tokens e criamos regras claras de aplicação. Como resultado dessas mudanças, chegamos nas seguintes definições:
Neutrals
Colocamos todos os tons em um mesmo espectro, para que conversassem melhor entre si quando aplicados juntos. Reduzimos a quantidade de variantes para 7, tornando mais fácil a escolha e padronização das aplicações.
Primary
Agora com 5 variantes, a paleta Primary passa a ter tons mais contrastantes entre si, facilitando o uso entre eles e principalmente, atendendo a critérios de acessibilidade
Feedback
As paletas de Feedback agora passam a ter 3 tens cada: um base, um mais claro e um mais escuro. Isso habilita a construção de componentes com variantes mais consistentes e uma melhora na criação de diferetes status para cada tipo de mensagem. Reaproveitamos o Azul da paleta Secondary e agora ele é utilizado como Information.
Revisando outros fundamentos
Na maior parte dos fundamentos, a questão da quantidade de variantes se repetia, então refizemos esses ajustes em espaçamento, border radius, strokes, e tipografia. Também eliminamos fundamentos que já não faziam mais sentido para a construção das experiências, como por exemplo o fundamento de sombras.
Abaixo, alguns exemplos:
Spacing
Anteriormente, as variantes de tamanho não seguiam uma regra consistente de evolução, alternando entre valores como múltiplos de 2px, 4px e 8px, o que resultava em uma grande quantidade de opções.
Muitas dessas variantes apresentavam diferenças sutis, quase imperceptíveis a olho nu. Reduzimos essas opções para simplificar o processo de escolha, que anteriormente gerava um paradoxo de escolha para os Designers. Isso tornava as decisões muito subjetivas, trazendo uma série de inconsistências nas interfaces.
Solução
Como solução, reduzimos consideravelmente o número de variantes e implementamos uma progressão geométrica na evolução das variantes.
Isso permitiu que os tamanhos evoluíssem de forma mais consistente, facilitando a escolha e garantindo maior uniformidade na aplicação.
Border radius
Assim como no Spacing, aqui o problema maior era a quantidade de variantes parecidas que acabavam por trazer uma série de inconsistências na aplicação.
Solução
Reduzimos a quantidade de variantes em quase um terço e criamos uma regra de uso baseada no tamanho do elemento onde o Border radius seria aplicado.
Isso acaba facilitando a aplicação, melhorando a consistência e ajudando os Designers a tomarem decisões melhores na hora de utilizar o fundamento.
Revisando componentes
Com os fundamentos definidos, partimos para o processo de revisão e criação de componentes. Os novos fundamentos habilitaram a possibilidade de criação de novos componentes e evolução dos já existentes, gerando novas possibilidades de uso e aplicação.
Aplicações
© 2024 Victor Mota. Todos os direitos reservados.