Nami

First of all, I knew I’d be working on this project end to end, and that was exactly what I wanted. Also, even before talking to Nami’s owners, I already suspected that most restaurants on iFood struggled with the fees the platform charges.

In other words, I started the project with a few assumptions, and they needed to be validated. I also wanted to gather new information and insights worth carrying forward.

The solution was to run two studies: a qualitative one, to gather information and potential insights, and a quantitative one, to validate my assumptions and whatever came out of the interviews.

Having the idea is easy. Executing it is a whole different story. I needed to figure out:

• who I would recruit for the qualitative interviews;
• how I would recruit them;
• what questions I would ask in the quantitative survey.

For the interviews, it was clear that participants needed to be Nami customers and delivery app users.

I scheduled sessions with 3 Nami customers who volunteered to take part and remotely ran an in-depth interview with each of them to understand their experiences, preferences, and needs. The focus was on uncovering their pain points and how they used delivery apps.

These conversations led to 3 insights and some very interesting quotes:

“iFood’s menu interface isn’t intuitive at all, and it’s frustrating to use.” “I’d like to put together my whole meal at once instead of having to browse each category to build my order.” “I like pretty much Nami’s entire menu, but paying iFood’s prices just isn’t practical. And it’s not like I feel like going to the restaurant every time I want something from there. Sometimes I just want to order from home, but I’m not paying 30% more for the same product.”

From these three quotes, I drew three conclusions:

1. Nami’s app needs to present its products more clearly and intuitively than iFood.
2. A feature to build a complete meal (starter, main course, and dessert) in one go would be a great solution, since browsing each category to pick every item discourages users.
3. Nami’s app is truly needed: the restaurant really is losing delivery sales because of platform fees.

As I mentioned, the goal of the qualitative research was to draw something relevant from customers to later validate alongside my assumptions. That’s why I consider this stage a success: instead of one insight, I came away with three.

With these quotes in hand, I needed to quantify the insights and understand their relevance in numbers. So I created a quantitative survey to complement the qualitative findings, with data that would validate the trends and patterns I had observed.

The idea was to build a form and send it to 10 Nami customers. The goal was to collect objective information, such as satisfaction levels, feature preferences, and usage frequency, and arrive at meaningful metrics to start making decisions and designing the product.

In addition to the 3 interviewees, I recruited 7 more Nami customers who use iFood to fill out the form. And I did it in the most inconvenient way possible: I messaged people who commented on Nami’s Instagram posts.

You’re probably thinking, “what kind of approach is that?” That’s surely what many of those people thought too, since most of them never replied.

For a while, I was stuck in this phase: reaching out to strangers on Instagram, chatting with those who replied, sending the form, and checking in day after day until I finally reached 10 respondents. Once I had all 10 responses, I went to check the results:

From the moment I created the form and started sending it to Nami’s clients until the moment I got 10 respondents, it took about 23 days. Yes, 23 days.

Collecting this information and data was an arduous task and, honestly, much harder than I thought it would be. Those days and weeks seemed endless as I refreshed the results page and saw that I still didn’t have 10 respondents.

To be honest, I even considered continuing with the project without getting those 10 respondents I wanted so badly, but in the end, everything worked out.

With the qualitative research complete, I was able to understand the behavior and pain points of the users of the product I was designing and, above all, collect information to validate them later.

With the quantitative research completed, I was able to validate my hypotheses and the information collected in the qualitative research.

Antes de tudo, eu sabia que iria atuar de ponta a ponta no projeto, e era exatamente o que eu queria. Além disso, antes mesmo de conversar com os proprietários da Nami, eu já imaginava que a grande maioria dos estabelecimentos no iFood enfrentava dificuldades com as taxas cobradas pela plataforma.

Ou seja, comecei o projeto com algumas suposições, e elas precisavam ser validadas. Também queria aproveitar para coletar novas informações e insights que valessem a pena levar adiante.

