olist
Published in

olist

Design System guiado pela documentação

Por que escolhemos usar uma ferramenta própria para documentar nossas decisões de design no olist.

Ilustração de uma página web com duas figuras no centro, representando regras do que fazer, em verde, e o que não fazer, em vermelho.

Se você trabalha em um empresa que utiliza ou consome algum Design System, deve ouvir bastante falar em documentação. Parece ser senso comum que documentar é essencial para a operação de design. Mas por quê? Em um ambiente de startup, em que tudo muda rapidamente e radicalmente, não parece provável que vamos priorizar criar e manter uma documentação sobre padrões de design. Foi o que eu pensei quando entrei no olist, porém a realidade é um pouco diferente disso.

Voltando um pouco atrás, quando o time de design era menor, essa era a mentalidade. Em 2018, com cerca de 4 designers, foi criada a primeira versão do Design System, o united. Ele era composto de uma biblioteca de componentes em React (linguagem de programação web) e uma biblioteca de design no Figma. Na época, a quantidade de produtos era menor, assim como o time, por isso era fácil de manter a consistência da experiência. Afinal, para qualquer dúvida que surgia, a solução era reunir os designers da empresa em uma conversa informal e tomar uma decisão sobre qual caminho seguir. E assim foi crescendo. As bibliotecas tinham cada vez mais componentes e o time cada vez mais designers.

Em 2020, os designers foram divididos em times multidisciplinares (squads), que eram responsáveis cada uma por uma parte da jornada dos lojistas. Pouco a pouco, a biblioteca de componentes passou a não ser mais suficiente para garantir unidade das experiências. Os poucos designers que estavam há mais tempo na empresa detinham o conhecimento sobre as muitas regras de uso do Design System. Conforme mais aplicações iam surgindo, essas regras iam se perdendo e logo ficou difícil de saber qual dos vários padrões era o padrão correto.

Foi na metade de 2021 que o primeiro time dedicado a cuidar do Design System foi formado no olist, eu faço parte desse time. O time era composto por 3 desenvolvedores front-end e 1 designer de produto. Sem ter o histórico da empresa, nós começamos um processo de descoberta para entender e priorizar os próximos passos. Rodamos uma pesquisa quantitativa entre os envolvidos com tecnologia e design e tivemos várias conversas qualitativas com algumas pessoas chave.

Não é surpresa que consistência e documentação apareceram como maiores dores nas entrevistas. Essas necessidades eram totalmente coerentes com o momento da empresa, pois conforme os times foram crescendo, era esperado que os processos evoluíssem junto a eles. A criação de um Design System ajudou nessa evolução.

Um Design System (ou a articulação dele) é uma ferramenta que espalha entendimento compartilhado de forma assíncrona. — Nikolas Klein

Ou seja, a documentação sobre as decisões de design é uma forma de sair de um conhecimento retido por alguns indivíduos para um conhecimento coletivo, diminuindo quantidade reuniões de alinhamento e aumentando a consistência dos produtos.

Gráfico circular apontando para as palavras chaves sobre as maiores dores dos usuários nas pesquisas.

Com isso em mente, começamos a estudar ferramentas e entender quais eram as possibilidades de documentação que melhor atenderiam nossas necessidades. Levamos em consideração os seguintes critérios:

  • Velocidade: em quanto tempo conseguiríamos lançar a primeira versão da documentação?
  • Customização: conseguimos personalizar o site, deixá-lo com a nossa identidade?
  • Acessibilidade: uma pessoa com deficiência consegue consumir a documentação?
  • Manutenção do conteúdo: somente uma pessoa especializada conseguiria adicionar conteúdo à documentação ou qualquer uma do time poderia fazer isso?
  • Autonomia: temos domínio da informação que está na documentação, podendo exportar esses dados para outra plataforma se necessário?
  • Valor: a ferramenta é paga? Qual o valor?

Usando esses critérios, avaliamos algumas soluções possíveis para nossa documentação, como utilizar ferramentas já conhecidas no mercado para Design Systems (Storybook, Zeroheight, Docz) ou soluções menos óbvias, como criar a ferramenta do zero. Após a análise, a solução que parecia melhor atender às nossas necessidades foi usar a combinação de uma ferramenta de Gestão de Conteúdo (CMS) com uma interface desenvolvida pelo time. Enquanto o CMS nos auxiliou com a oferta de uma interface já pronta que permite a criação de templates de páginas e adição de conteúdo sem necessitar de desenvolvimento, parecido com um blog, o front próprio possibilitou total controle sobre a identidade do site, responsividade e acessibilidade.

Mesmo tendo escolhido uma combinação de ferramentas que atendia às nossas necessidades, essa escolha só foi validada após a realização de uma prova de conceito (POC). Criamos uma primeira versão do site para entender o tempo e esforço de desenvolvimento real da documentação usando-as.

Print da prova de conceito da documentação. O site possui logo em azul no topo, um menu lateral e um texto de marcação no centro.
Prova de conceito da documentação

Feito isso, começamos a trabalhar mais em cima desta documentação e a evoluí-la gradualmente. Em pouco tempo a documentação começou a crescer e já assumir uma cara de um Design System, mesmo antes de ter os primeiros componentes. Hoje o nosso site já conta com atalhos para acessibilidade, versionamento e troca de temas.

Gravação da documentação do design system. Começa na página inicial do site, depois entra em tokens de cor. Dentro dessa página, o idioma do site é alterado para inglês e depois o tema é alterado para laranja.
Documentação em fevereiro de 2022

Mesmo sem ter muitos componentes no nosso Design System, já conseguimos entregar valor de outras maneiras:

  • Mostrar que é possível criar interfaces responsivas e minimamente acessíveis desde o MVP (Mínimo Produto Viável);
  • Definir uma fonte de verdade para as definições de design;
  • Expor não só o que existe no Design System, mas como e quando aplicar estes elementos;

Ainda estamos construindo nosso Design System e ter escolhido priorizar a documentação desde a fase inicial foi uma decisão muito rica para o time. Conseguimos trazer valor desde as primeiras decisões de design que padronizamos e ainda servir de vitrine do que defendemos e ensinamos.

Por fim, nunca é demais reforçar que o caminho tomado pelo time do olist não necessariamente reflete as necessidades de outras empresas. Por isso é tão importante o processo de pesquisa e o entendimento das pessoas antes de começar a construção de qualquer produto.

👉 Quer fazer parte de um dos melhores times de design do Brasil? Estamos com diversas vagas abertas no olist, candidate-se em olist.gupy.io

--

--

Bastidores da cultura e processos de trabalho do #teamOlist.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Luisa Scaletsky

Designer de produto trabalhando há cerca de 5 anos com design digital. Meu foco hoje é em ajudar as empresas a escalar design através de Design Systems.