EP 115 | O Design System da Hotmart: bastidores do Cosmos e a evolução da engenharia

Você que é amante da tecnologia, PodDev se aventurar conosco nesse podcast cheio de conhecimento e bom humor que vai transformar o seu dia a dia de trabalho para melhor. Começa agora o PodDev.

Fala galera, tudo bem com vocês? Aqui quem fala é Walter, também conhecido como Valtinho, sou gestor de comunidade aqui dentro da Hotmart, cuido de comunidade de tecnologia como a HotHackers e comunidade de inteligência artificial como a Jedi Community. Eu sou mestre cerimônia do Hot Encode Conference, inclusive o maior evento de tecnologia da Hotmart.

com os ingressos já disponíveis para vocês. Vocês podem ir acessar o link que está na descrição, ou vocês podem ir hotencode.com.br, acessar a nossa página, adquirir o seu ingresso, que é muito conteúdo. Então, se você gosta aqui do PodDev, gosta do conteúdo que a gente compartilha aqui no nosso podcast, você pode e deve adquirir logo o seu ingresso do Hot Encode Conference.

E também host do nosso queridíssimo podcast, o PodDev. E estou aqui com ela, a maravilhosa Bruninha, minha co-host.

Fala, comunidade. Estou muito feliz de estar em mais um episódio aqui com o Valtinho, uma conversa que vai ser muito boa, estou muito animada aí. Eu sou a Bruna, sou gestora de comunidade aqui na Hotmart também, estou cuidando hoje da Hot Hackers. Então, tem muita coisa legal vindo, o conference está muito bom, estamos muito animados com muito conteúdo também. E bora lá começar o nosso papo.

E hoje o Papa é intergaláctico, né? Ele é cósmico. Então, aqui a gente trouxe a nossa equipe do Cosmos, que é o nosso Design System, para falar um pouquinho da história, de como que ele é, como que foi desenvolvido.

para dar uma ideia para os nossos ouvintes um pouco sobre como foi o nosso processo de criação e maturação do nosso design system. E aqui a gente está com a nossa equipe maravilhosa, o nosso querido gestor da equipe, que sempre gosta de falar em público, principalmente quando o público são estagiários. Chega mais, Luquinhas!

Fala comigo, Valtinho. Fala, turma. Aqui quem está falando é Lucas, líder de pessoas da Hotmart. Já fui apresentado aqui como DJ da geração Z, já fui apresentado como palestrinha para estagiário. Então, a turma aqui já me conhece.

Mas vim falar um pouquinho também sobre Design System, que é um dos times que eu estou cuidando aqui hoje. E estou aqui com duas pessoas muito feras, inclusive um que está aqui há quase 20 anos na Hotmart. Fala para a gente aí, Pang. Inclusive o Pang reza a lenda que quando o JP chegou na sede, ele já estava lá, estava dormindo num canto. Aí o JP falou, já que você está aí, continua. E quando veio, é um excelente design.

Cheguei aqui quando era ainda tudo mato, né? Exatamente, Pange. Inclusive, o Pange está aqui amarrado, né? Porque é um cara que odeia falar, odeia gravar conteúdos. Porém, em prol do conhecimento dos nossos ouvintes, ele veio. Valtinho me disse um dia que a gente tem que enfrentar os nossos medos, né? Então, estamos aí com mais um podcast para entrar na conta. Estou bem feliz de compartilhar com vocês mais um encontro.

Boa. E completando aí a nossa mesa, nosso queridíssimo Swagger.

Chega mais aí, cobrinha! Fala, Walter. Fala, pessoal. Tudo bem? Aqui é o Gabriel Snake. Alguns aí têm vários apelidos, né? Slack, Snake, Swagger, Skate e por aí vai. Enfim. Mas, bom, falando um pouco sobre mim, eu tenho alguns hobbies peculiares. De vez em quando pratico um pouco de agricultura, planto uns cafés, às vezes desenvolvo um pouco de jogos também, um pouco de full cycle.

Mas aqui na Hotmart especificamente eu estou atuando há dois anos como desenvolvedor específico para o time de desenvolvimento do Cosmos, mas também já tive outras experiências como Vue, Nest JNS, Next, Nest, Go e algumas outras tecnologias aí que já devem ter morrido.

Snake, eu achei essa sua tática de manutenção de emprego maravilhosa. Porque você chega e fala assim, não, gente, eu planto café. Aí a galera, pô, beleza? Então eu quero tomar o café do cara, né? Só que pra ele ficar pronto demora quatro anos.

Então, assim, você tá com quatro anos do emprego garantido, velho. Ninguém vai te demorar e te falar pô, vou esperar o café do cara, né? Justo. Tem esse ponto e tem o ponto também que eu comecei faz pouco tempo, né? Então vai fazer quase um ano aí. Então tem algumas coisas além do café também. Excelente. Sem dúvida, sem dúvida. Vocês vão conhecer um pouco mais aqui durante esse episódio, né? Boa.

E para a gente começar aqui o papo, quando a gente fala, galera, de design system, a gente está falando de padrões, de práticas compartilhadas, de padrões de comportamento, e por aí vai. Tem um monte de coisa para a gente falar sobre design system. Mas quando a gente fala aqui da Hotmart, de por onde começar, por onde que começa a história do design system na Hotmart?

Bruninho, a história do Design System na Hotmart começou, curiosamente, pelo código.

A gente começou lá em 2017, não era um design system ainda, era mais uma toolkit, uma UI kit, que começou a partir do código. E os motivadores que trouxeram esse intuito de padronizar os componentes foi muito para agilizar o próprio trabalho do desenvolvedor.

