#5-Design System e a revolução dos processos
Entenda como ele pode mudar radicalmente a forma como trabalhamos.
_________________
Oi,
sou o Thiago Hassu, fundador e CEO da Meiuca. Esse já é o 5º de uma série de artigos, uma introdução aos conceitos que farão parte da nossa Formação Online em Design System & Ops.
Se preferir, volte ao primeiro artigo para não perder nenhum detalhe: “Design System na visão da Meiuca”.
Vamos lá,
😋
_________________
Mais que componentes
No primeiro artigo dessa série contei um pouco da visão da Meiuca sobre o que de fato é um Design System. Compartilhamos inclusive nossa própria definição, que construímos durante os últimos 3 anos:
“Um ecossistema de bibliotecas com componentes codados a partir de semânticas de design e gestão de estilo centralizada.”
Lembra? Realmente, os componentes são parte fundamental do que é um Design System, mas o seu impacto vai muito além da consistência. No quarto artigo falei um pouco sobre como eles e os Design Tokens, nossas variáveis semânticas de estilo, otimizam a comunicação entre design e tecnologia. Graças a esses dois elementos 100% espelhados, começamos finalmente a falar a mesma língua. E isso abre um mundo de novas possibilidades para melhorar a forma como trabalhamos!
Uma API de Design
Alguns anos atrás, assisti uma daquelas palestras que explodem nossa cabeça. Foi quando o Karri Saarinen, na época Design System Lead do Airbnb, falou no DS Conf 2018. Naquela altura ele já encarava um Design System como uma API de design, capaz de revolucionar nossos processos e métodos.
Nessa mesma palestra, citou dois exemplos que tangibilizam radicalmente esse mindset. O primeiro foi a mudança de flow na construção das telas entre negócios, design e tecnologia (conto em mais detalhes na nossa 1ª Aula Grátis da Formação). O segundo, que mais parece ficção científica, é como estavam aplicando reconhecimento de imagem e inteligência artificial para transformar um wireframe feito à mão em uma interface com código limpo.
Veja com seus próprios olhos:
Imagine o quanto isso poderia mudar radicalmente a sua esteira de produto. Hoje você descobre uma necessidade, cria um wireframe, depois um protótipo e vai validar o desejo e/ou a usabilidade com seu usuário. Refina sua interface a partir do resultado dos testes e depois prepara a passagem de bastão para o time de tecnologia, que pega o seu trabalho e desenvolve, na maioria das vezes, tudo do zero. Algumas sprints depois, isso vai pra rua.
Agora imagine que seria possível, por exemplo, reunir os seus usuários, rodar um workshop de co-criação e rabiscar alguns wireframes ali, na hora. E, em uma pausa de alguns minutos para o café, transformar esses insights em um protótipo de altíssima fidelidade. Foi bem nos testes? Estaria pronto para ir ao ar na mesma hora. Parece promissor, não é mesmo?
Listei abaixo outros ganhos e consequências que um Design System pode trazer ao seu dia a dia para ajudar você a reinventar os seus processos:
1. Designers fora do computador
Hoje ligamos Design System aos nossos softwares de design: “como o Figma pode ajudar? E o Sketch?”. Mas uma das consequências mais maravilhosas dele é justamente a economia de tempo em que os time de design passam em seus softwares. Um Design System bem implementado vai garantir que você peça um ajuste ou até uma interface inteira apenas “ditando” o que precisa ao seu time técnico.
“Fulano, na nossa tela de login preciso trocar aquele Secondary Button pelo Link Arrow, fechou? E ahhh, coloca um Spacing Stack MD entre eles pra dar aquele ritmo vertical que o povo gosta, tá? :)”
Claro, você vai criar boas práticas para sua squad não virar uma feira livre. O grande ponto aqui, é entender que economizará um tempo absurdo na passagem de bastão entre design e tecnologia. E esse tempo “que sobra” vai ajudar seu time de design a estar mais próximo do seu usuário e do negócio.
2. Comportamentos e micro-interações
Hoje, no flow “tela por tela”, acaba sempre faltando tempo para detalhar todos os comportamento e micro-interações. Acaba sempre escapando alguma coisa. A partir de um Design System, investimos esse esforço uma única vez. Depois basicamente precisamos indicar que ali vai o “componente x”, todas as suas validações e seu comportamento já estão previstos lá na biblioteca que nosso time de tecnologia tem acesso. Em outras palavras, o seu layout vira apenas uma representação gráfica para ajudar o time de tecnologia a entender o que está na sua cabeça (tipo como o ditado, só que mais bonitinho).
3. Wireframe nem faz mais sentido
Você ainda perde tempo criando um protótipo de baixa fidelidade? Com componentes bem consolidados isso deixa de ser necessário. Prototipamos em alta, o que aumenta a fidelidade inclusive dos resultados do teste. E claro, corta um tempo danado em todo o flow de design. Se você for um designer que manja um pouco de front end, pode ainda cogitar a possibilidade de prototipar com código inclusive.
4. Design e tech na mesma sprint
Uma das maiores dores das nossas squads hoje é a distância entre o que design projeta e o que tecnologia coloca no ar. Geralmente separados por uma, duas, três ou muito mais sprints. Isso acontece muito em razão do tempo que designers precisam para cumprir todo o seu flow: pesquisa, protótipo, teste e refinamento da solução. E isso traz algumas consequências. A primeira e mais óbvia é uma maior necessidade de documentação, para garantir que o time de tecnologia entenda de fato tudo aquilo que foi projetado. Outro ponto importante é que acaba colocando desenvolvedores em um papel apenas de executores, não como alguém que olha para o produto, qualquer sugestão acaba sendo “tarde demais”. Sem contar que essa distância entre as sprints só alonga seu time to market, o tempo em que sua empresa demora entre perceber uma dor e disponibilizar uma solução ao mercado (vamos falar mais disso no próximo artigo). Com um Design System e um time entrosado, fica muito mais viável desenharmos um processo onde design e tecnologia trabalhem de fato juntos, resolvendo o mesmo problema em uma mesma sprint.
5. Design Tools
Todo negócio tem particularidades e, muitas vezes, elas acabam gerando grandes gargalos de design. Imagine o tempo que o time do Netflix investe criando capas para suas séries (eles fazem teste A, B, C…X de todas elas). Para resolver essas questões, alguns times estão apostando na criação do que chamamos de Design Tools, ferramentas capazes de otimizar toda a nossa cadeia de produto. Cada vez mais vemos empresas investindo em software para escalar a forma como fazem mais software. A traquitana do Airbnb que apresentei acima é um exemplo. O Theo, projeto open source da Salesforce que converte Design Tokens em diferentes folhas de estilo, também. Então muito provavelmente, com um Design System e um time de Design Ops bem consolidado esse seja o seu próximo passo.
6. Brand System
Outro ganho incrível é testemunhar o mindset de escala se espalhando pela empresa. E aí, acabamos sistematizando muito mais do que as nossas interfaces. Hoje já começamos a falar do quanto isso está entrando em uma certa camada de marca, para escalar a forma como nos comunicamos. Um ótimo exemplo é o último rebranding do Uber, saca só.
Mas quem pensa nesses processos?
No terceiro artigo dessa série falei um pouquinho sobre Design Ops, sobre suas responsabilidades e, que com certeza, uma das mais importantes é construir bons processos para sua esteira de produto. Sempre tento resumir dizendo que os líderes de design e tecnologia devem apontar “o que fazer”, enquanto o time de Design Ops aponta “como fazer”. Simples assim!
:)
_________________
O que vem por aí?
No próximo artigo vamos falar um pouco mais sobre o impacto do Design System no Time to Market, ponto fundamental para as grandes empresas sobreviverem ao “novo normal” que vem por aí.
