Discovery case study

The CLIENT

Patrick Moulton, founder of Taystr, invested several months into developing an app for finding the best dishes around.

While staying in Indonesia, Patrick took his time to find the best design and dev team to accomplish an effective product. The team was organized, delivered in time for sprints, and managed to create good quality designs and a functional app.

Yet, five months after having spent time and money to launch Taystr, only he and his girlfriend were using it.

Why isn't anyone using
the app if it works?

How come it’s hard to find a dish?

How come the team didn’t anticipate these problems?

The CHALLENGE

When we heard his story, we suggested our Product Discovery process. We emphasized that he’d get to test the ideas before taking on any major work in design or development.

For clients who’ve been through a bad experience, knowing that there is a better way to manage the risks of building an app is a relief. However, there are always doubts regarding the quality of the result.

The Product Discovery process is a way to build long-term partnerships with our clients. We use an iterative and structured methodology to guide them through the high-risk decisions and features. Every client who’s done a Discovery with us can’t imagine working differently ever again.

The Product Discovery process is a way to build long-term partnerships with our clients. We use an iterative and structured methodology to guide them through the high-risk decisions and features.
Every client who’s done a Discovery with us can’t imagine working differently ever again.

Trying to find the exact dish you want is HARD. There are a ton of options out there: Uber Eats, Rappi, Grubhub, and more. Yet, none of them focus on dishes. Patrick explained that this was his biggest frustration while living as an ex-pat and digital nomad and why he originally built the app.

People are using more than one app at a time to find something to eat

The premise sounded simple: you can find reviewed dishes on the platform. The app allows you to find restaurants, dish specifications such as ingredients and ratings, and also review the dish yourself once you’ve eaten it.

"It should work for everyone, but I feel people who travel and love good food will be using it the most. They are the ones who don’t have a clue about what there is to eat. Sometimes the most authentic food is off-the-beaten-path, and I know I’m missing out when I'm in a new city.”
‍

Patrick Moulton, Founder of Taystr.

Despite having a focused goal, the app hadn't gained traction. Patrick felt there were two breaking points in his app: when searching for something to eat, and when reviewing an experience.

"How can we make people who are eating WANT to rate and upload pics of the dish?"

Taystr's sweet spot has everything that all the other apps fail to accomplish.

The Process

In our Kickoff meeting, Patrick demo-ed the current app for us. He explained the process that led him to build the app the way he did and where he thought it failed. When we were listening, our goal was to find:

What the core problem was

How people solved it NOWADAYS (without the app)

This step might be one of the -if not the most- crucial in our process. Empathetic problem solving is at the core of every successful product. To have success, we need to understand the problems users face. There is no other path.

"Have you ever been at a 4- or 5-star rated restaurant but had the absolute worst food?”

This is how Patrick laid out the problem. Finding good dishes is often unrelated to what a restaurant's rating is. And there isn't an effective way to solve it today.

"Have you ever been at a 4- or 5-star rated restaurant but had the absolute worst food?”

This is how Patrick laid out the problem. Finding good dishes is often unrelated to what a restaurant's rating is. And there isn't an effective way to solve it today.

To find a way to measure the effectiveness of any solution for Taystr's core problem, we created a Product Funnel. We translated the User Journey steps into measurable actions users take when searching for, selecting, and rating a dish.

User Persona

User Journey

Integrating all the actions into the Product Funnel was tricky due to their synchronic characteristics. Some actions like checking if the restaurant’s open and reading about the dish take place at the same time.

After refining the funnel: we determined the actions that marked the start and end of the funnel, which gave us our Success Metric.

We asked ourselves: is dish creation really the most important screen for most users of the app? Is that where all our energy needs to be for this app to work?

Product Funnel

Success Metric

We explained to Patrick the importance of identifying the riskiest screen: the idea that most user activity and value generation happens on one screen for any given app. Have you noticed how Youtube has a great video player, but the view history is kinda meh? Or how Airbnb has a breathtaking list of places to preview, but reviewing a rental it’s a bit meh as well.

That’s because they know where to place the effort.

the strategy

We presented two strategies for dish creation, but Patrick realized that we needed to change the focus. Even though the biggest problem was to get people to upload reviews, maybe the focus should be on how people were using reviews to find dishes.

The next day, we had a new strategy, and we called it the Universal Menu. And suddenly, it was clear to us that describing a dish you’d want to find or eat was essentially the same as reviewing a dish you’ve eaten.

With a strong proposal for the riskiest screen, we focused on the necessary screens to get the results for our Success Metric.

If we followed our Discovery process by the book, we’d need to put all our efforts into creating UI screens and the prototype for the Usability Test. However, Patrick had concerns regarding the branding of the app. He worried about making it stand out relative to other review apps.

We took it and adjusted it, but this process caused lots of friction due to the pressure to stand out from the competition. In this discussion, we insisted that even though unique branding totally makes a product, our special sauce was the “search dish” feature itself. Then a realization hit: our biggest competition wasn’t order-in apps, but recipe apps.

Taking cues from recipe apps, we managed to polish the branding and deliver the first iteration of the UI/prototype to Patrick.

THE Results

Having the prototype ready, we did a round of practice interviews with the team and then with Patrick to teach him how to do the interviews. Patrick invited his partner to participate in a UX Test, and we rehearsed the interview with them so he could see the script in action.

“We know some of the questions we’re asking are going to be silly or not obvious. Don’t worry, if something fails or is hard to do, it’s the prototype, not you.”

We interviewed Patrick's partner, showing the results feature by feature, reflecting whether each decision we made was successful or not.

Each element of the app is directly related to a question, and each question relates to an assumption about a user’s need. There are even some questions that the prototype didn't have an answer for, but we asked them anyways to validate if we were on the right track.

After conducting 12 interviews, about 70% of the questions didn’t reach success. However, the first three major steps of our product funnel were clear wins, and everyone could get through the prototype. Those first three steps were the basis of the Universal Menu as a strategy, the most innovative and riskiest part of our proposal.

We were able to innovate, deliberate, and validate the app in just under three weeks.