porque estavam nascendo várias plataformas ao mesmo tempo, internas, e o código estava sendo replicado. Foi o Hotmart UI, ele nasceu a partir do Bootstrap, na época era o hype do momento, hoje já temos outras ferramentas que entregam comportamentos numa tecnologia muito melhor.

mas realmente nasceu do desenvolvedor para facilitar o dia a dia dele. E por outras vantagens, a gente acabou conseguindo padronizar alguns componentes. Então outros times conseguiram utilizar da mesma base de código. E aí posteriormente a gente fez o espelhamento dos componentes no sketch. Não tinha nem figma na época ainda. Então era realmente muito mato para bater naquela época.

Mas pensando um pouco sobre se foi uma decisão certa ou errada, eu acho que isso varia para cada contexto. Então, pensando agora no passado, eu acho que foi uma decisão boa, porque realmente a gente conseguiu padronizar muita coisa, a gente conseguiu reduzir o tempo de desenvolvimento.

E acabou que o design depois meio que igualou, né? A gente conseguiu correr com o design ali também. Então, a gente criou um... Não diria que chama... Não vou chamar de design system, mas eu vou chamar de sabor design system. Porque a gente começou bem devagarzinho ali. Era muito... Tinha que produzir muita coisa, né? A gente estava virando uma plataforma nova, com uma interface nova, uma usabilidade melhor. Então, foi o que a gente tinha naquela época, né?

Mas aí depois a gente começou a evoluir mais a biblioteca, trouxe outros ensinamentos, trouxe outras melhores práticas de mercado. E hoje a gente está na nossa quarta versão do Design System, desde 2017, 2018 até hoje.

É, às vezes começou por uma necessidade ali de evitar a duplicação de trabalho, mas hoje em dia a gente já tem uma maturidade maior, né? Hoje em dia já se fala mais sobre design system, hoje em dia já se tem mais empresas que mostram o seu design system, você consegue ver isso de maneira muito nítida.

Mas na época era meio mato, né? Não sabia muito, não tinha esses delimitadores que a gente tem hoje, né? Você tem hoje empresas especializadas em construir um design system para a companhia. Então coisa que talvez há anos atrás não se pensava, né? Na época do Dreamweaver, construtores de site.

Exatamente, um bom ponto. Inclusive nesse meio tempo, ainda falando aqui internamente da gente, dos aprendizados históricos, nessas últimas versões que a gente teve, a gente foi adquirindo muita maturidade, por assim dizer, conforme a empresa veio evoluindo. A gente foi entendendo também as limitações de algumas tecnologias, a gente também estava numa fase ali, por exemplo...

Da última versão para a nova, a gente ainda tinha a intenção de abraçar muito as tecnologias. Então, nessa época, ainda como tudo era mato, a gente também ainda tinha a empresa ali, ela crescendo de um nível de startup.

para começando a Medium, Big Cap. Então, nesse meio tempo também entraram muitas pessoas, obviamente com muitos conhecimentos, trazendo muitas tecnologias ali distintas. Nessa época a gente ainda não tinha o conselho de front, que a gente vai adentrar nisso até no outro podcast a respeito de como trazer o front-end como estratégia de negócio para a empresa.

Isso, querendo ou não, impactou muito em como funciona o nosso design system hoje, o quão maduro ele é e o quão a gente consegue ir mais profundo nele para que ele atenda melhor as nossas interfaces. Dado esses aprendizados históricos aí, no passado a gente teve duas versões, por exemplo, com web components visando essas questões, por exemplo, de querer atender múltiplas stacks. Então a gente tinha...

aplicações ali em Angular, aplicações ali em Meteor, a gente tinha aplicações, por exemplo, em React e Vue, e algumas outras ali que poderiam vir a nascer futuramente, né? Mas o que isso implica de fato, né? A gente acaba ali que, dependendo do produto que a gente tem internamente, a gente tem características específicas, né? Então, algumas das situações que esbarra muito, às vezes, no design system ou na tecnologia que a gente está usando.

É a quantidade de vazão que a gente consegue dar, né? Então, dependendo ali da tecnologia, do tamanho do time, a gente pode ser que a gente não consiga dar vazão com a quantidade que o produto precisa crescer e a velocidade que o produto amadurece é muito rápida.

Então, se você tem um time muito enxuto, acaba sendo muito difícil também para o Design System dar vazão para essa quantidade de produto e de necessidade. E aí que entrou essa questão da estratégia do Web Components visando atender toda essa diversidade de tecnologia que a gente tinha dentro da empresa, né? Acho que o Pung, ele estava aí e ele... É, esse acho que foi o momento mais importante para o Design System, que como o Snake falou, o Design System ele entrou para ser muito agnóstico, de abraçar todo mundo.

E acaba que isso a gente começava a bater muita cabeça em alguns pontos, que o Web Component, por exemplo, ele não estava sendo muito evoluído em termos da comunidade, o projeto open source, então tinha muitas limitações em alguns pontos de implementação.

Mas o objetivo do Design System sempre foi temos que abraçar a companhia inteira. Então, o momento da virada de chave de parar de pensar na companhia inteira, porque a Hotmart tem essa veia do testar, de inovar, de testar novas linguagens. Então, a gente não tem uma linguagem oficial.

Não tem um framework oficial na empresa. Então, por isso que o Design System nasceu um web component. Mas o ponto chave disso foi realmente vamos tentar parar de abraçar tudo e vamos tentar abraçar a maioria. Que com isso a gente vai tirar um pouco da fricção, a gente vai conseguir...

