Sistemas de design são sobre relacionamentos

Os sistemas de design podem ser incrivelmente úteis. Eles fornecem elementos e diretrizes reutilizáveis ​​para criar uma “aparência e sensação” consistentes em todos os produtos. Como resultado, os usuários podem pegar o que aprenderam com um produto e aplicá-lo em outro. Da mesma forma, as equipes podem implementar padrões bem testados para navegação ou avaliações, tornando os produtos mais confiáveis. Sistemas de design eficazes resolvem problemas chatos de maneira repetitiva, para que desenvolvedores e designers possam se concentrar na solução de novos problemas.

No entanto, quando alguém usa o termo “sistema de design” em uma reunião, nunca tenho certeza de qual reação esperar. Eu vi curiosidade e entusiasmo em tentar uma nova maneira de trabalhar, mas também vi frustração e preocupação com a ideia de um sistema limitando a criatividade dos designers. Alguns designers argumentam que os sistemas de design minam a criatividade, ou que são soluções em busca de um problema. Os sistemas de design podem se fragmentar com o tempo, fazendo com que as equipes parem de usá-los.

Os sistemas de design não estão desaparecendo, no entanto. Apenas 15% das organizações não tinham um sistema de design em 2018, de acordo com uma pesquisa. Isso está abaixo dos 28% do ano anterior. Algumas equipes usam sistemas de design grandes e de uso geral, como o Material Design do Google, enquanto outros usam sistemas menores e mais personalizados, como o Cedar da REI e o Protocolo da Mozilla.

Os sistemas de design devem capacitar as equipes, não limitá-las. Para que isso aconteça, precisamos começar a pensar de forma mais holística. Um sistema de design não é apenas código, design ou documentação. São todas essas coisas, mais as relações entre as pessoas que fazem o sistema e as pessoas que o utilizam. Inclui não apenas arquivos CSS e documentos do Sketch, mas também confiança, comunicação e propriedade compartilhada. Como se vê, há todo um campo de estudo dedicado a explorar sistemas como esses.

A grande imagem

Um artigo de 1960 intitulado “Sistemas sociotécnicos” explorou as interações entre tecnologia, humanos e o ambiente mais amplo em que eles existem. Enid Mumford explicou que os pesquisadores começaram investigando como construir melhores relacionamentos entre gerentes e funcionários, mas na década de 1980, eles estavam focados em tornar o trabalho mais eficiente e econômico. Em 2011, Gordon Baxter e Ian Sommerville escreveram que essa pesquisa ajudou a inspirar o design centrado no usuário e que ainda há muito trabalho a ser feito.

Baxter e Sommerville argumentaram que hoje ainda existe uma tensão entre a pesquisa “humanística”, que se concentra na qualidade de vida dos funcionários, e a pesquisa “gerencial”, que se concentra em sua produtividade. Eles também explicaram que é importante considerar tanto a tecnologia quanto as interações humanas: “o desempenho do sistema depende da otimização conjunta dos subsistemas técnicos e sociais”.

Eu diria que os sistemas de design são sistemas sócio-técnicos. Eles envolvem interações entre as pessoas que criam o sistema, as pessoas que criam produtos usando o sistema e os usuários finais que interagem com esses produtos. Eles também evocam a mesma tensão entre eficiência e humanismo que Baxter e Sommerville viram.

Os sistemas de design não são compostos apenas de imagens e código; eles envolvem conversas entre designers, desenvolvedores, gerentes de produto, CEOs e pessoas aleatórias no GitHub. Essas interações ocorrem em vários contextos – uma empresa, uma comunidade de código aberto, uma casa – e acontecem em culturas e fronteiras organizacionais. Construir uma equipe pode significar reunir pessoas de disciplinas como animação, design de som, visualização de dados, haptics e redação. Criar um sistema de design bem-sucedido requer partes iguais de conhecimento técnico e habilidades sociais.

E, no entanto, leia atentamente os agregadores de notícias de design ou engenharia e é provável que você veja um foco distinto nesse “subsistema técnico” – código e ferramentas, em vez de pessoas e conversas. Qual ferramenta criativa é a melhor para acompanhar os tokens de design? Quais tecnologias JavaScript devem ser usadas para construir componentes reutilizáveis ​​— React, componentes web ou qualquer outra coisa? Qual ferramenta de construção é melhor?

