A evolução do design system do Grupo SBF durante 1 ano

Introdução

Neste artigo irei relatar minha experiência de um ano (2022 a 2023) aprimorando o Motriz, um design system whitelabel multimarca e multiplataforma que atende aos produtos digitais do Grupo SBF, holding responsável pelo maior ecossistema do esporte do Brasil.

Meu desafio consiste em evoluir esse design system em um time composto por apenas 3 pessoas, visando estabelecer uma experiência unificada que permita a escalabilidade e alinhamento com os objetivos estratégicos do negócio.

Imagem 1: Alguns componentes e estilos disponíveis no Motriz Design System.

Uma breve explicação sobre design systems

Um design system é uma coleção de componentes reutilizáveis, guiados por padrões claros, que podem ser montados juntos para construir qualquer número de aplicações. Os design systems viabilizam a criação de produtos melhores com mais rapidez, tornando o design reutilizável, e a reutilização possibilita a escala.

"Design System não é um projeto, é um produto servindo outros produtos."
- Nathan Curtis, EightShapes

É importante considerar que um design system tem 3 grupos de usuários: os designers, que criam as interfaces dos produtos utilizando os componentes desenhados; os engenheiros de software, que desenvolvem essas interfaces utilizando os componentes pré-codados; e os usuários finais (clientes das marcas), que usam estes produtos no dia a dia. Neste artigo, quando uso o termo usuários, me refiro ao grupo de usuários designers.

Contexto

Histórico

O design system do grupo SBF teve sua primeira versão implementada antes da minha entrada no time, e foi projetado inicialmente para atender a Centauro, marca principal do grupo, e a Nike do Brasil (Fisia), recém adquirida pelo grupo na época. Os componentes e estilos foram desenvolvidos contemplando o visual e experiência para estas duas marcas.

Com o passar do tempo, o grupo cresceu e adquiriu novas marcas como NWB, FitDance, Studio78, OneFan e Spoint. Esse crescimento gerou a necessidade de adaptar o sistema para que atendesse também a essas marcas, de forma a facilitar a escalabilidade e estabelecer uma consistência para o ecossistema da empresa. Minha chegada no time ocorreu no exato momento em que esta adaptação estava sendo colocada em prática.

Imagem 2: Ecossistema do Motriz em 2022.

Composição do time

Inicialmente a estrutura do time de design system contava com 5 pessoas: 2 product designers, 3 desenvolvedores web e 1 product manager. Tínhamos uma sinergia incrível e muitas ideias para aprimorar o produto.

Porém, 4 meses depois (após o lançamento do MVP), o time foi reduzido a apenas 3 membros: 1 product designer (eu), 1 desenvolvedor web e 1 desenvolvedor app atuando somente part-time, e essa segue sendo nossa estrutura atual.

Imagem 3: Estrutura do time de DS.

Experiência dos usuários

Para compreender o contexto do design system e suas implicações na empresa conduzi entrevistas com product designers e líderes de design. Com isso, pude diagnosticar dores e necessidades dos usuários e entender suas experiências com o sistema.

Identifiquei uma insatisfação significativa e pouca adoção do design system, além dos seguintes pontos de dor:

• Distanciamento do time de DS.

• Poucas variações e estados dos componentes e difícil personalização dos mesmos.

• Dificuldade de entender certos processos, por exemplo, o que fazer quando o componente desejado não existe.

• Falta de comunicação sobre mudanças e atualizações no design system.

• Documentação desorganizada e defasada.

Estabelecemos o aumento da satisfação e adoção e a resolução dos pontos de dor como os principais OKRs para 2023.

Lançamento do MVP

O MVP do Motriz foi lançado em janeiro de 2023, contemplando 6 componentes: botão, tipografia, hiperlink, label e text input. Estes componentes foram disponibilizados inicialmente apenas na versão web/web mobile (react), e posteriormente desenvolvidos para app (flutter).

O processo de design envolveu desenhar os componentes inicialmente com visual genérico, refinar com os desenvolvedores para avaliar a viabilidade técnica e posteriormente customizar cada um dos componentes para atender as marcas do Grupo SBF, que na época eram compostas por Centauro, Nike, NWB e GrupoSBF (produtos internos).

