Um produto digital não precisa ser reconstruído do zero toda vez que começa a apresentar problemas. Muitas vezes, a decisão mais segura é identificar o que deixou de funcionar, preservar o que ainda gera valor e evoluir as partes críticas em ciclos menores.
Em outros cenários, porém, pequenas correções deixam de resolver porque experiência, tecnologia, regras de negócio e estrutura do produto acumularam limitações profundas demais.
É aí que surge uma pergunta difícil para times de produto: devemos continuar evoluindo o que existe, fazer um redesign mais amplo ou reconstruir?
Este guia apresenta critérios para tomar essa decisão com mais evidência e menos impulso. O objetivo não é defender redesign ou reconstrução, mas mostrar como avaliar o produto atual antes de comprometer tempo, orçamento e usuários com uma mudança grande.
Resposta rápida: evolua o produto existente quando sua estrutura ainda permite corrigir os principais problemas de forma segura e incremental. Considere um redesign mais amplo quando jornadas, arquitetura ou padrões precisam ser reorganizados. Reconstruir do zero deve ser uma decisão excepcional, tomada quando limitações estruturais de experiência e tecnologia tornam a evolução progressiva inviável ou mais arriscada do que uma nova base.
Redesign não significa começar novamente
A palavra redesign costuma criar uma imagem equivocada: jogar a interface atual fora e desenhar uma nova versão.
Esse pode ser um dos resultados, mas não deveria ser o ponto de partida.
Um redesign de produto digital começa entendendo:
- o que funciona hoje;
- o que está causando problemas;
- quais usuários e jornadas são afetados;
- quais evidências sustentam essa percepção;
- o que pode ser corrigido localmente;
- o que é consequência de uma limitação mais estrutural;
- quais riscos uma mudança pode introduzir.
Esse cuidado é especialmente importante em produtos já utilizados por pessoas reais. Uma interface existente carrega comportamentos aprendidos, regras de negócio, integrações, exceções e decisões que nem sempre aparecem em um arquivo de design.
O Service Standard do GOV.UK trata serviços digitais como sistemas que continuam sendo pesquisados, medidos e melhorados ao longo de sua vida útil. A lógica é importante para qualquer produto digital: estar em produção não significa estar terminado.
Evoluir, redesenhar ou reconstruir: qual é a diferença?
Antes de tomar uma decisão, vale separar três tipos de intervenção.
| Abordagem | O que muda | Quando tende a fazer sentido |
|---|---|---|
| Evolução incremental | Partes específicas do produto | Quando a base ainda funciona e os principais problemas podem ser corrigidos por etapas |
| Redesign | Jornadas, arquitetura, interação, conteúdo e/ou interface de forma mais coordenada | Quando problemas atravessam várias partes da experiência, mas ainda existe valor na estrutura atual |
| Reconstrução | Uma parte substancial ou toda a base do produto | Quando limitações estruturais tornam a evolução progressiva inviável, excessivamente cara ou arriscada |
Essas alternativas não são necessariamente excludentes.
Um produto pode preservar boa parte de sua estrutura, redesenhar uma jornada crítica e reconstruir tecnicamente apenas um módulo que se tornou insustentável.
A decisão madura raramente é simplesmente “velho versus novo”. É uma decisão sobre o que preservar, o que modificar e o que realmente precisa ser substituído.
Por que reconstruir tudo parece tão atraente?
Produtos antigos acumulam fricções.
Componentes inconsistentes, fluxos criados em épocas diferentes, exceções de negócio, decisões técnicas antigas e reclamações recorrentes fazem uma folha em branco parecer libertadora.
O problema é que a folha em branco também apaga contexto.
O produto atual já contém conhecimento sobre:
- comportamentos reais dos usuários;
- regras e exceções do negócio;
- integrações necessárias;
- fluxos que já funcionam;
- hábitos construídos ao longo do tempo;
- necessidades de equipes internas;
- restrições técnicas e operacionais.
Reconstruir sem recuperar esse conhecimento pode resultar em uma interface mais moderna que repete problemas antigos ou cria outros novos.
O GOV.UK recomenda evolução contínua justamente porque serviços em produção geram informação que deveria influenciar as próximas decisões. Pesquisa, métricas, tickets de suporte, analytics e comportamento real formam uma base que um produto novo ainda não possui.
7 sinais de que evoluir o produto existente pode ser melhor que reconstruir
1. Os problemas estão concentrados em jornadas específicas
Se onboarding, checkout ou busca apresentam problemas, isso não significa automaticamente que todo o produto esteja comprometido.
Uma análise mais localizada pode revelar que poucas etapas concentram grande parte da fricção.
Nesse cenário, redesenhar o produto inteiro aumenta escopo e risco sem necessariamente aumentar o valor entregue.
Antes de definir uma intervenção ampla, vale fazer um UX Audit para identificar onde os problemas realmente estão.
2. Existem partes da experiência que funcionam bem
Um redesign não deveria procurar apenas defeitos.
Fluxos que possuem boa conclusão, baixa incidência de erros ou feedback positivo dos usuários representam ativos que podem ser preservados.
Isso também reduz a quantidade de comportamento que usuários existentes precisam reaprender.
3. A arquitetura ainda consegue suportar mudanças importantes
Uma experiência visualmente antiga pode existir sobre uma estrutura perfeitamente capaz de evoluir.
Da mesma forma, uma interface recente pode esconder uma base extremamente difícil de modificar.
Por isso, idade não deveria ser critério para reconstrução.
Produto, design e engenharia precisam avaliar juntos se a base atual consegue receber as mudanças necessárias com risco e esforço aceitáveis.
4. O negócio não pode interromper a operação
Produtos usados diariamente por clientes ou equipes internas podem não ter espaço para uma grande migração de uma vez.
Evoluir por partes permite testar mudanças, acompanhar métricas e controlar impacto antes de avançar para o restante da experiência.
Esse modelo também cria oportunidades de aprender com uso real em vez de esperar meses para colocar uma nova experiência inteira em produção.
5. Ainda não sabemos exatamente por que o produto apresenta problemas
Reconstruir antes do diagnóstico é especialmente arriscado.
Se abandono, reclamações ou baixa adoção existem, mas suas causas ainda são hipóteses, a primeira etapa deveria ser reduzir essa incerteza.
Isso pode exigir analytics, entrevistas, testes de usabilidade, análise de suporte ou outros métodos de pesquisa em UX.
6. Uma mudança progressiva permite medir resultado
Quando uma experiência inteira muda ao mesmo tempo, fica mais difícil saber quais decisões foram responsáveis por determinado resultado.
Mudanças progressivas podem facilitar comparação de indicadores antes e depois.
O Service Standard do GOV.UK recomenda definir o que sucesso significa e acompanhar dados que indiquem se uma mudança realmente produziu o efeito esperado.
No conteúdo sobre métricas de UX, explico como relacionar indicadores à experiência que está sendo melhorada.
7. O maior problema é dívida de experiência, não colapso estrutural
Interfaces também acumulam dívida.
Padrões duplicados, componentes inconsistentes, conteúdo desatualizado, fluxos pouco claros e decisões locais podem tornar um produto difícil de usar e manter.
Parte dessa dívida pode ser resolvida com arquitetura, revisão de jornadas e sistematização de padrões sem substituir todo o produto.
Quando inconsistência se torna sistêmica, também pode ser o momento de rever ou estruturar um Design System.
Quando um redesign mais amplo começa a fazer sentido
Há um estágio intermediário entre corrigir uma tela e reconstruir todo o produto.
É o redesign estrutural.
Ele costuma fazer sentido quando problemas atravessam várias partes da experiência e mudanças isoladas deixam de produzir coerência.
Alguns sinais:
- as jornadas principais não refletem mais a forma como usuários trabalham;
- a arquitetura da informação cresceu sem estrutura clara;
- navegação e nomenclaturas mudam entre áreas do produto;
- funcionalidades antigas foram acumuladas sem revisão;
- o mesmo problema aparece em vários fluxos;
- novos recursos exigem cada vez mais exceções;
- experiência mobile e desktop evoluíram de forma desconectada;
- componentes visuais já não correspondem aos comportamentos atuais;
- novos objetivos estratégicos exigem jornadas significativamente diferentes.
Nesse contexto, trabalhar tela por tela pode gerar uma experiência remendada.
É melhor compreender o sistema de maneira mais ampla e redefinir princípios, arquitetura e jornadas antes de voltar à interface.
Quando reconstruir do zero pode ser justificável
Reconstrução completa deveria ser tratada como uma decisão de alto impacto, e não como uma consequência automática de um produto antigo.
Ela começa a ser plausível quando limitações estruturais tornam mudanças importantes excessivamente difíceis ou arriscadas.
A tecnologia atual impede mudanças necessárias
UX pode revelar a necessidade de modificar uma jornada, mas engenharia precisa determinar se a base tecnológica consegue suportar essa mudança.
Quando cada nova funcionalidade exige contornos complexos, existe acoplamento excessivo ou partes críticas já não conseguem ser mantidas com segurança, a decisão deixa de ser exclusivamente de design.
A discussão precisa incluir arquitetura, segurança, infraestrutura, dados e operação.
O modelo atual do produto não corresponde mais ao negócio
Às vezes o problema não está em uma jornada. Está na forma como todo o produto foi concebido.
Uma plataforma criada para um único perfil de usuário pode precisar atender diversos tipos de organização. Um sistema desenhado para um processo linear pode precisar suportar diferentes jornadas simultaneamente.
Nesses casos, tentar preservar a estrutura antiga a qualquer custo pode gerar uma sucessão de exceções.
A arquitetura da informação deixou de representar o domínio
Produtos que crescem por muitos anos podem carregar estruturas criadas para uma realidade que já não existe.
Quando navegação, permissões, objetos e relações fundamentais precisam ser repensados, o redesign pode chegar a uma profundidade muito maior que a interface.
Veja também o guia de arquitetura da informação em UX.
O risco de manter é maior que o risco de migrar
Essa é uma das comparações mais importantes.
Reconstruir cria riscos de migração, regressão, perda de comportamento conhecido e adaptação dos usuários.
Manter também pode criar riscos relacionados a segurança, manutenção, escalabilidade, acessibilidade, operação e capacidade de evolução.
A decisão só começa a fazer sentido quando esses riscos são comparados de forma explícita.
UX sozinho não deveria decidir se o produto será reconstruído
Esse ponto é fundamental.
Um especialista em UX pode identificar problemas de jornada, comportamento, arquitetura da informação, interação, conteúdo e acessibilidade.
Mas a decisão sobre reconstrução precisa ser multidisciplinar.
| Perspectiva | Pergunta principal |
|---|---|
| Usuários / UX | Quais problemas atuais realmente precisam ser resolvidos? |
| Produto | Que capacidades são necessárias para a estratégia futura? |
| Negócio | Qual impacto, risco e retorno esperado da mudança? |
| Engenharia | A arquitetura atual consegue sustentar a evolução necessária? |
| Dados | Quais informações e históricos precisam ser preservados ou migrados? |
| Operação | Como a mudança afetará pessoas e processos que dependem do produto? |
| Segurança e compliance | Existem riscos ou requisitos que a estrutura atual não consegue mais atender? |
Uma decisão tomada apenas por uma dessas perspectivas tende a subestimar as outras.
O primeiro passo não é redesenhar: é diagnosticar
Antes de escolher entre evolução e reconstrução, precisamos saber o que realmente está acontecendo.
Um diagnóstico de produto existente pode combinar diferentes fontes.
Analytics e dados comportamentais
Observe conclusão, abandono, erros, adoção de funcionalidades e diferenças relevantes entre dispositivos ou segmentos.
Pesquisa com usuários
Dados mostram o que aconteceu, mas nem sempre explicam por quê.
Entrevistas, testes e outras abordagens qualitativas ajudam a compreender problemas, necessidades e contexto.
Suporte e operação
Tickets, dúvidas recorrentes e contornos criados pela equipe operacional revelam problemas que podem não aparecer nos dashboards.
Avaliação especializada
Heurísticas, padrões, conteúdo e acessibilidade ajudam a identificar problemas potenciais que merecem investigação ou correção.
Um UX Audit pode reunir essas evidências e transformar problemas dispersos em um diagnóstico priorizado.
Mapeie o que deve ser preservado antes de mudar
Um bom redesign não deveria começar com uma lista apenas do que está errado.
Também precisamos documentar:
- fluxos que possuem bons resultados;
- padrões que usuários já compreendem;
- funcionalidades de alto valor;
- conteúdo que reduz dúvidas;
- componentes reutilizáveis;
- integrações críticas;
- regras de negócio consolidadas;
- comportamentos necessários para usuários avançados;
- dependências operacionais.
Essa etapa reduz o risco de o redesign destruir acidentalmente algo que já funcionava.
Redesign incremental: como evoluir sem mudar tudo de uma vez
Quando a base permite evolução, uma estratégia incremental pode organizar o trabalho por jornadas ou problemas.
Um fluxo possível é:
- Diagnosticar: reunir evidências e localizar os problemas prioritários.
- Definir baseline: registrar como a experiência performa hoje.
- Escolher uma jornada crítica: evitar começar por dezenas de áreas simultaneamente.
- Pesquisar: investigar causas ainda desconhecidas.
- Prototipar: explorar alternativas sem comprometer imediatamente o desenvolvimento.
- Validar: testar as hipóteses mais arriscadas.
- Implementar: levar a mudança para produção com acompanhamento técnico.
- Medir: comparar comportamento e indicadores.
- Aprender: usar o que foi descoberto para escolher o próximo ciclo.
Essa lógica reduz o tamanho de cada aposta.
O GOV.UK também recomenda ciclos de melhoria ao longo da vida de serviços digitais, com pesquisa, feedback e entregas iterativas em vez de esperar por uma grande versão final.
Como priorizar o que redesenhar primeiro
Nem todo problema merece a mesma atenção.
Eu avaliaria pelo menos cinco dimensões.
| Dimensão | Pergunta |
|---|---|
| Impacto para usuários | Quanto o problema impede ou dificulta uma tarefa importante? |
| Alcance | Quantas pessoas ou jornadas são afetadas? |
| Impacto para o negócio | O problema interfere em receita, retenção, eficiência ou outro objetivo estratégico? |
| Risco | O que acontece se não fizermos nada? |
| Esforço e dependências | Quanto trabalho e quantas áreas precisam estar envolvidas? |
Prioridade não deveria ser confundida com facilidade.
Quick wins são úteis, mas um roadmap composto apenas por pequenas melhorias pode adiar indefinidamente problemas estruturais importantes.
Defina métricas antes do redesign
Se você só decide como medir depois de lançar a nova experiência, perde parte da capacidade de comparar.
Antes da mudança, registre uma linha de base sempre que possível.
Dependendo do objetivo, isso pode envolver:
- taxa de conclusão;
- abandono;
- erros;
- tempo em tarefas;
- adoção;
- conversão;
- tickets de suporte;
- satisfação;
- retrabalho interno;
- tempo necessário para executar um processo.
O objetivo não é provar que todo redesign gera aumento de conversão. É verificar se a mudança resolveu o problema que justificou o investimento.
Veja também como UX se relaciona com resultados de negócio.
Cuidado com o “redesign visual”
Uma das formas mais comuns de redesign é também uma das mais perigosas: modernizar a interface sem investigar a experiência.
Trocar tipografia, componentes, cores e espaçamentos pode melhorar consistência e percepção de qualidade, mas não resolve automaticamente:
- uma jornada mal estruturada;
- informação difícil de encontrar;
- regras de negócio confusas;
- campos desnecessários;
- falta de feedback;
- erros recorrentes;
- funcionalidades que não atendem necessidades reais.
Se os sintomas permanecem depois de várias mudanças de interface, provavelmente o problema precisa ser investigado em uma camada mais profunda.
Evite também o big bang redesign
Quanto maior a mudança realizada de uma vez, maior a quantidade de hipóteses colocadas em produção simultaneamente.
Isso pode aumentar:
- risco de regressões;
- necessidade de treinamento;
- dificuldade de adaptação de usuários existentes;
- complexidade de migração;
- volume de QA;
- dificuldade para descobrir qual mudança produziu determinado efeito.
Não significa que mudanças grandes nunca sejam necessárias. Significa que tamanho e risco precisam ser deliberadamente administrados.
A orientação do GOV.UK para serviços complexos é começar pequeno o suficiente para aprender e iterar a partir do uso, em vez de tentar resolver toda a complexidade de uma única vez.
Como redesenhar sem perder usuários existentes
Usuários experientes possuem memória construída sobre o produto.
Eles aprenderam onde determinadas ações ficam, como contornar limitações e quais sequências funcionam.
Por isso, uma mudança precisa considerar não apenas a usabilidade da nova experiência, mas também a transição.
Alguns cuidados importantes:
- testar com usuários atuais, não apenas novos;
- entender workflows de pessoas avançadas;
- preservar padrões que ainda funcionam quando possível;
- comunicar mudanças relevantes;
- evitar mover ações críticas apenas por preferência estética;
- planejar onboarding para funcionalidades significativamente alteradas;
- acompanhar suporte e comportamento após o lançamento.
Em sistemas profissionais, pequenas alterações aparentemente simples podem ter grande impacto sobre eficiência de pessoas que executam a mesma tarefa dezenas de vezes por dia.
Redesign também é uma oportunidade para acessibilidade
Se uma experiência será modificada de forma relevante, acessibilidade precisa entrar desde o início.
Deixar essa revisão apenas para o final pode gerar retrabalho porque problemas de acessibilidade podem estar relacionados a arquitetura, interação, componentes e conteúdo, não apenas a detalhes visuais.
Uma evolução gradual também permite corrigir dívida de acessibilidade por componentes e jornadas, desde que exista uma estratégia clara de prioridade e acompanhamento.
Uma matriz para decidir: evoluir, redesenhar ou reconstruir?
Não existe uma fórmula capaz de tomar a decisão automaticamente, mas a matriz abaixo ajuda a estruturar a conversa.
| Situação | Evoluir | Redesign | Reconstruir |
|---|---|---|---|
| Problemas concentrados em poucos fluxos | Forte candidato | Pode ser necessário | Raramente |
| Arquitetura de informação amplamente incoerente | Limitado | Forte candidato | Depende da tecnologia |
| Muitos padrões visuais inconsistentes | Possível | Forte candidato | Normalmente não é necessário apenas por isso |
| Tecnologia permite mudanças com segurança | Forte candidato | Forte candidato | Exige justificativa adicional |
| Tecnologia impede requisitos estratégicos essenciais | Pode ser insuficiente | Pode ser insuficiente | Precisa ser avaliado |
| Produto possui muitas partes valiosas | Forte candidato | Preserve o que funciona | Maior risco de perda |
| Causas dos problemas ainda são desconhecidas | Diagnosticar primeiro | Diagnosticar primeiro | Não decidir ainda |
A coluna “reconstruir” é propositalmente cautelosa.
Uma reconstrução completa só deveria ser recomendada depois de entender suficientemente a experiência atual e a capacidade tecnológica de evolução.
Exemplo: o que muda quando começamos pelo diagnóstico
Imagine uma plataforma B2B cujo time acredita que precisa de um redesign completo porque clientes reclamam que o sistema é difícil.
Antes de redesenhar, a equipe analisa o produto e descobre que:
- 80% das reclamações se concentram em três fluxos;
- a navegação principal é bem compreendida por usuários experientes;
- um formulário crítico possui regras que nunca são explicadas;
- existem quatro componentes diferentes para a mesma ação;
- boa parte da dificuldade é causada por exceções operacionais;
- a tecnologia suporta mudanças gradualmente.
Nesse cenário, reconstruir tudo poderia adicionar risco sem resolver melhor o problema.
Uma estratégia mais racional poderia priorizar os três fluxos, corrigir conteúdo e regras, consolidar componentes e medir novamente antes de ampliar o redesign.
Agora imagine que o diagnóstico mostre o oposto: arquitetura incapaz de suportar os novos tipos de usuário, integrações frágeis, regras fundamentais duplicadas em vários módulos e limitações técnicas que impedem as mudanças necessárias.
Nesse caso, reconstruir parte da base passa a ser uma hipótese mais plausível.
O diagnóstico não existe para defender uma solução. Existe para melhorar a qualidade da decisão.
O que deveria sair de um diagnóstico antes do redesign
Antes de começar uma grande transformação, eu esperaria pelo menos:
- mapa dos principais problemas atuais;
- evidências que sustentam cada problema relevante;
- jornadas prioritárias;
- partes da experiência que devem ser preservadas;
- restrições técnicas conhecidas;
- dependências operacionais;
- baseline das principais métricas;
- hipóteses que ainda precisam ser testadas;
- critérios para decidir o que será evoluído ou reconstruído;
- roadmap inicial de mudanças.
Isso permite que redesign deixe de ser uma encomenda de telas e passe a ser uma estratégia de evolução do produto.
Quando buscar ajuda externa
Um time interno pode conduzir esse processo quando possui capacidade para pesquisa, diagnóstico, produto, design e análise técnica.
Apoio externo tende a fazer mais sentido quando:
- não existe consenso sobre o problema;
- o time está muito envolvido na operação diária;
- é necessário um diagnóstico independente;
- faltam competências específicas;
- uma decisão grande precisa ser tomada antes de comprometer desenvolvimento;
- o produto passou por várias tentativas de redesign sem resolver os problemas principais.
Se a dúvida ainda é se chegou a hora de procurar ajuda, veja quando contratar um consultor de UX.
Se já decidiu contratar e está comparando fornecedores, veja também como contratar uma consultoria de UX.
Como uma consultoria de UX pode apoiar um produto existente
O trabalho não precisa começar com a decisão de reconstruir.
Em produtos existentes, uma atuação consultiva pode começar pelo diagnóstico dos fluxos atuais, análise de evidências, pesquisa com usuários e priorização dos problemas que justificam investimento.
A partir daí, o próximo passo pode ser:
- corrigir problemas específicos;
- redesenhar uma jornada crítica;
- reorganizar arquitetura da informação;
- validar uma nova solução;
- estruturar padrões e componentes;
- planejar uma evolução progressiva;
- ou, em conjunto com tecnologia, concluir que determinada parte realmente precisa ser reconstruída.
Na consultoria de UX da CamaraUX, a proposta é começar entendendo o problema antes de definir o tamanho da solução.
Conclusão: preserve o que funciona e questione o que não funciona
Produtos digitais acumulam história.
Parte dessa história vira dívida. Parte vira conhecimento, comportamento aprendido e valor que não deveria ser descartado.
Por isso, redesign não deveria começar com uma tela em branco.
Comece pelas evidências.
Descubra onde a experiência realmente falha, o que ainda funciona, quais mudanças são possíveis na estrutura atual e quais limitações impedem o produto de chegar onde precisa.
Se o produto pode evoluir com segurança, evolua. Se a experiência exige reorganização mais ampla, redesenhe. Se a estrutura realmente impede o futuro necessário, avalie uma reconstrução com produto e tecnologia.
Reconstruir do zero não deveria ser o começo do diagnóstico. Deveria ser uma das possíveis conclusões dele.
Perguntas frequentes sobre redesign de produtos digitais
Quando um produto digital precisa de redesign?
Um redesign pode fazer sentido quando problemas de experiência atravessam diferentes jornadas, a arquitetura deixou de acompanhar a evolução do produto, existem inconsistências sistêmicas ou novos objetivos exigem mudanças significativas. O ideal é diagnosticar o produto antes de definir o tamanho do redesign.
É melhor redesenhar ou reconstruir um produto do zero?
Depende das causas dos problemas e das limitações da estrutura atual. Quando a base ainda permite evolução segura, melhorar ou redesenhar partes do produto tende a preservar mais conhecimento e reduzir risco. Reconstrução deve ser considerada quando limitações estruturais tornam a evolução inviável ou excessivamente arriscada.
Produto antigo precisa ser reconstruído?
Não necessariamente. Idade não determina se um produto precisa ser reconstruído. Um sistema antigo pode continuar tecnicamente sustentável e permitir boa evolução, enquanto uma solução relativamente nova pode apresentar limitações estruturais. A decisão deve ser baseada em diagnóstico, não em idade.
O que analisar antes de um redesign de UX?
Analise jornadas críticas, comportamento dos usuários, analytics, feedbacks, suporte, arquitetura da informação, padrões de interação, acessibilidade, métricas atuais e restrições técnicas. Também registre o que funciona bem e deve ser preservado.
UX pode decidir se um sistema deve ser reconstruído?
UX contribui identificando problemas de experiência, comportamento e arquitetura da informação, mas a decisão de reconstrução deve envolver também produto, engenharia, negócio, dados, operação, segurança e outras áreas relevantes.
É possível redesenhar um produto por partes?
Sim. Quando a estrutura atual permite, uma evolução incremental por jornadas ou problemas pode reduzir risco, acelerar aprendizado e permitir acompanhamento de métricas antes de ampliar as mudanças para outras partes do produto.
Como medir se um redesign funcionou?
Defina antes da mudança quais indicadores representam o problema que será resolvido e registre uma linha de base. Depois do lançamento, compare métricas como conclusão, abandono, erros, adoção, conversão, suporte ou eficiência, de acordo com o objetivo do projeto.
UX Audit deve ser feito antes de um redesign?
Pode ser um excelente primeiro passo quando ainda não está claro onde estão os principais problemas. O UX Audit ajuda a organizar evidências, identificar fricções e priorizar o que merece investigação ou redesign antes de iniciar uma mudança ampla.
