País
BRasil
posição
empresa
synchro
setor
soluções fiscais
TEAM
Fui contratado pela Synchro, empresa com cerca de 30 anos no mercado e pioneira em seu segmento, passava por uma profunda transformação tecnológica, migrando seus diversos produtos para novas plataformas. Nesse cenário, já existia uma iniciativa interna para a criação de um Design System, liderada por Emerson Lemos ainda Sênior na época.
A principal barreira era a extrema a ausência de padronização entre os múltiplos produtos da Synchro, desenvolvidos em diferentes tecnologias ao longo dos anos. Isso resultava em inconsistências de UI e branding, retrabalho para as equipes de design e desenvolvimento, tudo isso impactava a experiência do usuário final.
Para este desafio, um time foi criado inicialmente liderado por Emerson Lemos e após sua saída, eu continuei tocando o projeto. Foi proposto então o "Helena Design System". O objetivo era criar uma fonte única para design e front-end, unificando a experiência do usuário e otimizando o fluxo de trabalho das equipes.
Como Product Designer na equipe do Helena DS, minha responsabilidade principal foi atuar diretamente na criação de novos componentes, definição dos padrões de design e disseminação que se tornariam a base dos mais de 20 produtos da Synchro.
Logo na minha chegada ao time estava acontecento uma fase de Discovery para entender a viabilidade de implementação, havia uma auditoria visual nos diversos produtos da Synchro, que confirmou uma acentuada inconsistência de UI e branding. Em paralelo, ao lado de Rodolfo Medeiros realizei entrevistas com alguns stakeholders (gestores, desenvolvedores, designers e analistas funcionais) que revelaram dores críticas, como a falta de padrões, o constante retrabalho e a necessidade por mais agilidade e componentes reutilizáveis. Esse benchmarking confirmou as hipoteses levantadas anteriormente, assim fortificando ainda mais a necessidade de uma estrutura única.
Esse processo incluiu também a identificação dos principais perfis internos que consumiriam o produto e um benchmarking de mercado para direcionar a estrutura do sistema.
Depois de me juntar ao time, uma das primeiras ações foi entender quais eram as iniciativas internas de pesquisas e entender a estrutura que os meus companheiros haviam iniciado. Isso me possibilitou entender a magnitude do desafio e aprender mais sobre as particularidades da organização e de seus times.
Alguns dos questionamentos principais com os stakeholders foram:
1. Quais são e quantos são os produtos oferecidos pela organização?
2. Quais e onde estão as inconsistências ligadas a identidade da empresa?
2. Existem componentes que se repetem em todos os produtos? Sua funcionalidade se repete?
3. Quais são as principais reclamações dos usuários quando falamos do uso dos produtos synchro?
Com a visão e idealização do Helena Design System liderada por Emerson Lemos, eu e Rodolfo Medeiros nos dedicamos ativamente ao suporte e execução de todo o seu desenvolvimento. Para concretizar o sistema, nossa equipe definiu um conjunto de ferramentas estratégicas: o Figma foi a plataforma escolhida para a criação e organização de todos os componentes e Design Tokens, a metodologia escolhida foi o Atomic Design, o zeroheight para documentação dos padrões e componentes, já o time de desenvolvimento optou por React, utilizando o Gitlab como repositório oficial da empresa para versionamento do código.
DEFINIÇÃO DO ROADMAP
Para guiar o desenvolvimento, foi criado um calendário trimestral com foco em garantir a previsibilidade e todo o escopo do projeto. Isso nos ajudou a priorizar a criação de tokens e componentes essenciais, definir o versionamento do sistema em conjunto com os desenvolvedores, e a estabelecer cerimônias ágeis para manter a equipe sincronizada e as entregas previsíveis."
O nome 'Helena' para o nosso Design System foi inspirado na deusa grega, buscando simbolizar a harmonia e a ordem que almejávamos. O 'nascimento' do Helena DS não ocorreu em um único evento, mas sim com o início efetivo da sua construção. Emerson Lemos deu o pontapé inicial, concentrando-se na padronização dos fundamentos: cores, tipografia e espaçamentos. A partir dessa base sólida, eu atuei no apoio e na criação progressiva dos componentes, tendo sempre o Atomic Design como metodologia central para garantir uma arquitetura coesa, consistente e escalável. Em paralelo a essa evolução dos componentes, iniciamos também a estruturação da documentação no zeroheight, registrando os padrões desde cedo.
Nesse processo prezamos sempre por:
Colaboração em tempo real: permite que os membros da equipe trabalhem juntos no mesmo documento ao mesmo tempo, o que pode ser muito útil para revisar e ajustar rapidamente os componentes do Design System.
Versões: o Figma armazena automaticamente versões anteriores dos arquivos, o que permite reverter facilmente quaisquer alterações indesejadas ou fazer comparações entre versões.
Compartilhamento fácil: o Figma permite compartilhar facilmente os arquivos com outras pessoas, mesmo que elas não tenham uma conta. Isso pode ser útil para permitir que outras equipes ou stakeholders visualizem e comentem os componentes do Design System.
Para a construção da nossa biblioteca de componentes no Helena Design System, adotamos o Atomic Design como metodologia central, nossa verdadeira 'esteira' de produção no Figma. Essa abordagem nos permitiu criar de forma estruturada e escalável:
Identificação dos Átomos: O ponto de partida foi a definição dos nossos elementos mais fundamentais – os 'átomos'. No contexto do Helena DS, isso incluiu nossas paletas de cores, as escalas tipográficas (nossos Design Tokens essenciais) e outros micro-componentes e estilos base que serviriam de alicerce.
Composição de Moléculas e Organismos: Com os átomos estabelecidos, passamos a combiná-los para formar 'moléculas' – componentes simples e funcionais, como botões, campos de input e outros controles de interface. Essas moléculas, por sua vez, eram agrupadas e organizadas para construir 'organismos' mais complexos e reutilizáveis, como cards, tabelas, cabeçalhos e outras seções de interface.
Composição de Moléculas e Organismos: Com os átomos estabelecidos, passamos a combiná-los para formar 'moléculas' – componentes simples e funcionais, como botões, campos de input e outros controles de interface. Essas moléculas, por sua vez, eram agrupadas e organizadas para construir 'organismos' mais complexos e reutilizáveis, como cards, tabelas, cabeçalhos e outras seções de interface.
Analisamos algumas ferramentas do mercado que permitem a construção de documentações online voltadas para o desenvolvimento de Design Systems. São várias as alternativas que o mercado oferece, mas diante do contexto da empresa, o zeroheight foi a solução escolhida.
O desenvolvimento do Helena Design System foi uma experiência de grande aprendizado. Destaco alguns pontos principais:
Desafio da Cultura de Design: Contribuir para a criação de um Design System em uma organização que estava amadurecendo sua cultura de design ao lado de ótimos parceiros foi desafiador, mas essencial. Exigiu muita comunicação, alinhamento e demonstração de valor contínua para fomentar a adoção.
O Poder do Atomic Design na Prática: A aplicação da metodologia Atomic Design desde a concepção dos componentes se provou fundamental. Ela nos proporcionou a clareza e a estrutura necessárias para construir uma biblioteca coesa, escalável e de fácil manutenção.
Padronizamos visualmente 28 módulos (produtos) mantido por 8 times de produto. Antes cada time de produto trabalhava por conta própria e a padronização dependia de conversas individuais;
Reduzimos para o intervalo de 1 a 3 dias o tempo necessário para correções de bugs ligados a componentes utilizados pelos times de produto.
Uso do design system pelo time (desenvolvedores, designers e produtos).
O processo de organização, contribuição e controle de issues nos repositórios foi reaproveitado por outros setores na empresa .
Apesar de todo o impacto positivo, ainda há muito a ser feito:
Expandir a Cultura de Contribuição: Fortalecer e ampliar as iniciativas para engajar toda a empresa na cultura de contribuição ao Design System, esse processo deve ter participação de todos do time, afinal não se constroi só.
Expandir a Documentação: Tornar a documentação mais acessível e didática, especialmente para facilitar a integração e o uso do sistema por novos desenvolvedores.