ter resultados melhores em mais projetos. E é mais fácil também, por exemplo, encontrar desenvolvedores que desenvolvem React do que um web component, por exemplo. Então, tudo melhorou a partir dessa virada. Muitas vezes, mais importante do que decidir com o que vai seguir, é decidir com o que não vai seguir. Porque isso aumenta a complexidade para a equipe.

E mais trabalho também, porque ele precisa dar manutenção em mais coisas, né? Exato. No papel é muito lindo. É, na teoria é maravilhoso, né? Agora tem um component que vai abraçar tudo. Você pode customizar assim, assado, mas... E o resultado disso? Só que se der problema lá, se você estiver utilizando a linguagem bio, aí você tem que resolver também. Aí saber dessa conectividade, como é que funciona e tal, é outra treta.

pegando duas partes interessantes que o Snake e o Pung trouxeram, que elas se conectam, que é o Snake falou sobre a diversidade de tecnologias e stacks que a gente tem aqui e o Pung falou sobre a virada de chave

Acho que a virada de chave do Design System não aconteceu repentinamente. A gente decidiu, do dia para a noite, colocar só uma linguagem de programação. Ela veio também com uma padronização da stack pela Hotmart, pela companhia. Então, nesse tempo, um dos amadurecimentos que aconteceram foi...

o front-end ser tratado como estratégico, que é o podcast que o Snake falou que a gente vai trazer mais para frente, mas a empresa entender que abraçar o mundo com os dois braços não é algo necessariamente positivo.

ou agregador, mas sim especificar uma stack diminui a mantenibilidade, diminui o custo, diminui a base de conhecimento necessária para novos desenvolvedores, por exemplo. Então essa padronização do lado da engenharia possibilitou que a gente também tomasse essa decisão do lado de cá e construísse um DS mais robusto, que é o que a gente vai falar um pouco mais para frente em relação à versão atual do nosso DS.

Excelente, essa questão de direcionamentos técnicos, que ela vê como estratégica, fez com que a gente conseguisse concentrar os esforços, sem querer abraçar tudo, para que a gente pudesse, por exemplo, pegar um caso aqui, a respeito do que poderia dar problema. A gente pega, por exemplo, o framework do React lá, os que estão construídos em cima do React. Você pega lá o Next, você pega o Astro, você pega o Tanstech.

todos eles divergem em algum ponto sobre a respeito de alguma implementação. Então, por exemplo, React Server Components. O próprio TANSTEC está escrito lá na documentação deles que eles têm uma opinião própria a respeito de como isso funciona. Então, você percebe que conforme vai evoluindo as ferramentas, elas vão criando novas soluções ou às vezes elas vão divergindo.

E não necessariamente elas acabam dando suporte para determinada tecnologia. E quando a gente decide concentrar nossos esforços numa única tecnologia, a gente passa a começar a padronizar diversas implementações que a gente teria aqui dentro.

e a principal delas, o design system ali, para que a gente pudesse construir as interfaces ali de maneira mais ágil, começar a ter padrões e decisões ali, junto com essa criação do conselho, a respeito de tecnologia, a respeito de como que isso vai ser migrado nas equipes. Então, de certa forma, veio como amadurecimento.

E não só isso, mas tem ajudado a gente ali a refinar os nossos produtos de uma maneira mais coerente, né? Trazendo consistência e coerência nos nossos produtos. Então, a partir desse momento, o que aconteceu também, né? A gente estava precisando, numa fase ali, que veio o novo brand da Hotmart também. Então, o que a gente tinha antes, ele atendeu a gente por um bom tempo.

A gente teve o iKit, depois a gente teve a evolução ali para um design system um pouquinho mais robusto, que atendeu a gente por um bom período de tempo, só que a partir de determinado momento, quando as coisas elas ficaram, expandiram bastante, a gente precisou, opa, vamos precisar dar dois passos para trás, olhar para dentro de casa, porque agora a gente precisa fazer uma pausa.

para dar uma manutenção no avião, para voltar a decolar e acelerar com mais eficiência. Então teve essa questão do amadurecimento técnico, mas também teve esse amadurecimento do lado da Hotmart como empresa, como marca.

E aí quando a gente precisou fazer esse ajuste também dentro da empresa, também veio essa necessidade ali de melhorar a parte de tecnologia, melhorar a parte de design. Então uma das coisas que até o Pang pode falar um pouquinho mais a respeito pra gente é que nessa jogada...

O time de produto também entrou com a gente junto disso, né? Ele entrou ali como parte dessa estratégia ali de criação do design system, né? Então, foram várias frentes com o ausenho técnico, time de front-end, parte de produto, os designers, os managers. Então, quando entrou todas essas decisões, a gente começou esse novo direcionamento de amadurecimento da empresa, né?

Já pegando um gancho nessa parte do direcionamento, a gente trouxe alguns pontos importantes aqui. Acho que essa parte de pensar em servir a maioria nela foi uma mudança como o Lucas trouxe também, estratégica, da maneira como a empresa está enxergando também ali o front, o design. E aí o Snake trouxe aqui um pouquinho desses direcionamentos técnicos, já entrou nisso também. Acho que é interessante a gente contar aqui para o nosso público.

Primeiro, como vocês definiram, porque o Snake já trouxe um pouquinho desses direcionamentos técnicos, mas também quais foram as estratégias para alinhamento com as outras áreas? Como que a gente levou isso? Como vocês fizeram esses alinhamentos?

Justamente, a gente acabou adiantando um pouquinho na pauta anterior, mas parte desses direcionamentos foram tomados olhando para a nossa realidade atual. Então a gente tem um sistema interno onde a gente mapeia todos os produtos, todos os repositórios, dependências, e a gente construiu basicamente um mapa de calor, que é onde estão concentradas as nossas tecnologias, quais são os frameworks que a gente usa.

