Como eu falhei em desenvolver um Design System
… ou não, depende do ponto de vista, me conta a sua opinião depois ler o artigo. ;)
Assim que entrei na InstaCarro me deparei com um cenário no mínimo curioso, que você provavelmente irá se relacionar: cada designer do time trabalhando as telas de maneiras completamente diferentes, nem parecia ser o mesmo produto.
Para não dizer que "era tudo mato", devo dizer que existia um styleguide bem simples que ajudava no desenvolvimento das composições, mas a organização dele e os assets que estavam disponíveis eram de outros tempos.
Foi então que o time surgiu com a ideia do meu primeiro projeto lá dentro: começar um Design System. E realmente parecia uma boa ideia, estávamos começando a desenvolver muita coisa do zero e ter uma base para tudo o que viesse em seguida seria ótimo!
E, de certa forma, foi!
O tempo era curto e precisávamos atualizar os assets do produto antes de desenvolver diversos projetos, como o redesign da plataforma de vistoriadores, logo, o nosso primeiro passo foi realizar um inventário de todos os design tokens do produto e propor as alterações. Depois disso, fomos atrás de diversos benchmarks de outros sistemas de design que inspirávamo-nos.
Novas fontes, cores de acordo com as diretrizes da WCAG, regras de espaçamento, um grid bacana, visual novo para todos os assets, tudo no caminho certo para um Design System by the book.
Mas esse artigo não é bem sobre sucesso, afinal, cases de sucesso já temos aos montes, não é mesmo?
Durante todo o processo de desenvolvimento acabei errando em vários aspectos, um deles foi não me aproximar o suficiente dos desenvolvedores, parte mais essencial para ter um design system bem implementado (me julguem).
A ideia de montar todo um sistema para o design não gira em torno só de facilitar o dia-a-dia dos designers, mas sim de fazer do design, como um todo, uma mesma linguagem em toda a empresa. E caso uma das partes não esteja 100% alinhada, o seu projeto vai estar fadado a não ver a luz do dia.
Além disso, outro problema identificado no processo foi que nós não definimos como seria a manutenção desse Design System, e hoje, só dois meses depois do desenvolvimento do projeto, já temos um arquivo obsoleto que vai precisar de alguns bons updates para contemplar os novos componentes que desenvolvemos.
Ter um plano de manutenção do seu Design System é essencial para não acabar como o styleguide do começo do artigo, esquecido em alguma pasta do drive e só sendo usado para copiar e colar componentes, é clichê, mas é sempre bom reforçar: o Design System é um ser vivo, precisa receber carinho, cuidado e ser alimentado para sobreviver.
Mesmo assim, não é como se o tempo gasto no projeto tenha sido em vão, na verdade, muito pelo contrário.
O direcionamento do Design System foi essencial para os projetos subsequentes à ele, e todo o time estava alinhado com as diretrizes. Não é também como se ele tivesse sido inútil para os desenvolvedores, eles reviram algumas coisas no código para adequar ao sistema, talvez não do jeito ideal (muito pela maneira como ocorreu o processo), mas de um jeito que funcionou para todos.
Essa foi a minha experiência começando um Design System pela primeira vez, e acredito que uma das que mais contribuiu com o meu crescimento, afinal, evoluir é sobre isso: errar, aprender e melhorar.
Tenho certeza que da próxima vez não vou cometer os mesmos erros, e por isso, convido você à também compartilhar os seus. Acredito que quanto mais histórias de "fracasso", mais aprendizado teremos uns com os outros. Pelo fim das soluções mágicas e muito mais problemas reais. ;)
Ficou alguma dúvida? Deixa aí nos comentários que a gente troca uma ideia.
