Visão Geral
Vetor é uma grandeza física, que possui magnitude, direção e sentido. Assim como um Design System deve ser complexo, escalável e objetivo. Por isso, o nome Vetor. Que além de estar relacionado a energia, direciona e demonstra o nível de trabalho necessário. Assim como um Design System direciona e restringe práticas e definições, otimizando o trabalho e tirando o máximo de entrega nas tarefas.
Problema e Objetivo
A dor partiu das inconsistências entre os projetos, e o tempo gasto em criar componentes em cada projeto. Dessa forma o Vetor seria uma solução para Designers e Desenvolvedores focarem em inovação e solução de problemas de forma mais assertiva.
Inicialmente esperamos ter ganho de tempo e qualidade de entrega. E dessa forma alocar melhor as pessoas do time.
Como ponto de partida, realizei uma pesquisa exploratória, com objetivo de entender as boas práticas de mercado e documentar tudo o que poderia ser usado ou não no nosso Design System.
Paralelamente, estruturei uma rodada de entrevistas com os desenvolvedores do time, para entender melhor os fluxos de cada um e levantar o valor da proposta. Feita a pesquisa inicial. Decidi adotar duas metodologias que guiariam o desenvolvimento e ajudariam a tomar as decisões de design previamente.
A primeira definição é sobre o uso de containers dentro do Figma. Essa premissa, surgiu dos projetos já criados, e foi uma dor identificada para construir componentes e telas de forma flexível.
A segunda seria o uso do método de snowflakes para componentes que não eram recorrentes. Dando mais autonomia para o time e tornando o Design System mais eficiente
A segunda seria o uso do método de snowflakes para componentes que não eram recorrentes. Dando mais autonomia para o time e tornando o Design System mais eficiente
Ideação
Nessa etapa, realizei algumas rodadas de definição técnica com o time. Com o objetivo de definir linguagens, repositórios, frameworks, uso de bibliotecas existentes e nomenclaturas.
Decidimos não usar nenhuma biblioteca para construir os componentes. Porém utilizamos a iconografia da Microsoft (Fluent Iconography) por sua versatilidade, e possibilidade de personalização. E iriamos usar o Storybook como plataforma de documentação.
Decidimos não usar nenhuma biblioteca para construir os componentes. Porém utilizamos a iconografia da Microsoft (Fluent Iconography) por sua versatilidade, e possibilidade de personalização. E iriamos usar o Storybook como plataforma de documentação.
O Primeiro passo após essas definições foi construir o fluxo de trabalho. Pensando em como as demandas entrariam na esteira e quais as condicionais.
O próximo passo, foi definir os aspectos visuais do Vetor. Para essa tarefa, mergulhei no manual de marca já com uma tarefa grande de trabalhar as cores de forma acessível. A marca possui cores e contrastes com uma matiz muito saturada, isso torna a legibilidade de textos e elementos um desafio para pessoas neuroatípicas e com deficiência.
Depois de muitos testes, construi uma paleta de cores acessíveis e que mantinham a essência da marca. Nessa etapa também definimos As nossas tipografias, unidades de medida e nomenclatura dos tokens.
Como último passo antes da criação, conduzi rodadas para identificar os componentes mais usados e requisitados junto aos Desenvolvedores e Designers. Assim, ficou mais claro o nosso cronograma e quais componentes priorizar.
Criação
Para facilitar a criação e manter a consistência criei dois checklists que auxiliariam na construção dos componentes. Esses documentos seriam as diretrizes das nossas decisões visuais.
A partir desse ponto, comecei a criar os tokens de referência e de fundação. Que seriam a base dos nossos componentes, já com a nomenclatura escolhida pelo time.
A partir desse ponto, a base para a criação dos componentes já estava feita dentro Figma. Começamos a seguir o cronograma de componentes, construído de forma bem sincronizada e conjunta.
Adotamos duas etapas de validação do componente. Uma onde os designer testavam o componente em uma área de playground, e outra onde a pessoa QA testa em ambiente de homologação. Nas duas validações consideramos os critérios de acessibilidade e consistência com os parâmetros do Vetor.
Seguimos um padrão de documentação dentro do Figma, para deixar mais transparente a todos os envolvidos no projeto.
Conclusão
Com a lista de componentes criada no Figma, e os componentes codificados na biblioteca. Rodamos um teste de desenvolvimento com dois Designer e dois Desenvolvedores Front-end. O Objetivo era medir o tempo de execução das tarefas e o ruído de consistência dos componentes entre os produtos.
No final do teste, descobrimos que os Designers e Desenvolvedores, executavam as tarefas de construção de tela com menos que a metade do tempo que levavam sem o Design System.
Com esse projeto implementado, foi possível defender maior alocação de profissionais no projeto. Uma vez que os custos seriam reduzidos com os horas de cada profissional. E claro, deixar que cada profissional foque em inovação, negócio e solução de problemas facilitando a construção dos produtos do dia a dia.