Mais informações sobre o processo utilizado podem ser encontradas neste artigo, escrito por Mateus de Paula, meu colega de time na época.

Vídeo de lançamento do MVP do DS Motriz. Edição por Mateus de Paula.

MVP da documentação

Em paralelo, lançamos nossa primeira versão da documentação do Motriz, com o objetivo de centralizar nossa fonte única da verdade e tornar o material do DS mais acessível para stakeholders e outros usuários que não possuíam familiaridade com o Figma, ferramenta onde os componentes eram documentados inicialmente.

Escolhemos o zeroheight por conta da ferramenta possuir um CMS onde poderíamos criar, editar e excluir páginas sem necessidade de código, tornando mais fácil o trabalho de inserir e atualizar o conteúdo. Além disso, havia a possibilidade de sincronização com as principais ferramentas usadas pelo time, como Figma e Storybook, e ótimos templates.

Imagem 4: Screenshots das páginas Início, Como usar e Cores na primeira versão da documentação, feita no zeroheight.

Imagem 5: Screenshot da comunicação sobre o lançamento da MVP da documentação.

Manutenção das bibliotecas de componentes

Uma das maiores queixas dos usuários era a quantidade excessiva de bibliotecas do Figma. Por exemplo, um designer que trabalhava na tribo Centauro precisava ativar até 4 bibliotecas, de forma manual, para acessar o material necessário para a construção dos seus protótipos.

A composição das bibliotecas por marca era a seguinte:

• 1 biblioteca de componentes web (onde eram documentados componentes em versão desktop).

• 1 biblioteca de componentes mobile (onde eram documentados componentes em versão mobile/app).

• 1 biblioteca de variáveis da marca (onde eram documentados os design tokens da marca).

• 1 biblioteca de variáveis globais (onde eram documentados os design tokens globais).

Para resolver o problema, unifiquei as bibliotecas de web e mobile com as bibliotecas de variáveis globais e de marca, reduzindo para apenas 2 bibliotecas por marca (CORE e TEAM components), e de 14 para 8 bibliotecas no total.

Com essa alteração, tivemos uma melhoria na encontrabilidade dos componentes e estilos por marca e eliminamos a necessidade de ativação manual das bibliotecas (e, com isso, o risco de usar componentes incorretos). Também foi criada uma biblioteca dedicada à facilitar a colaboração mais direta por parte dos usuários - a TEAM Components.

Por fim, a manutenção das bibliotecas também ficou mais sustentável, pois o time havia sido reduzido e eu estava atuando como a única product designer.

Imagem 6: Screenshot da apresentação da alteração das bibliotecas para o time, mostrando o antes e depois.

CORE X TEAM Components

Core Components é a biblioteca primária do DS, que contém os componentes whitelabel customizados para marca. Apenas o time de DS pode contribuir com ela.

Team Components é a biblioteca secundária do DS, e contém componentes criados para satisfazer a necessidade de um time, sendo exclusivos de uma unidade de negócio. Todos podem contribuir com ela. Esta biblioteca foi criada pensando em otimizar o processo de colaboração com os usuários. Quando o usuário precisa de um componente que não existe na biblioteca principal da marca, ele pode construir e documentar o componente na biblioteca TEAM (se o componente tiver potencial de ser usado em outros projetos da mesma marca). A centralização em uma única biblioteca é importante para evitar a redundância da criação de componentes.

Imagem 7: Demonstração de como os componentes são distribuídos nas bibliotecas de cada marca.

Design Systems prosperam
com colaboração

A colaboração é fundamental para o sucesso de Design Systems. Como cada usuário tem skills específicas, conseguimos reunir habilidades diversas e estimular a troca de ideias e perspectivas, promovendo o aprendizado contínuo e garantindo a participação ativa de times multidisciplinares na evolução do produto.

A parceria com os desenvolvedores e product & content designers foi adotada desde cedo e se tornou mais importante ainda quando o time ficou mais enxuto. Essa iniciativa tem sido essencial desde então para garantir que consigamos entregar os resultados esperados.

