Pular para o conteúdo
Sunstone Apps
← Voltar para o blog
UX e produto

Rodando uma critique heurística de UX no meu próprio app — e corrigindo o que ela encontrou

Eu tinha um jogo de Sudoku publicado na Google Play e nenhum designer de UX. Então rodei as dez heurísticas de Nielsen contra o meu próprio app. O score deu 25 de 40 — decente, mas três heurísticas estavam claramente fracas. Após uma rodada focada de correções, subiu para 28. Aqui está o processo completo: o que a avaliação encontrou, o que corrigi, o que rejeitei, e o que a mudança de score realmente significa.

Publicado: 9 min read

Por que fazer uma review formal de UX num app já publicado

O Daily Sudoku já estava na Google Play. Jogadores estavam baixando. Nada estava obviamente quebrado. Mas “nada está quebrado” é um padrão baixo — significa que o app funciona, não que a experiência é boa.

Eu vinha adicionando features por semanas: temas, desafios diários, conquistas, economia de créditos, sound design. Cada feature passou nos seus próprios testes. O que eu não tinha feito era dar um passo atrás e avaliar a experiência completa como um jogador a veria.

Uma avaliação heurística força essa mudança de perspectiva. Você pontua a interface contra um conjunto fixo de princípios — as dez heurísticas de usabilidade de Nielsen — em vez de perguntar “está ok?” O score é aproximado, mas produz uma lista ranqueada de problemas concretos. Essa lista vale mais do que qualquer tempo gasto olhando para as próprias telas.

O framework de avaliação

Usei as dez heurísticas de Nielsen, cada uma pontuada de 0 a 4, com teto de 40. A pontuação é deliberadamente rigorosa: um 3 significa “funciona bem com problemas menores,” e um 4 significa “genuinamente excelente — difícil de melhorar.” A maioria das interfaces reais fica entre 20 e 32.

Além dos scores heurísticos, rodei três verificações suplementares:

  • Teste de AI slop. Alguém olharia para isso e diria imediatamente “uma IA fez isso”? Isso pega gradient text, glassmorfismo, grids de cards idênticos e outros padrões saturados.
  • Red flags de persona. Três arquétipos de usuário (usuário mobile distraído, power user impaciente, iniciante confuso) mais uma persona específica do projeto (jogador de hábito diário), navegando pelo app como cada um.
  • Checklist de carga cognitiva. Foco único por tela, chunking, hierarquia visual, progressive disclosure.

A primeira critique: 25/40

Os scores contaram uma história clara. Sete heurísticas ficaram em 3 (decentes mas não ótimas). Três ficaram em 2 ou abaixo — e essas eram as que valiam corrigir primeiro.

Prevenção de Erro ficou em 2. O botão de Dica gastava créditos (um recurso IAP com dinheiro real) com um único toque, sem distinção visual das ações gratuitas como Desfazer. O botão Apagar não fazia nada quando tocado numa célula vazia — sem feedback, sem explicação. O drawer de dificuldade mostrava cinco opções sem descrição, sem dificuldade estimada, sem orientação para iniciantes.

Recuperação de Erro ficou em 2. Posicionamentos errados mostravam um flash vermelho mas sem explicação. Toasts de erro de economia desapareciam rapidamente sem caminho adiante. O botão de Dica desabilitado não dava nenhuma indicação do motivo.

Ajuda e Documentação ficou em 1. Um modal “Como Jogar” na tela inicial explicava as três regras do Sudoku (linha, coluna, bloco) mas não dizia nada sobre os cinco controles do jogo, o sistema de créditos, notas versus notas automáticas, ou o que acontece quando os erros acabam. O tutorial de primeiro uso cobria seleção de célula, entrada de número e feedback — mas não os controles que o jogador usaria trinta segundos depois.

Priorizando: o que corrigir primeiro

Nem todo achado merece ação imediata. Classifiquei em tiers de prioridade:

P1 (corrigir agora): Timer mostrando valores absurdos em durações extremas. Sem feedback em controles desabilitados. Sem explicação dos controles em lugar acessível.

P2 (corrigir em breve): Texto muted falhando no contraste WCAG AA. Drawer de dificuldade sem descrições. Labels de estatísticas ambíguos no Perfil.

P3 (corrigir eventualmente): Título da página web mostrando nome genérico da tela. Labels de acessibilidade do NumberPad hardcoded em inglês. Tela de Favoritos mostrando texto “Carregando…” puro.

Um achado que rejeitei explicitamente: adicionar um diálogo de confirmação antes de gastar créditos. A critique apontou como problema de confiança, mas a realidade de produto é que fricção no gasto de créditos reduz consumo, o que reduz recompra. O comportamento atual de toque único é a decisão de produto correta. Nem toda recomendação de UX serve ao negócio.

As correções, concretamente

Feedback em controles desabilitados