A solução foi conduzir duas pesquisas: uma qualitativa, para coletar informações e possíveis insights, e uma quantitativa, para validar minhas suposições e o que surgisse das entrevistas.

Ter a ideia é fácil. Executá-la é outra história. Eu precisava definir:

• quem eu iria recrutar para as entrevistas da pesquisa qualitativa;
• como eu iria recrutar essas pessoas;
• quais perguntas eu iria formular para a pesquisa quantitativa.

Para as entrevistas, estava claro que os participantes precisavam ser clientes da Nami e usuários de apps de delivery.

Agendei conversas com 3 clientes da Nami que se disponibilizaram a participar e conduzi, de forma remota, uma entrevista em profundidade com cada um, para entender suas experiências, preferências e necessidades. O foco era descobrir seus pontos de dor e como usavam apps de delivery.

Dessas conversas, saíram 3 insights e falas muito interessantes:

“A interface de cardápio do iFood não é nada intuitiva e é frustrante de usar.” “Gostaria de poder montar toda a minha refeição de uma vez, em vez de ter que navegar por cada categoria para montar meu pedido.” “Eu gosto de praticamente todo o menu da Nami, mas é impraticável pagar os valores que estão no iFood. E não é como se eu tivesse ânimo para ir ao restaurante sempre que quero alguma coisa de lá. Às vezes eu só quero pedir de casa, mas não vou pagar 30% a mais pelo produto.”

A partir dessas três falas, cheguei a três conclusões:

1. O app da Nami precisa apresentar os produtos de forma mais clara e intuitiva que o iFood.
2. Uma funcionalidade para montar a refeição completa (entrada, prato principal e sobremesa) de uma só vez seria uma ótima solução, já que navegar por cada categoria para escolher cada item desanima o usuário.
3. O app da Nami é realmente necessário: o restaurante está, de fato, perdendo vendas de delivery por causa das taxas das plataformas.

Como mencionei, o objetivo da pesquisa qualitativa era extrair algo relevante dos clientes para depois validar junto com as minhas suposições. Por isso, considero essa etapa um sucesso: em vez de um, saíram três insights.

Com essas falas em mãos, eu precisava quantificar os insights e entender, em números, a relevância desses dados. Elaborei então uma pesquisa quantitativa para complementar os insights qualitativos, com dados que validassem as tendências e os padrões observados.

A ideia era criar um formulário e enviá-lo para 10 clientes da Nami. O objetivo era coletar informações objetivas, como nível de satisfação, preferência de funcionalidades e frequência de uso, e chegar a métricas significativas para começar a tomar decisões e desenhar o produto.

Além dos 3 entrevistados, recrutei outros 7 clientes da Nami que usam o iFood para responder ao formulário. E fiz isso da forma mais inconveniente possível: mandei mensagem para pessoas que comentavam nos posts da Nami no Instagram.

Você deve estar pensando: “que tipo de abordagem é essa?”. Com certeza foi o que muitas dessas pessoas pensaram também, já que a grande maioria não respondeu.

Por um tempo, fiquei preso nessa fase: abordava desconhecidos no Instagram, conversava com quem respondia, enviava o formulário e acompanhava dia após dia, até finalmente chegar aos 10 respondentes. Quando consegui os 10 formulários respondidos, fui conferir o resultado:

Do momento onde eu elaborei o formulário e comecei a enviar ele para os clientes da Nami até o momento onde eu consegui 10 respondentes, foi cerca de 23 dias de prazo. Sim, 23 dias.

Coletar essas informações e esses dados foi uma tarefa árdua e muito mais difícil do que eu pensei que seria, honestamente. Foram dias e semanas que pareciam intermináveis quando eu atualizava a página dos resultados e via que não havia 10 respondentes ainda.

Sinceramente, cheguei a cogitar continuar com o projeto sem que eu conseguisse esses 10 respondentes que eu tanto queria, mas no final, deu tudo certo.