A resposta para essas perguntas é, claro, “depende!” Quem projetará, construirá e usará o sistema? Quais são suas necessidades? Sob quais restrições eles estão operando? Com quais ferramentas e tecnologias eles se sentem confortáveis? O que eles querem aprender?

Para responder a esse tipo de pergunta, Baxter e Sommerville recomendam dois tipos de atividades:

• Atividades de sensibilização e conscientização
  Aprender sobre as diversas pessoas que criarão e participarão do sistema e compartilhar essas informações por toda parte.
• Engajamento construtivo
  Comunicar-se entre funções, construir protótipos e considerar as partes técnicas e sociais do sistema.

Cavando em

No início de 2019, eu fazia parte de uma equipe – vamos chamá-los de “team blue” – que estava construindo um sistema de design para uma grande organização. Facilitei conversas informais com essa equipe e a “equipe verde”, que estava usando o sistema de design para construir uma aplicação web. A cada duas semanas, reunimos todos os desenvolvedores e designers em torno de uma mesa e conversávamos sobre o que estávamos construindo e quais problemas estávamos tentando resolver. Esses bate-papos foram nossas “atividades de sensibilização e conscientização”.

Não tínhamos permissão para tornar nosso sistema de design público, então fizemos a próxima melhor coisa: tratamos isso como um pequeno projeto de código aberto dentro da organização. Colocamos o código em um repositório que ambas as equipes podiam acessar e solicitamos contribuições. A equipe azul era responsável por revisar e aprovar essas contribuições, mas qualquer pessoa de qualquer equipe poderia contribuir. A equipe azul também estava construindo um aplicativo próprio, então, de certa forma, eles eram usuários e guardiões do sistema de design.

Essas interações ajudaram as equipes a criar produtos melhores, mas, igualmente importante, estabeleceram confiança entre as equipes. A equipe azul descobriu que as pessoas estavam usando o sistema de forma ponderada e construindo novas ideias inteligentes em cima dele. A equipe verde aprendeu que o sistema realmente foi adaptado às suas necessidades, para que pudessem trabalhar com ele em vez de contra ele. Baxter e Sommerville podem chamar esse trabalho de “engajamento construtivo”.

Descobrimos que ambas as equipes estavam sob pressão para aprender novas tecnologias e entregar um produto completo rapidamente. Em outras palavras, eles já estavam operando sob uma carga cognitiva bastante considerável. Como resultado, as duas equipes concordaram em se concentrar em tornar o sistema fácil de usar. Isso significou evitar todo o debate sobre componentes da web, concentrando-se principalmente em CSS e garantindo que nossa documentação fosse clara e amigável.

Juntando tudo

Organizações de todos os tamanhos criam elementos de design reutilizáveis ​​para ajudar as equipes a criar aplicativos mais consistentes e elegantes. As necessidades e dinâmicas de diferentes organizações são expressas em seus sistemas de design. Aqui estão alguns exemplos:

• O Material Design do Google possui diversas implementações em diferentes frameworks e linguagens. Ele é usado por várias pessoas dentro e fora do Google, por isso tem uma documentação abrangente e uma variedade de kits de ferramentas para aplicativos de design.
• O Fluent Design System da Microsoft tem como alvo quatro plataformas muito diferentes. Assim como o Material, ele inclui kits de ferramentas para designers de UX e documentação abrangente.
• O protocolo da Mozilla é implementado em Sass e JavaScript vanilla. Tem uma forte aposta na internacionalização. Alex Gibson diz que este sistema ajuda a Mozilla a “criar páginas da web da marca em um ritmo mais rápido com trabalho manual menos repetitivo”.
• O Cedar da REI é construído com componentes Vue.js e não pode ser usado com outras estruturas JavaScript. Cedar é usado principalmente pelos desenvolvedores internos da REI e está intimamente ligado à marca da empresa. O código do sistema de design é de código aberto, mas suas fontes não são.
• O Lightning Design System da Salesforce é uma estrutura CSS independente de JavaScript. Opcionalmente, ele pode ser usado junto com o Lightning Component Framework, que inclui duas implementações de JavaScript: uma usando componentes da Web e outra usando a estrutura Aura proprietária do Salesforce.
• O PatternFly da Red Hat foi criado para fornecer uma experiência de usuário consistente em todos os produtos da plataforma de nuvem da empresa, portanto, possui uma densidade de informações relativamente alta e inclui uma variedade de componentes de visualização de dados. A equipe da PatternFly recentemente mudou de Angular para React após algumas experiências com componentes da web. O PatternFly também inclui uma implementação independente de JavaScript usando HTML e CSS. (Divulgação completa: sou um ex-Chapeleiro Vermelho.)
• O Carbon Design System da IBM oferece implementações em React, Vue, Angular e JavaScript vanilla, bem como um kit de ferramentas de design para Sketch. A equipe Carbon está experimentando com componentes da web. (Dica de chapéu para Jonathan Speek por rastrear esse repositório.)

