Era uma vez um Design System chamado Copan…
[…] Ele é um sistema completo, que foi idealizado e feito em pouco tempo. O processo de criação foi rápido, eficiente e colaborativo. Sempre tivemos um direcionamento claro do que fazer e como fazer. Um produto feito de desenvolvedores para desenvolvedores, de designers para designers. Um ao lado do outro. Todos o amam, todos o utilizam. O produto perfeito, com um final feliz…
Corta. Próxima Cena .
Trimmm trimmm trimmm (barulho de despertador).
Hora de trabalhar. Acordo, tomo banho, escovo os dentes, me arrumo. Não costumo tomar café da manhã. Pego minha bike e vou até a Loft. Chego em 15 minutos. Me deparo com a realidade, e bem, ela está distante do meu sonho de conto de fadas.
De fato, o nosso Design System chama-se Copan. Talvez essa tenha sido a única coisa verdadeira do sonho. Felizmente, a história baseada em fatos reais é diferente.
"Ué, felizmente?"
Sim. Afinal, qual a graça de tocar um produto sem um desafio daqueles que te faz quebrar a cabeça para entender o que fazer?
Se você discorda, já aviso, talvez você não se interesse por essa história.
Ela começa dia 4 de Novembro de 2019, o dia que entrei na Loft. Nunca havia trabalhado como PM, tampouco com produtos front-end. Minhas experiências anteriores estavam mais focadas em produtos que envolviam backend.
Diante desse histórico, quando apresentaram o meu novo desafio, que era fazer parte de um Squad chamado Core Ux, onde o principal escopo seria dar continuidade ao Copan, o nosso Design System, pensei "O que diabos é um Design System?".
Entrei no bom e velho Google, coloquei todos os links que achei interessantes em um Word, e fui abrindo um por um, me informando aos poucos, entendendo, assimilando. Anotei as dúvidas e conversava com os desenvolvedores e designer do Squad e com outras pessoas para também entender mais sobre o contexto do Copan.
Com isso, também abri a porta de um novo mundo. Quase outra dimensão, tipo Stranger Things. Esse novo mundo, na verdade, era quase uma galáxia inteira chamada UI, onde habitam coisas como HTML, CSS, JavaScript. Border-radius, Shadows, Grid, Padding… enfim, já captou, certo?
E aí, então, que se inicia meu ciclo de vários tropeços, alguns acertos e muitos aprendizados na construção de um Design System.
3,2,1, valendo.
Comecei o trabalho basicamente dando continuidade ao que o Squad já estava programando, apenas organizando melhor o roadmap em fases, pensando a curto, médio e longo prazo sobre o que gostaríamos de fazer com o Copan.
O macro objetivo a curto prazo era fazer as pessoas realmente começarem a utilizar os componentes do nosso Design System, portanto, tínhamos alguns afazeres:
- Terminar de fazer todos os componentes "básicos" de uma interface do zero, como botões, inputs, dropdown (select), radio button, checkbox, entre outros, para tornar a biblioteca de padrões mais completa.
- Migrar as páginas atuais do site da Loft para importar a biblioteca do Copan para que não houvessem quebras quando os nossos desenvolvedores realmente começassem a utilizar os novos componentes.
- Paralelo a isso, estava claro para o Squad que precisávamos criar um processo de colaboração para que todos os designers e desenvolvedores conseguissem contribuir com o Copan, criando novos componentes, fazendo melhorias e consertando bugs. Afinal, quando conversamos sobre o futuro do Squad, não estava no nosso planejamento ficar criando componente a de eterno. Precisávamos de aliados e de engajamento.
Até aqui, nada muito complexo: bastava organizar o backlog, estimar as tasks, inciar a sprint, e assim completaríamos rapidamente as três tarefas.
Pois bem, a teoria é mais simples do que parece e foi aqui que começaram os meus tropeços e aprendizados dessa primeira fase de criação do Design System.
Vivendo e aprendendo.
- Fazer componentes, do zero, não é uma tarefa trivial.
Não basta escrever uma user story "Eu como designer e desenvolvedor quero utilizar o botão diretamente da biblioteca do Copan" e achar que a mágica vai acontecer.
Seguindo com o exemplo do botão, vamos pensar nas decisões mais básicas que precisam ser tomadas apenas individualmente.
Quais serão os tamanhos? Os estados (enabled, disabled, hover, etc)? Quais cores serão utilizadas? Vamos ter variações com ícones? Aproveito para compartilhar a leitura do Nathan Curtis "And you thought buttons were easy?" que vai ajudar nesse entendimento.
Além dessas decisões no âmbito individual, uma parte crucial do processo é pensar nesses componentes de forma coletiva. Talvez as decisões tomadas anteriormente não vão se encaixar muito bem nas interfaces atuais com todos os outros componentes.
Para ganhar velocidade na criação do Copan, definimos por padrão que os botões no estado disabled teriam 40% de opacidade. Isso funcionava em quase 90% dos casos, porém não fazia sentido quando esse botão era inserido no Hero com uma foto de fundo, por exemplo.
Esse foi apenas um dos casos de quando começamos a testar os componentes no todo. Portanto, a ideia é sempre criá-los pensando no coletivo e nos casos de uso, explorando bastante as interfaces atuais do seu produto, se ele já existir. Caso estiver no início da criação de um produto, é melhor compor e idealizar primeiro as funcionalidades e telas e estressar os protótipos com todos esses componentes coexistindo.
Outro aprendizado importante é não subestimar o tempo que leva para desenvolver e codar uma "família" de componentes. O processo end-to-end pode custar dias de um desenvolvedor e se você não estimar as tarefas com os pés no chão, com certeza isso irá atrasar sua sprint. Essa situação foi algo que o Squad vivenciou e por isso resolvemos mudar a abordagem depois de um tempo.
2. Não monopolize o processo criativo.
Parece óbvio, mas vale reiterar: monopolizar o processo de criação do seu Design System e biblioteca de componentes não é uma boa ideia - aliás, para ficar claro, é uma péssima ideia.
Traduzindo: se você tem um time de designers e desenvolvedores na sua empresa, use e abuse desses recursos.
Isso é valido não somente pelo senso comum de que "várias mentes pensantes são melhores que uma", mas também pelo processo básico da construção de um produto: criar a solução à 4 mãos, colhendo feedbacks dos usuários de forma contínua para resolver algum problema.
Resumidamente, não vale você criar um "checkbox" da maneira que você acha mais bonita, funcional ou agradável. Você precisa saber se esse componente agrada aos seus usuários, se ele soluciona o problema de algum designer e se ele está adequado para as interfaces atuais.
Nunca - repito - nunca, insira um componente no backlog para desenvolvimento sem antes validar com a maioria do time de designers. Dependendo do nível de engajamento os feedbacks serão extremamente úteis e você vai ter o buy-in do produto, pois na prática foi idealizado pelo próprio time.
3. Follow-ups são essenciais.
Não saia do radar. Quem não é visto, não é lembrado.
Conforme comentei acima, um dos afazeres a curto prazo era criar um processo de colaboração, e que de fato criamos. No ppt.
Comunicamos para toda a área de tecnologia com uma apresentação bacana. Nada mudou.
É claro, acabamos não fazendo follow-ups com o time pois concentramos as atenções do Squad em um outro produto e o processo de colaboração ficou à deriva.
Atualmente, venho participando dos fóruns do time de design para sempre ficar por dentro do que está rolando e aproveitar para evangelizar o Copan.
4. Aconteça o que acontecer, a culpa é sua.
O título está mais apocalíptico do que parece, mas já parou para pensar que é muito mais fácil se responsabilizar pelos "tropeços" (um eufemismo para erros nesse caso) que acontecem quando você está tocando um produto?
O que eu quero dizer é que, entre vários motivos que não conseguimos entregar com eficiência e sucesso o Copan nessa primeira fase, tenho certeza que poderia ter feito meu papel como PM muito melhor.
Seus usuários não estão gostando do produto? Você não ouviu eles como deveria. Não validou o suficiente.
O processo de colaboração não funcionou? Faça outro, faça melhor e continue testando novas ideias.
Atrasou a sprint? Estimou mal as tarefas ou superestimou a entrega do time.
Não estou dizendo que "tropeçar" nesse caminho é anormal. Pelo contrário, faz parte da evolução. O que estou dizendo é que é mais fácil trazer a culpa para si e tentar achar um meio para melhorar. Caso contrário, quando o problema vira do outro, o que você pode fazer para mudar a situação?
No geral, esses foram os principais pontos do início da minha jornada de construção e envolvimento com o Copan. Atualmente, estamos vivendo uma “segunda fase” de criação após pivotarmos a nossa abordagem e pretendo compartilhar em um próximo texto.
Ainda temos muito caminho pela frente e com certeza virão novos aprendizados e tropeços por aí.
Faça parte do time Loft!
Quer trabalhar em uma empresa que está revolucionando o mercado imobiliário?
Veja nossas vagas e se inscreva! — https://jobs.lever.co/loft/