Para aprimorar o processo de colaboração, foi essencial estabelecer três principais iniciativas: a flexibilização do processo de contribuição, critiques de novos componentes e inclusão das diretrizes de content design na documentação, que detalharei abaixo.

Imagem 8: Meme sobre colaboração dos usuários designers para o DS.

1. Flexibilização do processo de contribuição

Anteriormente, se um usuário precisava de um componente não presente no Design System, ele precisava solicitá-lo ao time e aguardar que fosse construído (o que poderia levar um tempo considerável). Ao refazer o processo de colaboração estabelecendo a iniciativa de Team Components (mencionado no tópico anterior), permiti maior liberdade aos usuários para contribuirem com componentes ao design system.

Imagem 9: Workflow de contribuição ao design system.

2. Critiques e refinamentos de componentes

Outro passo importante foi envolver os usuários nas etapas iniciais da criação de novos componentes CORE.

Ao terminar de prototipar e qualquer novo componente, eu convido-os para uma sessão de critique para apresentar o componente: seu contexto e necessidade, a ideia desenhada e personalizada para cada marca, suas variações de estados (normal, hover, pressionado, etc) e exemplos de aplicações nos produtos das marcas.

Com isso, é possível validar o visual e funcionalidade do componente, coletar percepções e ajustar o que for necessário para atender às necessidades de cada time.

3. Inclusão das diretrizes de content design na documentação

No Grupo SBF temos um time dedicado à disciplina Content Design, que é responsável por definir as diretrizes de escrita e guias de tom e voz para as marcas. Estes guias estavam sendo desenvolvidos, porém não havia sido pensado em como distribuí-los.

Pensando em disponibilizar esses guias para os usuários, atuei em parceria com o time de Content para desenvolver uma estratégia para trazer o material para nossa documentação de Design System.

O processo, que envolveu critiques com usuários utilizando o método de card sorting, nos proporcionou entender como melhor organizar o conteúdo e a arquitetura da informação de forma clara e sem atritos.

Imagem 10: Exemplo de critique do componente “Tag”, com informações gerais e detalhamento de todos os estados do componente. Alguns comentários dos usuários presentes.

Imagem 11: Exemplo de aplicação do componente “Tag” em produtos reais das marcas, apresentado no critique.

Após o critique com o time de design, passo para o refinamento com os desenvolvedores para avaliar a viabilidade técnica do componente e garantir que ele seja implementado de acordo com o protótipo.

Imagem 12: Documentação inicial de Content para a marca Nike.

A escolha de trazer as diretrizes de Content Design para a documentação do Design System tornou a nossa fonte da verdade ainda mais robusta, o que resultou em um aumento na satisfação dos usuários designers e maior sinergia entre as áreas de Content e DS.

Imagem 13: Meme sobre colaboração de design system e content.

Um novo brilho para a documentação

Com o passar do tempo nossa documentação no zeroheight foi sendo atualizada com mais componentes e estilos, se tornando cada vez mais completa e útil para os usuários.

Imagem 14: Screenshot da apresentação de novidades no zeroheight.

Porém, enfrentávamos diversas limitações, pois usávamos a versão gratuita da ferramenta e não tínhamos orçamento para fazer upgrade para a versão com as features necessárias.

Com a versão gratuita era permitido apenas uma documentação, o que não era ideal, considerando que atendíamos diversas marcas com diferentes componentes e estilos. O conteúdo era separado em uma aba para cada marca, e as páginas ficavam muito extensas, pois precisávamos incluir todas as variantes do componente e diretrizes de uso em um só lugar.

Pensando em escalabilidade, a separação por abas se tornaria insustentável com o tempo. Além disso, não era possível incorporar ferramentas, como Hotjar e Google Analytics, o que nos impedia de acompanhar a performance e o uso da documentação.

Migração para o Supernova

