6 perguntas sobre o sucesso e o fracasso de sistemas de design

Ultimamente, participando do desenho inicial de um sistema de design, tenho pensado bastante sobre isso.

Relacionado a isso, li isto na semana passada no UX Collective. Eu traduzi para os membros do sistema de design dentro da empresa e achei um desperdício não compartilhar aqui também.

Dizem que é um resumo de entrevistas com 10 designers que trabalham com sistemas de design.

Pergunta 1. Como fracassar em uma função de DS?:

• Virar a polícia

• Usar o poder do designer (falar de política)

• Integrar componentes e depois não usá-los

• Trabalhar de forma reativa em vez de antecipar as necessidades do time

• Não ouvir nem pesquisar a voz dos usuários (outros designers ou desenvolvedores)

• Um DS feito para o próprio DS

• Não manter um roadmap e um processo claros para o trabalho

• Criar uma experiência idealizada impossível de realizar

• Não testar junto com o time

• Não entender o DS como um produto

• Criar ferramentas e não ensinar as pessoas a usá-las

• Trazer teoria demais, distante da forma real de trabalhar

• Achar que dá para fazer tudo sozinho

• Não focar 100% em troca de conhecimento com alguém do time técnico

• Criar componentes flexíveis de menos e não permitir detaching

• Não pedir ajuda nem se conectar com as pessoas (internamente ou externamente)

• Ditar regras de longe, e não de perto, lado a lado

Pergunta 2. Quais soft skills são necessárias para que um DS tenha sucesso?

• Comunicação, comunicação, comunicação!!!

• Estar com os usuários, ouvir, perguntar e pesquisar é realmente importante.

• Reconheça os fracassos com humildade

• Tenha paciência

• Capacidade de criar um espaço seguro

• Ensinar

• Apresentar uma visão estruturada sobre como reutilizar

• É preciso manter consistência com firmeza também na expansão

• Ao entender a outra pessoa, não é necessário se projetar tanto. Aceite as regras como elas são.

• 95% é hard skill e 5% é soft skill para quando algo sair das regras.

• Incentive o crescimento das pessoas e compartilhe

• Autonomia

• Continue vendendo o produto (DS)

• Pense estrategicamente

• Faça com que todos participem

• Gerar barulho em torno do DS

• Dedique o máximo de tempo possível para descobrir o maior número possível de cenários

• Alinhe a linguagem.

Pergunta 3. A forma como o DS é operado deve ser mais centralizada ou mais distribuída?

Existem duas formas: uma equipe centralizada que verifica e se responsabiliza por como as pessoas projetam, e outra em que todos compartilham essa responsabilidade. Perguntaram às pessoas qual lado faria mais sentido escolher.

• Somos uma equipe centralizada demais, então surgem gargalos. Mas um modelo distribuído também pode ter problema de enfraquecimento de ownership.

• Temos uma equipe de designers com mais de 100 pessoas para centralizar o DS.

• Colaboramos com bibliotecas alpha criadas pelas pessoas e a partir disso montamos o backlog do time de DS.

• Educamos as pessoas para que criem componentes por conta própria.

• Centralizar ou não é, em grande parte, uma questão política. Antes de decidir isso, é preciso saber exatamente o quanto o sistema precisa escalar.

• É preciso ajustar expectativas e envolver as pessoas na construção do DS.

• Queríamos colaborar, mas não sabíamos bem como, então criamos um processo. (Culture vs Process)

• No começo, pode ser um pouco menos colaborativo para garantir a entrega. Conforme amadurece, pode se tornar mais colaborativo.

• Agora chegamos ao momento de descentralizar isso; precisamos ensinar as pessoas a contribuir.

• Se você não educar as pessoas, elas não vão contribuir.

• Quando um designer quiser ir além do padrão e criar algo melhor, é preciso conseguir pensar ao mesmo tempo em como padronizar isso.

• DS não é algo que 1 ou 2 pessoas consigam fazer sozinhas. Como se trata de construir um sistema, o DS deve começar no nível de squad.

• Isso varia muito conforme o tamanho do time; às vezes o time de DS foca no desenvolvimento de componentes core, e outros embaixadores podem disseminá-los.

