Redesign do fluxo de checklist de auditoria para uma rede de varejo

Um mesmo produto servia dois trabalhos opostos: definir o padrão e cumprir o padrão. Separá-los foi o projeto.

Contexto

Um teste prático para uma vaga de Product Designer me deu três telas de um produto real de gestão de redes: a home do módulo, a criação de checklist e a aplicação de checklist. O cenário era o de uma rede de varejo esportivo com dezenas de lojas pelo Brasil, onde o checklist é o instrumento que carrega o padrão de qualidade, é como a matriz define o que é uma loja bem operada e como cada unidade prova que está entregando isso.

Era um redesign de produto existente, com o briefing apontando que a criação tinha passos demais e que a aplicação não orientava bem o usuário. Não havia acesso a usuários reais, dados de uso ou stakeholders para entrevistar.

Trabalhei sozinho, do diagnóstico à alta fidelidade, e levei dois dias para entregar.

O problema

Antes de resolver o que o briefing apontava, precisei entender por que aqueles sintomas existiam. A resposta mudou o projeto inteiro.

Para o usuário. O produto tratava dois usuários muito diferentes como se fossem um só. O gestor de operações na matriz define uma vez um checklist que dezenas de lojas vão seguir: tarefa rara, feita com calma no desktop, de alta consequência, porque um erro se multiplica por todas as unidades. Ele precisa de poder e estrutura. O gerente de loja abre a unidade às 8h com o celular na mão e precisa passar o checklist rápido, registrando não conformidade com foto no lugar: tarefa diária, de alta frequência e tolerância zero a fricção. Ele precisa de velocidade e orientação. Os dois recebiam a mesma interface.

Para o negócio. A rede só existe como marca se o padrão de qualidade se mantiver em escala. O checklist é o mecanismo que sustenta isso, e o dado mais valioso que ele produz é a não conformidade, porque é o que dispara ação corretiva. Só que, na tela original, era exatamente esse registro o menos guiado: marcar “Não” não puxava nada, e foto e plano de ação eram botões opcionais soltos, com o mesmo peso de um comentário. O sistema estava desenhado para coletar respostas, não para produzir ação.

O reframe

Uma ferramenta genérica para dois trabalhos opostos.

Definir um padrão e cumprir um padrão foram espremidos na mesma experiência indiferenciada. Isso não é uma dor entre outras, é a raiz de todas elas: a criação parece pesada porque foi desenhada com a leveza que a aplicação exigia, e a aplicação não guia ninguém porque herdou a densidade que a criação pedia. Cada tela paga o preço de ter sido pensada para a outra.

Com esse enquadramento, o trabalho deixou de ser “melhorar três telas” e passou a ser “separar dois produtos que estavam sobrepostos”.

Suposições que assumi (e por quê)

Sem acesso a usuário, a escolha honesta não é fingir pesquisa, é declarar suposição e assumir a responsabilidade por ela. Deixei quatro explícitas no próprio material entregue:

• A aplicação acontece majoritariamente no mobile ou tablet, no chão da loja, mesmo que o print original mostrasse desktop. Essa suposição sozinha reescreve a tela de aplicação inteira.
• Criação é tarefa de baixa frequência e alta consequência. Aplicação é de alta frequência e baixa tolerância a fricção.
• O sistema de pontuação existe para a gestão regional medir conformidade, não para ajudar quem cria ou quem aplica. Logo, ele informa, mas não deve comandar a interface.
• A rede tem volume alto de lojas, então consistência e reuso importam mais do que flexibilidade infinita.

Declarar as suposições foi o que permitiu defender as decisões depois. Sem elas, o redesign seria só preferência estética.

A solução em destaque

• Home que lidera pela tarefa recorrente. A tela deixou de ser um menu de cinco opções de peso idêntico. Retomar uma auditoria em andamento vem antes de iniciar uma nova, aplicar domina a tela, e as funções de matriz (gerenciar, painéis, exportar, configurar) recuam para peso secundário.
• Criação quebrada em três momentos. Básico, perguntas, e regras e pontuação. O gestor define o nome, a categoria e a recorrência, depois monta as perguntas, depois ajusta pontuação. Resolve a densidade sem progressão e tira a pontuação da frente de quem só quer escrever uma pergunta.
• Reuso como caminho de primeira classe. Começar de um modelo passa a ser operação padrão, não exceção. Num contexto de rede, cada checklist nascer do zero é o oposto do que o negócio precisa.
• Não conformidade conduzida. Resposta conforme passa silenciosa. Marcar “Não conforme” revela, na sequência, gravidade, foto de evidência, plano de ação, responsável e prazo.
• Aplicação mobile-first, fluxo único. Uma pergunta conduzindo à próxima, sem painel lateral dividindo o estado, com salvamento offline visível.

Processo

• Diagnóstico antes de solução. Mapeei as dores das três telas e classifiquei por severidade, em vez de sair redesenhando. Foi esse mapa que revelou que as dores altas eram todas sintoma da mesma causa.
• Benchmarking dirigido por dor, não por inspiração. Cada referência entrou para resolver uma dor específica: Shopify e Linear resolveram a hierarquia da home, Typeform, Google Forms e Notion resolveram a criação, SafetyCulture foi o benchmark central para a aplicação mobile-first conduzida, e a lógica condicional no padrão de Typeform eliminou o ruído das ações repetidas embaixo de toda pergunta.
• Priorização explícita. Fechei o diagnóstico com um exercício de corte: se eu só pudesse consertar três coisas, seriam separar criar de aplicar desenhando a aplicação para o mobile, conduzir a não conformidade, e trazer reuso e progressão para a criação.
• Fui direto para alta fidelidade. Com três telas existentes como base e prazo curto, o risco não estava na estrutura, estava na densidade e na hierarquia visual.
• Não fiz teste de usabilidade. Sem usuário disponível e sem prazo para recrutar, teria sido teatro. Descrevo abaixo como validaria.

A interface

Resultado

O teste prático foi aprovado.

Como eu validaria

Com acesso a usuários, três coisas em ordem de risco:

1. Teste moderado com cinco gerentes de loja, aplicando um checklist real na loja, no horário de abertura. A métrica é conclusão sem ajuda e tempo até a primeira não conformidade registrada com foto.
2. Teste com três gestores de operações montando um checklist do zero e a partir de modelo. A pergunta é se a progressão em três momentos reduz abandono na criação ou só adiciona cliques.
3. Dado de produto, se existisse: proporção de não conformidades com foto e plano de ação preenchidos antes e depois. É a métrica que amarra direto ao problema de negócio.

Aprendizados

O ganho maior do projeto não veio de nenhuma tela. Veio de perceber que o briefing descrevia sintomas (“muitos passos”, “não orienta bem”) e que aceitar essa formulação teria produzido um redesign cosmético. O trabalho real foi encontrar a causa comum.

O que eu faria diferente: reservaria tempo para uma rodada rápida de teste, mesmo que com usuários aproximados, porque a suposição de que a aplicação é majoritariamente mobile carrega o redesign inteiro da terceira tela. Ela é bem fundamentada, mas continua sendo suposição, e eu preferiria tê-la testada a tê-la defendida.