Construindo Design Systems Para Produtos, Não Para Designers

Design Systems são bem conhecidos hoje em dia, com grandes empresas apoiando este método de documentação e especificação do design. Caso você não saiba, um Design System é uma coleção de documentos que definem um padrão visual e de comportamento para uma plataforma, produto ou serviço, seja ele digital ou não. Familiar, não? Basicamente, o Design System é utilizado como um guia de identidade para interfaces.

“Basicamente”, pois é assim que muitas destas empresas definem o sistema de design que utilizam, e também é como muitos designers defendem esta prática. O sistema de design empregado geralmente se limita a dizer quais cores, fontes, estilos gráficos e configurações visuais utilizar. Ele ajuda os desenvolvedores a manter um padrão visual e de comportamento para uma plataforma digital, por exemplo. O Airbnb, inclusive, apresenta o sistema deles como uma “linguagem visual”. Mas isto está longe do que um sistema de design deveria ser.

O sistema de design do Salesforce mostra elementos, cores e fontes.

A evolução de um guia de identidade em PDF para um guia visual em HTML não justifica a criação de um sistema de design. Para que o sistema exista, mais do que especificações visuais devem existir.

Para quem?

É importante especificar as personas e públicos do seu produto. Muitos dos “comos” e “porquês” surgem daqui. O Shopify faz um excelente trabalho definindo para quem o conteúdo deve ser escrito, qual linguagem usar, nível de escolaridade dos usuários, termos a serem evitados, cordialidade e tom de voz.

O Shopify especifica qual é o público, como escrever para ele, qual terminologia utilizar.

Porquê?

Uma das principais qualidades de um sistema de design é que ele pode ter vida. Vida no sentido tecnológico: sempre em mudança e aprimoramento, mesmo que seja um grande arquivo de Sketch ou uma Wiki com exemplos de código, ele está sempre atualizado.

Contudo, arquivos de Sketch e exemplos de código ainda são modelos rasos. É importante que o sistema indique os objetivos de se utilizar os elementos que estão listados nele. Por quê um botão assim ou assado foi escolhido? Quais são os benefícios que isso traz para o usuário final? Quais são os princípios de usabilidade que guiam esta escolha? Quais métricas a comprovaram?

Como?

Além dessas razões, é importante saber não apenas o “como” técnico (dimensões, cores, exemplos de código) mas as maneiras de apresentar este elemento ou conteúdo. Esta informação tem prioridade sobre as demais? Como é a ordenação hierárquica? Como este elemento se encaixa em um fluxo para usuários leigos, novatos, ou avançados? Como este elemento se comporta em diferentes aparelhos? Como este elemento melhora a utilização do serviço, a venda do produto, e assim por diante.

O Google explica porquê certos elementos de interface são utilizados em em quais contextos.

Quando?

Muitos elementos de design podem cobrir diversas funções, mas nem sempre podem ser substituídos sem um estudo. Designers e desenvolvedores confundem o uso apropriado de caixas de seleção (checkboxes) e botões de rádio (radio buttons), por exemplo. O sistema deve especificar quando utilizar cada elemento, qual é o comportamento esperado e quais resultados eles devem trazer. Isto também é muito importante quando falamos de acessibilidade, pois o sistema de design deve pontuar as melhores soluções (com os devidos porquês) para casos específicos.

Onde?

Não apenas saber em qual aparelho (celular, tablet, computador, ponto de venda) o produto será utilizado, mas em qual contexto social ou geográfico. 
Imagine um aparelho que deve ser usado para inspecionar avarias nas fundações de prédios. Corredores estreitos, com pouca luz, em meio à tubulação. As decisões de design levam consigo o contexto de utilização do produto, e isso é traduzido tanto na forma física do aparelho quanto na interface do software. Mesmo que o sistema demonstre visualmente que a interface tem tamanho de fonte grande, botões com bastante contraste ou outras decisões feitas para o caso, contar a estória e contexto de utilização são de enorme importância para o produto.

Como isto melhora o produto?

Em um patamar mais geral, os elementos — sejam eles interativos ou gráficos — devem trazer benefícios não apenas de acessibilidade e usabilidade, mas também para os objetivos do produto. Se um dos seus objetivos é melhorar a velocidade de utilização do produto, ou a legibilidade, ou a conversão, diferentes decisões de design serão feitas para alcançá-lo. Testes e métricas irão comprovar que este layout, elemento, ou interação é melhor para alcançar um dado objetivo, então conte esta estória na documentação do sistema, atribuindo objetivos claros à utilização deste ou daquele elemento.

Um dos objetivos da Microsoft é que pessoas com limitações motoras ou de comunicação possam usar seus produtos, e isto reflete diretamente nas decisões de design.

Testes utilizados

Também é importante, em todos os pontos acima, especificar se algum teste de usabilidade ou protótipo foi feito e quais foram os resultados coletados. Na necessidade de uma revisão da interface ou de um fluxo, os documentos gerados dos testes irão ajudar a manter um histórico e tomar decisões com mais facilidade e segurança.


Resumindo

  • Defina para quem é este sistema e como ele faz a ponte com o usuário
  • Inclua o contexto de utilização e como o sistema beneficia a experiência e resolve problemas únicos nessa situação
  • Explique a razão de cada elemento ser utilizado, tanto do ponto de vista de usabilidade, quanto de objetivo do produto e dos resultados dos testes
  • Além da razão, o modo de aplicação de cada elemento em relação a outros elementos do sistema e suas qualidades técnicas

Criar sistemas de design pode ser muito mais do que tabelas de cores e fontes. Podemos utilizar eles como ferramentas eficientes de contextualização do produto, juntando diversos pontos de decisão que formaram a experiência entregue, e também como documentação da evolução não apenas visual mas dos objetivos e dos usuários.

Se você tiver sugestões ou comentários, adoraria lê-los! Obrigado.