Sistemas de design: lições da Vivid

Nosso especialista em CSS Rachel Tannenbaum fez uma palestra incrível quando a Vonage organizou Pull Request, um encontro da comunidade de código aberto. Ela falou sobre sistemas de design, sua área de foco nos últimos três anos. Mas todos deveriam aprender sobre sistemas de design, não apenas aqueles que tiveram a sorte de participar do encontro. Por isso, vou compartilhar o que aprendi com a palestra dela neste artigo, respondendo às seguintes perguntas:

O que queremos dizer quando falamos em “sistema de design”? Por que as organizações precisam de um sistema de design? Os sistemas de design são de responsabilidade da equipe de design ou da equipe de desenvolvimento? Como os sistemas de design são implementados?

O que são sistemas de design?

Tudo começou com livros!

O manual da marca era a única fonte de referência para manter a integridade e a uniformidade da marca.

coca-cola-brand-book.png

Há muito tempo, quando os seres humanos ainda conseguiam sobreviver sem a internet, as empresas tinham um manual de identidade visual. Esse manual continha a filosofia da marca: cores, fontes, imagens etc. Ele definia estilos diferentes para cada contexto; por exemplo, um anúncio de jornal em comparação com um outdoor. O manual de marca da Coca-Cola, por exemplo, chegava a ter diretrizes até mesmo para o formato de suas garrafas de vidro! Esse manual permitia manter a identidade da marca e sua visibilidade, independentemente de quem lançasse o produto final.

Os manuais de marca entram na era digital: guias de estilo

Mas hoje em dia as pessoas não conseguem viver sem a internet. Os sites de página única se transformaram em aplicações web extensas, com subsites. Já não é mais possível que um único designer mantenha a aplicação de uma empresa. À medida que as equipes de design crescem para enfrentar esse desafio, surgiu um novo recurso para dar sentido a esse caos. Assim como o mundo analógico tinha o manual de marca, o mundo digital tem o guia de estilo.

vonage-style-guide-example.png

Um guia de estilo é a fonte de referência para os ativos digitais de uma marca. Esses ativos incluem elementos básicos, como cores, ícones, tipografia e componentes como botões. Também abrangem elementos mais complexos, como seletores de data, menus e outros. É claro que as empresas de software que desenvolvem ferramentas de design também estão fazendo experiências.

Mas o que os guias de estilo têm a ver com os sistemas de design front-end? Pense no processo de desenvolvimento front-end como algo semelhante a construir com Legos. Os guias de estilo pegam ideias abstratas, como cores e formas, e as transformam em um manual de instruções. Os sistemas de design pegam essas instruções e as trazem para o mundo real, combinando peças para formar objetos. A vantagem de um sistema de design em relação a um guia de estilo é que o sistema de design contém trechos de código, chamados de componentes, que podem ser rapidamente reutilizados várias vezes em toda a aplicação. O uso de componentes garante a uniformidade da marca e economiza um tempo precioso de desenvolvimento. Além disso, os sistemas de design são facilmente escaláveis e dinâmicos. Assim, com os sistemas de design, você deixa de escrever código como um artesão e passa a trabalhar como uma fábrica industrial de alta potência de Legos fofos.

Por que você deve usar um sistema de design?

Todo produto digital precisa de um sistema de design de experiência do usuário (UX)!

Ok, talvez não todos os produto digital precise de um sistema de design. A pergunta que você precisa fazer à sua organização é: somos uma Ford ou uma Ferrari?

A implantação e a manutenção de sistemas de design podem exigir muito tempo extra. O grande investimento inicial só vale a pena para projetos de grande porte, nos quais você economizará tempo a longo prazo. Sua equipe deve levar em consideração quantos desenvolvedores utilizariam o sistema de design, o escopo do(s) seu(s) produto(s) e os padrões e a comunicação da equipe de desenvolvimento.

Então, sua equipe é uma Ferrari? Se você é uma Ferrari, tem uma linha de produtos relativamente pequena, com poucos componentes reutilizáveis. Seus produtos não são desenvolvidos pensando em grande escala e, portanto, as economias de escala em seus projetos não trariam grande benefício para sua organização.

Ou você é um Ford? Você tem muitos produtos, muitas equipes e muitos designs que envolvem uma grande quantidade de páginas e funcionalidades? Um bom teste é se perguntar: se você tivesse que atualizar o design de todos os seus botões, isso seria uma tarefa gigantesca ou apenas um pouco incômoda? Se for uma tarefa gigantesca, você provavelmente é uma Ford.

Vantagens dos sistemas de design: organização e eficiência

Em termos simples, um bom design melhora a experiência do usuário e mantém a consistência da marca por meio da organização e da eficiência.

1. Pedido

   • Ordem na interface do usuário: Estabelece um design fixo, um padrão fixo de comportamentos, gestos, interações etc.

   • Ordem Ordem no desenvolvimento: traz ordem à desordem, ajuda a manter o código limpo e evita a duplicação de código.

