marivc

James Delivery · 2021

James Delivery: uma busca que entende o que o usuário procura

Uma semana para diagnosticar por que a busca de um super app devolvia tão pouco, e redesenhá-la de ponta a ponta: da pesquisa ao protótipo.

Meu papel
Product Designer
Estudo de caso
Empresa
James Delivery
Ano
2021
MobileResearchBusca

Resumo

Case desenvolvido em uma semana para o processo seletivo de Product Designer do iFood. O desafio: escolher um problema real de um produto digital existente e resolvê-lo, mostrando o processo inteiro, da descoberta à interface.

Escolhi a busca do James Delivery, um app que reunia de supermercado a serviços como eletricista. Num catálogo tão largo, a busca é o caminho mais curto entre a pessoa e o que ela quer, mas a do James devolvia pouco: só lojas, sem filtros, sem ordenação, sem histórico.

Usei o Double Diamond como guia: pesquisa e benchmark no Descobrir, hipóteses e recorte no Definir, fluxo, componentes e protótipo no Desenvolver. Como o projeto não foi a mercado, o case para honestamente no terceiro estágio.

O problema

A busca era a porta de entrada do app e entregava pouco. O diagnóstico cruzou quatro fontes: o mapeamento do fluxo atual, um benchmark com seis players, a análise das reviews de 2020 nas lojas e entrevistas com usuários.

  • Nota 3,4 no Google Play, com a busca entre as reclamações recorrentes nas reviews de 2020.
  • A busca retornava apenas lojas e restaurantes: itens, pratos e produtos ficavam invisíveis.
  • Zero filtros e zero critérios de ordenação, contra cinco e seis no iFood.
  • Sem histórico de buscas e sem feedback de resultado vazio: a tela simplesmente ficava em branco.

Desafio

Entender a fundo o fluxo de busca atual, mapear evidências e transformá-las em hipóteses capazes de sustentar uma nova proposta, ajudando o usuário a chegar mais rápido a resultados relevantes.

Restrições

Uma semana de prazo, produto de terceiros sem acesso a dados internos e o compromisso de manter consistência com os componentes existentes do app. Sem ida a mercado: o case se encerra no protótipo.

Contexto

Análise de experiência

Comparei a busca do James com a dos maiores players de delivery da América Latina, eixo a eixo: o que existe na busca, o que cada resultado informa, o que dá para buscar, filtros, ordenação e histórico.

iFood

A busca mais completa do benchmark: filtros por modo de entrega, distância, taxa e pagamento, seis critérios de ordenação, histórico com atalhos e resultado por prato e por item de mercado.

Virou a régua de completude do redesign: autocomplete, histórico e resultado por item entraram no recorte da primeira fase.

Rappi

Resultado em formatos distintos por categoria: loja, item de mercado e prato aparecem com apresentações próprias, cada uma com a informação que importa.

Inspirou os formatos diferentes de resultado por categoria na tela de busca proposta.

Uber Eats

Histórico de buscas que guarda até consultas sem resultado, e ordenação por avaliação, tempo de entrega e popularidade.

Reforçou o histórico como atalho de repetição, uma dor citada diretamente nas entrevistas.

Domicilios.com

O único player do benchmark que permitia apagar itens e limpar o histórico de buscas por completo.

O controle do usuário sobre o próprio histórico entrou na proposta desde o primeiro rabisco.

Merqueo

Focado em mercado: busca por item com autocomplete e ordenação por preço, mas sem filtros e sem histórico.

Mostrou que buscar item de mercado é padrão da categoria, não um luxo: o James, usado principalmente para mercado, não tinha.

Dos seis players, o James era o único sem filtro, sem ordenação e sem histórico ao mesmo tempo. Não era um problema de acabamento: eram capacidades básicas da categoria que simplesmente não existiam.

Abordagem

01

Boas práticas antes de opinião

Comecei por desk research em fontes como NN/g e Baymard, destilada num checklist de dezoito boas práticas de busca mobile: do ícone de lupa visível ao autocomplete a partir do terceiro caractere, passando pelo estado de resultado vazio.

02

Mapear o fluxo atual

Mapeei o fluxo real da busca tela a tela. O mapa expôs sugestões sem distinção visual entre categorias, retorno restrito a lojas, tags inconsistentes entre telas e nenhum feedback quando a busca não encontrava nada.

03

Ouvir as lojas e os usuários

Classifiquei as reviews de 2020 da Google Play e da App Store por tema: busca por item, filtro, resultado errado. Depois, cinco entrevistas remotas aprofundaram as dores. Uma fala resume o problema: 'Nesse app eu não achei onde filtrar a pesquisa. Ou não tem, ou não está fácil.'

04

Hipóteses ancoradas em evidência

Nove hipóteses conectaram as evidências ao valor de negócio, do campo de busca mais visível ao efeito de avaliações na decisão. Delas saiu o recorte da primeira fase: sete entregas, da home redesenhada à tela de filtros.

05

Rabiscar antes de desenhar

Fluxos rabiscados à mão para explorar caminhos enquanto era barato errar, e uma conversa de viabilidade técnica antes de qualquer tela: negociar o que entra agora e o que fica para depois faz parte do design.

06

Consistência com o que já existe

Mapeei os componentes existentes do app para definir o caminho visual do redesign. A proposta precisava parecer do James, e ser plausível de construir com o que o time já tinha.

07

O fluxo proposto

O fluxo ideal conecta as quatro frentes da proposta: home com busca em evidência, tela inicial de busca com histórico e categorias, autocomplete e página de resultados com refino.

08

O que viria depois

O prazo encerrou o case no protótipo. Os próximos passos já estavam nomeados: estressar cenários de uso, definir métricas de sucesso, rodar testes de usabilidade e refinar tecnicamente com o time de desenvolvimento.

Protótipo navegável

Percorra o fluxo proposto: da home à busca, do autocomplete aos resultados com ordenação. Toque na tela para começar.

Layout e mudanças

Cada decisão de tela ancora numa evidência da pesquisa: boas práticas, benchmark, reviews ou uma fala de entrevista.

  1. 01

    Home com busca em evidência

    Mercado vira a categoria padrão, refletindo o uso real do app. O endereço de entrega ganha destaque para evitar pedidos errados, e a busca entra na tab bar e em todas as páginas, deixando claro que dá para procurar item ou estabelecimento.

  2. 02

    Busca inicial como atalho

    Histórico personalizado pelo uso, com formatos distintos para restaurante, mercado e categoria, tempo de entrega e aviso de fechado antes do clique, e controle para apagar cada item.

  3. 03

    Autocomplete que constrói a consulta

    Sugestões a partir do terceiro caractere, informando onde cada resultado vive: em todas as categorias, num restaurante ou num mercado. Menos digitação, menos erro.

  4. 04

    Resultados que ajudam a decidir

    Contagem de resultados, ordenação e filtro à mão, e cards com o que as entrevistas pediram: distância, frete, tempo, avaliação e promoções em tags de destaque.

  5. 05

    O prato sem abrir o restaurante

    Os pratos mais pedidos expandem no próprio resultado, com preço, evitando a segunda busca dentro da página de cada restaurante que os usuários descreveram como cansativa.

Case de uma semana, encerrado no protótipo: sem números de mercado, o que fica é o método. Evidência antes de hipótese, hipótese antes de tela, e cada mudança de layout apontando de volta para a pesquisa que a justificou.

Próximo projeto

Handshake: confiabilidade com baixo atrito