Um sistema de design pode falhar sem previsão cuidadosa, esforço diligente e suporte

Ossistemas de design estão tão quentes agora – e por boas razões. Eles promovem uma abordagem modular para criar um produto e garantir a unidade e a estabilidade organizacional por meio de trechos de código reutilizáveis, componentes de interface do usuário e estilos de utilitário. Eles tornam a prototipagem fácil e fornecem uma linguagem comum para designers e desenvolvedores.

Um sistema de design é o culminar de vários componentes individuais, que podem incluir qualquer um ou todos os seguintes:

• Guia de estilo ou biblioteca de padrões visuais
• Ferramentas de design (biblioteca de esboços, por exemplo)
• Biblioteca de componentes (onde os componentes vivem no código)
• Diretrizes e documentação sobre uso de código
• Documentação de uso de design
• Diretrizes de voz e tom
• Diretrizes da linguagem de animação

Os sistemas de projeto são produtos autônomos (internos ou externos) e provaram ser um meio muito eficaz de desenvolvimento orientado ao design. No entanto, para que um sistema de design seja bem-sucedido, todos precisam embarcar.

Eu gostaria de discutir alguns fatores que podem ajudar a garantir – ou dificultar – o sucesso do seu sistema de design. Alguns desses conceitos serão mais focados no desenvolvedor, mas a maioria é adaptável entre disciplinas.

Suporte Organizacional

Simplificando, qualquer produto, incluindo produtos internos, precisa de suporte. Algo tão multifuncional quanto um sistema de design, que é usado por todas as equipes de projeto verticais, precisa do suporte dos níveis superior e inferior de sua organização.

Suporte de nível superior significa que todos, desde os gerentes de projeto até os VPs, entendem o valor de um sistema de design, fornecem recursos para sua implementação e defendem seu uso em toda a empresa. Isso é especialmente importante em empresas em que esses sistemas estão sendo implantados em cima de bases de código existentes, porque isso pode significar que alguns esforços precisam ser programados para refatoração do trabalho.

Com os sistemas de design, pequenos investimentos incrementais ao longo do tempo levam a grandes ganhos em geral.

O suporte de baixo para cima significa que os projetistas e engenheiros de todos os níveis apóiam esse sistema e se sentem responsáveis ​​por ele. Um sistema de design é o produto de uma organização e todos devem se sentir confiantes contribuindo para isso. Se o seu sistema de design também suporta clientes externos (como contratados), eles também podem se tornar parceiros valiosos.

Investimento

Um sistema de design precisa de apoio e amor para crescer. Também precisa de investimento contínuo de esforço e recursos. Eu gosto de comparar isso com o trabalho.

Você pode exercitar-se intensamente por três meses e ver alguns ganhos, mas uma vez que você pare de se exercitar, esses efeitos desaparecerão lentamente. Se você continuar a se exercitar, mesmo que seja menos frequente do que o esforço inicial, você se verá mantendo a sua forma física.

Da mesma forma, se você passar três meses revisando seu sistema de design, mas negligenciando mantê-lo, enfrentará a mesma situação. O impacto irá desaparecer à medida que o sistema ficar fora de sincronia com novos designs e você acabará com pedaços de código desconectados e elementos de design que ninguém está usando. Seus engenheiros e projetistas deixarão de usá-lo quando os padrões ficarem desatualizados, e então você se verá temendo outra rodada de investimentos substanciais.

Com os sistemas de design, pequenos investimentos incrementais ao longo do tempo levam a grandes ganhos gerais.

Com esse ponto, também quero observar que, devido ao dimensionamento, os sistemas de design podem ter um impacto considerável em toda a plataforma, o que torna extremamente importante investir em itens como acessibilidade e arquitetura sólida desde o início. Você não quer escalar um sistema frágil que não seja fácil de usar.

Cuide do seu sistema de design e continue trabalhando nele para garantir sua eficácia.

Responsabilidade

Uma maneira de fazer isso é ter uma equipe dedicada trabalhando no sistema de design, gerenciando tickets e atualizações de estilo que vão para o resto da sua empresa. Com uma equipe específica para atuar como proprietária do sistema de design, seja a equipe de projeto, a equipe de engenharia ou uma nova equipe formada por designers e engenheiros (a melhor opção), sua empresa tem mais chances de manter sistema atualizado que não quebra.

Esta equipe é responsável por algumas coisas:

• Ajudando os outros a se instalarem no sistema (suporte)
• Projetando e construindo componentes (desenvolvimento)
• Defendendo a consistência e aderência geral da interface do usuário (evangelismo)
• Criando um plano de implementação e um sistema de atualização (gerenciamento de produtos)

Isso é um monte de papéis, por isso ajuda ter várias pessoas nesse time, pelo menos em meio período. Uma coisa que descobri ser eficaz é manter o horário de expediente para ajudar todos a se prepararem e responder a qualquer pergunta sobre o uso do sistema. Ter um canal aberto do Slack também ajuda com isso, assim como trazer bugs / problemas / ideias e fazer anúncios como novos lançamentos.

Comunicação

Uma vez que você tenha recursos e um plano para investir em um sistema de design, é realmente importante que a pessoa ou equipe responsável atue como uma ponte entre o design e a engenharia. A comunicação contínua é crucial aqui, e a maneira como você se comunica é ainda mais importante.

Lembre-se de que ninguém quer saber o que fazer, especialmente designers e desenvolvedores, que costumam ter muita autonomia. Apesar de quanto ou quão pouco controle os outros stakeholders têm ao longo do processo, eles precisam se sentir como se tivessem contribuído e se sentissem ouvidos.