2. Eficiência

   • Desenvolvimento eficiente: Reduz o tempo de desenvolvimento, permite que os designers tomem melhores decisões, economizando tempo e dinheiro para sua organização.

   • Atualizações eficientes: - Atualizações em todo o sistema com facilidade.

gmail-ui-uniformity-example.png

O Gmail é um ótimo exemplo de como os sistemas de design geram ordem e ganhos de eficiência. Em qualquer dispositivo, fica claro para o usuário que se trata de um produto do Google. Apenas pelos componentes da interface do usuário, fica claro para o usuário que tipo de interações ele pode esperar. E, no que diz respeito à eficiência, você se lembra de quando o Google mudou do Material Design 2 para o Material Design 3? Imagine todos os lugares em que as barras de navegação vermelhas e roxas precisaram ser alteradas, todos os lugares em que os cantos precisaram ser arredondados exatamente da mesma forma. Em vez de enormes dores de cabeça em todo o seu conjunto de produtos, um sistema de design garantiu que o Gmail, o Google Docs, o Google Slides e todos os outros apresentassem a mesma aparência por meio de componentes reutilizáveis.

Lições da Vivid

vivid-vonage-design-system-cover.png

Implementar um sistema de design em iterações

Não crie um sistema de design de UX logo de início! Pense nos sistemas de design de UX de maneira LEAN. Você quer criar os componentes mais úteis e mais escaláveis. Por isso, precisa saber quais componentes são realmente utilizados pela sua equipe de design. Isso significa que sua organização deve, primeiro, desenvolver seu produto ou produtos e, depois, avaliar quais componentes são mais reutilizados. Os sistemas de design não são para a versão V0.1 do seu produto, mas apenas a partir da V1.0 em diante.