atualmente de JavaScript e etc. E a gente percebeu que React era predominante dentro da Hotmart. A gente tinha ali, tem Vue, igual o Snake trouxe, tem Meteor, tem outros frameworks atualmente, mas na sua maioria são React. Então, como o React já é um framework também muito consolidado no mercado atualmente,

a gente entendeu, por conta da nossa base hoje de código, por conta de oportunidade, desenvolvedores, comunidade, enfim, todos os critérios para escolher o React como o framework oficial, para isso,

Foi um dos critérios que a gente usou para, dentro desse conselho de front-end, a gente especificar ele como o framework oficial da empresa. Quer dizer que mais nunca a gente pode usar outro framework ou, enfim, considerar uma nova tecnologia? Não.

Mas para esse momento da Hotmart, até para contenção de legado também, a gente optou por considerar o React como oficial e aí o Cosmos está sendo construído nesse framework. Um outro ponto importante, antes dessa virada de chave com o React.

Até na última versão, antes do React, que é o que a gente estava desenvolvendo ainda em Web Component, um ponto que vale ressaltar aqui é que em toda a história do design system aqui na Hotmart, ele sempre foi feito muito...

feito à mão, quase que artesanalmente. Então, eram todos os componentes criados do zero. Então, não que a gente ignorou a existência dos open sources que existiam na época, mas o fato da gente...

Hoje, a base do nosso Design System, a gente utiliza bastante de open source. Então, isso não só deu uma agilidade para a gente desenvolver, mas também uma base sólida, mais testada, porque tem milhares de pessoas trabalhando em cima desse framework que a gente utiliza como uma fundação do Design System.

São muitos aprendizados durante o tempo que a gente foi pegando, amadurecendo e hoje chegou num formato que eu acredito que está muito promissor, não só na parte do design, mas também na parte do código.

Porque o front-end, a gente conhece que a cada semana tinha um framework novo nascendo. Então a gente acaba que ficava sempre correndo atrás do próprio rabo ali, tem que atualizar, tem que fazer não sei o quê. Ah, tem que trocar agora porque chegou um novo framework que está com muita estrela no GitHub, é um novo momento, vai trazer muito benefício, mas é o hype.

faz sentido para o nosso momento, faz sentido para a gente. Então a gente realmente tem que aprender com os erros. A gente está aí na nossa quarta versão, aprendemos bastante e hoje eu diria que nunca foi tão bom trabalhar com um design system dentro da Hotmart. Não se porque tecnicamente é fácil vender um design system. Para quem é técnico, entende os benefícios.

Mas o importante foi realmente trazer a parte da diretoria, da parte de negócio e mostrar realmente os benefícios para o negócio em si. Então isso eu acho que realmente trouxe a empresa inteira...

como, não, realmente, olha, isso aqui é necessário, não é só pintar a caixinha da mesma cor, não é só, ai, tem que falar, design system é o assunto que todo mundo fala, não, realmente tem benefícios para o negócio, né? Então, realmente, conseguimos chegar num, eu não diria que está perfeito ainda, porque não...

Não existe um DS perfeito. A gente está sempre evoluindo, vamos ter novos aprendizados daqui para frente, amanhã vai ter uma outra ferramenta, uma nova AI. Então a gente tem que sempre estar se atualizando com isso e trazendo, igual o Snake falou, trazendo pessoal de produto, trazendo pessoal do business, do negócio ali, porque realmente traz benefícios além do técnico.

até a gente trouxe no início do ano um episódio sobre débitos técnicos, e nesse episódio a gente falou como a gente já tratou débitos técnicos e tudo mais, e que hoje a gente tem um processo formal de priorização de algumas coisas. E hoje o Cosmos, o design system nosso, é considerado um débito técnico, não porque ele esteja defasado ou porque tem um débito embutido nele, mas que a implementação dele não pode ficar para trás.

Então, até numa fala do Leonan em um evento interno nosso, ele falou, ó, você fazer algo fora do nosso design system é pegar empréstimo com a Giotta. Você tem que pagar até o final do ano. Entendeu? Não tem mais conversa, não tem mais... Então, isso mostra o Leonan como um vice-presidente nosso, mostrando realmente a importância da implementação e comprando a ideia de um design system em todos os nossos produtos.

Ter essa experiência de ser a mesma coisa do início ao fim, independente do produto que você esteja na plataforma. Porque o cliente não está ali acessando o clube ou financial software. Ele está acessando o Hotmart.

Então eu não quero saber se é uma coisa ou se é outra. Como a Hotmart divide isso. Eu tô na Hotmart, eu quero ter a experiência da Hotmart. Voltinho, você já pode vir pro time de DS, tá? Você tá bem entendido de padrões, comportamentos. Rapaz, eu sou aqui, entende tudo um pouco dentro da Hotmart. Pô, isso que o Pang falou é até interessante, porque eu entrei aqui na Hotmart em julho de 2024.

pouco mais de um ano e meio. E entrei com a missão justamente de rampar o Design System. E naquela época a gente estava desenvolvendo a terceira versão do DS, ainda em Web Components. E eu lembro direitinho que quando eu entrei aqui, era falar que ia ter uma nova versão do Design System e o pessoal arrepiava. Assim, o desenvolvedor já negava, já ficava aquele climão pesadíssimo.

Você começou a ser uma pessoa não grata nos lugares, né? Persona não grata nos fóruns de tecnologia. E olha lá, o Luquinhas está vindo com uma nova versão do design. Olha o Lucas de novo, cara. Exatamente. Minha fama aqui já não é muito boa por causa do palestrinha e vinha falar de Cosmos, a nova versão aí que bagunçou.

