DiFérias: Discovery e design de marketplace náutico
Um marketplace náutico de dois lados nos Lençóis Maranhenses: discovery com canvas e JTBD, identidade visual, jornada de reserva e repasse automático ao proprietário da embarcação.
- Cliente
- DiFérias
- Ano
- 2023
- Categorias
- UI / Product Design
Um marketplace de dois lados no polo dos Lençóis
A DiFérias é uma plataforma de aluguel de lanchas, barcos e experiências náuticas no polo dos Lençóis Maranhenses, com bases em Barreirinhas, Atins e Santo Amaro. O produto conecta quem quer passear a quem tem embarcação para alugar, e por isso precisa funcionar bem para dois públicos ao mesmo tempo: o turista que vai reservar e o proprietário que vai anunciar e receber. A home publica hoje 50 destinos, mais de 200 ofertas e mais de 5 mil clientes.
Fui responsável pelo discovery, pelo design e pela implementação da plataforma, e continuo sustentando o produto. O primeiro ciclo foi um POC, registrado no assessment com a decisão de seguir por iteração em fluxo. A plataforma no ar é o que veio depois, e é o que este case documenta.
O problema tem quatro fricções, e não uma
O material de lançamento lista o que o turista enfrenta quando chega ao cais: negociar preço, horário e embarcação sem saber exatamente o que está contratando; incerteza sobre disponibilidade e horário de saída; falta de fotos reais e de informação sobre o barco; e dificuldade de pagamento, com pouca segurança na reserva.
Do outro lado do marketplace existe um problema simétrico, e menos visível: proprietários de embarcação com ativos parados fora da temporada, sem canal de venda confiável e sem previsibilidade de ocupação. Um produto que resolve só a busca do turista não resolve o marketplace, porque a oferta precisa ser sustentável para quem anuncia.
O discovery: assessment, JTBD e fluxo
O trabalho começou por dois canvas preenchidos no ciclo do Disruption Lab: um Business Value Canvas, que definiu objetivo, público, problema e diferenciais, e um Business Model Canvas, que estruturou parceiros, atividades, proposta de valor, canais, custos e receita.
Na sequência veio o mapeamento de Jobs to be Done, com o perfil do cliente de um lado e o mapa de valor do outro. O que ficou registrado ali:
Jobs: pessoas que vão para locais de veraneio, proprietários que vão disponibilizar veículos parados, e as parcerias como caminho de distribuição.
Dores: proprietários com ativos ociosos que querem rentabilizar, e pessoas sem acesso seguro a veículos de lazer.
Ganhos esperados: frota extra de verão para quem tem veículo parado, locação segura para quem aluga, e a possibilidade real de experimentar a embarcação.
Modelo de receita: cobrança sobre a locação, com fee documentado como hipótese inicial no próprio JTBD.
Fechando o ciclo de discovery, produzi os wireframes de fluxo do usuário, cobrindo busca, filtros, detalhe, reserva, pagamento, gestão da reserva, cancelamento e avaliação.
A marca antes da interface
Um marketplace de experiência vende confiança antes de vender reserva, então a identidade visual foi parte do trabalho de produto, e não uma etapa decorativa. O sistema inclui o logotipo em todas as variações necessárias (cor, versão escura, versão clara e ícone), três elementos gráficos proprietários (mar, sol e vento), um banco de fotos da região e as aplicações físicas: outdoor de 900 por 300 centímetros, windflag, camisa e panfleto.
A decisão mais difícil foi sobre dinheiro
A parte do produto que exigiu mais cuidado não foi a tela de busca. Foi o repasse ao parceiro. Um marketplace que cobra do turista e precisa pagar o dono da embarcação carrega um problema de confiança nos dois sentidos, e resolvê-lo por fora do fluxo (combinado por telefone, transferência manual, planilha) destrói a operação conforme a oferta cresce.
A solução implementada usa subconta por parceiro com split automático. O desenho ficou assim:
Onboarding do parceiro: o cadastro na plataforma dispara a criação da subconta, e o parceiro recebe um link onde confirma os dados, envia documento e faz reconhecimento facial, exigência regulatória do Banco Central. A análise leva até 48 horas, e a conta passa por estados definidos: pendente, em análise, aprovada ou rejeitada.
Split na cobrança: o repasse é configurado no momento em que a cobrança é criada, por percentual ou valor fixo. Quando o turista paga, o gateway desconta a taxa, apura o valor líquido e credita automaticamente a parte do parceiro na subconta dele.
Contingência regulatória: no período de avaliação, existem limites operacionais impostos pelo Banco Central (teto de subcontas e teto de cobranças por subconta), o que obrigou a pensar a fila de aprovação de parceiros como parte do fluxo de produto, e não como detalhe de back office.
Do lado técnico, duas regras que entraram no desenho: a chave da subconta é devolvida uma única vez e fica só no backend, e a atualização de status vem por webhook, sem consulta repetida à API.
A plataforma no ar
O produto publicado tem cinco superfícies principais, e cada uma responde a um momento da jornada:
Home: hero com a proposta, vitrine de ofertas, destinos e prova social com números da operação.
Busca: lista de ofertas com filtros persistentes na lateral.
Destino: recorte por região, para quem já sabe onde quer navegar.
Oferta: galeria de fotos, preço por dia, comodidades e ofertas similares, que é onde a decisão acontece.
Parceiro: benefícios, como funciona e depoimentos, que é a porta de entrada do lado da oferta.
Implementei o site com Lovable sobre um design system em componentes, com padrões de card, tipografia e espaçamento consistentes entre as páginas. Além das cinco superfícies, o produto tem home e oferta em versão mobile, busca, destino, página de parceiro e uma página institucional.
O reel abaixo percorre o produto em uso, da home à página de oferta:
O que esse projeto mudou na minha forma de trabalhar
Design não termina no handoff. Como continuo sustentando o produto, cada decisão de interface volta como feedback de operação. Isso muda o critério: uma tela que parece elegante mas gera dúvida no suporte não passa.
O dinheiro é parte do design do produto. Onboarding de parceiro, split de pagamento e status de aprovação são fluxos de experiência, com estados, mensagens e prazos. Tratá-los como assunto exclusivo de engenharia é o caminho mais curto para uma operação manual disfarçada de plataforma.
O lado da oferta precisa de tanto cuidado quanto o lado da demanda. A página de parceiro tem a mesma função que a página de oferta: convencer, explicar e reduzir risco percebido.
Confiança se desenha com informação concreta. Foto real da embarcação, comodidades, preço por dia e política de cancelamento são o que transforma uma negociação de cais em uma reserva.