O sistema de design que você não precisa

Sistemas de design, tão quentes no verão passado.

Já faz um tempo desde que o hype “Eu devo ter um sistema de design” atingiu o pico. Naquela época, a maioria dos designers sentiu a necessidade de experimentar este novo artefato, disponível na Agência Fort ou Figma mais próximo de você.

É quase 2021 agora e aprendemos muito. Agora sabemos que, se mal intencionadas, as estruturas do Design System podem se tornar carentes, exigir governança e nos distrair dos problemas reais do produto e do usuário, apenas para acabar sucumbindo à sua própria complexidade.

Equipes com recursos infinitos – tempo, dinheiro e paciência – para mexer os pauzinhos certos são as que estão colhendo os benefícios. Quando isso for alcançado, designers, desenvolvedores e o resto da empresa viverão em perfeita harmonia para sempre. No entanto, para alguns de nós, experientes ou não, decidir como documentar e produzir uma fonte confiável da verdade ainda é um desafio.

Neste artigo, vamos mergulhar nos sistemas de design, examinar seus benefícios e dar sentido a estruturas menores, mas poderosas, como guias de estilo e bibliotecas de padrões.

Vamos abordar questões como:

O que é um Sistema de Design e como ele se torna muito complexo?

Como podemos domar a documentação do projeto com estruturas menores?

É uma biblioteca de padrões ou um guia de estilo bom o suficiente para pequenos projetos?

Em primeiro lugar, vamos entender os Sistemas de Design.

Sistemas de Design

Alla Komaltova define Sistemas de Design como “um conjunto de padrões interconectados e práticas compartilhadas organizadas de forma coerente para atingir o objetivo dos produtos digitais”. Faz sentido quando você pensa nisso como uma estrutura para entender os elementos responsáveis ​​por manter você, equipes e partes interessadas na mesma página.

Tudo começa com a compreensão de que um produto não é apenas o seu software ou o arquivo Sketch em que ele reside, é a empresa e as práticas em torno dele. Diretrizes de marketing, escolhas de design, ambiente físico e social, linguagem compartilhada, requisitos de marca, voz e tom, para citar alguns. Até este ponto, parece uma ideia razoavelmente boa embrulhar tudo isso em um pequeno laço elegante. Em teoria, podemos despertar a consciência do produto, fornecer uma linguagem compartilhada entre as equipes, melhorar os negócios por ter um produto pronto para escalar, sem mencionar um ciclo de desenvolvimento consistente, do desenvolvimento da IU ao front-end, às vezes até back-end.

Não foi um passeio fácil. Com o hype veio a ilusão de um sistema capaz de resolver a maioria dos problemas que a indústria e os designers enfrentam. Mas sendo um organismo vivo assim como o software que criamos, os sistemas de design não devem depender de estruturas definitivas, devem ser capazes de mudar de direção e se adaptar às circunstâncias, que é onde os problemas começam a mostrar formas mais claras.

A natureza orgânica do desenvolvimento de produtos pode tornar a Design Systems cada vez mais necessitada e, sem uma estratégia clara, você pode perder o controle com atualizações infinitas ou ficar preso a estruturas obsoletas. As empresas que obtiveram sucesso nesta tarefa tiveram que dedicar equipes inteiras para acompanhar as atualizações constantes e o escrutínio de novas entidades integrando seus Sistemas.

Para fazer tudo isso funcionar perfeitamente, precisamos estabelecer processos para tudo o que seu sistema de design toca. Uma comunicação clara entre as equipes, pessoal dedicado para lidar com atualizações e manutenção de documentação são essenciais para estender a vida útil do seu Sistema de Design.

Complexidade

A imagem abaixo destaca algumas das complexidades envolvidas na manutenção adequada de um Sistema de Design ao longo do tempo. A animação mostra um esforço coordenado e multifacetado para gerenciar a comunicação, a governança e as diretrizes que, quando alcançadas, permitem que seu DS tenha uma chance de ser útil.

