Maida Design Language System
Um Design System com vasta documentação para aplicações móveis e web, criado como uma solução white-label, capaz de se adaptar a diferentes identidades de marca e produtos, mantendo a limpeza e clareza, mesmo com alta densidade de informação.
Empresa Maida Health
Data do Projeto Junho/2019 - Abril/2020
Função Coordenador de UX, Designer UI/UX em uma equipe de 4 designers
Problema
Em uma healthtech em expansão que introduziu design tardiamente, produtos consolidados precisavam de consistência na experiência, interfaces e identidade corporativa, enquanto suprem clientes B2B que exigiam soluções white-label que atendessem usuários finais diversos.
Solução
Para unificar a experiência em todos os produtos, propusemos a criação de um Design System proprietário, para orientar projetos futuros e permitir a reestruturação dos sistemas existentes.
Estudos extensivos e busca de referências foram realizados para entender os conceitos por trás de um Design System e definir o estado-da-arte no assunto, juntamente com técnicas como Design Sprints e Design Thinking para obter uma melhor compreensão dos problemas que tínhamos que resolver com esta solução; tudo isso enquanto mediávamos o suporte ao projeto com a gerência.
Definindo o problema
Como resultado de nossa pesquisa, chegamos as dores que nosso Design System tinha que resolver:
Ecossistema acessível- Como um "produto, servindo produtos", seu uso principal é ser consumido por outros (designers, devs, marketing) e ser uma fonte de verdade facilmente acessível que qualquer pessoa pudesse consumi-lo, permitindo a criação de produtos que compartilhem a mesma experiência e identidade visual.
Promover comunicação - O sistema eve resolver problemas de comunicação, fornecendo uma linguagem compartilhada entre desenvolvedores e designers e permitindo que eles trabalhem juntos.
Todos estão convidados - Há uma diversidade de personas envolvidas. Embora seja um desafio, também é uma funcionalidade - se alguma solução for muito complexa, torne-a simples, para poder servir para todos.
White-label - Personalização é esperada para acomodar a marca dos nossos clientes.
Na imagem: Uma das Design Sprints que realizamos para definir melhor nossos desafios.
Entregáveis
Visamos uma estrutura modular e reutilizável tanto para designers quanto para desenvolvedores, e essa estrutura deve ser facilmente acessível e consumível. Assim, nossos artefatos de entrega seriam os seguintes:
-
Biblioteca de padrões e componentes;
-
Frameworks Front-End reutilizáveis;
-
Documentação de design e Front-End completa e clara, para todos os ambientes (Web e Mobile).
Algumas amostras dos entregáveis de design são mostrados abaixo:
Ferramentas
-
No início do projeto, a equipe de design mudou para o Figma (do Sketch), pela facilidade na colaboração e ferramentas mais robustas.
-
Os desenvolvedores do projeto decidiram usar Angular para web e o Flutter para mobile, considerando soluções multiplataforma.
-
Os componentes e a documentação de desenvolvimento seriam consolidados no Storybook.
MVP
Como o projeto evoluiu a partir de material criado anteriormente, a definição de nosso Produto Mínimo Viável veio de uma interseção do que era o absolutamente necessário, o que já havia sido feito e o esforço estimado para desenvolver os elementos personalizados necessários.
Documentação
Se queremos que pessoas reais usem isso de verdade, temos que criar uma estrutura de documentação tão fácil de ler quanto possível. Dividimos a documentação em 3 seções principais, da seguinte forma:
Princípios
Esta seção estabelece os propósitos, valores e objetivos do Design System, descrevendo sua filosofia, personalidade e como ele se comunica com o usuário.
Nossos princípios são:
Incluir a todos - Considerar todas as pessoas, independentemente do seu nível de experiência.
Planejar. Criar. Iterar- Criar com base em teoria e intenção. Evoluir quando necessário.
Informação clara e acessível - A informação é a parte mais importante.
Construção permanente - Se tudo pode mudar, até este manifesto.
Guidelines
Esta seção trata das regras fundamentais que usaremos para criar produtos em nosso Design System - padrões para criação, melhores práticas e definição de nossa identidade.
-
Documentação - Como escrever páginas no sistema;
-
Terminologia - Jargões comuns usados em toda a documentação;
-
Nomenclatura - Convenções de nomenclatura e padrões compartilhados entre design e desenvolvimento;
-
Sistemas de medidas - Esclarecimentos sobre o uso de Pixels e REMs;
-
Grades, Hierarquia e Espaçamento - Como construir e posicionar elementos espacialmente;
-
Tipografia- Família de fontes e variações;
-
Cor - Nosso sistema de duas cores, variações de cor e usos de cor;
-
Padrões - Formas e efeitos aplicados comumente em componentes.
Pressione qualquer uma das imagens para ver mais detalhes.
Elementos, componentes, organismos e modelos
A última seção é dedicada às partes tangíveis do nosso sistema de design, descrevendo como construí-las, quais padrões usar e guias sobre como usá-los.
Embora tenhamos unido essas partes para facilitar o uso, internamente as diferenciamos da seguinte forma:
Elementos - Terminologia genérica para objetos tangíveis;
Componentes - Blocos básicos de construção do nosso sistema;
Organismos - Elementos complexos, geralmente contendo um grupo de outros componentes;
Templates - Mockups para páginas frequentemente usadas.
Embora essa classificação seja diferente da descrita no Atomic Design de Brad Frost, concordamos que seguir esse formato é mais fácil de entender, tornando nosso trabalho mais fácil.
A documentação de um elemento geralmente incluirá:
Definição - Uma rápida explicação da intenção do elemento
Nomenclatura - Identificação única conforme o padrão de nomenclatura
Anatomia - Construção e comportamento responsivo
Opções - Variantes específicas de contexto
Interação - Como o elemento muda quando manipulado
Guia de uso e melhores práticas - Como aplicar melhor o elemento
Checklist - Testes de garantia de qualidade
Versão - Alterações no elemento
Clique em qualquer uma das imagens para ver mais detalhes.
Fluxo de trabalho
-
Todo o trabalho começa na equipe de design.
-
Defina as tarefas a serem realizadas e atribua à equipe.
-
Antes de começar, faça pesquisa e benchmarking.
-
Primeiro protótipo e discussões com a equipe. Itere quando necessário.
-
Documentação, seguindo nossas diretrizes de documentos.
-
Entrega para o desenvolvimento Front-end para codificação, implementação e documentação. Discuta com a equipe de design para resolver quaisquer problemas e iterar quando necessário.
Resultados
Unidade e flexibilidade
Novos produtos estavam adotando nosso sistema de design e se adaptando quando a identidade do cliente exigia. Alcançamos nosso objetivo de construção modular, uma vez que nosso sistema fornece componentes feitos de padrões definidos por nossas diretrizes fundamentais.
Velocidade
Na terceira sprint de desenvolvimento, uma tela de login pôde ser codificada em menos de 30 minutos, em comparação com uma estimativa de 12 horas sem nosso sistema, segundo o desenvolvedor. Além disso, um projeto de telemedicina complexo, iniciado do zero, alcançou o mercado em apenas 5 meses, com a ajuda de nosso Design System.
Custos e receita
Desenvolvimento mais rápido significa desenvolvimento mais barato, pois significa recursos economizados ou gastos eficientes. Além disso, chegar ao mercado mais cedo significa ganhar dinheiro mais cedo, como mostrado pelo nosso exemplo de telemedicina.
Desafios e próximos passos
Vida na via expressa - Como uma equipe pequena, frequentemente estávamos criando e aplicando o sistema em paralelo. A nosso favor, isso significava que podíamos testar e iterar imediatamente, mas com tempo limitado para avaliar um problema e validar a solução.
Manutenção - Era difícil acompanhar mudanças constantes e decidir o que deveria ou não ser adicionado à documentação. Para mitigar isso, foram criadas regras de governança para definir como o sistema seria atualizado.
Falta de testes - Devido à nossa equipe pequena, quando chegávamos a um impasse, tínhamos uma discussão em equipe e tentávamos escolher a melhor opção, publicá-la e deixar o teste acontecer naturalmente, já que não tínhamos tempo para testar.
Design Tokens - A maioria das características no código é acessada por meio de variáveis e tokens no Storybook, mas a implementação ainda depende de um desenvolvedor. Design Tokens mantidos pela equipe de design não foram implementados.
Evangelização - Conseguir o apoio de todos certamente é um dos maiores desafios ao propor um Design System. A adesão ao projeto foi mantida pelos resultados mostrados ao usá-lo.
Supervisão do código e escolha de frameworks - Tivemos problemas para supervisionar o código e garantir sua modularidade. Isso foi resolvido quando conseguimos nomear um desenvolvedor Front-End dedicado para o produto. E, em retrospectiva, reavaliaríamos a escolha do framework, considerando que entendemos melhor os desafios agora e como é difícil encontrar desenvolvedores habilidosos em Angular e Flutter.