O Design System é um ecossistema de componentes programados e padrões semânticos de design, em outras palavras, é uma biblioteca de componentes reutilizáveis, que foi desenvolvida para suprir a necessidade de padronização visual de um sistema. Meus colegas de Design falaram um pouco sobre o início desse projeto no Asaas no artigo: Construindo um Design System: desafios e o que aprendemos com eles.

Neste artigo, abordarei o tema alinhado ao envolvimento do desenvolvimento Front End e para isso, é importante entendermos que o Design System é diferente de uma biblioteca de componentes. O primeiro, é um conglomerado de padrões, documentações e boas práticas, enquanto o segundo, estende esses padrões para o código. De modo geral, os dois trabalham juntos e a biblioteca de componentes geralmente é uma extensão do Design System.

Da perspectiva de Engenharia de Software, o Design System surge muito antes do código, sendo necessário pensar nele como uma ferramenta para solucionar problemas de experiência do usuário e ainda assim, garantir uma boa interface. Neste sentido, o desenvolvimento Frontend é uma das etapas necessárias para aplicar em código aquilo que foi idealizado pelo time de Design através do Design System.

Entre os benefícios de ter esse ecossistema para o dia a dia do desenvolvimento estão, a agilidade do trabalho, por saber o que usar de forma mais rápida, diminuição de preocupação em relação a escolha de componentes e, ao receber uma atividade para fazer, obter a descrição de todos os componentes a serem utilizados em determinadas atividades.

De modo geral, essa “biblioteca de componentes” nos direciona a seguir padrões visuais e comportamentais no sistema. Quando um usuário chega numa tela e precisa preencher um formulário, por exemplo, se este mesmo usuário precisar preencher um novo formulário em outro momento da sua experiência com o sistema, o comportamento precisa ser o mesmo, pois assim ele conseguirá entender melhor como os formulários funcionam dentro desse sistema, facilitando seu uso. Dependendo do contexto em que o Design System foi desenvolvido, os principais componentes variam.

No Asaas, por exemplo, atualmente possuímos três Design Systems diferentes: Icarus e o Atlas, que são utilizados em nossos sistemas, e Boto, que usamos em páginas externas. Cada Design System tem seus componentes principais e suas aplicações específicas.

É comum que as empresas utilizem apenas um Design System, buscando padronizar a usabilidade dos seus sistemas, porém é possível utilizar mais de um, seja por um processo de migração de padrões ou para experiências e objetivos diferentes, como em nosso caso.

Quando iniciei no Asaas, em 2020, já tínhamos o Icarus, que já não era tão moderno e utilizava tecnologias ultrapassadas para criar as telas, além de trazer complexidade de código. Percebemos também oportunidades de melhoria em acessibilidade, incluindo tamanhos de fonte, visualização, contraste e html semântico. Com o objetivo de construir algo do zero que nos ajudasse a levar uma interface nova para os clientes e melhorar a experiência dos usuários, iniciamos o projeto do Atlas, para resolver esses problemas, tanto na visão do usuário quanto para a experiência de desenvolvimento do time de Engenharia.

A primeira etapa foi realizada pelo time de design. Eles idealizaram os primeiros componentes e incluíram explicações de como os componentes deveriam se comportar na tela. Após essa idealização, o meu time, o Front-end, identificou os pontos de atenção, refinou os comportamentos e desenvolveu os componentes idealizados. Por fim, identificamos um fluxo no qual poderíamos adicionar os novos componentes do novo design system e testar sua efetividade, captando feedbacks dos usuários para melhorar a experiência.

Neste projeto, estavam envolvidos os times de Design e Produto que, juntos, idealizaram os componentes do Design System baseados nos comportamentos e dados de experiência do usuário. O time de Desenvolvimento Front End ficou responsável por toda essa idealização, desde os componentes da nova biblioteca até a aplicação do primeiro fluxo.

Um dos nossos desafios no desenvolvimento do Atlas, foi a escolha das melhores tecnologias considerando nosso contexto e objetivos. O Asaas havia recém adquirido o Money, uma carteira digital que era desenvolvida com React, e o Base, um ERP desenvolvido com Angular. Ambos são frameworks de frontend que ajudam a desenvolver telas com mais agilidade, porém, precisávamos de uma tecnologia que nos ajudasse a desenvolver o Design System de maneira que pudesse ser utilizado com qualquer framework e também sem framework, se fosse necessário. Dessa forma, iniciamos o Atlas internamente, com tecnologias puras como HTML, CSS e Javascript.

Com o tempo, amadurecemos a ideia de criar os componentes suportando também frameworks, então recriamos o Atlas a partir do conceito de web components, utilizando uma tecnologia que permite criar tags personalizadas para HTML, estilo específico para cada componente, sem correr o risco de interferir em outros componentes. Também utilizamos typescript para fazer os web components e permitir que os componentes se adaptem a outros frameworks de frontend. Além disso, utilizamos o Storybook para fazer publicação dos componentes, o Chromatic para nos ajudar a fazer testes de snapshots, AWS para publicar e disponibilizar os componentes na CDN e permitir o uso via importação.

Caso sejam necessárias mudanças, o processo de migração de uma tela para a nova proposta é analisado junto ao time de Produto. Todos os componentes necessários são mapeados e se já estiverem prontos, a mudança é realizada, juntamente de testes internos e para os usuários, de maneira controlada.

Nessa fase de testes, coletamos informações para verificar a efetividade da nova experiência, se obteve bons resultados ou se impactou métricas, por exemplo. E caso os componentes necessários não estejam prontos, são encaminhados para criação e a tela é migrada em outro momento.

De maneira geral, assim como a validação das mudanças aplicadas, a efetividade do Design System em projetos de Front End é analisada a partir dos testes e pesquisas de satisfação. Contudo, o projeto como um todo se trata muito mais de uma boa prática de desenvolvimento e experiência do usuário, de maneira que tanto desenvolvedores quanto designers são incentivados a buscar melhoria contínua em nosso Design System, através de uma série de orientações. Também é uma forma de nos mantermos alinhados ao objetivo, compartilhando informações, problemas nos processos e resultados de testes de interface e validação de componentes através de testes A/B.