O maior ganho de UX por linha de código. Adicionei um padrão de callback onPressDisabled na barra de controles do jogo. Quando um botão está desabilitado mas o jogador toca, em vez de silêncio, um toast aparece explicando o motivo:

  • Dica desabilitada: “Selecione uma célula vazia primeiro” ou “Sem créditos ou anúncios disponíveis”
  • Apagar desabilitado: “Selecione uma célula primeiro,” “Este número faz parte do puzzle,” ou “Esta célula já está vazia”
  • Desfazer desabilitado: “Nada para desfazer”

Cada mensagem está localizada nos dez idiomas suportados. O toast ganhou uma melhoria visual: fade-in com slide-up, uma barra de countdown mostrando o tempo restante, e um fade-out na saída. Antes era um bloco estático que aparecia e sumia abruptamente.

Contraste e legibilidade

O token mutedForeground no modo claro media 3.9:1 contra o background surfaceStrong — abaixo do requisito 4.5:1 do WCAG AA. Escureci de rgb(120 113 108) para rgb(98 91 86), atingindo 5.4:1. O equivalente no modo escuro foi de rgb(168 162 154) para rgb(181 175 167), com 4.7:1. Ambos passam AA.

O contador de dígitos restantes no number pad era 10px a 35% de opacidade — quase invisível. Subiu para 12px a 50% de opacidade.

Expansão do Como Jogar

O modal “Como Jogar” ganhou uma seção de Controles: seis items (Desfazer, Apagar, Notas, Notas Automáticas, Dica, Créditos) cada um com ícone e explicação de uma linha. O último passo do tutorial de primeiro uso agora inclui uma linha sutil: “Você pode rever isso a qualquer momento em Como Jogar” — conectando o jogador à referência sem adicionar um quarto passo ao tutorial.

Clareza no drawer de dificuldade

Cada nível de dificuldade agora mostra uma linha descritiva: “40 pistas · Relaxado” até “24 pistas · Intenso.” Novos jogadores (sem best stars em nenhum nível) veem um badge “Recomendado” no Novato com ícone de sparkles.

Limpeza de nomes

“Sequência diária atual” e “Sequência do desafio diário” no Perfil viraram “Sequência de vitórias” e “Sequência do desafio diário.” Os nomes antigos eram parecidos demais e nenhum comunicava o que rastreavam.

Correções menores

Formatação do timer suporta horas (1:05:32 em vez de 65:32). Título da página web mostra “Daily Sudoku” em vez do nome da tela. Labels de acessibilidade do NumberPad usam chaves i18n. Estado de loading dos Favoritos usa skeleton cards em vez de texto puro.

A segunda critique: 28/40

Três heurísticas melhoraram:

  • Prevenção de Erro: 2 → 3. Toasts em controles desabilitados agora explicam o problema antes que o jogador cometa um erro.
  • Recuperação de Erro: 2 → 3. Toasts sugerem a ação correta. A dica de review no tutorial previne o “perdi minha chance de aprender.”
  • Ajuda e Documentação: 1 → 2. Seção de Controles no Como Jogar fecha a lacuna principal. Ainda não é contextual dentro do jogo, o que limita em 2.

As outras sete permaneceram em 3. Cada uma teve correções reais que não resolveram todos os problemas dentro daquela heurística.

O que aprendi sobre o processo

Pontue tudo primeiro, depois corrija. Fui tentado a começar a corrigir durante a avaliação. Resista. O score te dá um mapa; corrigir no meio da avaliação significa navegar sem terminar o mapa.

Descarte achados que conflitam com objetivos de produto. O diálogo de confirmação de créditos era uma recomendação de UX clássica que teria prejudicado a receita. Heurísticas são uma lente, não um mandato.

Localização multiplica o escopo. Cada nova chave i18n significa dez arquivos de locale atualizados. Subestimei esse custo e deveria ter agrupado as chaves melhor.

O score mais difícil de mover é Ajuda. Ir de 1 para 2 exigiu expandir um modal e adicionar referências cruzadas. Ir de 2 para 3 exigiria ajuda contextual dentro do jogo — uma arquitetura fundamentalmente diferente. Cada ponto custa mais que o anterior.

Re-critique com honestidade. É tentador inflar scores para mostrar progresso. Um 3→3 onde a correção foi real mas a heurística tinha outros problemas é honesto. Um falso 3→4 envenena todo o exercício.

O que resta

A critique identificou problemas remanescentes em P2 e P3: ajuda ainda não é contextual durante o gameplay, a tela de Perfil mostra dados demais sem progressive disclosure, atalhos de teclado web faltam para modais, e o skeleton de favoritos não tem animação shimmer. Cada um é uma melhoria real que não entrou nesta rodada.

O score foi de 25 para 28 numa sessão focada. O próximo salto — 28 para 32 — vai exigir trabalho estrutural mais profundo: ajuda contextual in-game, arquitetura de informação do Perfil, e acessibilidade de teclado. Cada um desses é uma feature, não uma correção.

Se você publica um app e se pergunta se a UX está “boa o suficiente,” tente as dez heurísticas. Você vai encontrar problemas que passava por cima todo dia. Se vai corrigi-los antes dos seus jogadores notarem, aí é com você.

Experimente o Daily Sudoku na Google Play