A Jornada do Design System na Geekie

Aprendizados de um projeto partindo do zero, com lições, esforços e celebrações ao longo do caminho.

Cassio Prates de Lima
Geekie Educação
13 min readMay 14, 2024

--

Sou Cássio, designer de produto na Geekie, onde facilito equipes diversas a colaborar e criar soluções que fazem diferença na vida das pessoas, tornando visível o processo de design e apoiando outros a fazer o mesmo.

Este artigo é uma retrospectiva do nosso projeto de Design System ao longo dos anos. Não é um guia de “como fazer”, mas uma reflexão sobre nossos erros, acertos e uma fonte de inspiração para aqueles que desejam criar seus próprios sistemas de design.

Imagem baixada de Freepik.com

Aqui na Geekie, Design System não é um tema novo. Em 2020, iniciamos uma ambiciosa jornada para implementar este projeto, visando promover consistência e simplicidade em nossos produtos.

Sem um Design System definido, gastávamos tempo orientando desenvolvedores sobre detalhes como tamanho de fonte, cor e espaçamentos. Sentíamos que esse esforço não resolvia o problema, pois as inconsistências se alastravam rapidamente, já que qualquer um podia mudar a interface livremente, resultando em uma experiência de produto sempre inconsistente. Era cansativo lidar com isso.

Lições que aprendemos errando

Estávamos animados, porém, nossa primeira tentativa (que durou pouco mais de um semestre) enfrentou uma série de problemas que, somados, minaram nossos esforços, culminando rapidamente no fracasso do projeto.

Vale eu começar essa história contando sobre as principais dificuldades que enfrentamos nessa época, pois vão ser muito importantes para o que vem depois:

  1. Falta de engajamento: o projeto era conduzido de forma paralela por um grupo de pessoas aspirantes pelo tema, mas que, ao mesmo tempo, estavam dedicadas a outras prioridades do negócio. Devido ao baixo esforço possível tanto de designers quanto desenvolvedores(as), o processo ocorria de forma lenta e pouco estruturada.
  2. Dificuldade em definir as coisas: a falta de objetivos claros causava confusão para o time responsável pelo projeto, sem um bom direcionamento da energia do grupo.
  3. Falta de uso dos padrões definidos: os padrões de interface decididos muitas vezes não eram seguidos nem pelo time de design nem pela engenharia. Isso resultava em uma proliferação de diferentes padrões, levando a layouts variados para componentes com a mesma função.
  4. Confusão na finalidade de uso: a ambiguidade sobre o propósito do Design System levou a usos inadequados e poluição na biblioteca. Os squads da empresa acabavam usando as ferramentas do projeto como um ambiente para realizar testes de front-end.
  5. Adoção de ferramentas engessadas: o projeto adotou ferramentas que após o uso, foram se mostrando problemáticas, e necessitando de muitos reajustes. No caso, usávamos uma ferramenta chamada “styleguidist”, que, apesar de parecer robusta, necessitava de ajustes manuais toda vez que fosse usada nos produtos da casa.

Com todas essas dificuldades, o projeto perdeu impulso e foi eventualmente abandonado, deixando uma sensação amarga no time. Apesar do desejo de avançar, a priorização era um desafio. Nossa jornada no mundo do Design System começou com contratempos, mas aprendemos lições valiosas — a importância de um time dedicado, com metas claras e autonomia, além do engajamento de todos os envolvidos. Reconhecemos a necessidade de mais energia e uma nova abordagem para impulsionar a iniciativa, e essas reflexões nos orientaram para o futuro.

Organização e planejamento

Nossa equipe de design começou, então, a progredir com pequenos passos.

Nosso belo time de Design. Na ordem Flávia Tagata, Melissa Tsuzuki, Laís Camilo, Jéssica Pereira, Fabricio Andreotti, Cássio Prates (eu) e Otávio Gergely.

Durante esse período, Fabricio (nossa liderança de design) e eu éramos os únicos designers que haviam testemunhado a tentativa anterior de implementar o projeto. Para superar essa lacuna de conhecimento, mergulhamos na teoria, explorando artigos de especialistas internacionais em Design System, como Nathan Curtis e Marcin Treder. Outro designer da equipe, Otávio Gergely, também se dedicou a cursos sobre Design System com a Meiuca — um estúdio de produtos digitais de São Paulo com bastante conhecimento no tema.