-No fim, somos uma equipe centralizada, mas trabalhamos de forma colaborativa com embaixadores. A decisão final fica com o time de DS.

4. Você acha que o DS são regras mais detalhadas e restritivas? Ou algo mais amplo e aberto, que dá liberdade para o designer criar novos layouts?

Fechado ou aberto? Se você trabalha com sistema de design, provavelmente esta pergunta interessa. Como também me interessa, resolvi perguntar às pessoas.

• Em relação à "acessibilidade", adote uma abordagem mais restritiva

• Todos começamos a partir de uma estrutura básica, mas começamos a criar algumas inconsistências. Por isso, decidimos não ser 100% fechados, mas impor um pouco mais de restrições. Ainda assim, sempre tentamos encontrar formas de devolver algo ao designer

• Depende da situação, então meça primeiro o risco e depois decida. Em geral, time menor = mais flexibilidade

• Não se trata apenas de ser criativo e criar novos componentes. São necessários componentes flexíveis o bastante para atender às necessidades das pessoas

• DS é negócio. Quanto menos componentes, melhor.

• As pessoas precisam gostar de usar o DS. À primeira vista, por parecer um uniforme, é fácil achar que não precisa de flexibilidade (mas precisa)

• Não dá para ser muito restritivo desde o início. Com tempo suficiente, ele pode começar a evoluir para certos padrões.

• Para designers que estão entrando agora na empresa, mais restrições podem ajudar. Para quebrar as regras, primeiro é preciso partir delas.

• Oferecemos ingredientes suficientes para que as pessoas criem suas próprias receitas.

• Isso depende da maturidade do time. Se houver mais juniores, como eles entendem menos documentação, tendem a pedir mais diretrizes de design. Então mais treinamento passa a ser necessário, mas ainda assim tentamos não prendê-los e permitir que trabalhem com liberdade. O maior desafio é fazer com que as pessoas leiam e usem a documentação por conta própria, então existe a possibilidade de levar isso para mais perto do designer, como no Figma.

• Se for sobre acessibilidade e estética, precisa ser mais restritivo.

• Tokens são importantes para manter a consistência.

• Uma boa documentação equilibra harmonizar as pessoas e deixá-las livres.

Pergunta 5. O que vocês acham de um DS conectado a branding e marketing?

(Como não conheço muito bem essa área, a tradução ficou um pouco difícil.)

Entendo que sistema de design, no fim das contas, deve ser algo voltado a produtos digitais, mas como o produto pode ser uma das plataformas de marca mais importantes, fiquei curioso para saber como as pessoas pensam essa conexão.

• Uma forma de pensar sobre o branding conectado ao DS é pensar em como isso influencia o DS no sentido inverso.

• Começamos a alinhar o sistema de design à marca para alinhar a aparência e a sensação da marca.

• DS é sobre escalabilidade e identidade de marca, mas a conexão entre os dois varia conforme o time de branding.

• Since DS is a language, MKT could support with assets for it;

• O time de branding deve entrar no DS desde o começo para estabelecer as regras básicas.

• Depende da empresa. Como o DS é uma ferramenta para fortalecer a marca, alinhar as duas coisas é importante. A conexão entre essas duas áreas também afeta a acessibilidade do DS.

• É importante encontrar uma forma de sincronizar com o time de branding para alinhar a estratégia.

• They were used to join projects that the company already had a partner to support with branding, so they would come together with these partners to bring the brand inside the DS;

• Às vezes documentação e sistema podem ser usados juntos, mas em geral não. DS é interface. O time de marca costuma ter um "sistema de branding" separado, e o mais comum é que as bibliotecas interajam entre si. Os dois não são completamente iguais.

Pergunta 6. Como medir o sucesso de um DS?

• Pesquisas de percepção para entender participação, adoção e o estado dos times

• Cobertura de componentes (o quanto o DS está sendo usado vs o quanto está hardcoded)

• Adoption

• Time to market

• ROI

• Figma Analytics

• Reação dos times de desenvolvimento

• Acessibilidade

• Número de vezes que os componentes foram usados

[xguru]

Uau, muito bom. Obrigado por organizar isso!