Uma receita para um bom sistema de design

Este artigo foi gentilmente apoiado por nossos queridos amigos da Backlight, uma plataforma colaborativa que capacita equipes de front-end a construir e enviar ótimos sistemas de design. Obrigado!

Em teoria, todos têm um conceito relativamente semelhante para o que significa um “Sistema de Design”, embora as nuances comecem a aparecer à medida que nos aproximamos do mundo real. A meta ainda pode ser a mesma, mas organizações diferentes exigirão estratégias diversas para alcançá-las. Tal como acontece com muitas tarefas complicadas em engenharia e arquitetura, não há bala de prata para o que faz um bom Design System.

Embora os empreendimentos bem-sucedidos compartilhem alguns padrões comuns que permitiram o surgimento de ferramentas e práticas recomendadas. Neste artigo, veremos quais soluções se encaixam dentro do guarda-chuva de um Design System e algumas etapas e pontos de verificação importantes que você precisa observar ao longo de seus projetos. Nossa experiência pode divergir, mas espero que haja aprendizados para você onde eu pessoalmente falhei e tive sucesso.

Objetivo e significado

Se considerarmos um “sistema” como uma combinação de partes trabalhando juntas, e “design” como o plano de aparência e função de algo. Então podemos entender o Design System como um coletivo de definições que ditarão padrões nos quais as partes interconectadas de um sistema parecerão, sentirão e funcionarão. Isso ainda é bastante abstrato, mas o suficiente para entendê-lo como mais do que aparência .

Não é uma biblioteca de componentes que você monta como um quebra-cabeça e chega a um layout consistente. Um sistema de design de fato tem um aspecto de apresentação, mas também tem a ver com função e integração. Trata-se de experiência .

• Experiência de usuário
  Com uma interface de usuário confiável e funcionalmente consistente.
• Experiência do desenvolvedor
  Com componentes fáceis de integrar e padrões definidos.
• Experiência das Partes Interessadas
  Com uma visão geral de como o produto evolui e cresce.

Com tantas peças em movimento, é compreensível que não haja uma resposta única para todos os sistemas de design.

Intencional x orgânico

Quando uma equipe decide criar um Design System, há duas abordagens em que eles precisam decidir antecipadamente:

• Orgânico
  Pegue um aplicativo existente como referência, extraia partes dele e abstraia-as o suficiente para serem usadas por outro aplicativo. Essa abordagem leva menos decisões desde o início, mas exige um esforço mais reativo da equipe para acomodar os requisitos recém-encontrados pelos adotantes. Decisões arquitetônicas tendem a ser tomadas conforme a necessidade, em vez de proativamente.
• Intencional
  Tokens, padrões e componentes são pensados ​​com antecedência. Os limites de um produto mínimo viável (MVP) são definidos e o trabalho começa. Para essa abordagem, ter metas e requisitos é um passo importante para alinhar as expectativas com as partes interessadas.

Orgânico

Ao permitir que o Design System se desenvolva organicamente, o sucesso do empreendimento se resume à adesão das partes interessadas e dos adotantes. E com que eficácia a equipe será capaz de reagir à medida que esclarece todas as incógnitas que encontrar ao longo do caminho, sem ser excessivamente perturbadora com suporte contínuo. É um caminho complicado e a comunicação é fundamental. Não há um caminho claro de ação, pois está intimamente ligado ao contexto da equipe.

Além disso, é difícil ajustar como um sistema enquanto ele está em execução (pergunte ao seu eletricista local) e como as tarefas levam tempo, os requisitos podem mudar: o mercado não esperará pela sua biblioteca de componentes. Um momento comum de “fazer ou quebrar” para um Design System orgânico é descobrir a história de desenvolvimento de um componente MVP (produto mínimo viável).

Por um lado, temos desenvolvedores e designers querendo criar a melhor experiência possível e qualidade de código por excelência; por outro, há KPIs, ROIs e sua banda de siglas para medir o sucesso. Encontrar o equilíbrio e permanecer escalável é complicado. Como abstrair algo inacabado é ainda mais complicado, e evitar que essas tarefas de acompanhamento sejam esquecidas no backlog é a questão de um milhão de dólares do gerenciamento de produtos.

Ser capaz de iterar de forma rápida e incremental em seu Design System se torna um requisito básico ao lidar com a abordagem orgânica. E também requer um nível extra de clareza de seus desenvolvedores consumidores (caso haja equipes separadas: uma criando o Design System, a outra criando recursos do produto). Ambos devem alinhar claramente as expectativas sobre os requisitos do produto e os requisitos de experiência do desenvolvedor para que haja uma simbiose adequada. Porque um Design System não é nada se for chato de usar ou se piorar a experiência do usuário de alguma forma.

Intencional

Há muito mais planejamento necessário, incógnitas a serem esclarecidas e infraestrutura a ser preparada ao fazer a escolha consciente de construir o Design System antes de ter um produto para usá-lo. O outro lado traz mais clareza com restrições. objetivos e expectativas. Se as velas forem verificadas duas vezes antes de deixar o porto, a tempestade é menos assustadora.