A equipe de design estava unida para elaborar um processo de trabalho, mesmo sem o apoio da engenharia. Nosso objetivo era estabelecer uma base para que, quando o time de desenvolvimento se juntasse à iniciativa, tivéssemos o necessário para avançar sem repetir os erros do passado.

Os passos que delineamos (e continuamos a seguir até hoje) podem inspirar outras equipes que desejam iniciar seu próprio Design System. Entenda que este processo não é linear, como a maioria das coisas no design. É uma série contínua de iterações que já revisitamos algumas vezes e que estamos cientes de que também precisaremos iterar no futuro.

Etapas do projeto em design

Passo 1: Visão Geral

1.1 Propriedades da marca: domine a identidade visual da marca. Todas possuem elementos essenciais como tipografia, cores e outros elementos visuais.

Alguns dos elementos do manual de marca da Geekie

1.2 Princípios de Design: defina bem os pilares de design. Aqui, prezamos por ser referência em educação, colorido, simples, amado e intuitivo.

1.3 Inventário de componentes: lembra do problema que citei da falta de padrões definidos nos produtos? Catalogamos todos os elementos usados no produto para evitar a criação de novos padrões e promover a reutilização dos existentes.

A imagem mostra uma lista de nomes componentes numa barra lateral à esquerda (botões, avatares, checkboxes, datepickers, etc..) e à direita, o componente botão com seu tamanho grande e suas variações (selecionado, hover, ativo, foco e desabilitado).
Listamos nossos componentes e seus nomes, além de uma fotografia de como eles se comportam.

Passo 2: Organização

2.1 Arquivos no Figma — Em meio à bagunça de arquivos e tentativas de estabelecer padrões, cada designer seguia seu próprio caminho, dificultando a colaboração e a consistência. Decidimos trazer ordem a esse caos. Padronizamos a estrutura de nossos arquivos, definindo diretrizes claras. O ápice desse esforço foi o arquivo que chamamos carinhosamente de ‘Master’, onde todas as telas de nosso produto principal e sua interface real foram catalogadas. Antes dele, tínhamos uma mistura confusa de especificações finais e testes de design, causando confusão sempre que iniciávamos um novo projeto.

Com a ‘Master’, finalmente temos uma referência confiável do que está em produção.

2.2 Nomenclatura dos componentes catalogados— Com os arquivos devidamente organizados, mergulhamos no próximo desafio: a nomenclatura. Este tema pode facilmente ser subestimado, mas aprendi que é importante para a comunicação eficaz entre equipes de tecnologia e produto (e, posteriormente, para construir componentes).

Para exemplificar, considere um campo de formulário que pode ter três variações: uma para blocos de texto mais longos, outra para textos curtos e outra com opções de formatação.

Este é nosso componente de "TextField", com suas 3 variações.

Todas essas variações fazem parte do mesmo componente. Se não forem tratadas dessa forma, melhorias em uma delas não serão refletidas nas outras, o que pode levar os times a criar mais componentes diferentes com funções muito parecidas.

Essa atenção aos detalhes evita confusões e promove uma linguagem comum entre design e desenvolvimento, além de ser interessante em termos de escalabilidade e coerência no produto. Realizamos sessões práticas para mergulhar na nomenclatura, discutir padrões e colocar a mão na massa, a fim de disseminar o conhecimento entre a equipe.

2.3 Design tokens — Em seguida, organizamos as menores partes que compõem cada um dos nossos vários componentes, pensando neles como pequenas peças que serão usadas para construir cada componente. Mais adiante, abordarei os tokens de forma mais específica.

Passo 3: Desenvolvimento

Após todos esses passos em Design, o próximo passo precisava, obrigatoriamente, envolver o time de engenharia… tudo o que tínhamos feito até então foi um excelente processo de organização, mas não é um Design System de fato enquanto não envolver código.

Era agora ou nunca. Ou conseguíamos o engajamento do time de engenharia ou o projeto poderia novamente esfriar e morrer.

