Ir para o conteúdo
Airtm/2026/Design system

Uma estrutura para dois produtos

A Airtm tem dois produtos na mesma plataforma web: uma carteira para pessoas e um app de pagamentos para empresas, construídos por times diferentes em momentos diferentes.

Design systemArquitetura da informaçãoWebAcessibilidade
Papel
Senior Product Designer — direção, cinco rodadas de exploração e os componentes, construídos em código.
Parceiros
Time de design, Produto, Engenharia, Marca.
Norte
Toda tela deveria responder onde estou, o que posso fazer e o que eu tenho — do mesmo jeito, nos dois produtos.

Em 30 segundos

01 · Problema
Dois produtos dividiam uma plataforma, mas navegavam de formas diferentes. Em 1366×768, o menu do protótipo deixava só quatro de doze destinos acessíveis.
02 · Decisão
Separar identidade global, contexto da página e ações sobre listas em três camadas, usando breadcrumbs apenas onde existe profundidade real.
03 · Resultado
Direção fechada após cinco explorações; componentes React funcionais e registros de decisão foram entregues à engenharia. Este case não afirma adoção em produção.

O problema

O design system publicado era mobile-first, então na web cada tela resolvia a orientação por conta própria: títulos de página diferentes, breadcrumbs usados como navegação padrão, um menu lateral de nove itens soltos misturando ações e destinos, e os dois produtos se afastando sem nada que os mantivesse juntos.

Barra globalquem sou eu, o que está me esperando01Cabeçalho da páginaonde estou, o que posso fazer aqui02Barra de ferramentaso que estou fazendo com esta lista03NÃO É PADRÃOBreadcrumbs só em árvore profunda, como Configurações
Três camadas, cada uma respondendo a exatamente uma pergunta, e o breadcrumb rebaixado a árvores profundas, porque este produto é feito de destinos rasos e fluxos lineares.
01

A restrição

Dois produtos, uma plataforma, e nenhum dos dois podia parar de lançar enquanto isso acontecia. O sistema tinha de servir a uma carteira para pessoas e a uma ferramenta de pagamentos para empresas sem que um parecesse visita no outro, e tinha de poder ser adotado por engenheiros que não iam ler um documento de especificação para isso.

02

O que tentei primeiro

Breadcrumbs como forma padrão de dizer onde você está, por serem explícitos e baratos. Também são errados para este produto, que é feito de destinos rasos e fluxos lineares, e não de uma árvore profunda, então o breadcrumb quase sempre tinha um nível só — um controle que ocupa espaço para repetir o título da página.

03

A virada

Três camadas, cada uma respondendo a exatamente uma pergunta, e nada respondendo a duas. Uma barra global para quem você é e o que está esperando. Um cabeçalho de página para onde você está e o que pode fazer aqui. Uma barra de ferramentas para o que você está fazendo com a lista à sua frente. Breadcrumbs viraram opcionais para árvores realmente profundas, e os fluxos lineares ganharam um stepper.

Medido no hardware que as pessoas têm

Em 1366×768, o menu do protótipo deixava apenas quatro dos doze destinos acessíveis, com a ação principal abaixo da dobra. A revisão considera altura e largura da tela.

Entregue como componentes, não como especificação

Entreguei ao time componentes React, estados e registros de decisão sobre saldo, superfícies interativas e navegação. O handoff está documentado; este case não afirma adoção em produção.

04

Do que eu abri mão

Da liberdade de cada produto. O app de empresas perdeu a possibilidade de inventar a própria moldura para uma tela que se beneficiaria disso, e alguns layouts ficaram com um pouco menos de espaço. Um só sistema significa que alguém sempre abre mão de algo; deixei a troca explícita em vez de deixar cada time descobri-la depois.

05

Resultado

Direção fechada depois de cinco rodadas, um protótipo funcional publicado para o time e os componentes entregues à engenharia — com as regras escritas para que a próxima pessoa não precise rediscuti-las.