Como a construção de um design system mudou a forma de fazermos apostas.

builder
A ilustração é do Nuno Junior

A Wavy, onde trabalho, é a parte do grupo Movile que constrói soluções de comunicação mobile. Ajudamos nossos parceiros de negócios a criarem produtos de comércio móvel e conteúdo, fornecendo serviços através das operadoras de telefonia de toda a América latina.

Aqui, tomar riscos e fazer apostas é parte do nosso DNA: quando vemos uma oportunidade de fazer algo novo que tem valor para o usuário, precisamos apostar! Erramos muito, aprendemos rápido e apostamos de novo, para no fim, termos uma ou duas ideias que deram certo.

Para cada ideia, é preciso fazer pesquisas, protótipos, testes de usabilidade, para então fazer o design do produto, desenvolver o front e o backend, testar novamente e refinar os detalhes.

Em 2017, a Wavy lançou 13 novos produtos de conteúdo, sendo 8 deles em formato de aplicativo mobile (Android e iOS) ou PWA. O tempo de desenvolvimento desses produtos variam de 3 a 7 meses. Exemplo disso é o “Vivo Meditação” — uma aposta da Wavy em parceria com a Vivo, que levou em média 6 meses para ser lançado na loja.

A nossa realidade pedia mais apostas

Depois de tanto tempo sofrendo com esses longos meses de desenvolvimento, precisávamos começar a apostar mais, lançar ainda mais produtos mas sem tanto custo, com mais agilidade, com menos pessoas envolvidas e aprendendo mais rápido. Foi assim que surgiu o Block Builder, o projeto que criou blocos de design, TI, produto e UX para construção de apps.

Montamos um time com dois Devs, uma profissional de produto e eu como designer. Tínhamos uma meta bem agressiva: criar um design system em 100 dias. O prazo foi estabelecido pelos times de design, produto e tecnologia, para que não houvesse desperdício de recursos dos respectivos times. Para validar esse design system, teríamos que criar com ele, um app em 3 semanas (então na prática, tínhamos 100 dias menos 3 semanas = 79 dias).

Marco zero

Captura de Tela 2018-10-10 às 15.02.37.png

Juntamos todos os produtos que já lançamos nos últimos 2 anos, separando-os  por categorias. A categoria mais recorrente era a de conteúdo (apps de notícias, receitas, novidades em assuntos específicos, etc). Ela era também a com mais componentes básicos (que podem estar em qualquer produto de qualquer outra categoria, por exemplo: botões, formulários, fluxos de login, etc.). Definimos que a nossa biblioteca base seria criada com componentes mais comuns dessa vertical.

Nosso roadmap de 100 dias

A minha dica para iniciar qualquer projeto de design system é primeiro fazer um “inventário” de tudo que você tem em seus produtos. Separar todos os componentes por categorias e subcategorias e entender os componentes ou fluxos mais comuns ou mais importantes nos projetos em geral. Reflita se um design system ajudaria de fato a criar uma unidade entre esses componentes, seja visual, de marca, de código, etc. Quando se tem muita coisa parecida sendo feita, e isso leva tempo de desenvolvimento (e dinheiro), talvez seja o momento de criar bloquinhos pré-montados de UI+UX+dev+marca, etc.

 

Um pouco de pesquisa

Começamos uma busca por empresas que já construíram seu design system, conversamos com algumas delas, lemos muitos artigos no Medium de pessoas que participaram do processo de construção de DS mundo a fora.

Como aprendizado dessa parte, adotamos e disseminamos o conceito do Atomic Design. Explicamos a importância de separar os componentes visuais para um projeto de design system, e passamos a chamar esses elementos de átomos, moléculas, organismos, templates e páginas. Assim, fica fácil se comunicar com todos do time (não que tenha sido fácil, mas em determinado momento, falar em moléculas e átomos já era algo natural para todos).

Fizemos um benchmark inicial com os top 10 aplicativos do mercado, considerando os mais baixados do Brasil, Índia e China*. Listamos o que eles oferecem em comum, fazendo um exercício parecido com o do inventário, que citei anteriormente, mas com apps de terceiros. O objetivo de pesquisa era baseado na questão: quais as features mais simples (e essenciais) de um app de conteúdo (notícias)? As respostas foram colocadas em uma planilha e as features existentes em nossos apps também foram mapeadas. Assim, chegamos numa lista de features mínimas e comuns que deveríamos contemplar em nosso projeto.

A minha dica para iniciar qualquer projeto de design system é primeiro fazer um “inventário” de tudo que você tem em seus produtos.


Comece pelo mais simples: monte uma biblioteca

Nos baseamos em nosso app de notícias mais recente e completo para começar a biblioteca de componentes. Nessa fase, não precisei desenhar nada: tudo era reaproveitado do layout do app em questão. Eu ia pegando parte por parte e alimentando a biblioteca, transformando páginas inteiras em partes de templates, organismos, moléculas e por fim, átomos. Criei estilos de texto, estilos de camadas, separei conjuntos de ícones, botões, tags, etc

Ferramentas

Falando um pouco de ferramentas, usamos o Sketch para criar a biblioteca em conjunto com o Abstract para versionar os arquivos. A integração com os devs foi através do Zeplin ❤. No caminho, surgiram diversas opções de ferramentas que testamos, mas seguimos com as mais convencionais. A verdade é que design system é um bicho recente pro mercado, e não tem muitas soluções boas para se usar.

A segunda fase foi mapear os fluxos dos usuários para funções comuns como login, assinatura, cadastro etc. Montamos protótipos desses fluxos e validamos com os Devs, com o time de produto e com possíveis usuários (sim, fomos fazer teste de usabilidade na rua, mas não vou falar sobre eles neste post, pois é um assunto para ser tratado a parte).

Lembra que comentei ali em cima sobre criar bloquinhos pré-montados? Era disso que estava falando: um fluxo de login é padrão em todos os nossos apps, então para que desperdiçar tempo criando um novo sempre que vamos ter login no app? Esse fluxo criado no Block Builder, basta ser inserido em um produto, e eventualmente customizado. A “casca” já está criada, codada, testada e pronta para ser implementada.

Criamos uma documentação com os detalhes de cada componente, e validamos o Block Builder no ciclo de 100 dias, onde as últimas 3 semanas construímos um aplicativo de notícias usando os componentes do DS. Alcançamos a meta que nos propomos com sucesso, mas o trabalho de um design system não acaba nunca.

Em um próximo artigo, vou falar sobre a jornada da documentação de um design system, que é uma tarefa árdua, porém essencial. Também falarei de como testamos o design system com o time e com o produto final.

Compartilhei aqui um pouco da minha jornada nesses 100 dias, e você, tem alguma dica sobre design system? Comenta aí!

 

*Se você está se perguntando porque vimos apps da Índia e China, explico: esses dois países lideram o mercado de tecnologia mundial, então é sempre válido olhar para o que os gigantes estão fazendo!

 

Formada em Desenho Industrial pela Faculdade Paulista de Artes, Patricia é designer na Wavy e já passou por empresas como Dafiti, E/OU-MRM e Apontador. Responsável por desenvolver junto com o time de dev e produto, o design system da Wavy, seu maior sonho é fazer a diferença na vida das pessoas por meio de tecnologia.

Posted by:Pati Panza

Formada em Desenho Industrial pela Faculdade Paulista de Artes, Patricia é designer na Wavy e já passou por empresas como Dafiti, E/OU-MRM e Apontador. Responsável por desenvolver junto com o time de dev e produto, o design system da Wavy, seu maior sonho é fazer a diferença na vida das pessoas por meio de tecnologia.

Deixe seu comentário