Mas brincadeira à parte, isso era realmente um trauma, ainda é, mas a gente está mudando. E aí o Pank falou que o DS não está perfeito, mas particularmente eu acho que o DS hoje está lindo. Está incrível, se eu pudesse mostrar aqui no podcast, mas teve toda uma parceria com o produto, com o design, para, igual os meninos falaram, não só construir a parte de tecnologia, mas construir a parte visual. Tem uma fala de um designer que trabalhou com a gente.

que é um design system consistente, não faz um produto consistente. Isso está muito atrelado propriamente à tela, aos padrões de produto, à forma como o design enxerga e entende a experiência do usuário. Então, Valtinho, por isso que eu brinquei que você já pode vir para design, porque o DS toca muito no usuário final. Então, qual é a experiência que a gente quer?

Fornecer para o nosso end user. Então, se entrou no produto X, é aquela experiência. Se entrou no produto Y, é a mesma experiência. Então, o DS vem para não garantir, mas habilitar que isso aconteça.

Muito bom, ponto muito bem colocado. O design system vem também para gerar credibilidade para os nossos clientes na ponta final. Então, ele agrega valor e demonstra que o nosso produto ali é consistente, independente de onde a gente está acessando. Vou dar o exemplo da Coca-Cola, você vê uma latinha vermelha, você reconhece a Coca-Cola.

Então a partir do momento que você acessa um determinado produto da Hotmart e você acessa outro produto da Hotmart, você identifica ela. Assim como se você vier uma latinha rosa e azul, você sabe que é Guaraná Jesus. Muito bom.

Design system. Design system, exato. E falando de virada de chave e todos esses pontos aí que o pessoal comentou, né? E também junto com o alinhamento do direcionamento técnico. Na verdade foi tudo um conjunto ali de múltiplas mãos, né? Então existem muitos créditos de muitas pessoas, né?

Então, quando o pessoal falou aí do Leonan, falou das outras engenharias, das outras gestões, né? E também do conselho de front, claro, né? Que ajuda ali muito a fortalecer essa questão de comunidade dentro da empresa, né? Então, quando a gente fala ali de direcionamento técnico e fala também dessas outras questões ali de credibilidade de outras pessoas, todas essas partes envolvidas, elas de certa maneira ali, por exemplo, todo esse medo, esse frio,

na barriga que o Lucas comentou que sentia das pessoas quando se falava em design system, era justamente por conta. De certa forma, o conhecimento ali estava descentralizado, não tinha um senso de comunidade e não tinha essa presença ali de todo mundo envolvido em prol de um objetivo em comum.

Então, quando a gente alinhou esses objetivos, vamos criar uma frente de design, de padronização de produto, vamos mexer no core do design system, vamos trazer isso alinhado com a tecnologia dos front-ends, vamos definir isso se não tem, então o pessoal definiu também, assim como outras partes de tecnologia. Isso acabou, de certa forma, trazendo os nossos pilotos, de certa forma,

habilitar isso de maneira mais fácil, mais ágil, né? E também permitiu com que a gente evoluísse de maneira mais rápida, né? Então, como o próprio Pang comentou, a gente conseguiu ali adquirir com mais eficiência coisas específicas da comunidade, né? Então, a gente trouxe ali algumas ferramentas top de mercado. Então, o motor ali do nosso design system, ele ainda usa, por exemplo, Style Dictionary, algumas ferramentas como Base UI, Radix, justamente para criar nossos componentes base.

Só que também permite a gente usar os tokens para permitir a gente crescer futuramente para outras tecnologias. Isso conforme o design system também ganha maturidade. Que agora é um ponto onde a gente começa a entrar ali, desse direcionamento técnico, onde começa a entrar essa adoção, justamente trazendo essa perspectiva dessa maturidade que a empresa ganhou ao longo desse tempo.

E vira um consenso de responsabilidade, né? Porque isso deixa de ser um problema da equipe de Design System e vira um problema de todo mundo, todos os front-ends ali trabalhando nisso.

Eu acho que uma coisa que facilitou muito a implementação e você criar mais coisas já dentro do nosso design system foi a possibilidade de MCP junto com inteligência artificial, né? Eu acho que entra como uma possibilidade de você poder desenvolver telas e componentes já conectados com o design system de uma maneira ridiculamente fácil, né?

Como é que foi essa outra decisão de direcionamento técnico também que tivemos? Essa parte aí, ela é bem curiosa, né? Porque eu gosto de falar que se a gente tem um alicerce bom, uma base boa, querendo ou não, habilita muito a gente, né? Então, a nossa camada ali, por exemplo, de estilização de tokens, a camada de fundação primária, ela estava muito consolidada, né?

Então a gente já tinha estressado ela muito, então a gente trouxe ali uma arquitetura mais elaborada nos nossos tokens, né? E isso permitiu com que a gente implementasse com uma certa facilidade os nossos componentes.

E aí, implementando os nossos componentes, a gente também conseguiu implementar a documentação ali usando AI ali, né? Justamente para auxiliar na criação dos exemplos, dos testes, unitários e as variações dos componentes, né? E como surgiu essa questão do MCP que a gente tem aqui dentro hoje da Hotmart? Ela veio muito por causa disso, né? Então, a gente, por exemplo, dessas documentações, foi até uma história curiosa, né? Porque a gente não tinha...

