O artigo seguinte é oferecido apenas para fins informativos e não se destina a fornecer, nem deve ser considerado, aconselhamento jurídico ou financeiro. Por favor, consulte os seus próprios consultores jurídicos ou contabilísticos se tiver dúvidas sobre este tópico.

Na Flex, somos uma pequena equipa de engenharia conhecida por ir muito além do que se esperaria de nós, com uma forte propensão para a ação. Após alguns anos de rápidas mudanças e reviravoltas nos produtos, acumulámos uma quantidade significativa de dívida de UX que começou a resultar numa experiência pouco fluida. 

Ainda precisávamos de lançar rapidamente, mas com um nível de exigência muito mais elevado para a qualidade e uma compreensão partilhada do que a "qualidade" realmente significava. No entanto, quando a ideia de criar um sistema de design me foi apresentada, entrei em modo de pânico ligeiro.

Tendo construído dois sistemas de design anteriormente, eu conhecia as armadilhas que podem implicar: trabalho personalizado desnecessário, discussões triviais, documentação desatualizada, etc. Não tínhamos tempo nem recursos para nos perdermos na bagagem que os sistemas de design podem trazer. 

O Desafio

A questão rapidamente se tornou: "Como podemos implementar um sistema de design "leve" — que entregue valor sem nos atrasar?"

A primeira coisa que tínhamos de fazer era avaliar o que um sistema de design abrangente implicava versus o sistema leve que pretendíamos construir.

Sistemas de Design Normais e Abrangentes

• Componentes personalizados (botões, modais, tabelas, etc.)
• Ferramentas personalizadas (configurações do Storybook, infraestrutura interna)
• Processos/governança para alterações
• Custos de manutenção elevados

Sistemas de Design Leves

• Apenas os componentes e padrões mais utilizados
• Fácil de adotar — a documentação e o código estão onde os programadores já trabalham
• Aproveita bibliotecas existentes em vez de construir do zero (quando possível)
• Tem padrões para demonstrar a utilização

As Nossas Restrições: Equipa pequena, grandes objetivos.

Começámos com uma série elegante de designs que abrangia desde componentes de nível atómico (botões, campos de entrada, etc.) até layouts comuns e fluxos de várias etapas. 

Ao longo deste processo, fizemos todos os esforços não para criar novos componentes, a menos que fosse absolutamente necessário. Aproveitar as ferramentas que tínhamos escolhido era imperativo. Somos uma pequena empresa que entrega imenso trabalho todas as semanas; a última coisa de que precisávamos era de nos perdermos em pormenores sobre problemas personalizados de componentes personalizados.

Embora as inconsistências visuais fossem claras, um problema mais profundo que eu tinha notado na Flex era a falta de uma abordagem unificada para construir UIs comuns, como formulários. Podíamos ir ao código e encontrar cinco formas diferentes de implementar UIs de formulários. Era claro que precisávamos de uma série de padrões.

Criação de uma Série de Padrões Unificados

Tínhamos começado anteriormente a trabalhar numa secção de 'cábulas' para os programadores terem uma coleção de boas práticas para copiar/colar. Este tornou-se o local perfeito para apresentar o nosso sistema de design emergente. Podíamos usar esta área (mais tarde renomeada como “Playground”) para permitir que os programadores visualizassem e usassem estes padrões para as nossas UIs mais comuns, acelerando o seu trabalho, e também permitir que os designers vissem que o que construíram é realmente o que está a ser usado. Finalmente, ter isto incorporado na nossa própria aplicação web (em vez de externamente, através de uma plataforma como o Storybook) ajudou a garantir a sua utilização.

No entanto, a história tinha acabado de começar. Tínhamos alguns dragões para abater primeiro:

1. Estávamos presos a uma versão anterior da nossa biblioteca de UI escolhida e seria um esforço bastante hercúleo para atualizar. Esta mudança abrangeria a totalidade da nossa aplicação voltada para o cliente e da nossa ferramenta interna, Alfred.
2. Precisávamos de combinar repositórios para co-localizar as nossas aplicações internas e web para garantir a utilização do sistema de design entre aplicações.

Após completar esses marcos, remodelámos o tema de ambas as aplicações para corresponder aos novos designs e o ímpeto começou a crescer.

Multiplicadores de força

Após a remodelação do tema da nossa ferramenta interna, Alfred, e da aplicação web, começámos a criar uma série de boas práticas no Playground. Com o tempo, o Playground continha os “80/20” dos nossos casos de uso — um balcão único para componentes, layouts e utilitários partilhados.

‍

‍

Embora soubéssemos que o Playground seria benéfico para os programadores copiarem/colarem componentes para acelerar o trabalho, esta coleção de padrões revelou-se perfeita para os LLMs entenderem como o código da UI deveria ser gerado.

