Projetando um design system — People Commerce
Background | No início de 2019 eu viria a integrar a equipe da Onawa como Product Designer, com o objetivo de ajudar a construir uma visão de Produto na empresa. Na ocasião, já prestávamos consultoria técnica e estratégica para a Wine Eventos (frente de negócio do clube Wine) através de um modelo de venda por relacionamento.
Research | Antes (e durante) a construção do produto, todo o tipo de insumo que pudesse ser coletado naquele momento seria documentado, juntamente com a intenção de que o mesmo modelo pudesse atender à mais empresas como uma plataforma white-label.
As entrevistas e todo o processo de imersão foram essenciais para o que viria adiante. O desafio era entender o momento da plataforma pré-existente e suas principais dores, tanto para os usuários, quanto para o desenvolvimento e negócios, tocando em pontos como performance, experiência e escalabilidade. Falo com mais detalhes sobre todo o processo de Discovery neste artigo.
O produto | O produto consistia em entregar à marca, além de consultoria para ativação do seu próprio canal de venda por relacionamento, uma multi-plataforma contendo 3 diferentes aplicações:
- Office: um app mobile nas mãos dos revendedores, onde são feitas vendas e acompanhamento de pedidos e clientes.
- Store: um e-commerce para cada revendedor, onde clientes podem comprar produtos, comissionando o responsável pela loja.
- Dashboard: o painel administrativo da marca para gerenciamento do seu próprio canal de venda por relacionamento.
Confira mais sobre o projeto acessando-o no meu portfolio visual.
Arquitetura da informação | Como resultado do trabalho de imersão, foi revisada toda a forma como funcionalidades estavam organizadas. Mais que isso, foi preciso entender como diferentes aplicações e usuários se relacionavam. Tudo isso serviria de base também para o projeto do Design System. Acessar FigJam
Interface | Antes porém de se documentar o que viria a ser nossa biblioteca de tokens, assets e componentes, passamos por etapas tais como benchmark e a ideação a partir de wireframes, sempre envolvendo o time responsável e obtendo importantes feedbacks técnicos e relativos à experiência.
Para consolidar a direção que o projeto viria a seguir, interfaces conceituais com seus principais pontos de interação (para cada uma das aplicações) serviram como uma espécie de validação inicial, antes da etapa de detalhamento.
Design System | Conforme avançávamos, ficava evidente a necessidade de se trabalhar um Design System. Diante de aplicações distintas, mas pertencentes a um mesmo ecossistema, era nítida a percepção de que eles precisariam conversar entre si, manter consistência visual, informacional e, principalmente, otimizar processos de design e desenvolvimento, visando a escalabilidade.
Ecossistema | Para atender às aplicações, o Design System seria dividido de forma a cobrir uma aplicação Mobile (Office) e duas Web (Store e Dashboard). Para isso, a biblioteca ficou dividida em Core Components – que atenderiam a todas elas, e outras duas ramificações: Mobile e Web. Publiquei o projeto na comunidade do Figma neste link.
- Core Components: Inicialmente, com os projetos bem definidos em termos de layout, já foi possível determinar os design tokens contendo paleta de cores e tipografia e os assets, como ícones e logos.
- Mobile Components e Web Components: Considerando as diferentes aplicações, estas duas bibliotecas contém cada uma componentes específicos. Todo o processo de componentização correu muito em paralelo com o trabalho de UI, ora priorizados em conjunto com a equipe, ora motivados pela necessidade de organização do projeto.
A verdade é que são muitas e muitas horas trabalhando não só em cima de telas, mas de todo um sistema, feito com toda a dedicação de alguém que imergiu no projeto mas que também sempre buscou olhá-lo de cima, com uma visão macro.
Amadurecimento | Em meados de 2019, a principal ferramenta utilizada para criação dos layouts era o Sketch, realizando o hand-off pelo Zeplin. Com a excelente evolução do Figma, todo o projeto foi importado, expandindo as possibilidades de hand-off e com novas ferramentas como auto-layout, variants e libraries conversando entre si.
Aprendizados | A criação de uma UI e seus tokens, assets e componentes feitos do zero trouxe vantagens, como a flexibilidade e alta customização visual, levando o conceito da simplicidade sempre junto consigo ao criar componentes sob demanda. Porém, não ter adotado por exemplo um design system pronto (como muito é mencionado o Material Design) trouxe também desafios como a necessidade de detalhamento de interações e cenários ainda não previstos.
É importante ressaltar ainda que, na realidade, este se trata “apenas” de um projeto de Design System, ou como muitos preferem chamar, Design Kit, biblioteca, enfim. Nomes a parte, são inegáveis os benefícios de se pensar nisso desde o início, como pude descrever aqui. O Design System também deve ser tratado como um produto e como tal é imperfeito e deve estar sempre em evolução.
Levo como aprendizado que a implementação técnica deveria ter sido feita com total integração com o time de Design, documentando e tornando os componentes já codados disponíveis para que todos os vejam, processo que seria o ideal para a manutenção. Por conta até das limitações, essa etapa despertou meu interesse e hoje venho estudando programação Frontend e React e entendendo melhor como funciona a implementação, manutenção e documentação a partir de ferramentas terceiras, como o Storybook.