Como o fluxo infinito de documentação, remoção e manutenção de aspectos de entrada e saída de seu processo e produto, o círculo giratório bege representa o esforço necessário de governança e comunicação para entrar em contato constante com processos de gestão específicos. Também é notável a relação inversa entre esforço e valor que se segue: projetos menores tornam essa complexidade mais gerenciável, mas colhem menos benefícios de processos e estruturas superdesenvolvidos devido aos custos de manutenção, enquanto projetos muito grandes geralmente têm os recursos para fazer uma manutenção adequada mas enfrentam um aumento exponencial de complexidade à medida que o número de entidades, processos e conexões aumenta.

Governança

Alguém precisa ser responsável por configurar o ambiente para o novo conteúdo que entra no sistema. Você pode criar uma estrutura onde um gerente define o ritmo e decide o que entra ou sai, ou pode criar um ambiente aberto, onde todos podem colaborar quando necessário. Neste último cenário, todos podem analisar componentes e dar feedback. Essa pode ser uma boa maneira de envolver as pessoas e fazer com que todos compartilhem a mesma língua e compreensão.

Comunicação

Não é uma tarefa fácil fazer com que as pessoas acessem e acompanhem um sistema em constante mudança. Não espere ser o único designer à frente do sistema, informações relevantes se espalham facilmente sempre que uma nova pessoa entra ou sai. Uma simples adição ou alteração de cor em um componente principal precisa ser devidamente documentada com sua finalidade e à vista, para que todos estejam na mesma página.

Diretrizes

Os componentes devem ser criados propositalmente. Uma biblioteca simples exibindo pode não servir bem para a experiência do usuário. Diretrizes claras que explicam as motivações, contextualizam e mostram exemplos são úteis para evitar o uso indevido e a criação de elementos novos e desnecessários.

Cada produto exige diferentes fundamentos e soluções. A equipe de design da Atlassian sentiu que precisava de uma vitrine personalizada de seu sistema de design. A solução melhora a comunicação e prima pela linguagem visual através de cartões. Seu sistema de design inclui diretrizes de marketing, produto, marca e até ilustração.

Quando devemos encerrar tudo em um sistema de design?

Produtos maiores exigem um ambiente pronto para escalar e mover-se rapidamente. Eles estão sempre mudando em uma miríade de elementos de IU, decisões de UX, atualizações de marca e reescritas de código. Agora imagine uma equipe de design menor sendo responsável por criar, manter e atualizar essas estruturas.

“Talvez eu não precise de um Sistema de Design afinal”

Sortudo! Ainda temos bibliotecas de padrões e guias de estilo. Eles ainda têm um grande propósito se a intenção for voltada para o lado visual e de desenvolvimento do produto. Como designer, sobrecarregado com a lista crescente de novos artefatos de design, ainda fico confuso com os atributos sobrepostos que cada um tem. Então, vou colocar suas nuances de uma forma mais moderna.

Padrões funcionais e perceptivos

Suponhamos que você tenha um guarda-roupa bonito e, dentro dele, combinações de roupas que atendem à maioria das suas necessidades sociais: festa, trabalho, reunião, academia. Este guarda-roupa é a sua colecção de elementos funcionais, repletos de peças cruas que proporcionam um leque de possibilidades de roupa ao dia-a-dia. Podemos definir isso como o lado funcional do guarda-roupa. Eles são os blocos brutos fornecidos pelos navegadores, <button>, <a>, <input> … ou, nesta analogia, peças de roupa sem vida.

Indo mais longe com essa analogia, digamos que você tenha algumas preferências em relação a cores, marcas e tudo o que dá um toque pessoal às peças, daí o estilo. Esses chamados blocos funcionais têm um propósito, mas carecem de preferências pessoais. Agora eles ganham cores, bordas, proporções, fundo.

Depois dessa inspeção de moda, o guarda-roupa parece mais feito para você, não só tem as peças que você gosta, mas um toque pessoal, atributos que melhoram a percepção. Neste ponto, podemos relacionar esse guarda-roupa com o seu produto / site e finalmente dizer que um conjunto de elementos funcionais pode ser um padrão funcional, e um conjunto de regras que define o look & feel é chamado de padrões perceptuais.