Parceria entre Design e Engenharia

Tivemos um grande apoio, desta vez, do nosso diretor de engenharia, Oda, que acreditou na iniciativa e destacou algumas pessoas para fortalecer o projeto:

  • O primeiro é o Leonardo Pádua, um desenvolvedor com alma de designer, que traz uma vasta experiência em Front End, um bom gosto estético e habilidades excepcionais de comunicação.
  • O segundo é o Gabriel Guilhoto, um desenvolvedor sênior com quem compartilhei desafios na criação de nosso produto para o Ensino Fundamental Anos Iniciais (e que entende profundamente como nosso produto funciona), o que fortaleceu nossa relação de confiança.
  • E por fim, a Izabela Melo, gerente de engenharia, uma líder extremamente empática, que desempenha um papel fundamental em direcionar e equilibrar os esforços da equipe.

Sou grato por ter essas pessoas como aliadas, que desempenham suas funções com excelência e são muito habilidosas no que fazem.

A importância da Acessibilidade

Acessibilidade está sendo um foco crucial para motivar tanto eu quanto o time, além de elevar nosso propósito ao construir.

Garantir que nenhum estudante seja deixado para trás, atendendo às necessidades de pessoas com limitações físicas ou socioeconômicas.

Por aqui, enfrentamos desafios diários ao priorizar este tema durante a execução, pois até então nossa abordagem era manual e pouco consistente. Com a implementação do Design System, temos a oportunidade de incorporar diretrizes de acessibilidade de forma modular em nossos produtos, como as boas práticas da WCAG. O Design System Acessível (como batizamos o projeto) foca especificamente nesse objetivo, visando tornar nossos produtos cada vez mais acessíveis.

Nossa estratégia para desenvolver o Design System

A abordagem que utilizamos para avançar no projeto junto com o time de desenvolvimento foi a mesma que utilizamos em qualquer outro projeto aqui na Geekie: entender profundamente o problema.

Começamos buscando insights de especialistas do mercado de tecnologia no Brasil que possuem experiência com Design Systems. Queríamos saber o que era essencial no projeto e quais os principais desafios enfrentados por eles. Dessa forma, poderíamos elaborar o MVP (Produto Mínimo Viável em português) e possivelmente escapar dos erros mais comuns. Essas conversas foram excelentes e já deixo aqui meu agradecimento a:

  • Thiago Kpelo, desenvolvedor e especialista no assunto que já ministrou diversas oficinas e cursos sobre o tema, além de ajudar empresas como a Loft a construirem os seus próprios Design Systems.
  • Guilherme Gonzales, designer que apoiou a Gympass a criar seu próprio Design System num momento crítico do negócio, durante a pandemia.
  • Ana Rodrigues, liderança de design da Arco, empresa que engloba a Geekie e muitas outras, que nos deram ótimos conselhos para perseguirmos um objetivo que gerasse valor no negócio.

O que vou compartilhar em seguida foram insights dessas pessoas, que nosso time aplicou (e ainda aplica) com bastante sucesso:

1. Comece pequeno

Inicie pela base, a “fundação” e as menores peças da interface, antes de criar componentes mais complexos (como botões ou dropdowns).

Inicialmente, estava ansioso para mergulhar na criação de componentes. No entanto, à medida que o tempo passava e as discussões avançavam, percebi que focar nos tokens foi a escolha mais sábia. Na Geekie, estamos constantemente refinando esses elementos fundamentais e já estamos observando os benefícios dessa abordagem, mesmo sem ter desenvolvido nenhum componente até o momento (estamos há 1 ano nos tokens).

2. Meça os resultados

A avaliação dos esforços envolve tanto métricas quantitativas quanto qualitativas. Estes dados combinados nos permitem entender tanto o impacto quantitativo quanto o valor percebido pelos usuários, orientando-nos na direção certa.

3. Pense em escala

Imagine o Design System como uma fábrica de componentes reutilizáveis para diversos produtos, não apenas para um único.

É importante pensar no projeto como um produto próprio, capaz de atender a várias necessidades e produtos diferentes. Isso, apesar de mais trabalhoso no começo, deve ser uma premissa, e pode evitar muito retrabalho no futuro. Ouvimos alguns casos de empresas grandes que, infelizmente, tiveram que reconstruir todo o Design System por não levarem esse ponto à risca.