Um plugin, por exemplo, que pegasse as nossas documentações e convertesse isso como knowledge base, né? Para IA. E aí, curiosamente, num belo dia de hackathon, a gente conseguiu criar uma CLI, né? E essa CLI, ela era uma coisa bem simples, né? Mas às vezes é muito aquela questão do princípio de Pareto, né? Do 80-20. Então a gente gastou 20% de esforço ali para criar uma CLI. E essa CLI só fazia uma higienização em algumas coisas ali que a gente não precisava da documentação.

E a gente conseguia criar um knowledge base usando o formato da comunidade para IA hoje que a gente tem, que é o LLMTXT, que é uma das coisas que recentemente teve até uma treta da comunidade a respeito do Daywind, então estava bem forte nas últimas semanas, só que a gente já tinha criado isso no meio do ano passado.

E aí esse Knowledge Base, ele querendo ou não, já estava servindo ali para alimentar algumas outras ferramentas nossas internas, né? E dito isso, um belo dia o Lucas, ele chegou com uma demanda ali do MCP, falou, como que a gente consegue ali habilitar as nossas ferramentas, né? Então, de início a gente queria ir muito na direção talvez ali do V0, do Louvable, né?

de agregar valor na geração de protótipos. Então, com o Knowledge Base, isso já era possível ali, né? No nosso ambiente de playground. Só que a gente queria um pouco mais, né? A gente queria, na verdade, era habilitar os nossos devs a gerarem consistência a respeito disso, né? E aí foi então que... Aí uma menção honrosa ao Pitch, o Vianna, Rafa Montes, aí os príncipes que...

Me ajudaram bastante, né? Eles criaram um Golden Path Lite de criação de MCP interno aqui. E graças a essa documentação ali foi bem tranquilo de criar o MCP. E eu acabei usando esse Knowledge Base ali para servir via MCP. E no automático já inferi contexto aos nossos modelos de IA conectado com as interfaces, né? Então isso habilitou o uso.

Eu acho que é algo legal da gente até dar visibilidade para a turma que está ouvindo, que antes da gente trabalhar no MCP propriamente, essas ferramentas que você trouxe, uma delas é o LibreChat, que basicamente é uma biblioteca front-end que encapsula a conversa barra interação com modelos de IA.

Então hoje a gente usa o LibreChat aqui dentro, a gente deu o nome de Hotmart Chat e ali a gente viu um potencial muito grande de fazer com que as pessoas, seja produto, seja técnico, seja designer, quem fosse, pudesse tirar dúvidas a respeito do DS, do Design System. Então a primeira coisa que a gente fez foi pegar esse arquivo que foi gerado, que estava imenso, e fazer o upload para deixar como disponível, como base de conhecimento para esses agentes dentro dessa ferramenta LibreChat pudessem consumir.

E aí você falou também sobre uma ferramenta que chama Playground. A gente fala Playroom, Playground, cada hora é um termo diferente. Mas é uma ferramenta também que potencializou absurdamente o nosso design system aqui dentro, junto com a inteligência artificial. Por quê? Aí ela gera código.

Então, quando a gente junta a geração de código com a necessidade de prototipagem, você precisa de uma ferramenta que renderize aquele conteúdo. E a ferramenta hoje que a gente usa, a lib que a gente usa, é a do Playroom. Então, o que esse agente inicialmente fez?

Chamava até Cosmos AI. Na primeira versão, né? É a primeira versão, exatamente. Que usava o Cloud Sonnay 4.5. Não, 4.0 e depois a gente subiu para o 4.5 e agora está atualizando cada vez mais. Mas basicamente ele pegava a base de conhecimento, pegava o prompt do usuário, gerava ali um arquivo, não, um código em HTML puro. Não tinha imports, não tinha... Enfim, era específico para o ambiente de renderização, de Playroom.

A gente copiava esse código, o usuário abria uma nova aba direto desse Playroom e colava esse código lá. E ele poderia ter a renderização dessa tela lá. Então isso, quando a gente mostrou isso para a parte de negócio da Hotmart, inclusive eu fiz uma apresentação para o Jota, para o João Pedro.

E eu lembro direitinho da fala dele, que essa foi a segunda experiência mais marcante dele aqui na Hotmart, que foi essa virada de chave no uso de inteligência artificial. Então daí para frente a gente viu o potencial imenso que tinha e aí fomos trabalhando justamente em subir um servidor, subir um MCP para que pudesse ser usado direto na IDE.

Excelente ponto. Tanto que teve um tempo que a gente chegou até a discutir sobre qual que seria ali os próximos planos, né? A gente tinha essa V1, só que a gente queria evoluir ainda mais e integrar isso dentro do LibreChat, né? Igual o Lucas comentou aí, porque eram ambientes separados. Aí a gente começou a...

fazer uma análise do que entregava mais valor. Se a gente evoluía para uma solução de web containers, que é uma solução mais elaborada do que o Playroom. O Playroom é literalmente um ambiente que permite a gente rodar o código React, porém sem lógicas de estado. Então, ele é algo mais simples ali. Mas para a prototipação, ele é muito excelente. E aí a gente usava o Tailwind, que é uma das ferramentas base que a gente tem também dentro do Design System.

e a outra parte eram os componentes então como os nossos componentes eles seguem as outras ferramentas que eu mencionei de Composition First, que é tanto o Base UI quanto o Radix eles permitem que você basicamente arraste os componentes como se fossem Legos e aí promoveu toda essa experiência user-friendly e aí que a gente falou, bom, acho que agora é o E aí

aonde que a gente pode atacar aqui, que a gente consegue agregar valor, também pensando ali nessa questão do princípio de Pareto, né? E aí que a gente foi atrás do MCP, a gente gastou ali mais ou menos um mês ali pra subir isso, foi bem tranquilo, era mais questão de estudo ali, entendendo, como essas ferramentas são bem novas, essa questão do MCP, do modelo e tal.

