Projeto Add a feature — UX/UI Design

Laís Martins
5 min readOct 22, 2020

--

Esse é um dos projetos do Bootcamp de UX/UI Design na Ironhack São Paulo

Como podemos melhorar o serviço de pagamento do iFood para que os clientes possam compartilhar momentos especiais com os amigos sem se preocuparem com questões financeiras?

O Projeto

A proposta desse projeto era eleger um aplicativo existente, e já bastante aderido pelo mercado, para adicionar uma nova funcionalidade a ele. A entrega final do projeto era um protótipo em alta fidelidade com o novo recurso proposto.

Assim, minha ideia foi adicionar ao aplicativo do iFood uma funcionalidade de dividir o valor total de um pedido com demais usuários que também desfrutariam do mesmo.

Pesquisas: testando a desejabilidade

Como esse projeto trouxe uma proposta que inverte o processo de entendimento das necessidades e frustrações do usuário pois se inicia já com uma ideia (normalmente inicia-se com pesquisas, análises e então a fase de ideações), as pesquisas realizadas tiveram um papel ainda mais focado em validar o desejo de um recurso como esse. Para isso, iniciei com uma técnica chamada “Research Learning Spiral”.

Conhecido também como “Espiral de pesquisa”, esse recurso é utilizado para entender o objetivo da pesquisa, quais hipóteses ela validará ou não, quais informações queremos que ela traga como resultado e assim, entendendo quais perguntas e em quais formatos metodológicos ela deve ser construída.

Assim, defini minhas pesquisas em três partes: pesquisa quantitativa realizada através de um Google Forms enviado por WhatsApp, grupos de Facebook; pesquisas qualitativas através de entrevistas com usuários; e por fim , uma análise competitiva.

Pesquisa Quantitativa — Survey

Os resultados foram:

  • 33 respostas totais;
  • 97% pagam seus pedidos dentro do aplicativo (registram seus cartões);
  • 31% (maioria) se sentem tão desconfortáveis em cobrar alguém posteriormente que deixam de cobrar (consequentemente não recebem);
  • 78% dos pagamentos são realizados por transferência bancária;

Pesquisa Qualitativa — entrevistas

Entendendo esse resultado primário, segui para as entrevistas com o objetivo de entender desses usuários quais os sentimentos que tinham ao precisar cobrar, o que eles faziam ou deixavam de fazer nessas situações e como entendiam uma melhora para essa questão.

“gostaria de nem precisar passar por essa parte de pensar em cobrar alguém”

“é realmente muito incômodo, ainda mais quando a divisão é combinada antes mas as pessoas não pagam, eu não tenho coragem de cobrar e já saí muito no prejuízo por isso”

“seria legal se essas divisões pudessem ser feitas no momento da compra sem depender muito de banco que acaba sendo desculpa pra postergar o pagamento”

A partir das entrevistas, realizadas com 3 pessoas, foi possível identificar que o problema estava em volta do cobrar, e que o não receber dobrava o sentimento de culpa, primeiro por não conseguir cobrar, segundo por acabar sem o dinheiro. Todos entendem que poder compartilhar esses valores dentro do próprio aplicativo seria muito mas simples e evitaria tanto esses sentimentos quanto a divisão de valores e recebimento dos mesmos.

Análise Competitiva

Realizei uma breve análise competitiva com os aplicativos UberEats, James e Rappi para identificar se possuíam algo parecido com esse recurso idealizado ou outras formas de partilhar o pagamento entre os usuários.

A análise resultou negativa para o UberEats e James, e inicialmente positiva do Rappi. O último possui uma funcionalidade de compartilhar o pagamento que estava inativa na hora do teste. Ou seja, não realiza o que propõe. Entendendo assim que tornaria o aplicativo do iFood ainda mais único dentro de seu mercado por oferecer esse recurso.

Definição de problema e HMW

Observei que o serviço não esta atendendo a todas as necessidades dos usuarios no que diz respeito ao pagamento e divisão de pedidos compartilhados, pois não atuam no constrangimento de quem precisa cobrar e e receber dinheiro das pessoas com quem diviram o pedido.

Segui com a definição do problema principal e com os HMW (how might we), que é a técnica de expressar em forma de oportunidade um problema real do usuário, facilitando tanto seu entendimento, quanto o próximo passo que é a fase de ideação de soluções. São frases que se iniciam com “Como podemos melhorar” e acabam com alguma oportunidade.

Definição de problema

Pessoas que realizam e pagam pedidos por aplicativos delivery para dividir com outras pessoas, precisam uma maneira de dividir o pagamento no ato da compra para que não se sintam constrangidas em cobrar o valor e recebam devidamente.

HMW

Como podemos melhorar o serviço de pagamento do iFood para que os clientes possam compartilhar momentos especiais com os amigos sem se preocuparem com questões financeiras?

Com o problema e a oportunidade definidos, parti para a fase de ideação, análise do comportamento do aplicativo existente e o resultado final foi o protótipo, em alta fidelidade, com a funcionalidade proposta.

Protótipo

Para interagir com o protótipo, clique neste link do Figma: https://www.figma.com/proto/cM7jFXDhMvPKHRoGGne8Lp/Projeto-3-Add-a-feature-iFood?node-id=18%3A1&viewport=664%2C349%2C0.25&scaling=scale-down

Conclusão

Essa funcionalidade foi projetada para viabilizar a divisão de valor de um pedido com outro(s) usuário(s) dentro do aplicativo. Foi identificado que o serviço, por não disponibilizar esse recurso, acaba por gerar constrangimentos, não pagamento de valores e até a desistência de comprar. Com isso, as pesquisas trouxeram a desejabilidade do recurso e com ele acredita-se que essas dores e frustrações serão evitadas, sendo possível medir através do próprio uso do recurso e o possível aumento de pedidos de grande volume.

Esse projeto foi o primeiro durante o curso realizado individualmente e foi um processo muito interessante e motivador. Acredito no resultado final e, caso você também acredite (Oi, iFood e Movile, sumidas :) ), entre em contato que podemos conversar um pouco mais!

--

--

Laís Martins

UX/UI Designer, aplicando a diversidade do design e das pessoas nas soluções centradas nos usuários. Figma | Arquitetura da informação | UI