#1 - Design System na visão da Meiuca
Como enxergamos o assunto 3 anos depois de sermos pioneiros no Brasil.
Antes de mais nada, acho que faz sentido apresentar a Meiuca. Hoje basicamente misturamos design, tecnologia e criatividade para levar inovação aos negócios e à sociedade. Pra fazer essa diferença no mundão temos a Meiuca Org, nosso braço sem fins lucrativos onde dedicamos parte do nosso tempo e lucro para minimizar desajustes sociais.
Mas por muito tempo, fomos 100% especialistas em Design System & Ops. Quebramos a cara, erramos e aprendemos muito durante essa jornada. Além de ajudar empresas de todos os portes e segmentos, criamos nossa própria metodologia e, com nosso Bootcamp até então presencial, formamos mais de 300 profissionais. Eu, Thiago Hassu, sou fundador e CEO dessas pessoas diversamente interessantes por aqui. E vou dividir nossa visão e alguns “hackzinhos” (uso bastante essa palavra) em 10 belos artigos com você. Combinado? :)
_________________
Importante: assim como muitas empresas, estamos repensando nossas ofertas de serviço e modelo de trabalho. Muito em breve vamos lançar uma nova série de artigos contando toda essa jornada de transformação.
_________________
Antes de mais nada: o que estamos querendo
resolver com um Design System?
Entenda que grandes empresas ou startups em growth possuem muitas interfaces para administrar. Nossas experiências são cada vez mais omnichannel e isso implica em múltiplos produtos, para públicos e devices diferentes (o que nos obriga inclusive a nos relacionar com algumas tecnologias ao mesmo tempo). Na tentativa de escalar ou minimamente acelerar a forma como projetamos e desenvolvemos tanta interface, acabamos contratando um grande número de profissionais e colocamos todos eles para trabalhar de forma ágil. Mas toda a autonomia das nossas squads sem os mínimos padrões acaba trazendo uma grande inconsistência à mesa. E, mesmo trabalhando com todas as boas práticas ágeis do mundo, a sensação é de que ainda entregamos muito pouco de sprint em sprint. Por aqui falamos que muitas empresas vivem o “fake agile” sem nem perceber. Afinal, continuam perdendo muito tempo projetando e desenvolvendo os mesmos componentes, isso só alonga o seu roadmap de produto.
Vale destacar que mesmo antes de todas as complexidades que o Corona Vírus trouxe ao nosso dia a dia de trabalho já vivíamos uma grande corrida, nesse novo mundo com hábitos de consumo e comportamento sendo repensados, os negócios passaram a ser obrigados a se reinventar “para ontem” e velocidade virou uma questão de sobrevivência. Mas então qual é a saída para escalar de verdade a concepção e entrega dos nossos produtos digitais?
É justamente aí que entra o Design System, uma abordagem para projetarmos e desenvolvermos do menor para o maior, a partir das variáveis de estilo. Tudo 100% espelhado entre design e tecnologia. É onde começa também uma grande confusão de conceitos.
Mas como o mercado enxerga o assunto?
Nosso mercado de design e tecnologia é muito “recente”, somos bombardeados com novas metodologias a cada semana. E é natural que ao surgir algo novo, essa novidade venha acompanhada de reações tentando simplificar ou até diminuir a sua importância. Com o Design System não foi diferente. Cansamos de ouvir pessoas confundindo com um simples Style Guide, dizendo que era basicamente o Atomic Design do grande Brad Frost ou até encarando como uma simples biblioteca de componentes no seu software de design preferido. Ter “design no nome” de alguma forma também contribuiu para fazer com que se tornasse uma iniciativa que nasce nos times de design, isso o deixa ainda mais distante do que realmente faz um Design System ser um Design System: a tecnologia. A boa notícia é que nos últimos 03 anos testemunhamos uma grande evolução na curva de aprendizado e visão do nosso mercado. A seguir vou compartilhar com você a visão da Meiuca, mas gostaria de deixar claro que isso não nos coloca como donos da razão, combinado? ;)
Então o que realmente é um Design System?
Durante esses últimos três anos e nossos mais de 10 Bootcamps (entre turmas abertas e algumas em modelo in company), pensamos e repensamos algumas vezes nossa própria definição. Entender o que seria um Design System pra gente foi fundamental para evoluir a maneira como trabalhamos. Hoje entendemos como:
“Um ecossistema de bibliotecas com componentes codados a partir de semânticas de design e gestão de estilo centralizada”.
Essa definição acumula uma série de insights. O primeiro ponto é o fato das empresas trabalharem com múltiplas tecnologias: interfaces para devices com linguagens diferentes necessitam de bibliotecas diferentes, por isso um ecossistema (além de todas as bibliotecas de suporte). Pode até ser que sua empresa trabalhe com apenas uma tecnologia ou que seu Design System comece com uma única biblioteca, mas com certeza em algum momento novas tecnologias serão incorporadas e, nascerá assim, o seu ecossistema. O “codado” é para lembrar o fato de um Design System não existir sem tecnologia. Já com a palavra semântica, queremos dizer “razões de existir”. Cada componente de um sistema precisa ser pensado e essas definições partem, em sua maioria, do time de design (por isso “semânticas de design”). A gestão de estilo centralizada fica por conta dos Design Tokens, que explico abaixo.
Design Tokens
São nossas variáveis semânticas de estilo, devidamente espelhadas entre design e tecnologia. O termo foi popularizado pela Salesforce. Basicamente são todas as opções visuais que temos para compor um componente. Algumas empresas no mercado trabalham apenas com Design Tokens de cor, tipografia e espaçamento. Na Meiuca trabalhamos com muitos outros, recentemente começamos esse mesmo processo com micro-interações inclusive. Os Design Tokens são fundamentais também para criar uma lógica de templates no caso de múltiplas marcas e garantir um segundo nível de escala. Levamos isso em consideração para projetar o Design System do Grupo Claro BR e também o da XP Inc., por exemplo. E nesse caso, a dica de ouro é não “casar com suas variáveis” ao batizar (dar a semântica) os seus Design Tokens. Ou seja, não chame o azul de azul, ele pode ser vermelho para outra marca ou até mesmo para a mesma marca no futuro.
Base components
A partir dos nossos Design Tokens criamos o que chamamos de Base Components. Eles são aqueles componentes indivisíveis, as menores partes que formam nossa interface. Um botão, um título, um parágrafo, um card e por aí vai. Eles são fundamentais para a construção de um Design System combinável e robusto. Vale lembrar que aqui na Meiuca não usamos a nomenclatura do Atomic Design, mas isso é assunto o bastante para outro artigo.
Components
Com nossos Base Components e Design Tokens de espaçamento em mãos (hoje trabalhamos com 4 categorias de espaçamento) compomos o que chamamos de Components. Eles podem ser mais ou menos complexos, a dica aqui é garantir que você tenha componentes mais complexos para acelerar a produção da sua interface sem deixar de contar com as suas versões mais básicas, assim você garante que os times possam gerar outras combinações sem ter a necessidade de atualizar a sua biblioteca principal com muita frequência (o que chamamos de Design System Core).
Camadas no produto
Para completar, dividimos a presença do Design System em nossos produtos em 03 camadas (duas bibliotecas e os componentes que correm por fora). A primeira é o que chamamos de Design System Core, aquela biblioteca com componentes comuns aos produtos de uma mesma linguagem, apenas Design Ops pode contribuir com ela. A segunda é o que chamamos de Team Components, uma biblioteca secundária com aqueles base components e components criados para satisfazer a necessidade de um time (criada e desenvolvida pelo próprio time). E tem ainda o que chamamos de Not in DS, aqueles componentes de uso pontual, que podem ou não respeitar os Design Tokens, mas são fundamentais para os indicadores de negócio e/ou uma melhor experiência.
Vale lembrar que um componente que nasce nas bibliotecas de time pode ser promovido ao Design System Core pelo time de Design Ops (em breve vamos explicar pra você o que é uma operação de design na nossa visão). A penetração (porcentagem) de cada uma dessas linhas nos produtos da companhia é uma das principais métricas de sucesso do seu Design System, será reflexo da maturidade do seu sistema. Vale lembrar que 100% na primeira linha, assim como 0% na última (aquela reservada para nossas exceções) são utopias. Não acredite nisso!
Você deve estar se perguntando então: “mas e a consistência, Thiagão?” Sim, queremos produtos consistentes. Mas entenda que é impossível prever todos os componentes que absolutamente todos os seus produtos em cenários futuros (eu disse futuros) vão precisar. Então é fundamental encarar o seu Design System como um produto, que vai evoluir. E estruturar um processo de colaboração, onde todos os times que o consomem garantem também a sua evolução. E mais: entender que ele existe para potencializar o resultado do seu negócio, então se você mapear uma interação/componente que “corre por fora” mas é fundamental para melhorar o churn do seu app, por exemplo, vá em frente. Design Ops está aí para garantir que bons processos aconteçam e a implementação do seu Design System seja feita da melhor maneira possível. Mas isso também é assunto para outro artigo, belezinha? :)
_________________
O que vem por aí?
No próximo artigo vamos falar justamente da importância de encarar o seu Design System como um produto. Nos próximos artigos vamos falar do seu impacto no Time to Market, a importância de Design Ops para revolucionar os processos no momento em que estamos vivendo e muito mais.
Espero que tenha feito sentido pra você. Deixe suas principais dúvidas nos comentários, prometo tentar responder nos artigos que estão por vir! :)
_________________
Formação Online em Design System & Ops
Compilamos tudo o que aprendemos em uma formação acompanhada de 02 meses com muita mão na massa. Faça sua pré-inscrição para a nossa Formação Online em Design System & Ops e recebe a nossa primeira aula grátis, onde explicamos esses e muitos outros conceitos.