A previsibilidade do sistema também cresce ao planejar com antecedência, e isso porque o Design System se torna seu próprio produto e não a ferramenta para melhorar os outros. Com essa abstração, padrões e soluções utilizadas em outros são mais facilmente transportados.

Embora escolher Intencional em vez de Orgânico possa parecer contraproducente no início para equipes com menos experiência por não ter uma prova de conceito para testar, é especialmente útil evitar armadilhas comuns ao começar. “Apoiar-se nos ombros de gigantes” é um jargão comum e verdadeiro neste caso. Portanto, a melhor receita daqui para frente deve ser aproximadamente:

1. Identificar requisitos básicos;
2. Pesquise cedo e minuciosamente para casos semelhantes;
3. Skim resultados de 2 para soluções e estratégias implícitas;
4. Faça tudo do seu jeito montando uma combinação de soluções comuns e adicionando seu próprio molho;
5. Iterar.

Esses cinco passos podem parecer simples e óbvios, mas não são. É fácil pular uma das reuniões de requisitos ou interromper a pesquisa. Um conselho, porém: você pagará juros na etapa 4 se esquecer qualquer um deles.

Construir para a eficiência

Nenhum consumidor de pacote gosta quando uma atualização de dependência interrompe seu aplicativo de alguma forma. Não é diferente quando o pacote em questão faz parte de um Design System. Na verdade, pode-se apontar que é pior. A reação de uma dependência interna que quebra um aplicativo tende a ser maior do que quando é um pacote de código aberto, além disso, as alterações na interface do usuário tendem a “interromper silenciosamente” na frente dos usuários finais primeiro: o que é particularmente frustrante.

Com isso em mente, já podemos alinhar algumas questões:

• Documentação da API
  Facilite a descoberta e o uso.
• Controle de versão
  Indica como as versões devem impactar os consumidores.
• Registro de alterações
  Indica quais mudanças cada versão traz.
• Lançamento
  Uma maneira sensata de manter o código estável e fácil de entregar para todos os consumidores.
• Ambiente de desenvolvimento
  Ainda não há nenhum aplicativo usando, deve descobrir como mostrar e desenvolver artefatos.

Importante ressaltar que a prioridade de cada um desses itens pode variar de acordo com a sua quilometragem. Mas a necessidade deles aumentará à medida que o Design System for dimensionado, a adoção aumentar e os recursos crescerem. Eles podem não ser suficientes para impedir que uma equipe avance, mas com certeza prejudicarão a produtividade se a capacidade for distorcida para descobrir essas soluções.

Fonte da verdade

Outro eventual ponto problemático que muitas equipes enfrentam é identificar a fonte da verdade em um Design System. É código, interface do usuário ou documentação? Para muitos tipos de produtos, basta olharmos para o lado do consumidor e podemos identificar facilmente qual é a saída principal. A razão pela qual fica complicado neste caso é porque cada tipo de consumidor o usará de maneira diferente e, portanto, a resposta varia de acordo com a demografia solicitada.

Um Design System geralmente é uma mistura de uma biblioteca de componentes, documentação e um guia de estilo. E não só o consumidor é diferente para cada um desses artefatos, mas o artesão também é diferente. Um desenvolvedor, um designer, um escritor técnico; pessoas diferentes serão necessárias para criar cada saída.

Batata quente

Para manter a entrega consistente, a comunicação e a colaboração são fundamentais. E o processo em cascata já estabelecido também não é encorajador.

Não há espaço projetado (com trocadilhos) para colaboração ou iteração com base em cada especialidade. Muitas vezes, o designer não tem conhecimento de algumas limitações de código e o desenvolvedor não tem noção do UX pretendido para a saída. Essa abordagem não é extremamente prejudicial, é possível criar um bom produto com ela. Mas um grande é difícil, cada parte do processo é quase desconectada, a menos que a equipe faça um esforço ativo para corrigi-lo.

Os sempre incríveis Dan Mall e Brad Frost cunharam o nome igualmente ótimo para um novo processo: Hot Potato. Esse processo não apenas estimula a comunicação, mas também impõe diretamente a colaboração à equipe, unificando a fonte de verdade do trabalho. Com isso, cada artefato entregue não apenas compartilha uma origem comum, mas também é um produto da expertise da equipe combinada.

Tornar esse tipo de colaboração sem atrito é mais fácil falar do que fazer. Mesmo sentado lado a lado para evitar o “você está mudo”, “minha conexão caiu” e “você pode me ouvir?” aborrecimentos, quando colocada a troca de informações tende a ser informal facilmente, e então o processo pode acabar sendo difícil de documentar ou muito síncrono. Queremos menos gargalos, não mais.

