Há um grande número de artigos que ensinam como os designers podem dizer não . Isso é principalmente sobre freelancers e como interagir com clientes difíceis. Há também artigos com dicas para lidar com Product Managers. No entanto, e quando você está apoiando um Design System? O que fazer com solicitações conflitantes de outros designers ou desenvolvedores.

Ainda não sei o que estou fazendo…

Se você não é um especialista e está apenas começando a criar um sistema de design para sua empresa do zero, pode não saber que direção tomar. Você pode, claro, ler vários artigos com receitas sobre “ como começar ”, mas às vezes nada melhor do que a experiência pessoal. Tentar algo, cometer erros às vezes e aprender com os erros. Estar aberto a coisas novas. Seja uma pessoa “Sim, vamos tentar”.

Você tem que ser o mais flexível possível em tal situação. No entanto, documente suas decisões se você não quiser que as decisões bem-sucedidas permaneçam como “magia negra” e as malsucedidas permaneçam como uma coincidência desconhecida.

Não me refiro apenas a anotar a decisão em si, mas como você (ou outros) chega lá. Argumentos, etc. Sim, isso pode ser, às vezes, difícil. Especialmente quando a decisão foi intuitiva (intuição). No entanto, se você aprender a questionar a si mesmo e aos outros, poderá eventualmente começar a entender a origem da ideia.

Essa documentação permitirá que você entenda melhor as relações de causa e efeito e aprenda o que funciona e o que não funciona. E da próxima vez, se você perceber que uma nova proposta se encaixa em um padrão conhecido (ou segue na mesma direção), você poderá apontar isso para outras pessoas. Ou seja, você aprenderá a dar razões fundamentadas contra soluções arriscadas.

Já vi isso em algum lugar antes…

Você sempre pode pedir exemplos à comunidade quando se trata de más decisões . Designers (e muitas outras profissões) gostam de fazer listas do que não fazer .

Há uma grande variedade de artigos na categoria “ 10 Piores Decisões de Design ” e similares. No entanto, no que diz respeito a sistemas de design, o mais importante será a descrição de práticas “Boas/Más”, “Padrões”, “Fazer e Não Fazer”, etc. E o melhor é procurá-los na documentação de sistemas de design abertos.

Freqüentemente , esses documentos fornecem argumentos concisos, mas concisos, a favor ou contra uma solução específica e podem ajudar muito na análise de situações que surgem em seu sistema. E até mesmo em seu trabalho diário de design.

“O que fazer e o que não fazer” é um elemento-chave de qualquer documentação de projeto de sistema e quanto mais cedo você começar a documentar as práticas “boas/ruins” para o seu sistema, mais perguntas e mal-entendidos você poderá evitar.

“ Se não está documentado, não existe ”

A documentação é um compromisso. Mas também orientações sobre “o que posso/devo fazer”. Afinal, os designers muitas vezes tomam decisões questionáveis ​​porque não estão cientes do que deve e do que não deve ser feito dentro do sistema de design. Na sua ausência, a afirmação “tudo é possível” é um pensamento razoável.

Mas aqui é importante ressaltar: documentação não é sobre banimentos. A documentação é projetada para explicar como o sistema funciona e indicar razoavelmente o que vale a pena fazer e o que não vale. Da mesma forma, se o designer (ou desenvolvedor) for motivado apenas por “eu gosto assim” e isso contradizer a documentação - você tem um motivo razoável e justificável para recusar, referindo-se à documentação.

A documentação ajuda a dar um bom exemplo para que outros argumentem suas ideias. E transforme ideias em soluções que ajudarão a levar seu sistema de design para o próximo nível.

Biblioteca de design ≠ Sistema de design

Muitas vezes surgem problemas quando os usuários (ou colaboradores) não entendem o que é um sistema de design e pensam nele como uma biblioteca de design. Muitos designers estão acostumados a lidar com bibliotecas de design prontas para uso e ter que modificá-las para atender às suas necessidades.

“Gosto deste UI-Kit, mas foi criado sem qualquer consideração pelos meus casos de uso e por isso preciso personalizá-lo”. Parece bastante razoável, não é? Sim, se estivermos falando de soluções de terceiros das quais você (ou outra pessoa) usará apenas uma pequena parte. Mas no caso de um sistema de design interno, isso pode levar ao caos.

Algo parecido com isso, mas um pouco diferente….

Na minha opinião, o mais difícil é quando os usuários solicitam pequenas alterações. Alterações bem pequenas:

• Adicione a capacidade de usar ícones em cabeçalhos.
• Altere a ordem dos blocos na lista.
• Mostrar 3 botões em vez de 2 (definidos por um componente).

• Coerência da abordagem com outros componentes.
• A complexidade de implementação em componentes de código e design (Figma, Sketch, etc.).

Primeiro, você precisa descobrir se o padrão se cruza com algum outro componente. Para fazer isso, você precisa conhecer todos os componentes e seu comportamento de cor ou passar por cada um deles e ver se a proposta entra em conflito com algum dos outros componentes. Se houver os menores conflitos, é necessário discutir a proposta não isoladamente, mas no contexto do comportamento de vários componentes. Muitas vezes, isso pode exigir o convite de mais pessoas para a discussão.

A complexidade da implementação

Muitas vezes, o que parece uma solução simples em design pode exigir um grande esforço de desenvolvimento. Talvez porque a arquitetura atual não seja suficientemente flexível. Talvez vá contra os padrões/abordagens básicos usados ​​no desenvolvimento. Teoricamente, quase tudo é possível, mas algumas coisas exigirão mais esforço. Em tal situação, você pode precisar entender a importância dessas mudanças: “Bom ter” ou “necessidades críticas”.

Somos servos, não ditadores

O sistema de design é um produto . Mas é muito específico. Embora o sucesso da maioria dos produtos possa ser medido por quanto dinheiro eles ganham, para um sistema de design, o principal indicador é quantos usuários o utilizam e quanto isso facilita sua vida. Em outras palavras, um sistema de design é “O produto mais honesto” . E isso envolve muita responsabilidade. Não precisamos apenas tirar o melhor proveito do que os clientes desejam, mas também ajudá-los a entender as consequências de cada decisão questionável:

• falta de flexibilidade no prospect
• atrasos no desenvolvimento da solução (devido à complexidade da solução e sua manutenção)
• a necessidade de mudanças em cascata em outros componentes ou acordos
Gerenciando Contribuições do Sistema de Design

Em última análise, o sistema de design é sobre os usuários (designers e desenvolvedores). Então você tem que estar muito atento a eles. Afinal, sem eles não somos ninguém. E se as edições são razoáveis ​​e não quebram nada — por que não fazê-las?

Todos os motivos para dizer “não” são apenas para garantir que criamos o produto que os usuários precisam, não o que eles desejam.

Quando questionado sobre a contribuição do cliente no desenvolvimento do Ford Modelo T, Henry Ford disse a famosa frase: “Se eu tivesse perguntado às pessoas o que elas queriam, elas teriam dito cavalos mais rápidos”.

Obrigado por ler! Vamos ficar em contato! Conecte-se comigo no LinkedIn e siga-me no Dribbble e aqui no Medium para mais conteúdo relacionado a design.