Com a Pesquisa Qualitativa completa, eu havia conseguido entender o comportamento e as dores dos usuários do produto que estava projetando e acima de tudo, coletar informações para validá-las posteriormente.

Com a Pesquisa Quantitativa finalizada, eu pude validar minhas hipóteses e essas informações que foram coletadas na Pesquisa Qualitativa.

When I say that “I would have to turn this into the foundation of the project and start defining a few paths to follow,” I mean two things:

1. turning the collected data into more tangible information;
2. getting a brief understanding of the market Nami operates in.

How could I turn the collected data into more tangible information? Through Empathy Maps, a Persona, and a User Journey Map. And how could I understand the market Nami operates in? Through a brief Benchmark.

Empathy Map and Personas

Using the stories, comments, and information I gathered in the qualitative interviews, I built an Empathy Map for each user I interviewed. The idea was simple: make that information easier to visualize.

User Journey Map

As I said before, I needed to “turn the collected data into more tangible information.” The Empathy Maps helped me see and understand my interviewees as a whole. The Personas helped me define the profile I would be designing for, addressing their pain points and needs. But what would really help me make tangible the experience of ordering from Nami through other apps was the User Journey Map.

I needed to understand and make visible, as a whole, a user’s journey when ordering a meal from Nami for dinner. To do that, I planned to:

• choose one of the personas to map the ordering journey on iFood, based on the data from the user research;
• map every action in the journey, from opening iFood to receiving the order;
• map the user’s mood at each stage;
• map what they’re doing, thinking, and feeling at each stage;
• map the pain points they face at each stage;
• and finally, identify opportunities for improvement at each stage.

Benchmark

Next, I ran a Benchmark to analyze and compare other food delivery apps.

First, I collected and analyzed the reviews and ratings of each app on both stores (Google Play and the App Store) to understand users’ impressions and experiences.

How did I choose the apps? The criteria were being a Japanese restaurant’s app and having at least 10 reviews, whether positive or negative. I could have been broader and analyzed restaurants of any kind, since the main goal was to study independent platforms. But I chose to focus on Japanese restaurants for two reasons:

• they compete in the same culinary segment;
• they make it possible to compare how information and dishes are presented, which will inevitably be similar among direct competitors.

With the criteria set, I picked 3 platforms, then downloaded and used each one to experience it as both a new and a returning user. After that, I put together a simple, objective chart with an overview of my conclusions and experiences with each app. This gave me a comparison of all the products analyzed alongside Nami’s projected app.

Comparing the platforms, a few points stood out:

1. All of them offer lower prices than on iFood. That’s no surprise: it’s the same pain point we’re solving for Nami. It’s natural to assume this problem affects all of these restaurants and was what pushed them to build their own apps.
2. All of them offer free delivery. Also expected. Without a 30% fee on every sale, there’s room in the margin to offer this kind of benefit.
3. The platform with the best interface and navigation is the highest rated by users. If I had to venture a guess, I’d say that, among the apps analyzed, Sapporo’s was the only one designed by a specialized designer. The difference in navigation between it and the other two is striking.
4. Key points validated in my research, such as promotions and customization, were overlooked by every platform. That’s great news, because it opens room for a Nami differentiator, especially with the “Build Your Meal” feature.

Quando digo que “eu teria que transformar isso na base do projeto e começar a definir alguns caminhos para seguir”, me refiro a duas coisas:

1. transformar os dados coletados em informações mais tangíveis;
2. entender, de forma breve, o mercado em que a Nami está inserida.

Como transformar os dados coletados em informações mais tangíveis? Por meio de Mapas de Empatia, Persona e Mapa de Jornada do Usuário. E como entender o mercado em que a Nami está inserida? Por meio de um breve Benchmark.

Mapa de Empatia e Personas

Com as histórias, comentários e informações que obtive nas entrevistas qualitativas, montei um Mapa de Empatia para cada usuário entrevistado. A ideia era simples: tornar essas informações mais fáceis de visualizar.

Mapa de Jornada do Usuário

