Vouky
Vouky
Concierge digital para a organização de roteiros personalizados via IA
Concierge digital para a organização de roteiros personalizados via IA
Concierge digital para a organização de roteiros personalizados via IA
\
\
Viagem
Viagem
Viagem
\
2025
2025
2025
Resumo
Resumo
A Vouky é um MVP de planejamento de viagens com IA, criado para centralizar uma jornada hoje fragmentada entre múltiplas ferramentas. Atuei na pesquisa, definição da experiência, fluxos, prototipação e handoff, estruturando uma solução viável dentro de um contexto de escopo amplo, prazo curto e restrições técnicas
Estratégia e Descisão
Estratégia e Descisão
Minhas decisões deram foco e viabilidade a um MVP com ambição alta demais para o nível de validação, maturidade e capacidade de execução disponível
Minhas decisões deram foco e viabilidade a um MVP com ambição alta demais para o nível de validação, maturidade e capacidade de execução disponível
Minhas decisões deram foco e viabilidade a um MVP com ambição alta demais para o nível de validação, maturidade e capacidade de execução disponível
Desde o início, identifiquei que o principal risco do projeto não era apenas o prazo, mas o desalinhamento entre o escopo proposto e as condições reais para sustentá-lo. Mais do que isso, o risco central era a irrelevância do produto: avançar com uma solução tecnicamente ambiciosa sem validar dores reais do viajante, como logística, confiança e organização da jornada, poderia resultar em uma ferramenta pouco útil e com alta chance de abandono. A partir dessa leitura, minhas decisões buscaram reduzir incerteza e criar uma base mais consistente para o MVP, com um recorte enxuto de discovery para validar hipóteses centrais, o uso de uma biblioteca de UI para acelerar a construção e a defesa de maior foco nas funcionalidades essenciais
Desde o início, identifiquei que o principal risco do projeto não era apenas o prazo, mas o desalinhamento entre o escopo proposto e as condições reais para sustentá-lo. Mais do que isso, o risco central era a irrelevância do produto: avançar com uma solução tecnicamente ambiciosa sem validar dores reais do viajante, como logística, confiança e organização da jornada, poderia resultar em uma ferramenta pouco útil e com alta chance de abandono. A partir dessa leitura, minhas decisões buscaram reduzir incerteza e criar uma base mais consistente para o MVP, com um recorte enxuto de discovery para validar hipóteses centrais, o uso de uma biblioteca de UI para acelerar a construção e a defesa de maior foco nas funcionalidades essenciais
Desde o início, identifiquei que o principal risco do projeto não era apenas o prazo, mas o desalinhamento entre o escopo proposto e as condições reais para sustentá-lo. Mais do que isso, o risco central era a irrelevância do produto: avançar com uma solução tecnicamente ambiciosa sem validar dores reais do viajante, como logística, confiança e organização da jornada, poderia resultar em uma ferramenta pouco útil e com alta chance de abandono. A partir dessa leitura, minhas decisões buscaram reduzir incerteza e criar uma base mais consistente para o MVP, com um recorte enxuto de discovery para validar hipóteses centrais, o uso de uma biblioteca de UI para acelerar a construção e a defesa de maior foco nas funcionalidades essenciais
Esse cenário exigiu assumir o trade-off de menor profundidade por funcionalidade para sustentar uma visão mais ampla do produto, equilibrando usuário, negócio e tecnologia ao longo de pesquisa, definição de fluxos, prototipação e handoff para desenvolvimento, em colaboração com stakeholders e dentro de um contexto real de implementação
Esse cenário exigiu assumir o trade-off de menor profundidade por funcionalidade para sustentar uma visão mais ampla do produto, equilibrando usuário, negócio e tecnologia ao longo de pesquisa, definição de fluxos, prototipação e handoff para desenvolvimento, em colaboração com stakeholders e dentro de um contexto real de implementação
Esse cenário exigiu assumir o trade-off de menor profundidade por funcionalidade para sustentar uma visão mais ampla do produto, equilibrando usuário, negócio e tecnologia ao longo de pesquisa, definição de fluxos, prototipação e handoff para desenvolvimento, em colaboração com stakeholders e dentro de um contexto real de implementação
Execução e Processo
Execução e Processo
A execução foi guiada por evidências de pesquisa e benchmark, transformando dores recorrentes de confiança, logística e fragmentação em decisões de produto
A execução foi guiada por evidências de pesquisa e benchmark, transformando dores recorrentes de confiança, logística e fragmentação em decisões de produto
A execução foi guiada por evidências de pesquisa e benchmark, transformando dores recorrentes de confiança, logística e fragmentação em decisões de produto
As entrevistas mostraram que o problema não era apenas gerar roteiros, mas tornar o planejamento mais confiável, viável e centralizado. Os usuários validavam informações em múltiplas fontes, tinham receio de links pouco confiáveis, sofriam com a dispersão de vouchers e referências e valorizavam roteiros que respeitassem distância, horários e contexto real da viagem. A partir disso, a pesquisa deixou claro que o valor do MVP dependia menos de uma IA “falante” e mais da capacidade de organizar decisões com credibilidade, contexto e utilidade prática, reforçando uma abordagem de design orientado ao usuário O benchmark reforçou essa direção ao mostrar que, embora os concorrentes já oferecessem onboarding guiado, mapas interativos e algum nível de personalização, ainda existiam lacunas importantes em otimização de rotas, controle de agenda, uso offline, centralização de documentos e integração mais útil com afiliados. Isso sustentou minhas decisões de priorizar uma experiência menos dependente de chat isolado e mais estruturada em torno de onboarding eficiente, arquitetura da informação, lógica geográfica e apoio real durante a viagem, com foco em consistência da experiência e qualidade da solução Como desdobramento, a solução buscou conectar valor para o usuário e viabilidade de negócio no mesmo fluxo, priorizando aquilo que era mais aderente ao contexto do MVP. Funcionalidades como calendário de preços, recálculo de roteiro e briefing offline chegaram a ser consideradas como oportunidades relevantes a partir da pesquisa, mas não foram executadas por exigirem esforço técnico e custo incompatíveis com o estágio do projeto. Isso exigiu concentrar a proposta em uma base mais viável, com foco em arquitetura da experiência, clareza dos fluxos, priorização, tomada de decisão baseada em pesquisa e preservação da consistência mesmo diante das limitações de escopo e implementação
As entrevistas mostraram que o problema não era apenas gerar roteiros, mas tornar o planejamento mais confiável, viável e centralizado. Os usuários validavam informações em múltiplas fontes, tinham receio de links pouco confiáveis, sofriam com a dispersão de vouchers e referências e valorizavam roteiros que respeitassem distância, horários e contexto real da viagem. A partir disso, a pesquisa deixou claro que o valor do MVP dependia menos de uma IA “falante” e mais da capacidade de organizar decisões com credibilidade, contexto e utilidade prática, reforçando uma abordagem de design orientado ao usuário O benchmark reforçou essa direção ao mostrar que, embora os concorrentes já oferecessem onboarding guiado, mapas interativos e algum nível de personalização, ainda existiam lacunas importantes em otimização de rotas, controle de agenda, uso offline, centralização de documentos e integração mais útil com afiliados. Isso sustentou minhas decisões de priorizar uma experiência menos dependente de chat isolado e mais estruturada em torno de onboarding eficiente, arquitetura da informação, lógica geográfica e apoio real durante a viagem, com foco em consistência da experiência e qualidade da solução Como desdobramento, a solução buscou conectar valor para o usuário e viabilidade de negócio no mesmo fluxo, priorizando aquilo que era mais aderente ao contexto do MVP. Funcionalidades como calendário de preços, recálculo de roteiro e briefing offline chegaram a ser consideradas como oportunidades relevantes a partir da pesquisa, mas não foram executadas por exigirem esforço técnico e custo incompatíveis com o estágio do projeto. Isso exigiu concentrar a proposta em uma base mais viável, com foco em arquitetura da experiência, clareza dos fluxos, priorização, tomada de decisão baseada em pesquisa e preservação da consistência mesmo diante das limitações de escopo e implementação
As entrevistas mostraram que o problema não era apenas gerar roteiros, mas tornar o planejamento mais confiável, viável e centralizado. Os usuários validavam informações em múltiplas fontes, tinham receio de links pouco confiáveis, sofriam com a dispersão de vouchers e referências e valorizavam roteiros que respeitassem distância, horários e contexto real da viagem. A partir disso, a pesquisa deixou claro que o valor do MVP dependia menos de uma IA “falante” e mais da capacidade de organizar decisões com credibilidade, contexto e utilidade prática, reforçando uma abordagem de design orientado ao usuário O benchmark reforçou essa direção ao mostrar que, embora os concorrentes já oferecessem onboarding guiado, mapas interativos e algum nível de personalização, ainda existiam lacunas importantes em otimização de rotas, controle de agenda, uso offline, centralização de documentos e integração mais útil com afiliados. Isso sustentou minhas decisões de priorizar uma experiência menos dependente de chat isolado e mais estruturada em torno de onboarding eficiente, arquitetura da informação, lógica geográfica e apoio real durante a viagem, com foco em consistência da experiência e qualidade da solução Como desdobramento, a solução buscou conectar valor para o usuário e viabilidade de negócio no mesmo fluxo, priorizando aquilo que era mais aderente ao contexto do MVP. Funcionalidades como calendário de preços, recálculo de roteiro e briefing offline chegaram a ser consideradas como oportunidades relevantes a partir da pesquisa, mas não foram executadas por exigirem esforço técnico e custo incompatíveis com o estágio do projeto. Isso exigiu concentrar a proposta em uma base mais viável, com foco em arquitetura da experiência, clareza dos fluxos, priorização, tomada de decisão baseada em pesquisa e preservação da consistência mesmo diante das limitações de escopo e implementação
Encerramento
Mais do que comprovar sucesso por volume de funcionalidades, este MVP serviu para validar a direção do produto, revelar seus limites reais de viabilidade e tornar mais claro onde o valor estava, e onde ele ainda não se sustentava
Mais do que comprovar sucesso por volume de funcionalidades, este MVP serviu para validar a direção do produto, revelar seus limites reais de viabilidade e tornar mais claro onde o valor estava, e onde ele ainda não se sustentava
Mais do que comprovar sucesso por volume de funcionalidades, este MVP serviu para validar a direção do produto, revelar seus limites reais de viabilidade e tornar mais claro onde o valor estava, e onde ele ainda não se sustentava
O principal resultado foi a entrega do fluxo central definido para o MVP, com a criação de roteiro personalizado preservada como núcleo da proposta. Como o produto ainda estava em fase de estruturação, não houve métricas mensuráveis de uso ou performance nessa etapa. O que existia era uma definição clara do que deveria ser acompanhado após o lançamento, especialmente em relação à criação de roteiros, engajamento, uso durante a viagem e potencial de monetização
O principal resultado foi a entrega do fluxo central definido para o MVP, com a criação de roteiro personalizado preservada como núcleo da proposta. Como o produto ainda estava em fase de estruturação, não houve métricas mensuráveis de uso ou performance nessa etapa. O que existia era uma definição clara do que deveria ser acompanhado após o lançamento, especialmente em relação à criação de roteiros, engajamento, uso durante a viagem e potencial de monetização
O principal resultado foi a entrega do fluxo central definido para o MVP, com a criação de roteiro personalizado preservada como núcleo da proposta. Como o produto ainda estava em fase de estruturação, não houve métricas mensuráveis de uso ou performance nessa etapa. O que existia era uma definição clara do que deveria ser acompanhado após o lançamento, especialmente em relação à criação de roteiros, engajamento, uso durante a viagem e potencial de monetização
O principal ponto de limitação foi a dependência de APIs externas. Integrações como Booking, Google Maps e Google Voos não estavam disponíveis da forma esperada ou exigiam custo alto para o estágio do produto, o que comprometeu parte da experiência e das hipóteses de monetização. Isso indicou que o modelo baseado em afiliados, sozinho, possivelmente não seria suficiente para sustentar o produto no longo prazo
O principal ponto de limitação foi a dependência de APIs externas. Integrações como Booking, Google Maps e Google Voos não estavam disponíveis da forma esperada ou exigiam custo alto para o estágio do produto, o que comprometeu parte da experiência e das hipóteses de monetização. Isso indicou que o modelo baseado em afiliados, sozinho, possivelmente não seria suficiente para sustentar o produto no longo prazo
O principal ponto de limitação foi a dependência de APIs externas. Integrações como Booking, Google Maps e Google Voos não estavam disponíveis da forma esperada ou exigiam custo alto para o estágio do produto, o que comprometeu parte da experiência e das hipóteses de monetização. Isso indicou que o modelo baseado em afiliados, sozinho, possivelmente não seria suficiente para sustentar o produto no longo prazo
Hoje, eu começaria com uma visão mais mobile first, priorizaria uma etapa inicial mais robusta de pesquisa e validação e investigaria antes a viabilidade técnica das APIs e do modelo de monetização. Também faria um recorte mais enxuto do produto, concentrando os esforços na experiência de roteiro personalizado, que se mostrou o verdadeiro core do MVP
Hoje, eu começaria com uma visão mais mobile first, priorizaria uma etapa inicial mais robusta de pesquisa e validação e investigaria antes a viabilidade técnica das APIs e do modelo de monetização. Também faria um recorte mais enxuto do produto, concentrando os esforços na experiência de roteiro personalizado, que se mostrou o verdadeiro core do MVP
Hoje, eu começaria com uma visão mais mobile first, priorizaria uma etapa inicial mais robusta de pesquisa e validação e investigaria antes a viabilidade técnica das APIs e do modelo de monetização. Também faria um recorte mais enxuto do produto, concentrando os esforços na experiência de roteiro personalizado, que se mostrou o verdadeiro core do MVP