Mobile app • 2020

Stormia Design System

O Design System do Sistema Unimed. Criado principalmente para dar escalabilidade ao Super App, um aplicativo mobile com tecnologia white-label, personalizável via CMS e operado pelas mais de 300 unidades cooperativas espalhadas em todo o Brasil

Atuei como product designer contratado da consultoria de design de serviço Livework Studio e dentro da célula de inovação da Seguros Unimed, chamada Stormia. Participei desde o começo, encabeçando a iniciativa ao lado da minha parceira de trabalho, fazendo o Discovery dos desafios, pleiteando uma priorização, componentizando e documentando os elementos no Figma até as fases de design ops.

Diferente de muitos outros produtos digitais em que o Design System nasce quando já há um estrutura legada, no Super App o time teve desde o início a preocupação de montar processos e um sistema de desenvolvimento de interfaces que pudesse ser sustentável a longo prazo.

Tínhamos um escopo grande para o MVP do Super App e outro possivelmente maior ainda para sua evolução. Com um pouco menos de um ano para que pudéssemos passar por essas validações da solução e depois lançarmos no mercado, corríamos contra o tempo.

Muitas pessoas designers e desenvolvedoras seriam inseridas no time de produto. Assim, era de suma importância que pudéssemos construir uma fundação de design de produto com alicerces sólidos para, principalmente, dar aos novos membros do time capacidade de construir e evoluir features de forma consistente e com agilidade.

E um último ponto importante é que a tecnologia do aplicativo seria white-label, fornecida pela Seguros Unimed para as demais unidades cooperativas do Sistema Unimed. Essa unidade cooperativa (chamada de Singular) teria autonomia para personalizar seus dados, partes da aparência do aplicativo e configurar algumas funcionalidades com base em sua estrutura e no que ela oferece aos seus clientes.

Pegamos algumas horas da semana para ler alguns livros e artigos de alguns grandes nomes que discutiam o tema, como o Medium do Nathan Curtis, o livro Atomic Design do Brad Frost, o livro Design Systems da Alla Khalmotova e muitos outros.

Animados com o que estávamos aprendendo e sobre como poderíamos encaixar esses conceitos e inspirações em nosso dia a dia, começamos então com o que era a recomendação de quase todas as leituras: entendendo o nosso contexto.

Antes de criar qualquer coisa, analisamos o que já havia sido criado nesse enorme ecossistema de produtos digitais da Seguros Unimed e das várias Singulares da Unimed do Brasil. Cada uma tinha seu próprio aplicativo e não havia nenhum tipo de padronização entre eles.

Os trabalhos de inventário nos ajudou a diagnosticar quais eram as dores que haviam relacionados aos padrões de UI: inconsistências, usabilidade, acessibilidade, estética e branding.

Apresentamos esse diagnóstico e criamos rodas de conversa sobre o conceito Design System para os membros do time. Esse esforço de educação sobre qual era o desafio que estavamos enfrentando e ao mesmo tempo convidar mais pessoas para abraçar esse propósito foi constante. Entendíamos que era importante que as lideranças, designers e desenvolvedores estivessem dedicados a trabalhar juntos para a construção desse Design System.

Como dito anteriormente, esse Design System nasce para inicialmente atender a stack de aplicativo mobile. Nossos desenvolvedores optaram por utilizar a Biblioteca Ionic e pelo framework Angular para agilizar a produção e documentação dos componentes em tecnologia.

O Angular era familiar ao time e o Ionic possuía um grande suporte a esse framework; sua biblioteca robusta e SDKs nativas atreladas a documentações foram diferenciais para essa decisão.

O Design System tinha que considerar que apesar de focar inicialmente em um único produto, ele seria multi-temas por atender um produto white-label. Isso significa que precisariamos criar uma lógica para 2 temas de interface: um para o brand da Seguros Unimed (azul) e outro para as Unimeds Singulares (verde).

Optamos por diferenciar um tema do outro quase que unicamente pelas variáveis de cores, que teriam valores específicos para cada tema, mas chaves (tokens) iguais. Isso porque:

1. Apesar de serem marcas diferentes, ambas partem de uma mesma unidade visual. Criar uma similaridade seria um fator positivo para a experiência digital do Sistema Unimed de modo geral.

2. Seria mais viável tecnologicamente não criar tantas variações de tokens para os temas, isso porque o produto ainda estava no início e o escopo do Design System era dividido com o de produto.

Todo nosso styleguide partiu dessa lógica de temas por tokenização de elementos. Ou seja, variáveis de estilo construídas de forma semântica que atendem a qualquer tipo de tecnologia.

Isso é importante pois por mais que o Design System nasça focado em atender ao aplicativo, existiam as chances de reaproveitarmos essas decisões e boas práticas e aplicá-las em outros produtos legados, como: o site da Seguros Unimed, o gerenciador de conteúdo (CMS), blogs e outros produtos.

Com o styleguide definido entre os membros do time, trabalhamos em alguns concepts de interfaces e fomos gradualmente construindo nossa biblioteca de design.

Conforme as primeiras interfaces eram criadas, os componentes já entravam em um esteira similar a um kanban de aprovação dos componentes. Reservamos um tempo em nossa agenda para realizar uma análise de consistência, usabilidade e acessibilidade antes que esses componente entrassem em produção.

Toda nossa biblioteca foi construída utilizando o tema da Singulares (verde), que era onde os times trabalhavam na maior parte do tempo. Entretanto, com um plugin no Figma chamado Themer, consegui configurar nossos design tokens para que sempre que desejassemos, pudessemos converter nossas produções nas cores respectivas do tema da Seguros Unimed (azul), clicando em apenas um botão.

Como nossos desenvolvedores faziam parte de uma empresa a parte, tivemos dificuldade de tê-los presentes a todo momento. E talvez esse seja o principal aprendizado que tivemos. Apesar disso, elaboramos juntos, Design e Tecnologia, todo nosso styleguide inicial, nossa composição de tokens e handoffs que garantiam um espelhamento entre as duas frentes.

Nossos processos passaram por diversas atualizações ao longo de minha trajetória no time. Mas o que nunca sofreu grandes alterações, foi nosso esforço de dedicar algumas horas da nossa semana pra criar um encontro pra debater sobre design em escala, princípios de design, auditar nossas interfaces, apresentar componentes novos, priorizar componentizações e manter vivo um roadmap para essa iniciativa.