Como disse antes, eu precisava “transformar os dados coletados em informações mais tangíveis”. Os Mapas de Empatia me ajudaram a enxergar e entender meus entrevistados como um todo. As Personas me ajudaram a definir o perfil para o qual eu iria trabalhar, resolvendo suas dores e necessidades. Mas o que realmente me ajudaria a tornar tangível a experiência de pedir da Nami por outros aplicativos seria o Mapa de Jornada do Usuário.

Eu precisava entender e deixar visível, como um todo, a jornada de um usuário ao pedir uma refeição da Nami para o jantar. Para isso, planejei:

• escolher uma das personas para mapear a jornada de pedido pelo iFood, com base nos dados das pesquisas com usuários;
• mapear cada ação da jornada, da abertura do iFood até a entrega do pedido;
• mapear o humor do usuário em cada fase;
• mapear o que ele faz, pensa e sente em cada fase;
• mapear as dores que ele enfrenta em cada fase;
• por fim, identificar as oportunidades de melhoria em cada fase.

Benchmark

Em seguida, conduzi um Benchmark para analisar e comparar outros apps de delivery de comida.

Primeiro, coletei e analisei os comentários e avaliações de cada app nas duas lojas (Google Play e App Store), para entender as impressões e as experiências dos usuários.

Como escolhi os aplicativos? O critério era ser o app de um restaurante japonês e ter pelo menos 10 avaliações, fossem positivas ou negativas. Eu poderia ter sido mais generalista e analisado restaurantes de qualquer tipo, já que o objetivo principal era estudar plataformas independentes. Mas preferi focar em restaurantes japoneses por dois motivos:

• são concorrentes do mesmo segmento culinário;
• permitem comparar a forma de apresentar informações e pratos, que inevitavelmente será parecida entre concorrentes diretos.

Com o critério definido, escolhi 3 plataformas, baixei e usei cada uma delas para viver a experiência de um usuário novo e de um usuário recorrente. Depois, montei um quadro simples e objetivo com uma visão geral das conclusões e das experiências com cada app. Assim, consegui um comparativo de todos os produtos analisados ao lado da projeção da Nami.

Ao comparar as plataformas, alguns pontos se destacaram:

1. Todas oferecem preços menores que no iFood. Não é nenhuma novidade: é a mesma dor que estamos resolvendo para a Nami. É natural imaginar que esse problema afeta todos esses restaurantes e foi o gatilho para que criassem seus próprios aplicativos.
2. Todas oferecem frete grátis. Também era esperado. Sem os 30% de taxa sobre cada venda, sobra margem para oferecer esse tipo de benefício.
3. A plataforma com a melhor interface e navegação é a mais bem avaliada pelos usuários. Se eu pudesse arriscar um palpite, diria que, entre os apps analisados, o do Sapporo foi o único que passou pelas mãos de um designer especializado. A diferença de navegação entre ele e os outros dois é gritante.
4. Pontos importantes validados na minha pesquisa, como promoções e customização, foram ignorados por todas as plataformas. Isso é excelente, porque abre espaço para um diferencial da Nami, principalmente com a funcionalidade “Crie sua Refeição”.

After a lot of research, analysis, and validation, I wrapped up the Definition stage and moved on to Ideation. For this stage, I set a single task: creating the User Flow.

First of all, I needed at least a rough idea of the project scope and the screen flow, in other words, how many screens I would be designing. The User Flow helps me a lot with that, and it would also help the development team who would eventually take over the project.

Keeping the scope in mind, knowing what lies ahead, and planning for each step is essential, and that’s exactly why I chose this task.

This is the final User Flow. Notice that it uses 4 colors:

• White: introductory pages;
• Dark blue: NavBar buttons and the main screens they open;
• Light blue: extensions of those screens;
• Red: only the Splash Screen, since it’s quite different from the rest.

Depois de muita pesquisa, análise e validação, concluí a etapa de Definição e pude seguir para a Ideação. Nesta etapa, defini uma única tarefa: criar o User Flow.

