oi
Manutenção da seção mobile do design system da Kyte
O Design System da Kyte era foi feito por designers que já não estavam mais na empresa, porém a maioria dos componentes já não atendia a empresa por ter sido criado de maneira extremamente complexa, e o time de design já não se sentia confortável em utilizá-los.
Pelo fato da documentação não ser clara o Design System ao invés de ser um apoio para os designers ele se tornou um gargalo. Foi ai que o time tomou a decisão de fazer uma atualização completa dele, passando desde os fundamentos até os templates de página.
O principal desafio desse projeto foi fazer uma inspeção completa nesse legado para tentar reaproveitar elementos que ainda poderiam ser úteis, conciliar a tarefa de reconstruir um design system com as demandas frenéticas do dia-a-dia de uma Startup e comunicar de forma clara as alterações para o Dev. Team para conseguir manter o repositório de componentes atualizados.
Foi essencial criar um inventário para inspecionar, catalogar e categorizar todo o material existente para separar o que seria reaproveitado e o que seria descartado. Para conseguir dar conta de todo o trabalho dividimos em Mobile e Web e criamos um backlog com todas as tarefas. A parte Mobile do DS ficou sob a minha responsabilidade. Para criar um ponte com o time de desenvolvimento, fizemos um alinhamento com os tech-leads de Front-End, e decidimos que para implementar as atualizações elegeríamos (em ordem de impacto) um componente a cada sprint para ser refatorado.
Após a construção dos novos componentes o atrito que existia no fluxo de trabalho reduziu consideravelmente, porque além de componentes mais simples de serem utilizados a lógica de nomenclatura deles facilitava muito a construção de fluxos de navegação.
Ficou claro perceber os proveitos colhidos do projeto com a diminuição do tempo de entrega de novas features e além disso o processo de manutenção e adaptação das propostas em desenvolvimento ficou mais ágil.
O principal aprendizado que obtive desse projeto é o quão importante é uma documentação detalhada e atemporal, pois o conhecimento a respeito dos processos e guidelines de uma empresa precisam estar disponíveis não só para os designers de hoje mas também os designers que ainda virão.
Uma das principais etapas desse processo foi a criação do invetário com legado, pois dessa forma obtivemos uma visão macro de todo o material que tínhamos e conseguimos dessa forma evitar retrabalho. Além disso nesse momento percebemos que haviam alguns componentes que estavam sendo utilizados em muitas telas e fluxos diferentes, inclusive em projetos que já estavam nas mãos do Dev. Team, e que qualquer mínima alteração que fizéssemos poderia quebrar o layout e talvez gerar gargalo no fluxo de desenvolvimento. Portanto decidimos seguir utilizando o legado por um tempo até os times conseguirem construir um bom buffer de tasks para diminuir os riscos da manutenção.
Para otimizar a utilização no figma fizemos a taxanomia dos componentes de modo que ficassem organizados “por pastas”, dessa forma além de facilitar a manutenção quando necessário facilitava também a utilização deles nos arquivos. Também foi necessário refazer as bibliotecas de estilos e componentes para que fizesse sentido com a nova arquitetura de informações que estávamos desenvolvendo. Esse processo foi regado a testes e iterações até chegar em um modelo ideal que fizesse sentido. Também revisamos os estilos que já haviam sido criados com o objetivo de dar mais versatilidade e liberdade na hora da criação.
Em determinado momento percebemos que a biblioteca de componentes (Storybook) que estava sendo utilizada pelos desenvolvedores estava completamente diferente do que estava sendo utilizado no Figma, então antes de prosseguir fizemos um alinhamento com os desenvolvedores para ficar na mesma página. Apresentamos todo o trabalho que estávamos fazendo e as motivações para fazer a atualização, e eles compartilharam conosco todos os componentes existentes no storybook e também nos trouxeram os design tokens já existentes para que pudéssemos reaproveitar o que dava também no figma. Eles se foram bastante solicitos e falaram que essa lacuna de documentação também os prejudicava. Após esse alinhamento ficou decidido que o tech lead iria eleger um desenvolvedor para acompanhar de perto e colaborar com a atualização e também seria responsável pela construção dos componentes em react e atualização do stotybook.
