Painel onde o Guilherme Gonzalez conversou com o público sobre os principais desafios da construção de Design Systems nas empresas.
Assim como contei no último post, a programação do espaço Open Space da #DEXCONF19 teve 8 atividades escolhidas através de votação dos participantes do evento. O painel “Os nossos erros e acertos ao construir Design Systems” com o Guilherme Gonzalez (que na época era UX Lead na Dasa, mas hoje está na RaiaDrogasil) foi o terceiro tema mais votado pelo público, e foi realizado no segundo dia da programação, com a participação de várias pessoas da platéia, além da mediação da Melina Alves. Acompanhe abaixo o áudio + transcrição desse bate-papo.
Para aprender e trabalhar com pesquisa em design, inscreva-se na Formação em UX Research da Mergo: mergo.com.br/formacao-ux-research
https://soundcloud.com/dexconf/os-nossos-erros-e-acertos-ao-construir-design-systems
[Início da transcrição]
Aline Santos: Então a gente vai para o próximo painel para falar sobre os erros e acertos ao construir Design Systems. Para essa conversa, a gente vai chamar para mediar a Melina Alves, que eu gostaria de chamar aqui ao palco, e o especialista Guilherme Gonzalez.
Melina: Fechou. Quem quiser também (participar), vocês já sabem o esquema, é só sentar aqui e a gente vai conversar. Então, eu queria ouvir um pouquinho da história de vocês, rapidinho, nomes e o que vocês acham. Contem um pouquinho de vocês também antes de a gente começar aqui.
Matheus Nogueira: Meu nome é Matheus, eu sou da empresa Evolux, lá de Natal. Basicamente o nosso… Começando sobre os erros do Design System. A gente começou a tentar estruturar um Design System com uma equipe muito pequena, são 3 designers em uma equipe que não tem nem um ano, com um backlog de tickets e de testes chegando ao mesmo tempo, então… Começamos, montamos um em uma semana primeiro que não deu certo, um segundo que também não deu certo, mas que de pouquinho em pouquinho acabava passando algum valor para a empresa, mostrando alguns problemas, algumas vantagens e também mostrando para alguns desenvolvedores como funcionava, era a vantagem eu acho. O contexto é esse.
Melina: Isso é legal porque às vezes, em muitas empresas, os desenvolvedores influenciam os designers nesse aspecto do Design System, pelo menos foi um pouco da experiência que a gente conviveu. Conta um pouquinho da sua experiência (se referindo a outro participante), desculpa, como você chama? Não estou vendo seu crachá, qual que é seu nome?
Leandro Monteiro: Leandro Monteiro. Eu trabalho na Jüssi, nós somos uma agência de negócios e a gente está sempre mudando de clientes. Um problema que eu identifiquei, que deve ser o problema de muita consultoria e agência, é justamente o fato de, como a gente está sempre criando coisas do zero para clientes diferentes, a gente acaba tendo muito retrabalho, muito retrabalho mesmo, e a ideia que eu tive quando eu comecei a tentar implementar Design System lá foi justamente cortar esse tempo que a gente tem desperdiçado e aplicar experimentando coisas novas de fato, então hoje eu estou aplicando… Eu comecei a aplicar para alguns dos nossos clientes o Design System, para e-commerce inicialmente. Esse Design System inicialmente começou só como uma iniciativa de design e a gente só começou a aplicar de fato no código há pouco tempo, e eu mudei de conta e estou tentando aplicar…
Melina: Nessa outra conta…
Leandro: Isso, o Design System, do que eu já tinha eu consegui portabilizar um pouquinho, mudar os tokens para eu já aplicar. Isso acabou validando um pouco do que eu já havia pensado, de reaproveitar trabalho para diversas contas e ir testando esses componentes no mínimo para garantir que esse componente é o ideal para qualquer tipo de negócio ou talvez perceber quando ele não funciona e criar variações dele. Eu acho que uma dificuldade que a gente está tendo é justamente, como a gente é uma agência de negócios, ainda tem muita cultura do top down do cliente, então a gente tem que brigar bastante ainda por espaço de tempo para ganhar para conseguir investir nisso. Mas é isso.
Melina: Entendi. É porque diferente de cuidar de um produto… A gestão do produto é interna, então muita gente que é uma startup ou cuida de um produto, o tempo das coisas está dentro do time interno, e quando você está prestando serviço, na verdade, para alguém, esse tempo não é você que define, o tempo já vem determinado.
Leandro: No momento a gente está com esforços para mudar isso.
Melina: Entendi.
Leandro: A gente está conseguindo virar essa cultura, a nossa ideia é mudar o posicionamento e a gente de fato começar a tomar o negócio para a gente, produtizar todos os nossos processos, e conseguir de fato aplicar tudo da forma mais correta.
Melina: Legal.
Leandro: A ideia desse, eu chamo de “Blank Design System”, é para ajudar isso, então se a gente já tem alguns conjuntos de componentes que mudando alguns tokens a gente consegue já criar um grupo de componentes para cada cliente a partir de um único, fica muito mais fácil de gerenciar e fica muito mais fácil de a gente salvar tempo.
Melina: E vocês usam uma biblioteca específica? Liferay ou algum tipo de biblioteca que já existe, ou vocês fazem esse código do zero, vamos dizer assim? Já que é blank, é blank mesmo?
Leandro: Hoje a gente não está usando nada, por enquanto. Como são vários clientes, cada cliente também tem a sua linguagem por trás, alguns usam VUE, alguns usam puro HTML, alguns são tipo VTEX, então cada um tem suas particularidades. A nossa ideia é, pelo menos no Design, já ter algo, e em cada cliente que a gente entra já começar a aplicar isso na linguagem dele e conseguir criar uma gestão para diferentes linguagens. A gente está bem no começo ainda inclusive, e estou aberto a qualquer tipo de dicas.
Melina: Dicas! Estou pensando aqui, porque imagino que tenha essa dificuldade da questão tecnológica, até puxando aqui para as pessoas, o quanto desenvolver isso no código, no front end pelo menos, pode agilizar no caso de uma empresa que presta serviço para várias, ou o quanto isso pode na verdade dificultar, e o ideal seria a gente fazer um guia de UI, enfim, algo mais voltado ao PSD mesmo e entrado um pouco menos no código para talvez não ter essa questão de “ah mas a gente já escolheu essa biblioteca dentro desse formato e não bate”, e o quanto isso pode facilitar ou não. Alguém tem uma experiência para dividir com a gente, ou vocês aqui? De já ter feito isso…
Leandro: O que a gente tem percebido um pouco é a flexibilidade do Javascript, então a maioria dos frameworks hoje utiliza isso, acho que 90% dos nossos clientes têm um pouco disso, mas realmente, talvez, a gente está em um momento de experimentação, a gente quer testar isso ainda.
Melina: Ah, legal. (Melina se dirige a outro participante) Oi, tudo bem? Você é o…? Eric? Eric, se apresenta e você (se dirigindo a outro participante) também não se apresentou.
Paulo Aguilera Filho: Meu nome é Paulo Aguilera, eu trabalho no Banco Pan como Design System OPS, também na frente de acessibilidade, e a minha experiência com essa parte de Design System… Antes eu trabalhava na ContaAzul onde eu ajudei no nascimento do Design System mesmo, depois fui contratado no Banco Pan para trabalhar especificamente já nessa vaga, Design System e na parte de OPS também, então desde o início ali, pensa que a gente pegou, por mais que o head já tivesse vendido para todo o time sobre a importância, a necessidade real de estar uma pessoa focada, olhando só para isso, porque a gente tinha diversos problemas de inconsistência, comunicação no time, retrabalho por parte do time de design e desenvolvimento… Então essa parte, tanto de Design System quanto de OPS, eu entrei para atuar bem nisso, corrigir alguns problemas que a gente tinha no time e atuar no principal propósito de ter um Design System, que é a escala tanto por parte de design quanto de desenvolvimento, e também estreitar essa comunicação e manter a consistência e a melhor experiência no fluxo dos produtos do Banco Pan. Foi quando a gente iniciou, por mais que eles já tivessem comentado bastante com o pessoal, pensa em um time que nunca tinha trabalhado com isso — esse termo é muito novo também, essa forma de trabalho, então a partir do momento em que eu entrei lá e conheci as skills, as habilidades dos profissionais do time tanto de design quanto de desenvolvimento, e também PO, enfim, a gente foi começando a adaptar apresentações com argumentos de venda de Design System mostrando os reais benefícios para cada tipo de público, então pensa que até hoje a gente está fazendo isso também, porque não é algo que você passa apresentando para a galera uma vez que a galera pega e já assimila, então a gente está constantemente vendendo isso para a galera. São muitos funcionários no banco, hoje tem cerca de 2500, boa parte eu ainda não conheço porque não estão ali no dia-a-dia do time de produtos digitais, e também depois, só eu falando sobre isso, pensa que antes era descentralizado, então os próprios designers tinham iniciado movimentos para conseguir estruturar um Design System, mas sempre competia com o tempo da sua squad, então nunca era prioridade, porque os OKRs estavam sempre vinculados a entregas de features ou coisas que deveriam ser validadas, enfim, a dor que todo mundo tem em relação a Design System também. Então, a gente começou a pegar esse trabalho, quando eu entrei eu peguei esse trabalho que a galera já tinha feito e a gente começou a estruturar certinho, então a primeira palavra que a gente deu para todo mundo foi “não, ninguém cria mais nada novo. Se precisar criar alguma coisa nova vai ter que ter muito embasamento em evidência para a gente realmente investir um tempo nisso”.
Melina: Legal, então na verdade a questão da padronização e escolher o que você vai padronizar também é uma questão, porque às vezes não cria nada novo mas às vezes a escolha desses padrões é inconsistente com o que o produto está evoluindo, então como que… Eric você tem… Eu estava pensando aqui de a gente conversar de repente o quanto que a pesquisa pode ser um facilitador na escolha dessas bibliotecas e o quanto também essas bibliotecas devem ser complementadas, por exemplo, com um guideline textual, para que essa interpretação dos elementos de tela não seja também tão volátil, porque isso… O Design System, o que ele faz na verdade é tentar caminhar com as próprias pernas para que múltiplos designers consigam ter o mesmo olhar dentro de uma escolha padrão, então o quanto isso já faz parte da rotina de vocês? O quanto vocês querem comentar a respeito?
Eric Cerqueira: Bacana. Meu nome é Eric, eu sou designer OPS no PicPay. Eu já venho de uma estrutura onde eu trabalhava criando o Design System, atuando e dando manutenção. O nosso mindset é um pouquinho diferente, porque os designers correm livres e o trabalho do OPS é refaturar, corrigir e padronizar, estar acompanhando, então a gente não quer trazer uma limitação aos designers na hora de criar um componente novo ou algo que seja inovador, a gente entende que, cara, ele é o designer, ele é o responsável pela experiência, se ele chegar lá e falar que esse componente funcionou porque ele testou “XPTO”, a minha responsabilidade é encontrar um padrão dentro da minha biblioteca de Design System, e acho que um dos desafios que a gente tem além de o inicial, é muito sobre a pesquisa, sobre entender como que está a situação do Design System na empresa, entender como que os componentes estão, como que é o lado do desenvolvimento… É muito claro metrificar e entender códigos duplicados no desenvolvimento, mas é um pouco ambíguo e difícil de entender no lado do design, então quando você olha para o design e você começa a ter que colocar simplesmente componentes ao lado de componentes e olhar e eles estão inconsistentes, então existe muito essa pesquisa inicial e padronização e acho que o principal, acho que a dor principal, pelo menos que eu senti, passando pelo meu segundo projeto de Design System, é que a empresa entenda que Design System é um produto e não um projeto, ele não tem um fim, ele não começa aqui e termina aqui, ele é constante, ele tem seus próprios OKRs, e aí a gente entra no que eu acho que é uma grande dor, que é um momento que a gente está agora vivendo, e aí, como que eu vou metrificar isso? Como que eu vou entender que ok, no desenvolvimento é muito fácil metrificar, eu coloco algumas opções para entender ali o quanto está sendo usado, o quanto está sendo repetido, o quanto aquele código está sendo efetivo para o desenvolvimento, mas no lado do design eu consigo entender que facilitou o trabalho dos designers, eles falam “facilitou, foi ótimo porque essa biblioteca está pronta, eu consigo criar, eu consigo um desenvolvimento rápido, eu consigo testar muito rápido”.
Melina: Porque são métricas diferentes. O que ele está falando, essa métrica, é uma métrica de UI, é uma métrica de correspondentes, o quanto aquele elemento está sendo valorizado, e também a gente pode entender qual é a métrica do negócio dentro do UI, então são dois olhares de métrica que a gente precisava conversar. Conta um pouquinho aqui, chegou o nosso especialista, o Guilherme! Guilherme, o que você pode colaborar, nesse sentido?
Guilherme: Bom, primeiro, bom dia para todo mundo aí. Quando a gente fala de Design System a gente tem como… Desculpa, não ouvi seu nome. Eric? Como a gente comentou, a gente tem a questão de enxergar ele como um produto, só que ele não é um produto… Eu tenho falado muito disso, o Design System, ele é um produto para o designer porque ele tem o nome de “design”, mas quem realmente usa esse produto é o desenvolvedor, é o stakeholder, é o cara do marketing, é o fornecedor externo que desenvolve alguma coisa para a sua empresa, que faz uma landing page, então às vezes você não tem controle sobre quem vai realmente usar aquele Design System, então você tem que entender todo aquele universo, e aí tem uma questão de métricas, como o Eric comentou. É muito importante você pensar as métricas de uma forma… Como que você mede o sucesso do seu Design System? Como que você mede o sucesso para o desenvolvedor? Como que você mede o sucesso dele, de ele estar sendo seguido, de estar resolvendo algum problema? E aí isso tem que estar muito alinhado com o core do seu design na empresa, qual que é o princípio que você segue, o que você realmente precisa resolver, quais são os problemas que você tem na sua operação da empresa, isso é muito contextual, cada empresa tem o seu próprio ambiente. Tem empresa que tem, por exemplo, a Dasa, que é onde eu faço Design System, que a gente está começando, tem 6 meses de trabalho braçal sendo feitos lá, mas a gente ainda está muito longe de termos um Design System eficiente, justamente porque a gente tem uma empresa com 50 anos, mais de 30 squads, 42 marcas… Então assim, a gente tinha tantos problemas operacionais para resolver que a gente precisou falar assim “o que que eu vou resolver primeiro?”, e aí a gente escolheu, primeira coisa de tudo, “vamos padronizar as marcas”, porque tinha coisa no sistema saindo para a mesma marca onde você tem o site com a falta de consistência onde o fundo é verde e no outro o fundo é branco, e produtos da mesma marca mas que são produtos que não têm uma real consistência, e a primeira coisa que a gente falou foi “vamos padronizar a marca” e a gente começou a tacar só padrão de marca e esquecer totalmente componentes, porque a nossa operação precisava disso, primeiro uma operação muito mais profunda no branding mesmo do que na definição de componentes, de entregar para o desenvolvedor. E aí a gente conseguiu padronizar isso entregando para o desenvolvedor um arquivo, que é o Design Tokens, que é um SASS onde eles já consomem os padrões, eles não precisam mais pensar, o desenvolvedor não precisa mais olhar tipo “para que marca que eu estou fazendo isso?”, ele simplesmente muda duas letras no código, duas letras literalmente, que é só a abreviação da marca, e todo o produto muda de marca, e ele consegue fazer roll-up de marca com muita facilidade, então é muito essa dor.
Melina: Ah, que legal. E qual sistema SASS que vocês usam? Vocês desenvolveram um próprio? Como é?
Guilherme: Inicialmente a gente pegou o Theo da Salesforce, que é um compilador de Design Tokens que a Salesforce criou que fez o maior sucesso, que meio que eles que criaram, que foi a Jina Bolton que é da Salesforce que criou o conceito, e aí a gente pegou e fez uma adaptação, e eu deixei até disponível a nossa versão no meu Github, que é só uma adaptação para padronizar aquilo e entregar um arquivo legível para o desenvolvedor, e o desenvolvedor ter autonomia de escolher como ele vai implementar, porque na Dasa a gente tinha uma questão de que cada produto tinha uma linguagem diferente, isso também era um coisa para complicar para a gente, não dava para padronizar a linguagem. Tem gente usando VUE, tem gente usando React tem gente usando Angular e a gente não tinha como chegar e falar “não, você vai usar essa linguagem específica”, então a gente falava assim “beleza, a gente não pode controlar a linguagem, mas a gente sabe que 99% dos produtos mais novos aqui vão usar SASS”, então a gente escolheu o Tokens como uma forma de entregar para ele os tokens e foi uma forma que a gente viu de iniciar o Design System para ele realmente resolver os problemas operacionais e não ser simplesmente só mais um padrão para o cara ter que seguir. E é muito isso, é você enxergar aquilo como um produto. A gente hoje tem 42 esteiras de desenvolvimento rodando, todos os padrões de marca, e se eu quiser mudar um padrão de uma marca, eu consigo impactar todos os produtos daquela mesma marca. Se a marca mudar o logo eu consigo impactar tudo de uma vez só, eu não preciso ficar mudando um a um, ir lá no código de cada um, é muito… Tornar eficiente esse processo de marcas na empresa.
Melina: Então o que a gente está dizendo é que de repente pode ser um começo um alinhamento entre o branding, um segundo começo um alinhamento entre os times de desenvolvimento para entender qual linguagem padrão é mais eficiente na cadeia do negócio, do produto, e qual vai ser usada para talvez evitar o retrabalho de codar tudo e ficar… E você ter mais agilidade…
Guilherme: Sim. O Design System tem que ser enxergado como um produto que serve os produtos da empresa, então se você tem 3 aplicativos na sua empresa, um Design System vai servir para alguma coisa, só que isso vai depender do seu contexto, você tem que entender o seu ambiente de desenvolvimento, você tem que fazer pesquisa com os seus desenvolvedores, você tem que fazer pesquisa com o pessoal do marketing, tem que entender, quem é que faz landing page na empresa? Quem não faz? É aprofundar isso. É igual a gente faz o Research para definir quem é o usuário do nosso produto que a gente está fazendo para a empresa vender no mercado, entender quem é o usuário do meu produto de Design System dentro da minha empresa, quem são as pessoas que estão ao meu redor e que vão usar ele.
Melina: Maravilha. Jennifer, com o que você quer colaborar?
Jennifer: Então, eu só queria falar alguma coisa a respeito desse negócio do valor do Design System. Eu acho que o branding sempre foi um grande valor para toda a empresa, e a gente já sabe disso há muitos anos, e o Design System está tão atrelado ao branding que eu acho que é essa a nossa força, entendeu? Chegar na empresa e falar “um bom Design System fortalece o seu branding”, e esse vai ser o grande valor, valor financeiro que as empresas vêem.
Melina: É o discurso de negócio para defender a situação da biblioteca, o quanto você deve investir ou não nessa biblioteca.
Jennifer: Exatamente. Dois aspectos, um é a questão do branding, da força do branding dentro do Design System para você fazer uma coisa consistente e estar cross platforms, estar sempre em todo lugar, mas outra coisa do Design System é a agilidade, os produtos digitais precisam de agilidade, então o Design System é uma maneira de agilizar a execução.
Melina: Agora você falou de agilidade, me veio um outro ponto de vista: por que não pensar no legado? Porque a gente está falando assim “o impacto do histórico, os KPI’s… Se a gente não tem um padrão, se a gente não consegue compreender esse padrão, até para a escolha de reposicionar o Design System, porque como alguém comentou aqui, ele não é fechado, tem que pensar como um produto, algo que vai ser continuamente evoluído, por que não pensar aí nessa legado? quanto desse design funcionou e o quanto desse design não funcionou, para que as tomadas de decisão da próxima evolução desse visual seja considerado, com pesquisa, enfim, para a gente até implementar no código algo que você consiga metrificar, de repente até um Google Analytics vinculado a cada biblioteca, você já tagueia isso e já vai embora feito.
Jennifer: Quantas vezes você usa a mesma coisa, como se agiliza esse processo?
Guilherme: O que você está falando, Jennifer, não só é uma verdade como eu posso até te falar: na Dasa, para vender o Design System para a companhia eu não cheguei para eles e falei assim “quero fazer um guideline de marca, quero fazer um guideline de componentes”, isso é o que é importante para a gente, técnico. Para a empresa eu falei assim “olha, o que eu quero construir é um centro de excelência de marcas, e esse centro de excelência de marcas vai ter uma série de coisas” — isso é o que está sendo vendido para a empresa, ainda não foi oficializado, mas a ideia é vender para a empresa uma coisa muito maior do que um Design System, um Design System é só a ponta do iceberg, mas eu quero padronizar a comunicação do marketing, quero padronizar a comunicação de e-mails, eu quero padronizar a forma como a empresa se comunica com a RP…
Jennifer: Especialmente porque você está trabalhando com muitas marcas, não é? Você mesmo falou que dentro da empresa tem muitas marcas, então qual é o posicionamento da empresa com essas marcas? Como elas estão organizadas dentro desse sistema, dentro da empresa? Como elas estão conversando entre elas? Faz parte do Design System e das escolhas que a gente faz.
Melina: Legal. Alguém mais quer (fazer alguma pergunta)?
Thomás Camargo: Bom dia, meu nome é Thomás, eu trabalho no Gympass como UX Lead. Acho que esse assunto que vocês estão falando, acho que quando a gente fala de Design System a gente fica muito com UI na cabeça, é visual, e acho que é muito importante a gente falar que Design System não é só visual, a gente tem texto, comunicação, tamanho de texto, tamanho de palavra, animação, micro interações, gestual… Acho que ele é muito maior do que o que a gente fala só de cor, tamanho…
Melina: Até sound design, de repente.
Thomás: Sound design, exato. Então acho que é muito importante a gente falar disso também. Lógico que a gente está começando isso ainda, acho que é uma área ainda que a gente está evoluindo, mas é muito importante que Design Systems consistentes tenham isso, tom de voz, como que se fala, se comunica, como que anima, como que é uma ilustração… Acho que é por esse caminho que a gente tem que pensar também.
Melina: E se a gente for pensar assim no básico de usabilidade, no histórico, antes do UI, se a gente falar em usabilidade parece que “ah mas todo mundo já fala, mas o que que tem de novo nisso?”. O novo disso é essa conversa, é isso chegar aos olhos de quem toma decisão e isso tomar uma proporção maior do que a gente, como designer, conseguia fazer lá atrás, então acho que essa conversa é para que isso tenha força na tomada de decisão.
Paulo: Aproveitando o gancho da Melina, é legal também destacar que essa pessoa que, sei lá, em muitas empresas ainda não existe esse profissional para olhar focado para o Design System, mas se tiver esse profissional, lembra que também… Pensa que nunca teve e daí do nada chega uma pessoa e todas as responsabilidades vão cair na mão dela. Cara, eu falo pela minha experiência, no início a gente não sabia muito lidar com isso, virou o gargalo na hora o negócio. Tudo, definição de coisas, jogavam para o Paulo. Precisamos bater o martelo, melhor prática do mundo? Joga para o Paulo fazer. E não é bem assim na prática. A gente é um hub, a gente está ali estar articulando tudo, estar olhando tudo, isso e fazer a cultura realmente para o Design System entrar na cultura, o valor do Design System, e a gente precisa muito da ajuda dos designers e dos desenvolvedores e dos stakeholders que estão ali do nosso lado, só uma pessoa não vai fazer milagre em nenhuma empresa, é o conceito de time mesmo. E até aproveitando o gancho do “erros e acertos”, queria compartilhar também, no trabalho que a gente tem feito lá no Pan, a gente estruturou, definiu o melhor processo que a gente achou que ia rodar… Na prática, em uma squad que, vamos dizer assim, rodou bem, a gente estava rodando com os próprios times de desenvolvedores das squads, uma rodou bem por conta da maturidade daquela squad, em outras squads simplesmente não rodou e em outras eles pegaram o processo, mudaram o processo mas conseguiram fazer alguma coisa, então é um aprendizado constante, como o Eric e o Guilherme falaram ali, é uma evolução o negócio, é um eterno aprendizado. E ali também, qual é a pequena métrica que você vai colocar ali para ver se aquilo foi um sucesso ou não? Então, em um período em que a gente tem trabalhado com Design System, em determinada parte, a gente deu dois meses para o negócio rodar com o processo que a gente tinha estipulado, e nesses dois meses a gente começou a ver no dia-a-dia como que isso estava rodando, por isso que a gente viu que uma squad rodou bem, na que rodou mal a gente foi ver o porquê, a gente foi ver que não tinham tantas pessoas seniores ali que tinham conhecimento para realizar o desenvolvimento daqueles componentes, então a gente foi achando os gaps e o aprendizado também depois, tanto é que no Pan também hoje a gente tentou fazer de forma distribuída, vamos dizer assim, com os desenvolvedores das squads e não funcionou, não avançou na velocidade que a gente queria, então a gente tomou uma atitude, “beleza, vamos formar um time focado de Design OPS com as peças fundamentais do Design System”, então agora a gente já tem um designer UI focado e a gente está contratando desenvolvedores, iniciando para um desenvolvedor web, que é a maior parte dos nossos produtos, para a gente focar e essa pessoa ser referência para distribuir depois, para componentizar da melhor maneira para os times depois só consumirem, e também vai ser um aprendizado quando nós tivermos essas pessoas e vermos se vai rodar ou não, se vai precisar de outras, se vai mudar o formato do time ou não.
Guilherme: Junto com o que o Paulo está falando também tem a importância… A pessoa do Design OPS, a pessoa que vai cuidar disso ou o time que vai cuidar disso é um time que tem que estar disponível para entender as dores das pessoas, tem que ser uma pessoa que vai olhar pessoas também, ele não vai olhar só para componentes. É um ponto que eu tenho falado muito, componentes não são só o Design System, o Design System não se baseia em componentes, componentes são uma parte daquilo, e quando a gente fala de componentes a gente está esquecendo que componentes para o desenvolvedor já existem desde 1960, isso não é uma novidade para a tecnologia. O que a gente tem que fazer agora é agora olhar isso para o design e olhar como a gente pode melhorar a vida do designer para entregar melhor para o desenvolvedor. Nas entrevistas que eu fiz para entender os princípios de design que eu precisava melhorar na operação lá na Dasa, eu escutei muito “o Zeppelin é uma boa ferramenta para fazer handoff de design para desenvolvimento, porque os desenvolvedores gostam porque eles já recebem tudo meio prontinho, é muito legal”. Eu escutei de dois desenvolvedores isso, isso virou Post It que eu colei no quadro para ficar lendo isso para sempre, só que assim, o Zeppelin é uma merda para mim, porque ele me entrega tudo de um jeito que é “posição fixa”… Então aquilo para mim é ruim, porque eu quero fazer um layout utilizando flexbox, e aí eu não consigo adaptar, tudo que vem do Zeppelin eu tenho que pegar uma parte e jogar fora e ficar repensando o que que eu tenho que mudar no que o Zeppelin me entrega, aí eu fiquei pensando “então quer dizer que uma ferramenta que a gente usa de padrão de mercado e que todo mundo fala que é boa não é boa para todo mundo, ela é boa em alguns aspectos, mas a gente tem que olhar para o nosso contexto ali e entender que dentro do nosso time, das pessoas que estão trabalhando eu tenho pessoas que não vão gostar, e como que eu posso melhorar a operação para elas? Fazer com que elas façam o trabalho melhor e mais rápido independente de qual ferramenta eu uso?”
Melina: É um processo de agilidade, é um processo de padronização e ao mesmo tempo não é de unicórnios, não é você sozinho tomando decisão sobre isso.
Elias Fernandes: Só voltando um pouquinho, porque quando a gente fala dos erros e acertos de Design System, é bom, eu gosto de uma fala sua de quando a gente estava conversando também, Guilherme, que… Eu acho que o Design System, para construir, tem um processo, e aí a gente esquece do processo antes de falar do Design System, que é, por exemplo, uma coisa fácil que acontece, a gente vem em um workshop como esse, assiste, fala sobre Design System, aí a galera sai daqui e fala “eu quero fazer um Design System dentro da empresa” e já entra batendo em todo mundo, na frente de todo mundo, “não, a gente tem que fazer um Design System!”, sendo que a empresa nem conhece isso, a empresa nem sabe o que que é um Design System, ela não tem nem um guide de branding, ela só tem o logo lá e fala “usa desse jeito”, e falta muito a gente descer um pouquinho também e alinhar esse papel de o que que eu faço antes de um Design System? Qual que é o processo disso? Como é que eu vou começar a construir até chegar no momento de você sentir uma necessidade de fazer o branding e tal e começar a envolver as pessoas que precisam estar envolvidas? Eu acho que não são pessoas que devem ajudar, são pessoas que devem estar envolvidas no Design System, porque não é só o designer, a gente sabe que o Design System não é para o designer, ele é para o desenvolvedor, ele é para a companhia, então a gente precisa — eu acho que você tem uma fala muito legal sobre isso, e é legal você trazer isso um pouco mais a fundo.
Guilherme: O que o Elias está falando é que eu falo muito de a gente se aprofundar não só no que as pessoas precisam mas a gente se aprofundar nos princípios, o que rege as decisões a ponto de… Eu lancei faz um tempo uma ferramenta na internet, gratuita, que é um canvas para facilitar a construção dos princípios de design com a companhia…
Melina: Compartilha com a gente o link, qual que é o link?
Guilherme: http://designprinciplespyramid.com/ . É um canvas que foi baseado em um framework de pesquisa que foi apresentado na Clarity Conference de 2016 em que eles faziam assim “quem eu tenho que entrevistar para entender o que é meu Design System?”, “ah, os construtores, os usuários e os stakeholders, e aí transponha os problemas levantados por todos para dentro de uma pirâmide”, uma pirâmide mesmo, a minha proposta é pensar como se fosse uma pirâmide maslow, “quais são os meus problemas operacionais, quais são os meus problemas de design, quais são os meus problemas de entrega para o desenvolvimento ou para o stakeholder e qual que é a minha meta da companhia, o que eu quero atingir, fazer com aquele Design System, e por fim definir as métricas no final”. É só um canvas bem simples, na verdade, baseado em um framework de pesquisa, só que o interessante é que ele leva você a questionar se você realmente precisa de um Design System.
Melina: Olha, que ótimo.
Guilherme: Porque se você começar a levantar alguns pontos dentro dos problemas que vão surgindo você vai vendo e pode acontecer de você perceber que você não precisa de um Design System, você precisa de um manual de identidade visual que a sua empresa não tem. Aí você pode levantar e ver que você precisa, sei lá, bater papo com o desenvolvedor, entender a tecnologia que o cara usa, porque às vezes o cara está em uma terceirizada e você nem tem acesso, nem sabe o que o cara está fazendo. Então assim, quando você começa a levantar os pontos por trás disso, faz você ver se vale a pena fazer um Design System, porque é uma coisa que hoje está na moda, está todo mundo falando “preciso de um Design System, preciso de um Design System, acho muito legal ter”, todo mundo está falando, todo mundo está procurando curso, mas assim, você e está querendo fazer por quê? Para quê? Você vai resolver alguma coisa ou você quer fazer porque o coleguinha da empresa do lado está fazendo também? É realidade isso, a gente tem que falar assim “por que eu vou gastar meu dinheiro fazendo isso?”, porque custa dinheiro, gente, o desenvolvimento de um Design System para uma companhia pode trazer muitos benefícios, mas também vai gastar muito dinheiro, vai gastar muito tempo, vai custar isso para a empresa, a gente não questiona isso muito, a gente fala assim “o mercado está fazendo Design System então eu preciso fazer também”, mas aí você vai ver e a sua empresa tem um produto, tem dois aplicativos, não vai agregar nada para vocês agora. Talvez vá agregar quando vocês estiverem indo para internacional, estiverem fazendo 10 squads… Aí sim talvez vá agregar alguma coisa.
Melina: Talvez começar com uma biblioteca boa, talvez em PSD, ainda mais simples, um modelo mais tradicional…
Guilherme: Sim. Vindo para cá eu estava conversando com o Rafael Burity, ele veio junto comigo, ele é da Atech, a gente estava conversando e ele falou uma coisa muito interessante, que foi justamente disso. Guideline já existe há muito tempo, se você for um bom designer, a guideline você consegue seguir, não é nenhum absurdo, e o Design System não precisa de desenvolvimento ainda. Se você conseguir fazer uma guideline boa e entregar aquilo direito para o desenvolvedor você já tem um Design System funcionando mesmo que você não tenha nenhum código feito, então a gente também tem que lembrar que Design System é uma evolução de algo para resolver um problema, mas hoje é uma parte do dia-a-dia, você já pode fazer uma guideline de componentes no seu Sketch, no seu XD e seguir aquilo no dia-a-dia e fazer, e implementar, e tentar manter a consistência daquilo se você tiver poucas coisas para desenvolver.
Melina: Ótimo.
Guilherme: O Design System serve para você resolver problemas de grandes operações, de empresas que têm multiprodutos, diversas plataformas…
Melina: E também que têm muitos fornecedores, e que não é só o time interno que vai cuidar daquilo, e que a terceirização é uma parte da realidade do processo do produto.
Guilherme: Exato.
Felipe Dias: Meu nome é Felipe, eu trabalho na Livework. A gente está em um projeto de design de serviço onde a gente identificou a necessidade da criação de um Design System. São três produtos que nós precisaríamos criar, e para isso a gente começou aos pouquinhos, criando uma library e evoluindo para um styleguide, justamente pela necessidade de manter uma consistência, simples, só para ter realmente uma base onde todo mundo pudesse se alimentar disso, porém a gente foi vendo que na verdade, dentro dos produtos, da empresa, ou seja, a gente é uma consultoria, a gente está de fora e precisaria entender toda a galera, todos os stakeholders que também estão produzindo outras coisas dentro dessa empresa, e por isso foi bastante difícil a gente entender, fazer essa entrevista em profundidade com a galera, qualitativa e quantitativamente, e beleza, a gente entendeu que a galera está a fim também de criar esse Design System. A nossa principal referência hoje de mercado que faz isso como consultoria é a EightShapes do Nathan Curtis, você deve ter ouvido falar. O que eu quis agora foi jogar uma bomba aqui para saber se existe mais gente fazendo isso como consultoria e se existe processo para esse tipo de coisa para… como… Não em house, mas fora… Não sei se isso já está acontecendo.
Melina: Para que você possa aproveitar melhor a biblioteca e de repente não ter que começar do zero, não é?
Guilherme: Eu sei que tem a Meiuca, que está fazendo alguns trabalhos, a Cíntia, o Thiago Hassu, o Glauber, eles estavam fazendo alguns trabalhos, eu sei que eles fizeram o Design System da Claro. Eu já fiz algumas… Eu vou dizer “assessorias” para algumas empresas, para ajudar, mas assim, muito pontual, de tirar dúvida, ensinar… Eu fiz isso com a G2, o Peixoto que estava no estande da Product Arena me convidou para ir lá e ajudar eles a entender o que precisava, a gente foi lá e fez alguns exercícios juntos, mas assim, igual a EightShapes aqui no Brasil ainda não, porque aqui a gente ainda está tentando descobrir se precisa realmente fazer, a gente ainda tem uma maturidade um pouco abaixo do que é uma maturidade de design dos Estados Unidos, e a gente ainda está engatinhando em muita coisa, mas eu sei que um grande case é a Meiuca e um grande case que tem aí de pessoas fazendo isso, tem eu, o Paulo Aguilera fez algumas coisas, tem os cursos que estão surgindo por aí tentando fazer cada um de um jeito diferente, e acho que muitas ferramentas. A minha ferramenta da pirâmide é um pouco isso.
Melina: E vale resgatar também o que foi falado antes, que às vezes pegar o que já está pronto não te serve, e qual que é o histórico da pesquisa, do negócio? Então mesmo que seja um facilitador, tem que olhar isso com carinho para que a gente também não crie algo que não vai ser útil ou que não vai ser efetivo, voltando na história dos resultados aqui. Então a gente tem o nosso painel. Muito obrigada pela participação de todo mundo, foi muito bom conversar com vocês!
Guilherme: Obrigado, gente!
[Fim da transcrição]