Apresentamos: Cursor

Pouco depois de começarmos a construir o Playground, a nossa equipa de frontend começou a usar Cursor AI. Criámos o nosso Playground de referência de regras do Cursor para o usar como ponto de partida na geração de qualquer código baseado em UI:

• Para exemplos de como usar os componentes do nosso sistema de design, consulte o Playground em `src/areas/playground`.
• Ao implementar novos componentes como Drawers, Tables, Wizards, Layouts, etc., copie o ficheiro tal como está implementado no Playground e use-o como ponto de partida na área em que está a trabalhar.
• Na maioria das vezes, não estará a atualizar quaisquer ficheiros em `src/areas/playground`, mas simplesmente a usar os componentes aí presentes como pontos de partida para copiar para novas pastas em `src/areas`.

O nosso esforço anterior de re-tematização compensou imenso aqui, pois abriu caminho para o Cursor construir UIs consistentes com o nosso sistema de design sem ter de consultar quaisquer diretrizes de estilo.

Para aprofundar "o que significa qualidade de frontend na Flex", codificámos os padrões que tínhamos previamente acordado como equipa de UI. O Cursor faz referência a isto, para além das regras do Playground, para que o LLM compreenda não só o que deve ser construído, mas também como construí-lo em conjunto com as nossas várias ferramentas e convenções. Aqui está um excerto de como referenciamos a nossa atual biblioteca de UI, Mantine, a partir do nosso ficheiro de regras do Cursor:

• Use Mantine como a sua biblioteca base de componentes React.
• Aproveite ao máximo a biblioteca Mantine, incluindo componentes de `@mantine/core`, hooks de `@mantine/hooks`, formulários com `@mantine/form`.
• Para componentes, tente sempre usar primeiro os componentes nas nossas pastas `components/core` ou `components/composites`, caso contrário, use os componentes Mantine base sempre que possível.
• Evite usar estilos ou classes inline — tente sempre usar primeiro as props do Mantine para estilizar cores e cores de fundo, espaçamento e tamanhos, etc.
• Para cores, use sempre as cores do nosso tema Mantine (ou seja, `theme.colors.yourColorHere[index]`).
• Para espaçamento e tamanhos, use a função `rem()` do Mantine em vez de valores em pixel ou numéricos, ou seja, `gap={rem(12)}`

Resultados Flex

Usar IA em conjunto com o nosso sistema de design tem sido uma mudança radical em todos os aspetos para criar e manter um padrão mais elevado de velocidade e qualidade. A nossa recente funcionalidade de Contas a Receber foi construída inteiramente em três semanas! 

Da mesma forma, a utilização do Playground como uma coleção sólida de componentes e padrões realçou o nosso padrão de qualidade, tanto para programadores como para LLMs. Ao procurar uma abordagem mais leve para construir um sistema de design, conseguimos contornar as inúmeras armadilhas frequentemente associadas aos sistemas de design, preservando as vantagens de consistência e direção.

Recentemente, usámos o Playground como um recurso educacional para mostrar como os programadores podem usar alternativas a uma ferramenta de gestão de estado que estamos ativamente a tentar descontinuar. Num futuro próximo, pretendemos anexar os nossos padrões do Playground à nossa compilação de CI para garantir ainda mais a adoção.

Lições para Outras Equipas

Se está numa fase inicial, eis o que recomendamos:

• Comece pequeno: Concentre-se nos seus componentes de UI mais utilizados
• Evite trabalho personalizado: A maioria das bibliotecas de componentes de UI modernas pode ser utilizada para impulsionar o seu esforço de sistema de design. Guarde o trabalho personalizado para componentes e fluxos de trabalho mais complexos
• Seja específico sobre o que é 'bom': Certifique-se de que a sua equipa tem um conjunto de padrões acordados relacionados com ferramentas de UI e convenções de codificação para que os possa codificar com ferramentas de IA
• Torne-o óbvio para a sua equipa: Incorpore o seu sistema de design no produto para ajudar a garantir que é utilizado
• Torne-o acessível para LLMs: Certifique-se de que as suas ferramentas de IA podem referenciar facilmente o seu sistema de design e padrões para garantir o alinhamento antes de gerar código

Considerações Finais

Provavelmente não precisa de um sistema de design personalizado ou completo. Precisa de um que seja útil.

Na Flex, o nosso sistema de design tornou-se um multiplicador em engenharia, produto e design. Ajudou-nos a avançar mais rapidamente com um nível de qualidade muito superior.

Para equipas em fase inicial que apostam na velocidade e nas ferramentas de IA, este pode ser um dos investimentos em infraestrutura mais inteligentes que pode fazer.

‍