Então acontece que algumas IDE ainda não tem suporte a todas as ferramentas que elas fornecem. Então às vezes uma ali não tem suporte a prompts, a outra às vezes não tem suporte a samplings. Então tipo assim, hoje, por exemplo, a gente ainda não fornece um agente dentro do MCP, justamente por conta desse fator.

E também pela questão também que acredito que em algum momento a gente também tende a ir para uma ideia específica argentica, né? Então, aí muito provavelmente a gente use o modelo específico dessa...

dessa IDE específico, por exemplo, tá? Apesar que ainda não sei qual vai ser o direcionamento que isso vai ter de Golden Path. Então, por conta dessas limitações, a gente ainda não disponibilizou um agente dentro do MCP, mas é um desejo que a gente já tem, né? Então, porque existem alguns desafios ali ainda. Até mesmo da própria tecnologia.

Boa. A gente está vendo aqui, a gente falando até muito dessa inovação agora, quando a gente está falando de MCP, mas até dando um passo atrás aqui para a gente falar um pouquinho das bases técnicas antes da gente seguir, queria escutar um pouquinho de vocês também, quais foram as escolhas que vocês fizeram para essa base, para a fundação.

Bom, falando da parte técnica aqui, eu mencionei alguns momentos ali, algumas tecnologias, mas é importante destacar que hoje a gente tem duas bibliotecas principais, uma delas a gente chama de Core. Então, esse Core é responsável por fornecer a camada de fundação do nosso design system.

Então ele é basicamente a fonte da verdade ali, né? Então ele armazena nossos tokens. E esses tokens hoje, eles passam por uma ferramenta chamada StyleDiction, né? Que é uma ferramenta de tradução, né? Para plataformas. Então ela consegue transformar esses tokens, né? Que são unidades ali da menor unidade possível, né? Então, por exemplo, são variáveis CSS.

visando a menor unidade de estilização possível. E permite você traduzir isso para web, iOS, JSON e assim por diante. A outra ferramenta que a gente entendeu, que veio derivada ali do conselho de front também, é a questão do Tailwind First. Por que o Tailwind? Dos nossos estudos aqui, a gente entendeu que ela foi uma ferramenta ali muito user-friendly, tanto para a questão dos modelos de IA, justamente por conta da linguagem natural, né?

mas também pela simplicidade e adoção da comunidade. Então, ela acaba sendo uma ferramenta muito tranquila de trabalhar e ela também tem uma questão de performance absurda. Então, ela consegue reaproveitar muita coisa. E o outro pacote é a Lib de Components. Então, hoje a gente tem o Design System fornecendo essas duas bibliotecas, o Core e o Reaction, que é a nossa Lib de Components.

E aí tem a parte do Figma também, que também bebe dessa mesma fonte, que é o core dos tokens. E aí a Lib de Componentes usa as outras tecnologias, né? Que é o Radix e o Base UI, junto com o Tailwind, e com algumas coisas ali também do ChatCN e da comunidade que também permite a gente utilizar do React.

Para a parte do... Pegando um pouco o gancho do que o Snake falou sobre a stack de design, do nosso lado é um pouco mais simples mesmo. A gente trabalha com o Figma atualmente.

Mas a gente também criou algumas ferramentas e uns mecanismos para facilitar a entrega, a qualidade de entrega para o desenvolvedor. Então a gente conseguiu criar um plugin do Figma, um link, que hoje você seleciona um canvas, uns elementos, pode selecionar um componente ou a página inteira.

E ele consegue mostrar para você quais tokens não estão sendo utilizados. Ou quais tokens estão sendo utilizados do Malib antigo. Se tem a curta com um hexadecimal na mão. Então o Lynch fala, olha, você tem que usar o token tal. Você está usando um token antigo. Então isso possibilita uma entrega muito mais redonda. Em termos de...

padrões do que a gente tem de design system, mas também uma entrega melhor para o desenvolvedor. Você tem menos fricção entre o designer e o dev, porque isso é comum em qualquer lugar. Chega uma tela para o desenvolvedor fazer, fala, não, isso aqui está fora do padrão, isso aqui está diferente, vamos ter que consertar. Então, assim, reduz muito o tempo de entrega, o tempo de produção do... .

da feature que você está desenvolvendo ou do seu produto. Mas o mais importante de tudo mesmo, do lado do design, além do Figma, das ferramentas Figma, o plugin, foi uma implantação de processo dentro do time.

foi trazer os designers para perto, mostrar a importância do design system, a importância de conversar e não viver simplesmente no seu produto e cuidar apenas da sua feature. Então, a gente realmente, o processo de design, criação da mesma forma que o time de front-end tem um conselho, então a gente fez isso também do lado do design, porque...

Como os produtos nascem, acaba que nasce do nosso lado, né? A ideação nasce do produto, do time de design. A gente tem que estar alinhado também. Então...

Mais do que ferramental para a gente é o relacionamento, né? Foi o processo mesmo que a gente está implantando. Então isso para a gente também é outra virada de chave, né? Eu diria que é uma outra virada de chave, é uma maturidade que realmente era muito necessária para esse momento.

Gente, o papo está muito bom. E até aqui, só para trazer rapidamente para os nossos ouvintes, até sintetizando um pouco do que vocês tinham trago, quando a gente está falando de design system, a gente também está falando de levar em consideração o comportamento do consumidor que vem mudando.

