Voltar para os casos
4 min de leitura

Dos dados às decisões: repensando a exploração no iOverlander

O iOverlander é uma plataforma gerida pela comunidade que ajuda viajantes a encontrar e compartilhar lugares ao redor do mundo. O produto enfrentava dificuldades com navegação, confiança no conteúdo e na transformação de dados em decisões úteis.

Em 30 segundos

  1. Problema

    O app reunia muitos dados gerados por usuários, mas mostrava todos com o mesmo peso, e quem viajava tinha dificuldade para achar locais confiáveis rapidamente.

  2. O que fiz

    Redesenhei a experiência de descoberta: hierarquia de informação mais clara, pins de mapa mais limpos e navegação mais simples entre mapa e lista.

  3. Resultado

    Um formulário contínuo de check-in (antes, mais de 10 telas) e decisões mais rápidas na estrada, com sinais mais claros de qualidade e atualidade.

Visão geral

O iOverlander é uma plataforma de viagens feita pela comunidade, usada por overlanders para encontrar locais de acampamento, serviços e pontos de interesse no mundo todo. O conteúdo é gerado pelos próprios usuários e o uso é principalmente no celular, muitas vezes na estrada.

Problema

O paradoxo da descoberta

O iOverlander abriga uma riqueza incrível de dados gerados pelos usuários, mas o volume excessivo havia se tornado um problema. A interface apresentava as informações de forma igualitária, independentemente da relevância, forçando os usuários a filtrar o excesso de ruído para encontrar necessidades básicas durante a viagem.

  • Os usuários tinham dificuldade para encontrar lugares relevantes rapidamente.
  • As informações eram densas e difíceis de escanear em dispositivos móveis.
  • Faltavam sinais visuais de confiança para a atualidade e a qualidade das avaliações.
  • Incompatibilidade de navegação entre a visualização do mapa e as visualizações de lista detalhadas.

Menu principal do app, anotado com a heurística de consistência e padrões: toda função tem a mesma apresentação, até as configurações
Tela de seleção de localização do app, com anotações de três heurísticas de usabilidade
Tela de critérios para novos locais, uma página longa de texto, com anotações de três heurísticas de usabilidade
Etapa de banheiros (14 de 18) do fluxo de adicionar um local, com anotação de uma heurística de usabilidade
Tela de detalhes de um local do app, com anotação de uma heurística de usabilidade
Tela inicial de check-in e a mesma página depois de rolar até o fim, com a heurística de visibilidade do status do sistema anotada
1 / 6
Os usuários não estavam enfrentando problemas com a falta de dados, eles estavam lutando para compreendê-los, confiar neles e agir rapidamente com base neles.

Processo

Como o trabalho chegou até aqui

Das hipóteses aos wireframes: a pesquisa, a definição e os esboços por trás das decisões.

Hipóteses

Com o que eu sabia até ali, escrevi seis hipóteses para guiar o próximo passo: as entrevistas com usuários.

Seis post-its azuis com as hipóteses iniciais sobre como as pessoas usam o app iOverlander

Entrevistas com usuários

Cinco entrevistas com overlanders, recrutados pelo Instagram (principalmente casais e quem viaja de van, carro ou trailer) e feitas na mesma semana. Os insights abaixo são os pontos de dor que eles relataram.

Quadro de post-its cinzas com os insights das entrevistas e miniaturas das chamadas de vídeo

How Might We

Com os insights das entrevistas, fiz um exercício de How Might We dividido pelos temas que os usuários trouxeram: detalhes do local, salvar locais, adicionar novos locais e a página inicial.

Quadro com quatro temas (tela de detalhes do local, função de salvar, adicionar novo local, página inicial), cada um com post-its azuis de How Might We

Brainstorm de soluções

Para cada tema, um brainstorm de possíveis soluções. As ideias ficaram misturadas de propósito, para abrir espaço a soluções que cruzam os temas.

Quadro com os temas (salvar locais, adicionar novos locais, página inicial, login, detalhes do local), post-its amarelos de How Might We e post-its verdes com ideias de solução

Priorização MoSCoW

As ideias organizadas em Must, Should, Can e Won't, para decidir o que moldaria o início do design das telas.

Quadro MoSCoW com as colunas Must, Should, Can e Won't preenchidas com post-its verdes

Personas

Com um caminho claro sobre quais soluções testar, desenhei quatro personas a partir dos casos das entrevistas, para checar se eu estava deixando passar alguma oportunidade.

Quatro cartões de persona de overlanders, cada um com foto, veículo, objetivos, desafios, estilo de vida e necessidades

Fluxo do usuário: escolher onde ficar

Os fluxos foram o exercício que mais me ajudou: mostraram o quanto a experiência atual estava ruim. Este cobre a escolha de um lugar para passar a noite.

Diagrama de fluxo intitulado Choose a place to stay at the same night (escolher um lugar para ficar na mesma noite)

Fluxo do usuário: planejar a viagem

Foram três fluxos no total, todos baseados nos insights das entrevistas, como o de que nem todo mundo planeja os locais antes de pegar a estrada, ao contrário do que eu supunha.

Diagrama de fluxo intitulado Planning locals trip itinerary (planejar o roteiro da viagem com locais)

Fluxo do usuário: adicionar um local

O fluxo que mostrou o maior problema: um formulário de 18 páginas e a necessidade de estar no ponto exato (ou saber as coordenadas) literalmente impedem as pessoas de adicionar locais.

Diagrama de fluxo intitulado Adding a new place to the platform (adicionar um novo local à plataforma), que termina num formulário de 18 páginas

Esboços antes das telas

Com o problema definido, peguei papel e caneta para esboçar um redesenho ideal antes de abrir o Figma.

Esboços feitos à mão do fluxo de adicionar um local: mapa, adicionar um ponto, regras, localização atual ou no mapa, nome e tela de agradecimento

Wireframes

Os esboços guiaram os wireframes de média fidelidade, onde planejei o layout e a estrutura de conteúdo em torno do que os usuários precisavam.

Wireframes de média fidelidade do app Overlander sobre fundo laranja: mapa, detalhes do local, perfil e as telas de adicionar um local
1 / 11

Solução

Decisões e abordagem

Solução 1

Escaneabilidade em vez de densidade

Reestruturei os cartões de locais para destacar primeiro os fatores críticos de tomada de decisão: ícone da categoria, distância exata e uma pontuação agregada de sentimento, movendo as avaliações de texto detalhadas para baixo na hierarquia.

Solução 2

Alinhamento de comportamento real

Fluxos principais de usuários projetados em torno de necessidades imediatas ("Encontrar combustível perto de mim agora") em vez de navegação aberta, reduzindo o tempo para ação.

Solução 3

Confiança através do contexto

Foram introduzidos indicadores visuais claros sobre a atualização dos dados. Uma localização verificada ontem supera visualmente uma que não é atualizada há três anos, como deve ser.

Solução 4

Simplificando o check-in em um único fluxo

Reduzi a experiência de check-in de um fluxo fragmentado e de várias etapas (mais de 10 telas) para um formulário único e contínuo, otimizado para o uso no mundo real. Agora, os usuários podem escanear, responder e concluir o processo de uma só vez, reduzindo o atrito em situações de mobilidade.

Solução

Um caminho mais claro pela frente

O design final traz clareza estrutural para a experiência de overlanding. Pins de mapa mais limpos e uma hierarquia tipográfica distinta transformam dados em inteligência prática.

Experiência de descoberta redesenhada