Construir e manter um sistema de design é surpreendentemente muito trabalho de pessoas. Para conseguir o buy-in, você precisa fazer as pessoas quererem usar o seu sistema de design.

Isso pode ser um desafio, especialmente porque, em última análise, alguma parte precisa tomar uma decisão final sobre direção e execução. Como é difícil encontrar um equilíbrio, ter canais de comunicação abertos e ser o mais transparente possível o mais cedo possível é um bom começo.

Compra em

Uma boa comunicação também é importante para obter a adesão dos seus usuários (engenheiros e projetistas), bem como do gerenciamento de produtos.

Construir e manter um sistema de design é surpreendentemente muito trabalho de pessoas.

Para conseguir o buy-in, você precisa fazer as pessoas quererem usar o seu sistema de design.

Reúna exemplos e use vitórias, porque mostrar é muito mais poderoso do que contar.

Se você puder, peça aos desenvolvedores que usem seu produto em uma situação de baixo risco, onde ele oferece benefícios claros. “Hackathons” são um ótimo lugar para estrear seu sistema de design. Nosso hackathon vinterno na DigitalOcean foi uma oportunidade perfeita para:

• Evangelize pelo sistema de design
• Veja o que as pessoas estavam usando a biblioteca de componentes e com o que estavam lutando (excelente teste de usuário)
• Obtenha feedback do usuário sobre como melhorá-lo em futuras iterações
• Deixe as pessoas experimentarem os benefícios de usá-las

Esses tipos de momentos, onde as pessoas exploram por conta própria, são onde você pode realmente colocar as pessoas do seu lado e querer usar o sistema de design, porque elas podem colocar as mãos nele e tirar suas próprias conclusões (e se não o fizerem amá-lo, ouvi-los e melhorá-lo para que eles façam). Nem sempre temos a sorte de ter esse tipo de feedback instantâneo de nossos usuários diretos.

Arquitetura

Para garantir que seu sistema de design seja escalonável, é importante desenvolver uma arquitetura sólida no início do processo. Construa seu sistema de design com o crescimento em mente. O que acontece se sua empresa adquirir um novo produto? O que acontece quando se desenvolve um novo segmento de mercado? Como você pode ter certeza de que há espaço para customização e crescimento?

Algumas coisas que achamos úteis, do ponto de vista do desenvolvimento, incluem:

Espaçamento de Nomes

Use namespacing para garantir que o sistema não colida com os estilos existentes se aplicado a uma base de código existente. Isso significa prefixar todos os elementos do sistema para indicar que faz parte do sistema de design. Para certificar-se de não quebrar partes da compilação existente (que podem ter elementos base estilizados), você pode namespace todo o sistema dentro de uma classe pai. A estrutura aninhada do Sass facilita isso.

Esse tipo de namespace não seria necessário em novos projetos, mas é definitivamente útil ao integrar estilos novos e antigos.

Versão semântica

Eu usei versões semânticas em todos os sistemas de design em que trabalhei. O versionamento semântico usa um sistema de Major.Minor.Patch para atualizações. Você pode, então, marcar as versões no GitHub com atualizações com versão e se proteger contra o aplicativo de alguém que seja interrompido acidentalmente quando houver uma atualização, se elas estiverem ancoradas em uma versão específica (o que elas devem ser).

Também usamos essa versão semântica como um link com os recursos de nosso sistema de design (nossa biblioteca Sketch) para mantê-los em sincronia, com o mesmo número de versão correspondente ao Sketch e ao código.

Você tem que fazer do seu sistema de design o caminho de menor resistência, diminuindo a sobrecarga cognitiva do desenvolvimento e do design, não aumentando a sua capacidade.

Nosso sistema de design é servido como um módulo Node, mas é acessível através de nosso CDN como uma série de recursos construídos para prototipagem rápida e projetos únicos. Para esses recursos construídos, executamos um script de implantação que cria automaticamente pastas para cada versão, bem como uma pasta “mais recente”, se alguém quiser a versão sempre atualizada do sistema de design.

Portanto, o versionamento semântico é o que vincula os ativos do módulo Nó do nosso sistema de design, os recursos da biblioteca do Sketch e os ativos de arquivo estaticamente criados. Fornecer várias maneiras de consumir nosso sistema de design facilita a adoção e reduz o atrito.

Atrito

Algum tempo atrás, coloquei a questão de por que os sistemas de design se tornaram desatualizados e não utilizados, e uma conclusão importante que tirei da conversa foi: se é mais difícil para as pessoas usarem do que o sistema atual, as pessoas simplesmente não o usam.

Você tem que fazer do seu sistema de design o caminho de menor resistência, diminuindo a sobrecarga cognitiva do desenvolvimento e do design, não aumentando a sua capacidade. Isso é vital. Um sistema de design destina-se a tornar o desenvolvimento e o design muito mais eficientes, impor um estilo consistente em todos os sites e permitir que todos se preocupem menos com pequenas decisões, como tamanhos de fonte e semântica de HTML. Estes já estão resolvidos para eles, o que significa que eles podem se concentrar na construção do produto.

Mas se o seu sistema de design for complicado e ultrapassado, eles podem achar frustrante o uso e voltar ao que sabem, mesmo que não seja a melhor solução. Por exemplo, se você é um especialista em Sass e baseia seu sistema em mixins e funções complexas, é melhor esperar que seus desenvolvedores também sejam especialistas em Sass, ou queiram ser. Este não é o caso, no entanto. Você precisa falar com seu público e aprender sobre como eles funcionam e como eles vão querer usar seu sistema.

Reduzir o atrito para adoção deve ser um dos principais objetivos do lançamento do seu sistema de design.