0:00 Design System para startups, do zero ao sistema. 3 meses é o tempo que você e o seu time pode perder, refazendo a mesma tela cinco vezes ou mais, porque cada botão ou cada componente tem uma cor diferente ou um canto arredondado diferente e não tá conectado nem no Figma, nem no código. O problema cresce com o developer perguntando que fonte é essa? Esse espaçamento é 16 ou 20 pixels ou 24? Essa tela utiliza tokens ou não? Agora faça o cálculo de quantos milhares ou milhões de reais você e o seu time joga no lixo por ano por não ter um sistema construído da forma certa. Hoje você vai aprender a construir um sistema. A pergunta é por onde começar? Como criar um sistema que funcione de verdade em um startup onde tudo muda
0:46 toda semana e o time às vezes é inxuto ou às vezes é uma pessoa. Vou te contar como implementar um design system em uma startup de forma prática. sem firula, sem diz que me diz e que realmente funciona. Tudo nesse vídeo é baseado nas minhas experiências e lideranças de times. Atualmente, por exemplo, eu lidero times de web app, incluindo design operações e design system. Fui responsável pela construção do design system do time da Rolls-Royce há uns 6, 7 anos atrás e feito no Photoshop. Pois é, Design System no Photoshop. Já parou para imaginar? Eu tô falando isso para você entender que hoje você vai aprender. Eu já fiz isso, opero design system alguns anos e a ideia aqui é te passar passos práticos e construções e
1:35 técnicas para que você consiga chegar no mesmo resultado que os meus times chegam. Mas aqui fica uma pergunta: por startups precisam de design system? Primeiro vamos entender o problema real. Cenário típico de startup aqui para você entender. Designer fazendo tela atrás de tela. Grande parte baseada em velocidade, não em consistência. Cada tela pode ter uma inspiração diferente, ainda mais se a startup tiver vários designers em várias áreas diferentes. Parece até que o aplicativo ou website foi feito por 26 agências completamente diferentes. O developer perguntando qual corada, qual componente é isso, onde é que isso aqui tá, que documentação que é essa. Preciso codar tudo de novo do zero. PM reclamando que demora muito para fazer mudança ou que cada mudança parece uma tela completamente nova. Se
2:23 você já passou por isso, a aula de hoje vai te ajudar e muito. Eu sei que você tá se perguntando agora na sua cabeça: "E o que que um design system resolve?" Consistência visual, escalabilidade entre design e engenharia, velocidade de desenvolvimento, o que reduz custo, menos retrabalho, o que também reduz bugs e custo, comunicação mais clara entre os times de diversas áreas, estabilidade no produto, menos quebras e menos Pzer, ou seja, menos problema. principal para ser resolvido, menos quebra de sistema. A real é que sem um sistema, o produto inevitavelmente quebra quando cresce. Então é uma questão de tempo. Se o seu produto ainda é pequeno, possivelmente não precisa de um design system, mas se o seu produto
3:08 está crescendo, inevitavelmente ele vai quebrar. E o produto corre o risco de um refactor gigantesco, de ter que parar de funcionar para ser reconstruído. E você não quer participar de uma reconstrução de produto. Vou te falar, é problema. Quando começar e quando não começar um design system. Você não precisa começar um design system se você tem menos de cinco telas no produto ou se o seu produto é algo que nem testado foi ainda. Se você ainda tá validando um produto ou entendendo o product market fit, você também não precisa de design system. Se o seu time tem menos de três pessoas, a comunicação não é tão difícil assim. Talvez seja, depende do seu time. O produto muda radicalmente toda semana.
3:54 sistema de design vai acabar não te ajudando. E quando fazer um design system? Você precisa começar um design system quando você tem de 10 a 15 telas ou pelo menos uma jornada minimamente definida e validada. Se você já começou a repetir componente, repetir utilizações de coisas dentro do seu filme e dentro do código, Design System pode ajudar. Tem mais de um designer e mais de um front end trabalhando especificamente em construir páginas. Pode te ajudar. Produto tem uma direção mais definida, já sabe onde vai, já sabe o que quer, pode te ajudar. Você tá gastando tempo demais com inconsistências e diversas vezes você precisa refazer coisa que já fez porque desenhou errado. Design system. Os bugs, ou seja, problemas e erros no código começaram a aparecer porque os
4:40 componentes estão sendo colocados e codados na mão todas as vezes. Design system pode te ajudar. Então é bem simples aqui. Existe um porqu sim, existe um porquê não. Não serve para todo mundo, mas também não é uma coisa que vai te custar muito se for feito. Então mesmo que não seja o seu cenário, pode ser que ajude muito o seu time. Vale a pena pensar nisso. Aqui vai um método incremental que funciona. Esqueça criar um sistema completo do zero. Em uma startup você precisa de resultado rápido. Você precisa dividir em fases o que você vai fazer com o tempo certo, com a abordagem certa, senão você não vai conseguir entregar um design de sistema que funcione. A fase um é auditoria. uma semana, pegue todas as telas do produto atual, identifica quais
5:27 os componentes repetem diversas vezes, até mesmo quais os padrões de comportamento, cliqus, espaços e utilizações básicas do que eu chamo de foundation, ou seja, fundação. Quais desses itens repetem e quantas vezes repetem? Você vai criar uma lista de inconsistências de cores, fontes, espaçamentos e componentes. Quais as coisas estão sendo desenhadas de forma similar, mas que são inconsistentes. E aí você vai priorizar pelo que mais impacta e o que mais aparece na cara do usuário. Então, toda essa lista que você fez, toda essa priorização que você fez de repetição e inconsistência é a sua priorização do que aparece mais pro usuário. Então tudo que o usuário vê com constância é prioridade para ser
6:13 consertado dentro do design system. Fase dois, fundação. Uma duas semanas, você vai definir a paleta de cores da empresa, máximo cinco cores principais. Essa paleta de cores possivelmente vai vir do time de marca e de brand. Você vai escolher a tipografia, uma ou duas fontes ao máximo. Repito, possivelmente vai vir aí do seu brand guidelines e do seu time de marca. Você vai criar um grid básico, tanto de web como de mobile. Você vai criar um grid também entre os espaçamentos, tanto espaçamento lateral como vertical. Você vai padronizar os tokens básicos, ou seja, qual que é a linguagem dos tokens? A Jot, como que eu padronizo o token? fala com um time de engenharia. Deixa eu já deixar um adendo gigantesco aqui. Se você acha que design system é sobre design, bem você aprendeu design system errado e possivelmente aprendeu com o
6:59 influenciador. Design system é sobre produto, é sobre serviço, é um SAS quase. Ele depende de design, engenharia, conteúdo, estratégia, negócios, resultado, métrica e por aí vai. Então, padronização de token é básico, você tem que fazer. Se for app nativo, iOS guidelines. Se for Android, material design. Se for web, a escolha mais livre eu recomendo CHD CN ou TS SS, porque funciona melhor e é mais flexível. Fase três, componentes básicos, duas a três semanas, depende aí do lével de conhecimento que o seu time tem em relação a design system. Botões, quais são os primários, secundários e texto. Inputs, ou seja, formulário. O que que é texto? O que que é seleção, o que que é testa, ah, o que que é
7:45 multelector e por aí vai. Cards básicos precisam ser feito, imagem, texto, título, imagem, preço. Todos esses cards mais básicos do seu produto precisam ser feitos. E a navegação principal, tanto a navegação de cima como a navegação de baixo. Todos esses componentes, eu chamo ele de componente imutável. São componentes que você vai fazer uma vez e você vai atualizar pouquíssimas vezes durante a sua jornada e o seu uso dentro do seu produto, mas são componentes que sem eles o sistema falha, porque você precisa deles. Fase quatro, componentes avançados, conforme necessidade, obviamente, porque depende do produto e depende do time. exemplo, modais, tabelas, formes mais complexos, componentes específicos do produto, banner ou coisas de compra, de checkout, são componentes que são mais complexos,
8:32 demandam de mais pesquisa, demandam de mais atenção, logo nem sempre são prioridades nesse início. Dica rápida, anote. Comeceo e orgânico. Envolva o time todo desde o início. Não vá tentar fazer a parada sozinho achando que você vai conseguir. Não vai. Foque em componentes que realmente são utilizados pelo time e pelos usuários. Documente depois, implemente primeiro. Documentação importante. A J, eu sei. Nós estamos falando paraa startup. Implementa primeiro, documenta depois. Porque na implementação você vai aprender o que precisa ser documentado ou não. De qualquer forma, seja pragmático, não perfeccionista. Esse eu tenho um problema pessoal com ele. Design coding, ou seja, design e código
9:18 andam juntos. Se você só faz design, não é um design system. Só faz código, não é um design system. Os dois precisam coexistir. Sistema é sobre código. Sistema é sobre futuro. Facilidade de replicação. A palavra aqui é muito bonita, replicar. Um sistema é sobre reutilizar. Um sistema é sobre não ter retrabalho. Então é uma forma de você replicar o que já foi feito inúmeras vezes, sem ter que refazer todas as vezes. E agora vamos falar um pouquinho de estrutura prática que funciona. Organização no Figma. Vou colocar um print screen na tela aqui e você vai seguindo aqui o que eu vou te falando. Lá em cima você tem design system que aí você vai nomear o seu design system. Eu já trabalhei com o design system da Rolls-Royce que chamava RR System. Já
10:04 trabalhei com o design system da BTI que chama Loop. Trabalhei com design system da Kazu, que chamava CZ. Ah, e agora eu tô indo para uma nova empresa que tem um novo tipo design system que se chama TT System. Então, todos esses design systems você pode escolher o nome. Abaixo disso você tem categorias e aí dentro das categorias você tem os itens que serão criados. Então, categorias aqui são fundações, componentes. Anota aí, fundações, componentes, patterns, que são padrões, templates. Essas são as categorias. Agora a gente vai falar do que que tá dentro de cada uma. e por que elas são categorias. OK? Então, dentro de fundação, você tem cores, tipografias, espaçamento e grid. Essas fundações, elas são imutáveis, você não vai ficar mudando elas ou atualizando elas toda semana, ok? São fundamentos
10:50 que você cria pro seu sistema, que são a base da construção, é o alicerce da construção do seu sistema a longo prazo. Dentro de componente, aí depende do que você tem no seu sistema, da sua necessidade. Você tem botões, formulários, navegação, layout e por aí vai. Componentes pode ser qualquer coisa, pode ser cards, pode ser tudo que você tem aí no seu sistema. Tudo relacionado a formulário, tudo relacionado a botão, tudo relacionado à tipografia. Tudo que você tem que é um componente que vai ser reutilizado, tá dentro da área de componentes. Patterns, essa é nova. Patterns seriam como se fosse linha de raciocínio. Exemplo, o flow de login, por exemplo, a página de login. Ah, J é uma página, não é bem uma página, é um flow, é uma experiência. O dashboard, o layout do dashboard não é
11:35 um componente, é uma pattern, é um padrão visual. Ah, erros, por exemplo, todos os erros e estados de erro positivo ou negativo, é um pattern, é um padrão visual, não é um componente. Então, tudo que for o padrão visual mora dentro de patterns, templates. Bem, aqui depende, é arriscado fazer, mas depende, porque o template pode ser que o seu sistema comece a virar um pouco de WordPress e os seus clientes e o seu time de liderança não entenda muito bem a necessidade de template ou não. template pode ser landing page, product, settings page, profile page. Todas essas podem ser templates. Caso você não queira arriscar do seu líder ou do seu executivo começar a imaginar, pera aí, se tem template, eu não preciso do designer nem do desenvolvedor. É só fazer todas as páginas em template. Não
12:22 faça. Se você perceber que existe uma maturidade em comunicação, que eles não vão imaginar que o template feito uma vez acabou, aí faça, eu evito. Aí sou eu. Agora, como fazer uma implementação sem quebrar o produto? Aqui vai um aviso gigante, cuidado. Não se empolgue porque o sistema é legal e design system é fun. Se for feito errado, abraços para você e pro seu time. Porque quando dá errado um sistema, custa um dinheiro. Uhum. Então aqui vai uma dica de estratégia de migração. Não refatore tudo de uma vez. Ou seja, não vai refazer tudo de uma vez e achar que tudo vai virar sistema da noite pro dia. Não vai. Implemente componentes novos primeiro. Ah, J, mas você falou para fazer auditoria. Sim, a auditoria é priorização. Mas você vai
13:08 começar a implementar o que que é novo primeiro. Por quê? Porque não existe. Não foi utilizado em 400, não vai precisar de refatoração. Então você consegue implementar mais rápido. Você vai começar a migrar telas gradualmente, você não vai sair migrando tudo, OK? Teste em produção aos poucos. Faz um componente, joga na produção, vê o que acontece com o time de engenharia, vê o que acontece com os usuários. Tem arquivos no Figma de teste, não vai fazer suas alterações que eu tô te falando no arquivo master lá do seu UI kit. Pelo amor de Deus, não seja ingênuo, vai quebrar tudo. Cria um arquivo lateral, cria um sistema lateral, trabalha nele, testa ver se funciona, depois você faz o a virada, ok? Entenda se o que você já faz quebra
13:53 e se o que já existe está quebrando, porque você precisa saber se vai quebrar na hora que virar ou na hora que não virar. Planeje com o time como vai ser essa virada de desenhar na unha, codar na unha e agora todo mundo usa o sistema. Que regra é essa que você vai criar? E aí a gente vai falar de governança no próximo bloco, mas você vai precisar de regra, porque não adianta você ter um sistema se ninguém usa. Aí tu gastou dinheiro de novo, cuidado. E aqui vamos falar de governança. Governança é quem decide o quê. O designer decide aspectos visuais e o basicamente. O desenvolvedor define aspectos técnicos e performance. O PM decide priorização e roadmap. E todos os
14:38 envolvidos ou informados decidem naming, ou seja, as nomenclaturas e a organização disso. Claro que isso em um modelo descentralizado. Se falarmos de um modelo centralizado, aí vai ser necessário um time específico dedicado para criar o sistema e cuidar do sistema, porque criar um sistema qualquer pessoa cria. Manter um sistema é aí já é um pouco mais difícil. E quando falamos de governança, falamos da seguinte frase que vai aparecer depois de três dias que o sistema tiver no ar. A J, eu preciso de um componente novo? Bem, pode ser que sim, pode ser que não. Primeiro, proposta com justificativa. Por que que você precisa de um componente novo? Será que os componentes
15:24 que a gente já tem não cabem aqui aonde você precisa nesse problema? Número dois, discussão com stakeholders. Você vai ter que falar com o seu time. Olha, teve uma proposta de um componente novo. A gente acha que vale a pena ou não vale a pena? Vamos explorar ou não vamos explorar? Prototipagem rápida. Se vale a pena, vamos prototipar. Vamos tentar entender que componente é esse. Quatro. Implementação gradual. De novo, nada em sistema é assim. Tudo em sistema é devagar, é gradual, é lento, é, ó, no passinho, não vai sair dando pulo, não. E por último, feedback e ajuste. Colocou no ar o novo componente, funciona ou não funciona? Gera resultado com os usuários ou não? É importante fazer isso porque design system não é só fazer o
16:09 componente, lava as mãos, todo mundo vai para casa feliz, pode dar errado. A J, e quais são as métricas que importam quando falamos de design system? Você tem indicadores de sucesso, que é o tempo para criar uma nova tela, ele deve diminuir, óbvio. O retrabalho de design também deve diminuir, bugs visuais, ou seja, erros visuais que deve diminuir, satisfação do time, deve aumentar. Adoção do sistema, do design system é importante, precisa crescer. Tempo de design até a engenharia e o produto no ar é esperado que se reduza gradualmente, não vai reduzir imediatamente. Reclamações de clientes e usuários deve diminuir, ligações pro customer service deve diminuir, mas existem algumas armadilhas comuns aqui
16:56 nisso tudo. Overengineering, que é criar componente para caso futuro e ficar tentando fazer aquilo ali ser o o mais bem desenvolvido possível. documentação excessiva, abstração desnecessária, tudo que é overengine engineering, overdesign, onde você tá perdendo tempo demais, é desnecessário. Perdeu o tempo demais, discutiu demais, já não é sistema. Under adoption, ou seja, a adoção ela tá baixa. Por quê? Porque você não treinou o time, os componentes são muito rígidos, não tem uma flexibilidade, faltou comunicação, é problema, é armadilha e você tem que prestar atenção nisso. Perfeccionismo, esperar estar 100% pronto para poder lançar, tá atrasado. Não interar com feedback, tá errado. Foco em forma, mas
17:43 não na função daquele componente. Na beleza, mas não na funcionalidade. Tá errado. Tudo isso são alçapões, erros que você pode cometer, mas não vai, porque eu acabei de explicar. Tomara que não vá, né? Acabei de explicar, pô. Anota. Evolução contínua. Design system não é um projeto, você faz e acaba. Design System é um produto, e eu digo mais, Design System para mim é um serviço que a empresa contrata internamente para ser utilizado. E digo mais, design system não só é um serviço, como esse serviço ele é pago pela própria empresa. Então, se você aí tem uma discussão interna com o seu time que tá sempre ali, é, mas
18:28 como que a gente vai pagar por esse sistema? Quem que vai pagar pelo sistema? Os times que utilizam o sistema. Porque é um sistema, da mesma forma que você contrata o Figma, da mesma forma que você contrata o Confluence, você está contratando um design system. É um sistema de componentes e bibliotecas e documentações e regras que ajudam com que o produto tenha consistência, escalabilidade e que reduza refatoração, dinheiro, sinais que você e o seu time precisam evoluir. O design system componente começou a ser hackeado demais, que é o famoso ditat. Eu tô metendo ditat em tudo a J. Se isso tá acontecendo com constância, talvez seu design system precise de um update. Novos padrões de comportamento começaram a aparecer. Organicamente, seu design
19:15 system precisa de um update. Feedback constante e cheio de limitações. Designer tá reclamando o tempo inteiro que o design system tá cheio de limitação. Vale a pena dar uma revisada. O produto começou a mudar de direção, tava aqui, agora tá indo para cá. Vale a pena revisar o seu design system. E como evoluir esse design system se ele tiver realmente mudando? Você precisa fazer review mensal com o seu time. Você precisa ter um roadmap alinhado com o produto. Porque de novo, design system é um produto, é um projeto de longo prazo, é um serviço. Logo, da mesma forma que seu aplicativo tem um roadmap, o design system também tem um roadmap. deprecação gradual de componente antigo. Tudo que for ficar for sendo antigo ou que não funciona mais, você simplesmente faz com que ele não exista ou faz o dial down,
20:03 começa a diminuir o uso dele e coloca o uso de um novo componente mais atualizado. Documentação de mudanças, log. Você precisa de um change log ali para mostrar pro seu time o que quer que tá atualizando. Pegou? Fechando aqui, design system startup não é sobre criar a solução perfeita, é sobre criar solução que funciona pro seu contexto atual e que vai acabar evoluindo junto ao produto. Não é resolver hoje, é resolver o amanhã e o depois de amanhã. Você precisa começar pequeno, seja pragmático, envolva o time todo. E lembre-se, melhor ter um sistema imperfeito que funciona do que um sistema perfeito que ninguém usa ou um sistema que não atende as necessidades básicas do seu produto e dos seus usuários. Aí é problema. O importante é
20:50 criar consistência, velocidade, escalabilidade do time interno e do produto. O resto é perfumaria. E a última dica, documente as suas decisões, não apenas os componentes, mas as decisões. Isso vai salvar muito tempo quando o sistema evoluir. Caso tenha curiosidade, deixa um link aqui, um link e acabou. Chama designsystems.com, criado pelo time do Figma. E tem tudo lá, artigo, todos os sistemas de design para você se inspirar, tudo que você precisa. Fui.