Pesquisando por outras plataformas de documentação, encontrei o Supernova, que oferecia os mesmos serviços da versão mais avançada do zeroheight por um preço mais acessível. Após negociar a contratação com a gerência de design, iniciei o processo de migração do conteúdo do zeroheight para o Supernova.

A troca de plataforma elevou notavelmente a qualidade da nossa documentação, que agora conta com:

• Nova homepage: atalho para documentação individual de cada marca, explicação sobre estrutura, histórico, ferramentas, processos e material educacional sobre Design System, e detalhes sobre nosso processo.

• Documentação personalizada para cada marca: agora, cada marca possui uma página dedicada com todos os estilos, componentes e materiais necessários para construir os produtos digitais, além de uma homepage com atalhos para informações úteis, como "Como usar," "Como contribuir" e "Fale Conosco."

• Melhorias na arquitetura da informação: separação por abas da visualização da anatomia e variantes dos componentes das diretrizes de uso.

• Separação das guidelines de Content Design para cada marca.

• Página de checklist de acessibilidade para todos os componentes.

• Documentação de Design Tokens.

• Inclusão do Google Analytics e Hotjar.

• Possibilidade de acessar o componente do Figma e repositório do Storybook (documentação de engenharia) na página de cada componente.

Imagem 15: Homepage da documentação da Centauro, personalizada com o estilo da marca.

Além disso, a nova ferramenta facilitou o gerenciamento dos componentes a partir de uma tabela na qual é possível adicionar descrição, link do Figma, status, se já está documentado e o link para a página, link para o repositório de engenharia data de alteração. Também é possível gerenciar os design tokens, assets e fontes.

Imagem 17: Telas do app da Nike.

Impactos no negócio

Lançamento do App Nike Brasil

O uso do design system possibilitou a criação da interface e desenvolvimento do app do e-commerce da Nike Brasil, que foi lançado no final de 2023. Durante as etapas finais do projeto, atuei próxima ao time responsável pelo app auxiliando a resolver impedimentos e apoiando na adaptação dos componentes e estilos necessários.

Com isso, foi possível garantir um look & feel e experiência consistentes com as diretrizes da marca global Nike Inc., cuja aprovação era necessária para o lançamento do app.

Imagem 16: Tabela de componentes da documentação para a marca Centauro.

Lançamento do App Spoint

O app Crava, um dos produtos da empresa (e que ainda não usava o Design System) passou por um rebranding, sendo rebatizado de Spoint e ganhando um visual inédito.

O Spoint é um aplicativo que ajuda os usuários a converterem seus movimentos em benefícios. A partir da conexão com outros aplicativos esportivos, como Strava e Garmin, o Spoint identifica os registros nos apps conectados e transforma-os em pontos e benefícios exclusivos.

Com o uso dos design tokens do Motriz foi possível adaptar os componentes ao novo estilo da marca de maneira ágil, acelerando a atualização das interfaces do produto e o time-to-market. Além da alteração visual, a aplicação do design system no app garantiu diversas melhorias de usabilidade, arquitetura da informação e acessibilidade.

Imagem 18: Exemplo da tela de resgate de benefícios do app, demonstrando o antes (sem DS) e depois (com estilos e componentes do DS aplicados).

Após o redesign do app, parti para o design da nova Landing Page do produto em versão desktop e mobile. Com o uso do Design System, o tempo de prototipação foi de apenas 3h30min.

Imagem 19: Overview do protótipo em versão desktop da nova LP do Spoint, desenhado por mim no Figma.

Conclusão

Após um ano de intensa dedicação ao desenvolvimento do Motriz, reflito que não foi uma jornada fácil, mas a evolução foi notável. Conseguimos um aumento na adoção do Design System e resolver os principais pontos de dor dos usuários.

Provar o desafio do produto segue sendo um desafio constante: por mais completo que seja o material disponibilizado, muitas pessoas ainda não entendem o que é e pra que serve um design system e sentem dificuldade em usá-lo. É preciso confiar no processo e ter paciência; explicar quantas vezes for necessário, estar à disposição para apoiar os times e entender que alguns resultados só serão percebidos com o tempo.

Que em 2024 o Motriz Design System floresça ainda mas!