O que MVP não é
MVP, ou Minimum Viable Product, virou um termo gasto. A maior parte dos times trata MVP como "vamos construir rápido e ver o que acontece". Esse atalho é o que faz o MVP virar refatoração 6 meses depois.
A definição original é mais precisa: MVP é a versão mínima que valida uma hipótese de negócio em ambiente real. Não é "produto incompleto". É "produto suficiente pra responder uma pergunta de negócio". A pergunta tem que estar clara antes da primeira sprint. Sem hipótese, sem MVP — só código jogado.
Em projetos com UX-first, o MVP nasce do oposto: começa pela pergunta, valida com pesquisa e protótipo, e só vira código depois que a hipótese passou no teste. A pesquisa Forrester/IBM mostrou o impacto desse arranjo: 50% menos bugs em produção, 75% de redução no tempo de design e desenvolvimento, e ROI de 301% em 3 anos.
A Regra do Retrabalho 1:10:100
A regra prática mais conhecida em engenharia de software também se aplica direto à decisão de pular ou não a etapa de UX antes do MVP.
Corrigir um problema de produto na fase de pesquisa custa 1 unidade de esforço. O mesmo problema, se passar pra fase de protótipo, custa 10. Se chegar até produção, custa 100.
A regra explica por que MVP sem UX sai caro. Cada hipótese errada vira código. Código errado vira bug. Bug em produção vira ticket de suporte, suporte vira churn, e churn vira o final da startup. O efeito cascata começa na decisão de pular as 3 semanas de pesquisa.
Empresas maduras tratam UX antes do MVP como mitigação de risco financeiro. Não é "fase opcional de design". É a etapa que evita gastar de 50 mil a 500 mil dólares em código que ninguém quer usar.
As 5 etapas de UX antes do código
Existe um framework consolidado pra rodar UX antes do MVP em 3 a 4 semanas. As cinco etapas são sequenciais e cada uma tem entregável concreto.
Etapa 1 — Diagnóstico e alinhamento
O time se reúne pra mapear sintomas vs causas estruturais. O cliente costuma chegar com sintoma (taxa de conversão baixa, churn alto, abandono de funil). A etapa de diagnóstico separa o sintoma da causa.
Ferramenta dominante aqui: Matriz CSD (Certezas, Suposições, Dúvidas). Separa o que o time sabe do que está supondo. O que entra em "Suposição" vira hipótese a testar na etapa seguinte.
Entregável: documento de 1 a 2 páginas com hipótese central + lista priorizada de suposições a validar.
Etapa 2 — Pesquisa com usuários
Aqui acontece a economia mais brutal do MVP. A regra dos cinco usuários do Nielsen Norman Group: testes estruturados com cinco usuários por segmento identificam mais de 80% dos problemas graves de usabilidade.
Pra validação de hipótese de mercado, recomenda-se 15 a 30 entrevistas distribuídas em 2 ou 3 segmentos. O framework Mom Test ancora a entrevista no comportamento histórico ("o que você fez ontem pra resolver X?") em vez de opinião sobre futuro ("você usaria um app que faz X?"). Hábito é fato. Opinião é cortesia.
Entregável: relatório com 8 a 12 insights críticos + lista priorizada de problemas reais a resolver no MVP.
Etapa 3 — Auditoria heurística
Se o produto já existe (mesmo que como protótipo legado), as 10 heurísticas de Jakob Nielsen são aplicadas pra mapear violações: feedback de status do sistema, prevenção de erros, adequação com o mundo real, controle do usuário, consistência, prevenção de erros, reconhecimento em vez de memória, flexibilidade, design estético/minimalista, ajuda ao usuário.
Cada violação ganha severidade (1 a 4). Severidade 3 e 4 viram backlog imediato.
Entregável: matriz de heurísticas com 20 a 40 itens classificados por severidade.
Etapa 4 — Solução e prototipagem
Protótipo de alta fidelidade no Figma, navegável, com fluxos críticos cobertos. Não é mockup estático. É clicável, testável, e tem o nível de detalhe suficiente pra desenvolvedor olhar e implementar sem ambiguidade.
A regra prática aqui: cada estado importante tem que estar no protótipo. Estado vazio, estado de erro, estado de carregamento, estado de sucesso. Estado que falta no Figma vira improvisação no código, e improvisação no código vira bug.
Entregável: protótipo Figma navegável + documentação de estados + handoff técnico.
Etapa 5 — Validação e entrega
Antes do código, o protótipo é testado outra vez com os mesmos usuários da etapa 2. Pergunta da validação: "isso resolve o problema que você descreveu?" Se 4 em 5 dizem que sim, passa pro MVP. Se as respostas vêm difusas, volta pra etapa 4 com ajustes.
Junto vai a implementação de um Design System centralizado: tokens de cor, tipografia, espaçamento e componentes nomeados em vocabulário do negócio. Sem isso, design vira teatro e engenharia improvisa.
Entregável: design system + protótipo aprovado + roadmap técnico priorizado.
Os números do MVP com UX-first
A pesquisa Forrester/IBM, no estudo de Total Economic Impact (TEI) com 5 times de desenvolvimento e 60 executivos de Fortune 1000, mediu os resultados de design thinking aplicado a sistemas complexos:
- Redução de 75% no tempo de design e desenvolvimento, porque o time foca no problema certo desde o começo.
- Lançamento de novos recursos 2x mais rápido, porque a validação prévia mata as decisões erradas antes do código.
- Redução de 33% em redesigns pós-lançamento, porque a pesquisa de usuário identifica os fluxos certos antes da implementação.
- Redução de mais de 50% nos defeitos de software, porque ambiguidade de requisitos cai quando o protótipo já foi testado.
- ROI acumulado de 301% em 3 anos, com período de payback inferior a 6 meses.
Em paralelo, o McKinsey Design Index acompanhou 300 empresas por 5 anos. As empresas no quartil superior de práticas de design tiveram crescimento de receita 32 pontos percentuais acima dos pares e retorno aos acionistas 56 pontos percentuais acima.
Os erros mais comuns de quem pula UX no MVP
Três padrões aparecem repetidamente em projetos que pularam UX e estouraram budget:
-
Confundir velocidade com pressa: "queremos lançar rápido" vira "vamos pular pesquisa". O resultado é lançamento de produto errado. Velocidade de execução é maior quando a hipótese está certa. Pressa sem hipótese é só burn de capital.
-
Tratar protótipo como custo, não como investimento: 3 semanas de Figma testado economizam 12 semanas de código refatorado. A matemática é direta. Quem trata como custo vai descobrir tarde.
-
Confundir feedback de família com validação de mercado: o time mostra o protótipo pra colegas e amigos, ouve "ficou ótimo", e considera validado. Cortesia não é mercado. Validação real exige entrevistar quem não conhece o time.
Insight Otther: MVP em 12 semanas com UX-first
Na Otther, tratamos UX-first como pré-requisito de MVP. O modelo prático que aplicamos: 3 semanas de pesquisa + protótipo testado, seguidas de 8 a 10 semanas de engenharia com escopo fechado e estados mapeados. Total: 11 a 13 semanas, com a economia toda no não-retrabalho.
O critério que aplicamos pra decidir o escopo do MVP é a regra dos três estados. Cada feature crítica tem que ter três respostas claras antes de virar código: estado vazio (o que o usuário vê quando ainda não usou?), estado de erro (o que acontece quando algo dá errado?), estado de sucesso (o que o usuário vê quando completa?). Feature sem os três estados definidos no Figma não entra na sprint.
Se você está prestes a iniciar um MVP, ou está com um MVP em produção que precisa de redesign, vale uma conversa. 90 minutos de discovery focado costumam mostrar se o escopo atual está validado ou se precisa de ajuste antes da próxima sprint.