Como um audit heurístico transformou "o desktop encolhido" em um roadmap de mobile priorizado por impacto × esforço — com cada problema medido e uma proposta correspondente.
A Waypoint Telemetry é uma plataforma de telemetria de campo: câmeras instaladas em trilhas e sites registram passagens, geram imagens e alimentam análises de uso. O produto nasceu para desktop e, no celular, entregava a mesma interface em escala reduzida — os mesmos componentes, as mesmas colunas, o mesmo cabeçalho, só que espremidos.
Fui chamada para dizer o que estava errado na versão mobile e o que fazer a respeito. A frase que abre o audit resume o diagnóstico inteiro:
"O produto precisa de uma camada mobile, não de um desktop menor."
Conduzi um audit heurístico percorrendo o produto nos três breakpoints que ele já declarava — 1440, 768 e 390px — e documentando cada quebra com a medida real que a causou: a largura em que a coluna trava, a altura que o cabeçalho consome, o ponto exato onde o texto é cortado. Medida em vez de adjetivo: "a coluna da lista fica com ~170px" em vez de "a lista fica apertada".
Análise da experiência e avaliação heurística de cada tela nos três breakpoints, com evidência visual e medida para cada problema apontado — e uma proposta correspondente, na mesma página do deck.
Pesquisa com usuários. O audit é heurístico e o deck diz isso ao cliente com todas as letras: onde a evidência não bastava para decidir, a recomendação virou pergunta em vez de afirmação.
Essa honestidade sobre o limite do método virou, inclusive, o slide de fecho: "o que o usuário de mobile vem fazer aqui?". Se a resposta for conferir câmeras e capturas recentes em campo, o mobile deveria liderar com status de câmera e as imagens mais recentes, e tratar análise profunda como tarefa de desktop — em vez de reproduzir todas as telas de desktop em tamanho menor. Essa é uma decisão de produto, e ela pertence ao cliente; meu papel foi colocá-la na mesa com a evidência do lado.
Os componentes não foram reestruturados para telas menores — foram apenas reduzidos. Em Cameras, o split lista + mapa é mantido: a coluna da lista trava em ~170px, o que corta o placeholder do campo de busca no meio da palavra e quebra o contador em três linhas. Em Analytics, três colunas são preservadas: cada card fica com ~100px e ainda carrega um donut, um número, cinco chips de legenda e um parágrafo — títulos quebram uma palavra por linha. Documentos e glossário continuam tabelas, com a última coluna cortada na borda da viewport.
Proposta: empilhar abaixo de 768px. Cameras vira busca seguida de alternância Lista / Mapa. Analytics vai para um card por linha com gráfico de 240px. Tabelas viram cards: nome primeiro, metadados na segunda linha, ações em um menu.
O usuário rola antes de ver aquilo que veio buscar, em todas as abas. Em Images, cinco filtros sempre expandidos empurram a grade de fotos — a razão de existir da tela — inteiramente para baixo da dobra. Em Analytics, um gráfico vazio ocupa cerca de 400px de espaço em branco ao redor da mensagem "No recent data for this filter".
Proposta: colapsar o cabeçalho do projeto na rolagem para nome e chip de status, com datas e contagens atrás de um "Details". Filtros vão para um bottom sheet atrás de um botão com badge de contagem. Gráfico vazio vira um aviso compacto que já oferece a próxima ação.
Três nomes descrevem a mesma coisa: a sidebar diz "My Projects", o card diz "Open Dashboard", o cabeçalho diz "Dashboard". Em 768px a sidebar continua fixa, consumindo ~180px e deixando o conteúdo em uma coluna mais estreita que a de um celular. Navegação, documentação, conta e logout existem apenas dentro do drawer colapsado.
Proposta: mostrar a localização real no cabeçalho — Projects › Home Testing › Analytics, truncando o meio; sidebar vira rail de ícones abaixo de 1024px e drawer abaixo de 768px; e um nome por conceito, igual em sidebar, card e cabeçalho.
Três interações primárias assumem um cursor. No celular elas não ficam mais lentas — ficam impossíveis. A proposta dá a cada arrastar um equivalente em lista, transforma a linha da legenda no alvo de toque quando a fatia do gráfico é pequena demais para o dedo, adota verbos neutros de dispositivo e exige dois dedos (ou tocar para ativar) nos gestos de mapa, para não competir com a rolagem da página.
Cada proposta abaixo virou tela. Arraste a cortina para comparar: à esquerda o produto como estava, à direita o redesenho. São recortes da primeira dobra em 390px de largura — exatamente a faixa onde os problemas aparecem.
antes
depois
Antes, lista e mapa dividiam a largura: a coluna da lista ficava com ~170px, o placeholder "Search camera" era cortado no meio e o contador quebrava em três linhas. Depois, uma coluna só: contador em uma linha, busca com largura inteira, e um breadcrumb dizendo onde você está — o mapa passa a ser uma alternância, não um concorrente.
antes
depois
Antes, o cabeçalho do projeto — nome, subtítulo, datas de início e fim, contagem de sites e de câmeras — consumia a tela antes de qualquer conteúdo. Depois, o mesmo cabeçalho colapsa em nome e status, o resto vai para um "Details", e o mapa do projeto aparece ainda na primeira dobra.
antes
depois
Antes, três cards de ~100px dividiam a largura, cada um com donut, número, cinco chips de legenda e um parágrafo: "TRAIL USER MIX" quebrava em três linhas e "Click a slice to view evidence" em cinco. Depois, um card por linha: a distribuição vira lista tocável com percentual por categoria — a linha é o alvo de toque, já que a fatia do donut é pequena demais para o dedo — e o histograma ganha a largura inteira.
antes
depois
Antes, a barra de abas era cortada na borda da viewport e os contadores quebravam em 3 + 1. Depois, o cabeçalho do projeto vira uma linha — nome, chip de status e um chevron para expandir —, a barra de abas rola horizontalmente com a ativa sublinhada, e os contadores ficam em uma grade 2 × 2 que cabe na largura do celular.
Arraste a cortina, ou use as setas do teclado com a alça focada
Um audit que entrega trinta problemas soltos não é executável. As correções foram agrupadas em quatro fases, na ordem em que compensa atacá-las — cada uma entrega valor sozinha, e nenhuma depende da seguinte para fazer sentido.
| Fase | O que resolve |
|---|---|
| 1. Consertar as telas quebradas | Eliminar o overflow horizontal: barra de abas rolável, intervalo de datas empilhado, containers de tabela. Uma passada de layout, sem padrão novo — empilhar Cameras, deixar Analytics em coluna única e converter as duas tabelas em cards de mobile. |
| 2. Recuperar a primeira dobra | Cabeçalho de projeto que colapsa, filtros em bottom sheet e gráficos vazios reduzidos a um aviso compacto. |
| 3. Deixar claro e navegável | Separar ações destrutivas, corrigir o breadcrumb, revisar o drawer de mobile e tornar a atribuição de câmera possível com o toque. |
| 4. Polir a linguagem | Verbos neutros de dispositivo, nomenclatura consistente, pluralização e estados vazios que oferecem um próximo passo. |
Conduzi o audit sozinha: análise da experiência, levantamento das evidências, redação das propostas, priorização e o deck apresentado ao cliente. Também desenhei as nove telas da proposta mobile que aparecem aqui — elas existem para tornar a recomendação discutível: é mais fácil concordar ou discordar de uma tela do que de um parágrafo.
A implementação é do time de desenvolvimento, e o audit foi escrito para ser executável por eles: cada finding carrega a medida que o causou, a proposta correspondente e a fase em que entra. Nada de "melhorar a usabilidade do mobile" — e sim "empilhar abaixo de 768px, gráfico de 240px, um card por linha".
| Categoria | Situação |
|---|---|
| Entrega | Audit de 9 páginas com 3 findings estruturais, 1 nota sobre interação e um roadmap de 4 fases — mais 9 telas mobile redesenhadas. |
| Status | Apresentado ao cliente, em aprovação. A implementação ainda não começou. |
| Resultados | Ainda não há números: as métricas desta página são de escopo, não de impacto. Quando o redesenho for para produção, esta seção ganha a parte que falta. |
"Se o que o usuário vem fazer no celular é conferir câmeras e capturas recentes em campo, o mobile deveria começar por isso — e não reproduzir todas as telas de desktop em tamanho menor."