Guia de estilo (padrões de percepção)

Todo produto digital, seja um software ou um site, começa com definições básicas de cor, tipografia, bordas, proporções e ambos respeitam as diretrizes da marca. Todo sistema de design possui esta categoria central, responsável por manter a aparência dos botões, títulos e tudo que compõe uma interface. Essas regras e decisões de design juntas podem ser chamadas de guia de estilo – você não precisa descrever tudo o que seu projeto é, nem estilizar cada padrão funcional. Você só precisa ter uma ideia de como deve parecer e sentir.

Importante: o Styleguide é apenas uma documentação, pode estar dentro de um arquivo de esboço ou site. Ele pode mostrar elementos estáticos ou interativos.

Primer, do GitHub é um guia de estilo bem documentado. Possui definições para bordas, sombras, espaçamentos, animações, margens, tudo que define o visual de seu produto e apela à percepção.

Como usar

Produtos menos complicados, com menos designers, podem fazer bom uso desse tipo de documentação. Um conjunto simples de regras visuais pode ser um bom ponto de partida para manter a consistência e evitar as idas e vindas de um sistema de design.

O que você pode documentar em um guia de estilo:

Cores primárias e secundárias

Uso / hierarquia da tipografia

Escala / proporções

Estilo de ícone

Estilo de borda

Sombras

Capacidade visual (alertas, foco, desativado)

Animação

Bibliotecas de padrões (padrões funcionais)

Alguns chamam de sistema de design, mas não é. Bibliotecas de padrões se relacionam com o que descrevemos como padrões funcionais. Pode ser um widget de calendário, uma navegação, um cartão com guias, um modal, uma seleção múltipla ou qualquer bloco de interação significativo e direcionado a um propósito. Semelhante ao Styleguides, ele pode ficar dentro de um arquivo de design ou no front-end.

Como designer, em algum ponto você terá que lidar com seus esboços de IU se tornando elementos front-end reais. Nesse novo ambiente, eles têm código, talvez uma nova linguagem e outras pessoas ao seu redor. Uma biblioteca de padrões pode colocar todos em sincronia.

Bibliotecas de padrões são mais utilizadas quando documentam o propósito por trás de cada elemento de design de design, melhorando a reutilização e a criação de novos componentes e até mesmo duplicatas desnecessárias.

Como usar

Comece documentando cada bloco interativo em seu produto. Se você tiver um produto funcional, os elementos da IU também existem no código, portanto, certifique-se de que tudo esteja alinhado.

Componentes que você pode documentar:

Elementos de navegação

Entradas

Botões

Cartas

Gráficos

Mesas

Listas

Do lado prático:

Se você quiser mantê-lo no lado da interface do usuário, use bibliotecas integradas no Sketch, Figma ou Adobe XD

Se você quiser mantê-lo na interface do usuário e no front-end, use ferramentas como o Storybook.

Se você quiser manter a simplicidade, com um conjunto de componentes HTML / CSS, basta criar uma página / library e listar tudo.

Eu realmente preciso de um sistema de design?

Este artigo pretende dar aos designers uma reflexão sobre a complexidade e as ferramentas que escolhemos para trabalhar. Podemos reconhecer que um sistema de design é realmente uma ótima ferramenta para a forma como criamos software atualmente, mas também devemos ter em mente que esse sistema de design pode se tornar mais complicado do que o produto que você está tentando construir, se não for domesticado.

Trabalho para uma empresa de consultoria de software, a Guava Software, e temos uma espécie de clientes com desafios e contextos diversos, cada um com o seu nível de complexidade. Nossa equipe de design é composta por cinco talentosos designers, cada um em uma frente diferente com os stakeholders, usuários, desenvolvedores e o próprio produto. Portanto, para uma equipe pequena, com produtos diferentes, faz sentido ter estruturas menores e flexíveis.

Se o seu produto tem um nível mais alto de complexidade e você pode dispor de tempo e dinheiro para colocar sua equipe na construção, manutenção e gerenciamento de um sistema de design, vá em frente, a recompensa será o dobro do esforço.