Na Geekie, nosso Design System está sendo projetado tanto para nosso produto principal, o Geekie One (desenvolvido em React), quanto para nosso CMS (sistema de gerenciamento de conteúdo, em português) voltado para Web e utilizado pela equipe editorial. Ele também é robusto o suficiente para apoiar qualquer novo produto que a empresa decida criar.

4. Liberte-se do perfeccionismo

Um desafio comum para designers, e falo por experiência própria, é a busca pela perfeição e uniformidade em tudo que criamos. Adianto que isso não vai acontecer. Em nosso contexto de Design System, as peças criadas serão implementadas gradualmente no produto, não substituídas de uma só vez. O esforço necessário para uma substituição completa é imenso e não justificado. Já é uma grande conquista se as novas peças reduzirem o esforço necessário para construir as funcionalidades atuais. Com o tempo, essas peças substituirão gradualmente os elementos existentes no produto, até que, em algum momento no futuro, a maioria dos componentes seja consistente com o Design System.

5. Explore oportunidades de negócio

Assim como em qualquer projeto financiado, esperam-se resultados positivos. Com o Design System não é diferente. Embora pessoas desenvolvedoras e designers possam ver o valor claro, outras partes interessadas podem não entender o projeto tão bem, especialmente porque os benefícios geralmente são a longo prazo.

Como poderíamos alavancar as entregas relevantes de produto com entregas do Design System? Aqui, estamos sempre pensando em maneiras de integrar o que está sendo desenvolvido pelas equipes de melhoria de produto com o progresso do nosso Design System. O intuito é garantir que o Design System não apenas gere valor para o negócio, mas também seja testado e demonstre seus benefícios de forma simultânea.

Tangibilizando o projeto

Com os bons conselhos em mente e nossas etapas do projeto claras, começamos a construir Design System.

Após uma pesquisa feita pelos desenvolvedores Léo e Gabriel, escolhemos o Storybook como o repositório mais adequado para o nosso Design System, que é um ambiente de desenvolvimento popular que facilita a criação de interfaces e a documentação do comportamento de nossos tokens e componentes de forma simples.

Além disso, utilizamos o Style Dictionary, uma ferramenta que nos permite definir estilos uma vez e utilizá-los em qualquer plataforma ou linguagem. É assim que o Design System consegue criar estilos para diversos produtos diferentes.

Com o time de design, começamos a definir os tokens de texto, que incluem fonte, espaçamento entre letras, peso, altura de linha, tamanho e estilo. Muito da interface é texto, então vale a pena olhar com carinho para isso. Fizemos muitos testes com esses tokens para criar combinações que abarcavam as boas práticas da WCAG de acessibilidade.

A imagem mostra texto normal em tamanho grande, com uma fonte básica, peso normal, espaçamento de letras e altura de linha normais. Além disso é possível visualizar um texto em negrito e também em itálico, e suas características.
Exemplo de combinações de tokens de texto para um corpo de texto grande, com foco em acessibilidade.

Nossas combinações de tipografia (feitos juntando essas pecinhas acima) asseguram que os textos atendam a critérios de acessibilidade, como tamanho mínimo de fonte e espaçamento entre letras, facilitando a criação de textos acessíveis e consistentes.

Em paralelo, mapeamos todas as cores usadas no produto e seus contextos. Dedicamos uma atenção especial à acessibilidade e consistência, priorizando a coerência e um bom contraste nos elementos utilizados.

Vários tokens de cor com nomes genéricos que formam as combinações possíveis para cores de botão
Tokens de cor que para as possíveis cores de botão em nossos produtos

Aqui, várias cores foram unificadas e ajustadas até se tornarem tokens únicos com nomes simples. A sensação de organização ao concluir essa etapa foi imensa.

Lançamento e combinados

Depois de 5 meses de pesquisa e construção da fundação com o time de desenvolvimento, finalmente estávamos prontos para lançar a versão inicial de nosso projeto.