Sistemas como esses são consistentes e confiáveis ​​porque pessoas de diferentes equipes e funções trabalharam juntas para construí-los. Esses sistemas resolvem problemas reais. Eles não são o resultado de desenvolvedores tentando impor sua vontade aos designers ou vice-versa.

Josh Mateo e Brendon Manwaring explicam que os designers do Spotify “vêem seu papel como principais contribuidores e coautores de um sistema compartilhado – do qual eles são proprietários”. Mina Markham se descreve como “a tradutora entre engenharia e design” no sistema de design Pantsuit. Jina Anne se aprofunda na dinâmica da equipe e na pesquisa de usuários por trás dos sistemas de design: “Alerta de spoiler! Você vai precisar de mais do que apenas designers.”

Vamos construir algumas coisas!

Agora que passamos pela pesquisa e alguns exemplos, vamos falar sobre como construir um novo sistema de design. Comece conversando com as pessoas. Descubra quem usará e contribuirá para o seu sistema de design. Essas pessoas provavelmente abrangerão uma variedade de disciplinas – design, desenvolvimento, gerenciamento de produtos, negócios e afins. Aprenda sobre as necessidades e objetivos das pessoas e peça que compartilhem no que estão trabalhando. Considere planejar uma reunião informal com lanches, café ou chá para criar uma atmosfera acolhedora. Estabeleça uma comunicação regular com essas pessoas. Isso pode significar ingressar em uma sala de bate-papo compartilhada ou agendar reuniões regulares. Mantenha o tom casual e amigável e concentre-se em ouvir.

Ao falar sobre o que você está trabalhando, procure por problemas e objetivos comuns. Você pode descobrir que as equipes precisam exibir grandes quantidades de dados, por isso estão investigando ferramentas para exibir tabelas e gerar relatórios. Priorize soluções para esses problemas.

Procure também padrões repetidos e variações em temas semelhantes. Você pode achar que botões e formulários de login parecem um pouco diferentes entre as equipes. Qual é o significado dessas variações? Quais variações são intencionais – por exemplo, um botão primário versus um botão secundário – e quais variações ocorreram por acidente? Seu sistema de design pode nomear e catalogar os padrões e variações intencionais e pode eliminar as variações “acidentais”.

O objetivo aqui é estabelecer um ciclo de feedback rápido com as pessoas que estão usando o sistema de design. Feedback mais rápido e iterações menores podem ajudar a evitar ir longe demais na direção errada e ter que mudar drasticamente o curso. PJ Onori chama essas mudanças repentinas e grandes de “thrash”. Ele diz que um pouco de thrash é bom - é um sinal de que você está aprendendo e respondendo às mudanças - mas isso pode ser perturbador. “Você não deve temer o thrash”, diz ele, “mas você precisa saber quando é útil e como ajudar a mitigar suas desvantagens. Uma das melhores [maneiras] de mitigar as desvantagens do thrash é começar pequeno – com tudo .”

Considere começar pequeno, configurando alguns elementos básicos:

• Um sistema de controle de versão para armazenar seu código. GitHub, GitLab e Bitbucket são ótimas opções aqui. Certifique-se de que todos os usuários do sistema possam acessar o código e propor alterações. Se possível, considere tornar o código de código aberto para atingir o público mais amplo possível.
• Código CSS para implementar o sistema. Use variáveis ​​Sass ou propriedades personalizadas CSS para armazenar “tokens de design” – valores comuns, como larguras e cores.
• Um arquivo package.json que define como os aplicativos podem construir e instalar o sistema de design.
• Documentação HTML que demonstra como usar o sistema de design, de preferência usando o próprio CSS do sistema.

A documentação do node-sass para a estrutura CSS Bulma descreve essas etapas com um pouco mais de detalhes. Você pode pular a instalação e importação do Bulma se quiser começar do zero, ou pode incluí-lo se quiser começar com alguns dos princípios básicos.

Você deve ter notado que eu não mencionei nada sobre JavaScript aqui. Você pode querer adicionar esse elemento eventualmente, mas não precisa dele para começar. É fácil entrar em uma toca de coelho pesquisando as melhores e mais novas ferramentas JavaScript, e se perder nessa pesquisa pode dificultar o início. Por exemplo, “5 razões pelas quais os componentes da Web são perfeitos para sistemas de design” e “Por que eu não uso componentes da Web” são pontos válidos, mas somente você pode decidir quais ferramentas são adequadas para o seu sistema. Começar com apenas CSS e HTML permite coletar feedback do mundo real que o ajudará a tomar essa decisão quando chegar a hora.

Conforme você lança novas versões do sistema, atualize o número da versão do seu sistema para indicar o que mudou. Use o controle de versão semântica para indicar o que mudou com um número como "1.4.0". Incremente o último número para correções de bugs, o número do meio para novos recursos e o primeiro número para grandes mudanças disruptivas. Continue se comunicando com as pessoas que usam o sistema de design, peça feedback e contribuições e faça pequenas melhorias à medida que avança. Essa maneira colaborativa e iterativa de trabalhar pode ajudar a minimizar o “thrash” e estabelecer um senso de propriedade compartilhada.

Por fim, considere publicar seu sistema de design como um pacote no npm para que os desenvolvedores possam usá-lo executando o comando npm install your-design-system . Por padrão, os pacotes npm são públicos, mas você também pode publicar um pacote privado, publicar o pacote em um registro privado ou solicitar aos desenvolvedores que instalem o pacote diretamente de um sistema de controle de versão. Usar um repositório de pacotes tornará mais fácil descobrir e instalar atualizações, mas instalar diretamente do controle de versão pode ser uma solução fácil de curto prazo para ajudar as equipes a começar.

Se você estiver interessado em aprender mais sobre o lado da engenharia das coisas, o Building Your Design System, de Katie Sylor-Miller, oferece um mergulho profundo e fantástico. (Divulgação completa: trabalhei com Katie.)

Empacotando

Os sistemas de design são compostos de código, designs e documentação, bem como relacionamentos, comunicação e confiança mútua. Em outras palavras, são sistemas sócio-técnicos. Para construir um sistema de design, não comece escrevendo código e escolhendo ferramentas; comece conversando com as pessoas que usarão o sistema. Aprenda sobre suas necessidades e restrições e ajude-os a resolver problemas. Ao tomar decisões técnicas, de design ou de estratégia, considere as necessidades dessas pessoas sobre a “melhor” maneira teoricamente de fazer as coisas. Comece pequeno, itere e comunique-se à medida que avança. Mantenha seu sistema o mais simples possível para minimizar o thrash e convide comentários e contribuições para estabelecer um senso de propriedade compartilhada.

Dando igual peso às considerações de engenharia e interpessoais, podemos obter os benefícios dos sistemas de projeto, evitando as armadilhas. Podemos trabalhar de forma eficiente e humana; não temos que escolher um sobre o outro. Podemos capacitar as equipes em vez de limitá-las. Equipes capacitadas nos ajudam a atender melhor nossos usuários – e é por isso que estamos aqui em primeiro lugar.

Leitura adicional no SmashingMag:

• Dicas para gerenciar sistemas de design
• Incluindo animação em seu sistema de design
• Além das ferramentas: como construir um sistema de design pode melhorar a maneira como você trabalha
• Construindo um sistema de projeto em larga escala para o governo dos EUA (estudo de caso)