Design em escala — destaques e comentários sobre o livro
No inicio do ano terminei a leitura do livro Design em Escala, de Filipe Nzongo. Retomo o livro agora para destacar as partes que mais me chamaram atenção e que já foram ou acredito que serão úteis para o meu trabalho. A intenção desse texto é compartilhar conhecimento com o time com quem trabalho e com a comunidade interessada em Design System e continuar a conversa iniciada pelo autor através do livro.
O livro conta com uma parte sobre História do design system (capítulo 1) que considero muito valioso. Passando pelo Atomic Design e creditando pessoas importantes para a evolução até o entendimento que temos hoje de sistemas de design.
Auditoria de Design System
Todos os produtos da empresa devem seguir o Design System? Como funciona a questão da auditoria? Pretendemos implementar esse processo na empresa ainda esse ano. Por isso, o exemplo do Material Design (p. 15) caiu como uma luva. O autor explica que no inicio o time fazia revisão de todos os produtos e fala sobre como isso era cansativo. É introduzido o conceito de brand proximity e citado que o YouTube ainda possui um Design System próprio que não é tão próximo do Material.
A ideia de brand proximity pode ajudar os times de Design System a priorizarem quais produtos devem vir primeiro em questões como auditoria e consultoria.
No capítulo 4 — Linguagem de design, contamos com um subtítulo sobre o mesmo assunto. “A maioria das vezes não dá retorno financeiro imediato, mas ela mostra quanto a empresa valoriza a experiência do usuário, como também mostra a sua maturidade” (p. 122). O autor ainda cita que a auditoria garante que a marca não está se tornando inconsistente.
Design System é um produto
“(…) Muitas empresas não sabem que um sistema de design é um produto por si só, que permite às organizações sistematizarem seus produtos, conteúdos e serviços digitais em escala.” (p. 24)
É essencial para um time de Design System se posicionar como um time de produto. Quando o sistema de design é enxergado como um serviço, o time passa a ter problemas para se sustentar. É necessário que os outros times enxerguem que temos um roadmap, um backlog, KPIs, a manutenção, a comunicação, as consultorias, etc. Quando o Design System é enxergado como serviço, a responsabilidade de evoluir o produto passa a ser centralizada. Quando visto como produto, a responsabilidade é compartilhada com outros times, como deve ser. No capítulo 3 — Sistemas de design na perspectiva do usuário, o autor ressalta a importância da consistência para os produtos e a responsabilidade compartilhada dessa entrega entre vários times (p. 102 à 104).
Alguns mitos
O autor traz alguns mitos sobre Design System e a realidade de seu ponto de vista. Me serviu muito para reflexão. No momento da leitura desse capítulo me deparava com questionamentos externos sobre o sistema de design tirar a liberdade e limitar a criatividade do designer. Essas discussões e o livro serviram para acelerar o diálogo e as ações para flexibilização do Design System no qual trabalho.
Por que os sistemas de design falham?
Nesse subtítulo Nzongo levanta a questão de que, como designers, não somos educados para falar sobre nossas falhas e erros, somente êxitos e que isso, de certa forma, prejudica nosso trabalho e entregas. Eu concordo 100%. Sinto falta de conteúdos sobre sistemas de design que sejam focados em métricas e adoção e atribuo ao caráter experimental que o produto possui, com isso acredito que seguimos errando bastante e divulgando pouco.
Nessa questão sobre a falha de Design Systems, gostaria de destacar a parte que fala sobre comunicação (p. 50).
“Comunicação: a falta de comunicação pode levar seu sistema de design ao fiasco, por isso, é preciso que se estabeleça uma boa comunicação interna entre as equipes, seja de design, engenharia, produto, etc. Para que todos estejam alinhados. Além disso, delegue pessoas para divulgarem e advogarem pelo sistema de design na sua empresa. Tais iniciativas poderão fazer seu sistema de design ser usado de maneira correta. Desse modo, evitará falhas de comunicação entre as equipes. Fazer esse trabalho de curadoria, advocacia e comunicação pode ser um grande desafio, mas, se você encontrar o equilíbrio certo e for transparente, já é meio caminho andado.”
Outro assunto bem interessante abordado nesse capítulo, mas que não irei me aprofundar são os tipos e níveis de maturidade do sistema de design.
Documentação
O capítulo 8 fala sobre documentação e propõe um modelo bastante completo para Padrões. Me chamou a atenção o tópico “solução”:
“Solução: a solução aborda a reutilização de boas práticas de design recorrentes e como resolver as restrições relevantes. Essa solução deve ser escrita de uma maneira que dá ao designer uma ideia de como resolver as restrições com eficiência, mas não é como uma diretriz guideline, na qual você só precisa seguir as instruções passo a passo para chegar a uma solução. Portanto, a criatividade do designer é necessária para produzir uma boa solução.” (p. 225)
Ainda estamos engatinhando no quesito Padrões. Por isso, acredito que possa servir como uma inspiração para criarmos nossa forma de fazer.
O próximo tópico, “uso”, recomenda evitar Do e don’t em documentações por serem ineficazes para orientar designers. Em outro momento do livro o autor explica de forma mais aprofundada essa questão usando exemplos. Durante um bom tempo eu concordei com esse ponto, que não é uma boa ideia usar esse tipo de recurso. Porém, atualmente voltamos a testar isso na documentação do Design System no qual trabalho visto que os designers não são o único público do produto e que possuímos indícios qualitativos de que não são todos os usuários que leem as documentações. Esse recurso está sendo testado como um esforço para agilizar o entendimento sobre pontos críticos e melhorar a qualidade de uso dos componentes.
Esse capítulo também fala sobre documentação de componentes, cores, design tokens, espaçamentos, etc. Senti ser bem focado em designers. O Design System no qual trabalho é focado em pessoas desenvolvedoras, product designers, content designers, product owners, além de outras pessoas de desenvolvimento e produto. O livro é um material muito bom para iniciar reflexões, mas, como toda referência na vida, não poderá ser usado completamente da forma apresentada.
Workshops
Alguns capítulos trazem sugestões de workshops. Isso é bem interessante e já ajudou a mim e a equipe na qual trabalho. No capítulo 5 — Definindo os princípios de design há um workshop que usamos como referência para uma co-criação. Estamos evoluindo a documentação de Design System e, com isso, uma das etapas da criação da nova interface do DS foi o alinhamento com a Chapter de UX sobre os Princípios de Design que todos passaremos a seguir.
Conclusão
Além de todos esses assuntos que citei, o livro tem um capítulo focado somente em DesignOps e muito mais conteúdo sobre Design System que não caberia aqui. — Afinal, estamos falando de um livro em formato grande e de quase 300 páginas!
O que mais gostei no livro não foi uma parte em específico, mas o estado de reflexão para o qual ele me levou. Gostei bastante das descrições de documentação, dos workshops e da parte mais voltada para História. Era uma expectativa minha que adentrasse um pouco mais ao código, mas o tanto que entrou já me deixou com inquietações que vou correr atrás de realizar pesquisas sobre e conversar com os devs com quem trabalho. Fora que, não era uma proposta do livro falar sobre desenvolvimento e sim, design.
Quero aproveitar o espaço para deixar meu agradecimento ao professor Filipe Nzongo por compartilhar sua pesquisa. O livro pode ser adquirido pela loja UmLivro ou pela Amazon.
Se você estiver lendo esse livro e quiser conversar com alguém sobre ele, pode me chamar no LinkedIn (@juwviegas). Estou sempre aberta para conversar sobre Design System ;)
