A maioria dos problemas que aparecem no final de um projeto foi plantada no início. Como a vm2 estrutura um projeto de plataforma digital — do diagnóstico ao monitoramento pós-lançamento.
Uma das perguntas que mais aparecem no início de uma conversa com um novo cliente é: “Como funciona o processo de vocês?”
É uma pergunta justa. Empresas que já contrataram projetos digitais antes carregam experiências de atrasos, escopo que cresce sem controle, entregas que não correspondem ao que foi combinado. Querem entender antes de assinar.
O que a gente aprende em mais de 6.000 projetos entregues é que a maioria dos problemas que aparecem no final de um projeto foi plantada no início. Não por má intenção — por falta de alinhamento sobre o que estava sendo construído, para quem, e com qual critério de sucesso.
A maior parte das empresas chega com um brief. Às vezes bem elaborado, às vezes uma lista de funcionalidades, às vezes uma referência de outro site que gostaram.
O brief é um ponto de partida para a conversa, não para o projeto. O projeto começa quando o brief é questionado.
O que esse site precisa fazer que ele não faz hoje? Quem vai operar a plataforma internamente — e com qual nível técnico? Qual é o fluxo que mais importa para o negócio? O que define sucesso doze meses depois do lançamento?
Essas perguntas raramente estão no brief. E as respostas a elas mudam o que vai ser construído.
Nessa fase, o trabalho é entender o negócio por trás do projeto: o contexto competitivo, os sistemas com os quais a plataforma vai precisar se integrar, as restrições técnicas e orçamentárias reais, e — principalmente — os fluxos que têm mais impacto para a operação do cliente.
Com o diagnóstico feito, o segundo passo é definir a arquitetura da solução: quais são os módulos da plataforma, como eles se comunicam, quais integrações são necessárias, qual é a stack tecnológica adequada para o contexto.
Essa decisão, feita antes do design, evita retrabalho caro mais adiante. Uma interface bem desenhada sobre uma arquitetura errada vai gerar problemas que não se resolvem com ajuste visual.
É também nessa etapa que se define o escopo de forma objetiva. Escopo mal definido é a raiz da maioria dos conflitos entre cliente e fornecedor em projetos digitais. Quando o que está incluído não está claro desde o início, as interpretações divergem — e a divergência aparece sempre no pior momento: quando o projeto já está em andamento.
O design no processo da vm2 não é uma fase que acontece depois da arquitetura e antes do desenvolvimento. É um processo iterativo que começa cedo e continua até o lançamento.
O primeiro entregável de design raramente é uma tela finalizada. É uma estrutura navegável — um protótipo que permite testar fluxos, validar hierarquia de informação e identificar problemas antes que qualquer linha de código seja escrita.
Essa sequência é intencional. Mudar um protótipo custa horas. Mudar código custa dias. Mudar uma plataforma em produção custa semanas. Cada erro identificado mais cedo no processo é um erro resolvido mais barato.
Aprovado o protótipo, o design evolui para especificação: sistema de componentes, comportamentos de interação, estados de carregamento, mensagens de erro, versões mobile. O desenvolvimento começa com um documento que responde às perguntas antes de elas aparecerem.
Com arquitetura definida e design especificado, o desenvolvimento segue um processo estruturado em entregas parciais. O cliente não espera o projeto inteiro para ver algo funcionando — cada módulo é entregue, testado e validado antes de avançar para o próximo.
Essa cadência tem um propósito além da transparência: ela cria pontos de decisão ao longo do projeto. Quando o cliente vê o módulo funcionando, às vezes percebe que precisa de algo diferente do que havia imaginado. Detectar isso na entrega parcial é incomparavelmente melhor do que descobrir no dia do lançamento.
As integrações com sistemas externos — ERPs, CRMs, plataformas de pagamento, APIs de terceiros — são tratadas como parte do escopo técnico desde o início, não como tarefa de última hora. Integração é onde os projetos mais escorregam: a API do sistema legado não documenta tudo que precisaria, o fluxo de autenticação do parceiro é diferente do que estava especificado, o ambiente de homologação não replica o comportamento de produção. Antecipar esses riscos é parte do trabalho.
O deploy é o momento em que o projeto começa a gerar valor. Mas é também o momento em que os problemas reais aparecem — os que nenhum teste em ambiente controlado consegue simular completamente.
Os primeiros dias e semanas após o lançamento são um período de monitoramento ativo. Comportamento dos usuários, performance sob carga real, erros que aparecem em combinações de dispositivo e navegador que ninguém havia testado.
Depois desse período de estabilização, começa a fase que a maioria das agências não cobre: a evolução contínua da plataforma. Os dados de uso mostram onde os usuários estão saindo, quais fluxos estão gerando mais suporte, quais funcionalidades estão sendo mais utilizadas. Essas informações alimentam o roadmap das próximas melhorias.
É por isso que o processo da vm2 não termina no deploy. O projeto vivo é diferente do projeto entregue.
Nota: Este artigo descreve a metodologia padrão da vm2 para projetos de plataforma digital. Cada projeto tem suas especificidades — o processo se adapta ao contexto, mas os princípios se mantêm.
UX não é sobre satisfação do usuário. É sobre decisão. E decisão é sobre negócio — especialmente no B2B, onde múltiplos perfis avaliam a mesma plataforma.
A escolha de tecnologia para um projeto digital não começa pela tecnologia. Começa pela pergunta certa: o que essa plataforma precisa fazer?
Responsivo e mobile first não são a mesma coisa. A diferença é de processo — e ela muda o que é construído, desde o wireframe até o deploy.