A colaboração ao vivo chegou a grandes distâncias entre colegas. Como o VSCode Share ou o FigJams da Figma, IDEs em nuvem, existem muitas opções. Mas quando se trata de iterar entre diferentes especialidades, não é super simples. Adicione isso à pilha de ferramentas, arquitetura ou processos mencionados nas seções anteriores e você terá uma pilha de trabalho a fazer antes mesmo de começar a trabalhar.

Arquitetando um sistema

Como apontado acima, manter um sistema de design é muito trabalhoso. O melhor conselho é provavelmente tentar e não fazer as coisas do zero sempre que possível. Use os recursos da comunidade onde for conveniente. Fazer isso reduzirá o tempo de manutenção de pontos específicos do sistema e ajudará a integrar engenheiros e designers se eles já estiverem familiarizados com certas partes do sistema.

Em vem a luz de fundo. É uma plataforma como serviço que reúne uma série de ferramentas de forma opinativa, porém flexível, para agilizar toda essa configuração de arquitetura. Você pode começar do zero ou escolher um modelo inicial que melhor se adapte ao seu projeto. Nenhuma roda é reinventada se não for completamente necessária, eles usam recursos da comunidade em todos os seus iniciantes (o que eu tentei, Yogi, é baseado em ChakraUI), menos manutenção para eles, e o consumidor não se preocupa em ficar preso. Além disso, o código será enviado para sua plataforma de controle de versão, portanto, faltam apenas alguns comandos de shell para serem removidos, se necessário.

Uma vez lá, ele organizará a integração com uma plataforma de versionamento (Gitlab e GitHub são suportados), um sandbox baseado em Storybook, um IDE baseado em VSCode, testes de unidade e até publicação no registro NPM (este último dependerá do seu plano com eles, pode ser na sua conta ou na deles).

Múltiplas saídas

Mapeamos anteriormente que existem pelo menos 3 saídas diferentes que a maioria dos Design Systems exige: documentação, código, interface do usuário. Quando a arquitetura está pronta para produzir cada um deles, a equipe geralmente descobre outro desafio: mantê-los em sincronia. Os desenvolvedores estão sempre ansiosos para fazer mudanças atômicas, você toca em um lugar e eles se espalham por todos os lugares consumindo essa informação. Dentro de um Design System, nem sempre fica claro como realizar.

Se você não estiver seguindo o Hot Potato Process, é fácil perder a noção de quais atualizações de interface do usuário já foram abordadas pelos desenvolvedores. E mesmo se você fizer isso, há documentação. A luz de fundo resolve esse problema colocando tudo.

E uma vez que as alterações são feitas, sem sair do painel da plataforma. É possível verificar a documentação atualizada ao vivo.

E tudo isso é apenas arranhar a superfície do que eles podem impulsionar sua arquitetura. Você também recebe:

• Teste de captura de tela em Pull Requests com o recurso "Visual Review"
• Suporte ao desenvolvimento orientado a testes com testes de unidade integrados
• Sandbox com visualização ao vivo

É um ambiente de desenvolvimento completo para o seu Design System. E você ainda obtém todas essas integrações, mesmo que decida não usar os iniciadores. A infraestrutura está lá para você construir a biblioteca de componentes que alimentará seu Design System do zero.

Colaboração remota em tempo real

Como mencionado anteriormente, o Hot Potato Process pode se tornar problemático para as equipes configurarem uma maneira remota e assíncrona de trabalho. A luz de fundo resolve isso com uma combinação de dois recursos:

• Integração do projeto;
• Compartilhe um link ao vivo.

A integração de design traz o artefato de design de sua ferramenta de design na mesma plataforma. Assim, o restante da equipe pode ver, adicionar comentários e fazer referência ao trabalho diretamente do mesmo painel:

Com esse recurso, o processo de batata quente começa na prancheta, não importa onde sua equipe esteja localizada. E sem alternar as guias, também suaviza o processo de codificação com o recurso de compartilhamento de link, melhor explicado com o gif promocional deles do que qualquer coisa que eu pudesse fazer sozinho. Os desenvolvedores podem compartilhar um link remoto em tempo real de seu trabalho sem publicar coisas em qualquer lugar, sem nenhum processo intermediário, o que é um grande impulso para as equipes que precisam iterar rapidamente no trabalho detalhado.

Aprendizado

Caso ainda não tenha sido, espero que esteja mais claro agora o que é criar e manter um Design System. Muito mais do que um punhado de classes CSS, definições de token e tipos de letra; é ferramental, suporte ativo e advocacia. A utilidade de um projeto é ditada pela qualidade de sua produção e pela rapidez com que ele pode se adaptar aos requisitos em constante mudança.

Então, se nada mais, prepare-se para ser produtivo e eficiente ao criar seu projeto. Se você ainda está encontrando seu terreno, ferramentas como Backlight o ajudarão com padrões sensatos e uma ótima experiência do usuário pronta para uso. Se já tiver experiência com uma arquitetura específica, escolha suas batalhas com sabedoria e use a comunidade para lidar com o resto.