Case 04 · UX de produto · Ready for Audit
Tornando visível um filtro escondido numa tabela maior que qualquer tela
Saber quais lojas estão prontas para a auditoria, semana a semana, quando o filtro de período escondia os checklists que ainda esperavam aprovação.
Lado B
Nem só de grandes épicos vive o designer. Este é um case pequeno: poucos dias numa tela que já existia, o tipo de ajuste pontual que aparece no dia a dia e faz parte do trabalho tanto quanto os épicos. Pequeno, sim. Simples, nem tanto.
Negócio trocado · NDA
O produto real está sob NDA (acordo de confidencialidade), então este portfólio leva o trabalho para outro negócio: uma rede de supermercados fictícia faz o papel do cliente e do produto reais. As telas são adaptações ilustrativas super simplificadas, e o negócio, as regras e os dados são inventados. O problema de design e o raciocínio por trás de cada decisão são meus.
O produto fictício
O Shelf, nome fictício que uso aqui, é o back-office da Almare Markets, uma rede de supermercados inventada. É uma plataforma web interna, grande e feita para desktop, onde times das lojas, das regiões e da sede cuidam de lojas, orçamentos de campanha, pessoas e checklists semanais. São tabelas largas, filtros, drawers e muitos user roles, cada um vendo a sua parte dos dados. O produto real é de outro negócio, e a rede faz o papel dele para manter o cliente confidencial. Entrei no projeto real em maio de 2026, quando ele já tinha anos de uso.
Este case fala de uma das telas de revisão, onde os QA leads conferem, semana a semana, quais lojas estão prontas para a auditoria de segurança alimentar.
Problema
Uma lista larga responde a uma única pergunta: esta loja está pronta para a auditoria e, se não estiver, quais checklists semanais ainda esperam aprovação?
Cada linha é uma loja, cada coluna uma semana de checklists de segurança alimentar. A lista só mostrava o período de auditoria escolhido no filtro, uma janela limitada, e tudo fora dele simplesmente sumia. Uma loja podia parecer em dia com muitas semanas de checklists ainda esperando aprovação, e o botão de lembrete prometia uma semana pendente quando eram muitas mais. O período não aparecia em lugar nenhum da página. E o Status só contava as semanas da tela, então mudava com o filtro sem avisar.
Restrições
- A tabela real é muito mais larga que a tela. É uma aplicação desktop, e mesmo num monitor grande as pessoas rolam para o lado e perdem a linha que estavam lendo.
- O limite no período continua: é ele que mantém a lista rápida.
- Vários user roles veem linhas diferentes e podem fazer coisas diferentes, de corrigir uma semana a só consultar.
- A tela já existe no produto, então cada mudança tinha que caber na tabela, nos filtros e nos tooltips do próprio produto.
Decisões
-
01
Mostrar o que o filtro esconde
Uma coluna Pending conta todas as semanas ainda aguardando aprovação, seja qual for o filtro, e abre essas semanas agrupadas por ano. Uma contagem vazia mostra “-”, não “0”. O lembrete usa a mesma contagem completa, então nunca promete menos do que falta.
O backlog inteiro, a um clique: semanas de dois anos que o filtro de período escondia. -
02
Dizer quais semanas você está vendo
Uma segunda linha de cabeçalho nomeia o período escolhido no filtro, sobre o Status e todas as colunas de semana. A borda esquerda dela é a linha entre as colunas que o filtro muda e as que ele não muda.
A faixa do período começa onde o filtro passa a importar; a coluna da loja fica fixa enquanto as semanas rolam. -
03
Fazer o filtro padrão funcionar de verdade
O período já vem selecionado e o filtro aparece como ativo desde o primeiro carregamento. Limpar volta a esse padrão em vez de esvaziar o campo, e Aplicar recorta as semanas e recalcula o Status, então restringir o período pode deixar uma loja como Ready for Audit.
O painel de filtro, com o período primeiro: o único campo sempre ativo. -
04
Não se perder numa tabela larga
O nome da loja fica fixo à esquerda e as ações à direita. Primeiro tirei o destaque da linha, porque o azul significava “clicável” e as linhas não são; depois o trouxe de volta como um tom neutro. Acompanhar uma loja por muitas colunas de semana precisa dele. Registrei isso como uma reversão, em vez de mudar em silêncio.
-
05
Uma regra de Status que dá para ler
A primeira regra tinha uma condição a mais do que as pessoas conseguiam guardar de cabeça. Trabalhando com os devs, tirei essa condição: era mais difícil de explicar do que valia. O tooltip agora diz a regra numa linha, com o texto que os devs escolheram entre as minhas duas opções.
-
06
Alertas que dá para ver
A marca de semana pendente usava o amarelo do app, claro demais no branco e pior nas linhas coloridas. Troquei pelo amarelo escuro do design system, que passa de 3:1 em todos os estados da linha; um laranja mais vivo parecia mais próximo da marca, mas falhava nas linhas com hover.
Cor da marca Numa linha branca Pior estado da linha Ícones pedem 3:1 O amarelo do app 1,82:1 1,56:1 Falha Um laranja mais vivo 3,15:1 2,71:1 Falha O amarelo escuro do design system 3,52:1 3,03:1 Passa Contraste da marca de semana pendente (WCAG 2.2, contraste de elementos não textuais) nos quatro estados da linha: branca, colorida e as duas com hover.
Como foi feito
Esta tela veio antes dos documentos que uso hoje, então mostra uma forma anterior do mesmo processo, em menos de uma semana.
- Dia 1Trace da página realO meu page tracer me deu um primeiro rascunho da tela de produção como protótipo, com cópias dos componentes do produto. Com alguns ajustes pontuais, cada melhoria partiu da coisa real.
- Dias 2–4Todas as melhorias, uma specNumerei cada uma, anotei o porquê e coloquei no protótipo no mesmo dia.
- Dias 3–4Regras fechadas com os devsEles confirmaram a regra de Status. Depois a simplificamos juntos, e eles escolheram o texto do tooltip.
- Dia 3Documentos de sign-off e hand-offWhat’s New para o sign-off dos stakeholders e Dev and QA para o time de desenvolvimento, com requisitos numerados, user stories e regras de negócio.
- DepoisPerguntas abertas na telaCada uma presa ao controle a que se refere, escrita para ser lida em voz alta numa revisão.
O que eu faria diferente
A regra de Status mudou numa conversa com os devs, e o protótipo acompanhou. Dois documentos não. Eles ainda descrevem a primeira regra, porque nada ligava uma decisão a todos os lugares em que ela vivia. O meu assistente de acompanhamento de features fecha essa lacuna. Ele veio semanas depois, e desde então toda decisão chega à matriz, aos logs e aos dois documentos de uma vez.