ao longo dos últimos anos numa velocidade muito rápida. Então, a gente está falando da parte técnica, mas a gente está falando de entender também novas tendências de marca, de branding. Então, o papo aqui a gente poderia expandir por mais um tempão para entrar em todas essas frentes. Mas como a gente precisa começar a caminhar aqui já para o final...

E aí eu trouxe até um pouquinho desse ponto aqui para pegar um gancho, que é o que os nossos ouvintes podem e devem fazer para amadurecer o design system na sua empresa. Pegando um pouco do que eu estava falando, eu acho que ferramental, sim, é importante. A gente precisa realmente ter isso de uma forma organizada, documentada. Todo mundo precisa estar na mesma página.

Mas para mim, o que pode e deve fazer é você estar presente em todos e trazer a empresa para o seu contexto também. Todo mundo tem que entender um pouco de tudo. Tem que conversar, tem que estar alinhado, comunicação. Eu diria que pode e deve se comunicar mais. Eu acho que é aí que a gente se perde, porque criar um design system não é tão complicado.

O difícil é manter um design system, é evoluir um design system, é não deixar as pessoas perderem e falarem. Qual que, no meio de um processo, você está lá dois anos trabalhando nisso, todo mundo entende valor. Como é que a gente não deixa as pessoas esquecerem que aquilo é importante? Eu acho que é muito mais a comunicação, proximidade e processos.

Porque pegar uma Lib, adaptar para a sua identidade visual e ter uma V0, uma V1, é de boa, é tranquilo. O difícil é manter, é aplicar, é escalar e não deixar a peteca cair. Eu acho que é a união da coisa.

Inclusive, se caso, por exemplo, a equipe mudar as pessoas que fazem parte dela, elas não abandonarem o Design System. Não é começar de novo, não é começar de novo. É a gente ter histórico, aprender com os erros e nunca deixar a peteca cair mesmo. É sempre um passo à frente na parte técnica.

Falando um pouco a respeito do que eles podem e devem fazer, um dos pontos aqui que acho que ficou muito evidente ao longo de toda a nossa conversa aqui é que a cultura do design system está muito intrínseca em todas as fases. Então a gente falou ali da gestão envolvida, a gente falou do time técnico, a gente falou do time de produto, do time de marketing. Então a gente precisa que todas as pessoas ali envolvidas, tanto no consumo,

Elas saibam o porquê, a importância disso e quais impactos isso causa no nosso dia a dia. A gente pode colher e ditar aqui vários benefícios que o design system tem, várias métricas de uso que podem acelerar a nossa eficiência. A gente pode entrar em vários outros subtópicos a respeito do design system. Só que a gente precisa ter esses pilares fundamentais dentro da empresa, que é essas...

organizações que o Pang mencionou, né? Que são os processos design, são os comitês, são esse fortalecimento ali de comunidade, pra que a gente prolongue a vida útil, tanto do design system, mas dos nossos sistemas, né? Então, porque, tipo assim, o design system, querendo ou não, ele é um alicerce dos nossos outros sistemas.

Então ele faz parte disso. Então a gente precisa olhar para ele também com o mesmo carinho que a gente cria os nossos produtos para o usuário final. Porque é lá na ponta final que ele vai impactar.

Eu diria que nossos ouvintes podem e devem saber que Design System não é gasto, ele é investimento. Então, como o Snake já disse, em relação às pessoas olharem para o DS como uma oportunidade, como tudo na vida, você tem um gasto inicial maior.

mas você tem um retorno a médio e longo prazo. Então, o tempo que você gasta inicialmente para formular, estruturar, roadmap, encaixar o design system nos produtos, nos programas da companhia...

A curto prazo é um pouco complexo, demora, é caro, mas a médio e longo prazo você tem um benefício, por exemplo, em relação à produtividade, porque o tempo que você gastaria para desenvolver uma tela, você reduz ele 30%, 50% ou até mais, agora com a IA a gente está falando de 80%, 90% de trabalho economizado com a IA, integrando, por exemplo, com o Figma DevMode.

Então, eu acredito que, principalmente os stakeholders, enfim, diretores, o pessoal da alta liderança da companhia, entender que o DS é sim uma ferramenta potencializadora de resultados. Então, desde a experiência do usuário até produtividade interna, até resultados finais da companhia.

Bom, é sobre investimento, mas é sobre crescimento saudável, então, né, Luquinhas? Perfeito, isso aí. Aí assim a gente segue aqui para o final do nosso episódio. É isso, mas teremos muitos outros episódios sobre front, né, gente? Quero receber vocês aqui muito mais vezes, com certeza.

Teremos e teremos também mais assuntos no Hot Encode Conference. Teremos aí, para os nossos ouvintes, tem o cupom PODDEV10, que dá 10% de desconto nos ingressos do nosso evento. Vale cada centavo, assim como o DS é investimento, o Hot Encode Conference para a sua carreira é um investimento também.

Porque a quantidade de conhecimento que você pode adquirir ali, junto com diversas pessoas extremamente sênios e especialistas da Hotmart e do mercado, é uma coisa inigualável. Vocês não vão se arrepender. Podem mandar nos comentários se você já viu algum conference, se você já esteve aqui com a gente dentro da Hotmart. Comenta aí nesse episódio. Comente aí o que você acha do DS, da empresa de vocês.

E quero agradecer os nossos ouvintes que nos escutam aí e sempre estão participando dos nossos episódios. Aos nossos convidados que vieram aqui trazer um pouco do conhecimento, vivência e história junto com o Design System, né? E nos vemos nos próximos episódios, pessoal. Muito obrigado. Valeu. Valeu, pessoal. Valeu.

See you next time.