Realizamos um evento de lançamento com toda a equipe de produto e tecnologia da Geekie, incluindo design, engenharia, pedagogia, garantia de qualidade e gerentes de produto. Contamos a história por trás do projeto, destacando nosso propósito de trazer consistência, simplicidade e acessibilidade aos nossos produtos.

Apresentação do Design System: Desafio de garantir consistência na experiência do usuário em todos os dispositivos e segmentos da educação. Miniaturas dos apresentadores Léonardo Pádua, Gabriel Guilhoto e Cássio Lima à direita.
Um dos momentos iniciais da apresentação, onde contextualizávamos as equipes do porquê do projeto.

Apresentamos rapidamente o que é um Design System, usando uma analogia simples com uma fábrica de peças de Lego. Mostramos nossos tokens, como usá-los, e estabelecemos três compromissos simples:

  1. Utilize o Design System: incentivamos a colaboração entre equipes para promover o uso do sistema, pois isso impulsionará nossa evolução coletiva.
  2. Forneça feedback relacionado ao Design System: encorajamos todos a compartilhar feedback sobre o sistema, pois é fundamental para melhorias contínuas.
  3. Priorize a acessibilidade para melhorar a experiência de todos: reconhecemos a importância da acessibilidade e nos comprometemos a tomar decisões que melhorem a experiência de todos os usuários.

Fotografia atual e próximos passos

Medindo nossos esforços

Estamos monitorando quantitativamente a adoção dos novos tokens do Design System, analisando quantos arquivos existentes os incorporaram e quais equipes estão utilizando. Isso nos permite incentivar o engajamento e compreender melhor quem está utilizando.

Uma captura de tela do slack mostra que o time de desenvolvimento foi de 84 para 86 arquivos utilizando o Design System, e que o squad “Criação e Gestão de Atividades” foi o responsável por esse incremento, em especial um desenvolvedor com apelido de “Senaart”.
Acompanhamos semanalmente o avanço da implementação do Design System em nossos times.

Além disso, coletamos feedbacks das pessoas desenvolvedoras, como este compartilhado por Glauco, desenvolvedor de um dos times, que não apenas validam nossos esforços, mas também nos motivam a continuar.

Relato de Glauco Villas com a experiência positiva com o Design System Acessível: intuitivo, com autocomplete e fácil de usar. Economizou tempo e esforço, funcionando perfeitamente sem necessidade de modificações. O desenvolvedor sentiu grande economia de tempo e esforço!
Feedback positivo de Glauco sobre o Design System Acessível: economia de tempo e eficiência

O legal é que estes feedbacks surgiram só de disponibilizar os tokens mais básicos de nossas aplicações.

Oportunidades de negócio

Estamos atualmente concentrados em implementar o modo escuro por meio do Design System. Embora o modo escuro não seja uma novidade no mercado atual, representa um benefício significativo para nossos produtos. Além disso, do ponto de vista da acessibilidade, pode proporcionar maior conforto para estudantes que utilizam tela em ambientes escuros, assim como para pessoas com miopia e/ou baixa visão. Esta é uma excelente oportunidade de negócio e estamos empolgados para ver os resultados.

Essa iniciativa, inclusive, nos fez iterar nos tokens de cores já construídos, trazendo mais robusteza ao Design System, apoiando para que qualquer produto tenha suporte ao modo escuro.

Próximos passos

Em seguida, planejamos concluir os demais tokens como espaçamentos e ícones, para finalmente podermos desenvolver os componentes mais básicos de nossa aplicação. Além disso, queremos compreender melhor as necessidades de acessibilidade, essenciais para nossos produtos educacionais e para o futuro que acreditamos. Essas pesquisas certamente trazem o desconhecido e muita coisa pode acontecer.

Estamos avançando com passos constantes, construindo um projeto com robustez, fruto de aprendizados obtidos através de diversos desafios, pesquisas e iterações.

Pessoalmente, posso dizer que a jornada tem sido incrível, e cada um desses passos tem valido muito a pena, contribuindo para a consistência, simplicidade e acessibilidade de nossos produtos.

--

--

Cassio Prates de Lima
Geekie Educação

Hi, I'm Cássio, a designer with more than 12 years of experience working at Geekie since 2019. I empower teams to create impactful solutions in education.