Como identificar quais componentes você precisará? Você sempre pode começar pelos elementos mais básicos: tipografia, cores, botões etc. Esses elementos serão amplamente utilizados, independentemente do produto. A partir daí, seu sistema de design irá evoluir. Nathan Curtis tem um excelente (https://medium.com/eightshapes-llc/the-component-cut-up-workshop-1378ae110517) sobre isso chamado “The Component Cut-Up Workshop”, no qual você pode ver o fluxo de trabalho para dividir um site nos componentes que compõem o sistema de design.

vivid-abstract-artwork.png

Na Vonage, nosso sistema de design passou por várias iterações. O primeiro projeto se chamava Volta e contribuiu significativamente para a padronização do CSS. Depois, à medida que o projeto ganhou mais apoio da liderança, passou a ser conhecido como Vivid.

O Vivid-2 foi desenvolvido com base no Material Design. Logo percebemos que isso apresentava vários problemas:

• pesado demais para o que precisávamos

• falta de comunicação com a comunidade e solicitações de alterações/correção de bugs

• não está em conformidade com a especificação

• não totalmente acessível

• não se destina a servir de base para a criação de um sistema de design a partir dele

Vivid 3: Repensando tudo

Ao passar do Vivid 2 para o Vivid 3, decidimos repensar tudo completamente. Por isso, utilizamos o biblioteca Fast da Microsoft como nossa base. Escolhemos o Fast porque ele foi desenvolvido propositalmente para servir de base para um sistema de design. Ao mesmo tempo, é leve, mas também está em constante evolução para adicionar novos componentes e recursos. E, o mais importante, foi desenvolvido de acordo com os padrões do W3C e do OpenUI.

O Vivid-3 não só possui todas as vantagens do Fast, como também apresenta melhorias:

• cobertura de teste - passando de 70% para 100%

• documentação - com trechos de código prontos para uso, facilitando para que os desenvolvedores simplesmente copiem e colem o que precisam

• acessibilidade - em conformidade com WCAG 2

• marca branca

Construir uma ponte

A equipe como ponte

Seu sistema de design deve servir como uma ponte. Monte sua equipe com as pessoas certas, que compartilharão seus conhecimentos e moldarão o sistema de design para atender às necessidades de cada função de negócios.

Quem é responsável pela criação do sistema de design? Resumindo: a equipe de desenvolvimento. A equipe de desenvolvimento deve ter a responsabilidade principal pela criação do sistema de design, mas não é a única responsável. Uma das vantagens mais importantes de um sistema de design é que ele atua como uma ponte entre designers e desenvolvedores. O sistema de design funciona como um guia, fornecendo uma linguagem comum para esclarecer a comunicação entre desenvolvedores e designers. Quanto mais responsabilidade for compartilhada entre essas equipes e quanto mais contribuições de cada uma forem investidas na criação de um sistema de design, melhor será o produto final e maiores serão as sinergias em toda a sua organização.

Ponte com ferramentas

Paralelamente à nossa API, mantemos uma biblioteca de componentes no Figma para os designers. Quando estão trabalhando no design de uma página, aplicativo ou qualquer outro projeto, eles podem adicionar rapidamente a biblioteca de recursos da Vivid aos seus componentes de design. Dessa forma, mantêm um design uniforme. No arquivo final do Figma, os desenvolvedores têm tudo o que precisam para programar: exatamente quais componentes usar e suas especificações precisas, com precisão de pixel (tamanho, forma, fonte etc.).

vivid-component-library-figma.png

Além disso, exportamos tokens de design para cores, tipografia e tamanhos do Figma para usar na biblioteca de código. O legal dos tokens de design é que, ao alterar um deles no Figma e exportá-lo, a mesma alteração é feita automaticamente no Vivid também.

Identifique as principais preocupações na sua organização

identify-main-concerns-investigate.png

A Vonage é uma empresa de grande porte, com muitas equipes de desenvolvedores trabalhando em uma ampla gama de produtos. Isso resulta no uso de um grande número de bibliotecas de desenvolvimento front-end em toda a empresa: Vue.js, React Native, Angular e outras. A missão do Vivid é unificar o design em todos esses projetos. Para o Vivid, identificamos três preocupações principais: escalabilidade, uniformidade entre frameworks e acessibilidade. Precisamos que o Vivid seja atualizado de maneira uniforme em uma ampla gama de produtos. Precisamos garantir que o resultado final seja independente do framework front-end. E, por fim, precisamos garantir que a solução esteja em conformidade com os padrões de acessibilidade mais recentes.

Para atender a essa necessidade, o Vivid é baseado em componentes da web.

O que são componentes da Web?

Os Web Components são um conjunto de diferentes tecnologias que permitem criar elementos personalizados reutilizáveis — com suas funcionalidades encapsuladas, separadas do restante do código — e utilizá-los em seus aplicativos web. Basicamente, o produto final de um Web Component é HTML, CSS e JavaScript, o que significa que ele pode se adaptar a qualquer ambiente de desenvolvimento. Para saber mais, recomendo a leitura de Introdução aos Componentes da Web.

Os componentes da Web contêm três elementos principais:

1. Elemento personalizado

Este é o elemento “host”. Ele será visível no DOM e, normalmente, terá um nome exclusivo. Por exemplo, nos componentes Vivid, o nome do elemento personalizado sempre começa com vwc. Essas iniciais significam Vivid Web Components. A segunda parte do nome é o nome do elemento, que serve como uma descrição de sua finalidade. Por exemplo, vwc-button, vwc-dialog, etc.

1. Reino das Sombras

Uma espécie de “sub-DOM” oculto, que fica abaixo do elemento anfitrião, o elemento personalizado. Ele permite que um componente tenha sua própria árvore DOM “sombra”, que não pode ser acessada acidentalmente a partir do documento principal, pode ter regras de estilo locais e muito mais.

1. Modelo

Dentro do “shadow-dom”, podemos ver o modelo HTML que contém os elementos ou partes do componente.

Os componentes web do Vivid exigem que os usuários definam os componentes de acordo com suas necessidades (texto, ícone etc.) e, em troca, eles receberão componentes totalmente funcionais e com design pronto, praticamente sem necessidade de programação e sem alterar a estrutura HTML do próprio componente.

Por exemplo, para adicionar um modal ao projeto, basta fazer o seguinte:

Nos bastidores, dentro do shadow-dom, todo esse código será, na verdade, adicionado ao projeto:

<vwc-elevation dp="12">
  <dialog class="base icon-placement-side hide-body hide-footer" open="">
  <slot name="main">
    <div class="main-wrapper">
      <div class="header border">
        <slot name="graphic">
          <vwc-icon class="icon" name="info"></vwc-icon>
        </slot>
        <div class="headline">Dialog Headline</div>
        <div class="subtitle">subtitle content</div>
        <vwc-button size="condensed" class="dismiss-button" icon="close-line">   
        </vwc-button>
      </div>
    </div>
  </slot>
  </dialog>
</vwc-elevation>

E, para garantir que a caixa de diálogo seja aberta dentro de um modal, a abertura deve ser ativada por meio da função showModal.

<script>
  function openDialog() {
    dialog = document.querySelector('vwc-dialog');
    dialog.showModal();
  }
</script>

O produto final ficará assim:

vivid-dialog-component.png

Experimente o próprio produto

De todas as ferramentas que auxiliam no desenvolvimento de sistemas de design, o Storybook é provavelmente a mais popular. Mas, apesar de todas as suas vantagens, ele não lida facilmente com componentes web de maneira adequada. Ele não exibe corretamente o código dos componentes nem gera trechos de código para os desenvolvedores.

Por esse motivo, a documentação do Vivid é criada com… o próprio Vivid! O uso de nossos próprios componentes levou a melhorias tanto nos próprios componentes quanto em sua documentação.

É essencial utilizar os componentes fora do ambiente de desenvolvimento. Dito isso, os desenvolvedores de sistemas de design devem sempre lembrar que não são os usuários da biblioteca. Não presuma que a maneira como você usa os componentes seja a única ou a correta; mantenha um diálogo aberto com seus usuários.

Conclusão

Agora que você já sabe um pouco mais sobre como criamos o Vivid, não deixe de experimentá-lo! Confira o Storybook ou o repositório do GitHub no GitHub. Adoraríamos ver o que você está criando com o Vivid ou saber mais sobre suas próprias experiências na criação de um sistema de design. Mande uma mensagem para a Comunidade de Desenvolvedores da Vonage no Slack ou no Twitter.