Design System: da confusão à construção de um produto
Reunimos neste capítulo inicial os primeiros passos e aprendizados dos criadores do DS da Quero
Quem já participou do processo de construção de um design system sabe que não é fácil. Na Quero, vivenciamos fases distintas na construção no nosso DS, e hoje, com um pouco mais de clareza conseguimos identificar três fases e nomeá-las de: fase da confusão, da construção e, atualmente, a fase de continuação que pretendo detalhar em breve.
Mas antes — só para contextualizar um pouco mais sobre o que é isso — design systems são sistemas (como o nome já nos sugere) que reúnem princípios, padrões e bibliotecas que facilitam o desenvolvimento de outros produtos.
Para chegarmos até aqui, foi preciso um marketplace em pleno funcionamento e da visão de importância que o time de Design tem para a empresa.
E novamente: não foi fácil. Adianto que, de todos os aprendizados, o maior foi entender que nem sempre o que um product designer quer é o que os stakeholders e a Engenharia precisam.
O que tínhamos a nosso favor? A diretoria da Quero estava do nosso lado e viu a necessidade de desenvolvermos um design system quase ao mesmo tempo que nosso time. Seria bem mais complicado se tivéssemos que trabalhar duro também para convencer a diretoria.
De resto, de componente em componente, do buy-in à governança, foram cerca de dois anos para que tivéssemos em design a certeza de que havíamos concluído uma importante etapa: a zillagem de todas as páginas do marketplace! Ou seja, havíamos concluído a conversão das páginas antigas para o Zilla.
E, sim, aqui o design system é verbo; é ação.
Confusão: preciosismo versus pragmatismo
Inconsistência. Este, quase sempre, é o motivo que leva um time a pensar no desenvolvimento de um design system. E ele foi o nosso também: quando não há padronização, cada product designer acaba desenhando uma página à sua maneira. O resultado disso era claro para todos da empresa: o que o nosso maior produto, o Quero Bolsa, menos possuía era coerência quanto aos componentes do site.
A inconsistência acabava afetando a nossa relação com a Engenharia. Havia um custo grande com a criação de cada página praticamente exclusiva desenvolvida por diferentes designers, mesmo que a intenção fosse a mesma de um time. Tanto para os engenheiros quanto para os designers, o tempo de implementação de novas features era bem maior.
Ao fim, os stakeholders entenderam a dor do usuário também, o maior afetado na cadeia. Por isso, ter o buy-in da diretoria foi mais fácil. Então, o time de design de produto tinha a primeira decisão a ser tomada: fazer o DS do zero ou refatorar tudo. Naquela época, a maioria votou por criar um design system do zero. Autocrítica aqui é bem-vinda: ao optarmos pelo caminho mais difícil, é necessário admitir que foi, sim, um preciosismo nosso.
Quando começamos a pensar no nosso design system, a primeira tarefa a ser feita seria entender o ponto de intersecção entre cada uma das áreas que dependeriam dele — como o Produto, a Engenharia, o Design e o Branding — e como elas se relacionariam. Porém, ao rever todo o processo de construção, é claro o fato que começamos pelo mesmo motivo que todas as empresas começam: era o designer querendo construir algo — mesmo que sem pragmatismo, naquele momento, era a vontade de fazer acontecer.
A história do inventário
Aqui no time de tecnologia da Quero, a história é bem famosa. Um dia o time de designers foram para um coworking e lá se isolaram por uma semana para elaborar a primeira etapa da construção do nosso Zilla.
O processo foi bem oldschool. Foi feito um inventário físico (e nada ecológico), foram impressas todas as páginas do Quero Bolsa e coladas na parede para mapearmos todos os componentes que já existiam. Este foi o primeiro passo da construção, já que um DS é construído a partir de uma necessidade específica e a nossa já havia sido apontada.
Com todas as páginas, as necessidades e os problemas visíveis, o time começou a listar tudo para posteriormente desenhar tudo que seria necessário para uma library. Foi nessa fase também que os princípios iniciais do Zilla foram desenvolvidos. Afinal sem isso não teríamos um DS, no máximo uma nova library e não seria esse o caminho para que os problemas fossem, enfim, resolvidos.
Era hora de decidir muito além do acabamento de cards e botões. Foi o momento de unir o planejamento da construção ao branding e também à acessibilidade. A partir daí, foi o início da segunda fase, chamada de construção.
E assim nosso time ganhou o que mais nenhum outro time de tecnologia tinha até então, o dia da guilda de design, no qual dispúnhamos de um dia da semana dedicado à resolução de problemas globais da empresa. Naquele caso específico, zillar as páginas do nosso marketplace era um deles, sendo esse, naquela época, um trabalho de todos os product designers.
Nem tudo são flores — não mesmo
Um design system é um produto — é assim que vemos hoje e como, na nossa visão, deve ser visto desde o início.
Infelizmente não enxergamos o Zilla dessa forma lá no início, quando um grupo de designers da Quero resolveu se reunir para fazê-lo de fato acontecer. O resultado daquela semana de imersão foi a construção de um design system para designers e não para a Engenharia, não para a empresa.
Hoje, com os aprendizados colhidos após as falhas ali do comecinho, percebemos que primeiramente devemos entender se aquele projeto vai resolver os problemas e não apenas pensar na perfeição de um design system. Naquele momento, naquela semana, foi construído algo imenso, um design system robusto, que transbordava da capacidade que tínhamos até então.
Aquela imensidão de projeto nunca daria vazão e a Engenharia, que usaria o DS conosco, nunca conseguiria utilizá-la. Esquecemos que, para construir algo em tamanha imensidão, deveríamos também ter a parte dos engenheiros. E, não, nada deles estava pronto. Faltou sinergia entre Design e Engenharia na visão de nosso imenso projeto.
E isso ficou escancarado não só para a guilda de designers, mas para os stakeholders também. Acabamos sendo questionados por não termos trazido uma solução real após a imersão. O problema resolvido era apenas dos designers e, para ser resolvido globalmente, deveríamos fazê-lo aos poucos, como um time, e não construir um verdadeiro monstro de laboratório.
Um ovo, um lagarto e um Zilla
Ao lançarmos o MVP, lançamos também o nosso how-to, ou seja, como deveríamos ter feito o processo. A robustez do nosso design system estava de acordo com o nome que escolhemos a ele. Se tivéssemos começado do início, aos poucos, não teríamos enfrentado tantos problemas na execução. Ao nosso favor estava o ambiente de iteração constante que a empresa respira.
O Zilla, nosso pequeno grande monstro, não foi pensado como um produto. Caso contrário, deveríamos ter cuidado do ovo, criado o lagarto para que, maduro, pudesse enfim ser lançado como o verdadeiro Zilla.
Assim, mesmo que a evolução do Zilla não tenha sido feita da maneira ideal desde o início, pelo menos nosso time evoluiu organicamente para darmos mais um passo na construção do nosso design system.
Processos, alinhamentos e documentação: esses seriam nossos alicerces para a próxima fase, que contarei mais para frente. Até porque um design system, assim como qualquer bom produto, não tem fim.
Quer saber mais sobre a história e aprendizados Zilla? Acompanhe os próximos capítulos, digo, artigos.
Você também pode ler mais sobre ele, aqui:
- Design system: conectando desenvolvedores e designers, por Ney Pimenta.
- Design ágil na prática: adaptando UX ao seu meio e cultura, por Álvaro Rosa.