Antes de tudo, eu precisava ter pelo menos uma noção do escopo do projeto e do fluxo de telas, ou seja, de quantas telas eu iria desenhar. O User Flow me ajuda muito nesse ponto e também ajudaria a equipe de desenvolvimento que, no futuro, teria esse projeto em mãos.

Ter o escopo em mente, saber o que vem pela frente e me planejar para cada etapa é muito importante, e foi pensando nisso que escolhi essa tarefa.

Este é o User Flow finalizado. Repare que ele usa 4 cores:

• Branco: páginas introdutórias;
• Azul escuro: botões da NavBar e as telas principais que eles abrem;
• Azul claro: extensões dessas telas;
• Vermelho: apenas a Splash Screen, por ser uma tela bem diferente das demais.

Before starting the tests, a few decisions had to be made. I needed to define:

• how many users I would recruit (or how many I’d be able to recruit);
• which screens were truly essential for the MVP and, consequently, which were worth testing;
• which journeys and tasks users would complete.

And above all, there was a big challenge: how would I recruit these people, meet them, and ask for some of their time to run the tests?

I tested the prototype, still in low fidelity, with 3 users. I scheduled a time with each of them and went to their homes, so the test could happen in a familiar setting, as close as possible to the real moment of ordering food.

I brought two phones: one with the prototype open in Figma and another to record the whole session. That way, I could focus on what each user was doing and review every detail calmly afterward. In each session, I asked them to complete tasks such as signing up for the app, logging in, searching for a specific dish, and so on.

The prototype was fully interactive, but guided by the path of each task. If a user went down a journey that didn’t lead to the goal, a modal popped up on screen with a message like: “We get that you’d come here first, but why not try another option?”

This approach kept users from getting lost in screens that didn’t exist yet and, at the same time, showed me exactly where their expectations didn’t match the flow I had designed. In practice, every modal that opened was a friction point mapped.

Throughout the sessions, I noted every step, every hesitation, and every decision users made.

With all this material in hand, I could finally confirm some decisions, rethink others, and move on to the final stage of the project: the high-fidelity prototype.

Antes de começar os testes, algumas decisões precisavam ser tomadas. Eu precisava definir:

• quantos usuários iria recrutar (ou quantos conseguiria recrutar);
• quais telas eram realmente essenciais para o MVP e, consequentemente, quais valia a pena levar para os testes;
• quais jornadas e tarefas os usuários iriam realizar.

E, acima de tudo, havia um grande desafio: como recrutar essas pessoas, ir até elas e pedir parte do seu tempo para conduzir os testes?

Testei o protótipo, ainda em baixa fidelidade, com 3 usuários. Marquei um horário com cada um e fui até a casa deles, para que o teste acontecesse em um ambiente familiar e o mais próximo possível do momento real de pedir comida.

Levei dois celulares: um com o protótipo aberto no Figma e outro para gravar todo o processo. Assim, eu podia me concentrar no que cada usuário fazia e, depois, revisar cada detalhe com calma. Em cada sessão, pedi que realizassem tarefas como se cadastrar no aplicativo, logar, procurar um prato específico e afins.

O protótipo era totalmente interativo, mas guiado pelo caminho de cada tarefa. Se o usuário seguisse por uma jornada que não levava ao objetivo, aparecia um modal na tela com uma mensagem como: “Entendemos que você viria aqui primeiro, mas que tal tentar outra opção?”.

Essa solução evitou que os usuários se perdessem em telas que ainda não existiam e, ao mesmo tempo, me mostrou exatamente onde as expectativas deles não batiam com o fluxo que eu tinha desenhado. Na prática, cada modal aberto era um ponto de atrito mapeado.

Durante as sessões, anotei cada passo, cada hesitação e cada decisão dos usuários.

Com todo esse material em mãos, finalmente pude confirmar algumas decisões, voltar atrás em outras e seguir para a etapa final do projeto: o protótipo em alta fidelidade.