iOS Recipe Converter

Role

UX Designer

Project Goal

Through a prototype of 36 screens, it was discovered that to maintain interest in learning to create recipes, the problem flow illustrated a constant tendency require the user to take action on disclaimers. That requirement needed to be re-evaluated. The project consisted of an iOS app, pictures, but mostly disclaimers. A new direction was needed and was agreed upon by the other UX designers on the team.

Situation

It would not be possible to take a step by step on checkbox disclaimers. The goal is to get through onboarding in as fewest mobile screens as possible.

Assumptions

The 1:1 consultation model won't work in this model. This mobile app required collaboration on the assumptions to be made. What was going on back in the original design thinking?

Gluten-free use case

Gluten allergies uncovered the need for more options in the recipe creation space. The design decisions that brought the app to the iOS store where unavailable. The function needed to cover a few bases:

• to ensure people were exploring the possibility of new ways to make the same recipes
• searching for recipes on the web
• stick to this specific app for the above over going to Google, for example

So before starting work, the following were completed in at least one, or just one iteration: Created, designed and developed to launch to the Apple App Store

Emphasizing "at your own risk" style disclaimers. I then created wireframes and prototypes to look at why that was necessary as a priority over function.

Current State

Despite having a solid start, the Apple store data revealed an immediate need to manage the rate of uninstalls. The people were not getting what they were looking for.

Problem

This project was introduced mid-cycle and well after being deployed to the app store, so it was necessary to trace out the current user flow. What numerous steps in the current flow are also hold-ups for the user? Critical for the stakeholder was to lay down disclaimers everywhere.

How might the action look to a gluten-free buyer of the substituted product when it is already a familiar ingredient? Does it follow a natural flow instead of getting caught up in a checkbox loop? Is it restricted by having to use a mobile-sized screen?

Taking action

Exploration might be taking too long. It is offset by the dent in disclaimers in the hierarchy. Glancing at the food pictures, it is obvious they are outdated.

Solution

The short answer is persona research.

"Why not just googling it?" - a user test interviewee

If the main players in this project are photos and exploration, how might I use generate more engagement (and less uninstalls)? With plans to make advertising a viable business direction or with partnering with top swapped products, is the attention to disclaimers justified or obtrusive given the circumstances?

User is busy with just enough motivation to make their own recipe. I needed it to distinguish the App flow from an Instagram page from a product with the same information. What actions does the current app library of recipes allow?

One scenario we workshopped had this in common: You are at home, busy, and decide to take on cooking the same meal a different way.

Design

Through a UX team collaboration, we assessed that using pictures helps us to explore recipes in other similar apps, I was able test that hypothesis in an informal team workshop.

Disclaimers, on the other hand, lures-me not. Recipes let you learn how to put it all together in the kitchen. Initially, the work made the team hungry. Contributing a first recipe needed to be just as intuitive.

What do Disclaimers do?

• Combine sessions for disclaimers.
• Let the priority remain learning to use the app.

Disclaimers inform. If needed, they let you approve and re-approve actions before you get the chance to try it out.

Action Hierarchy

To facilitate moving beyond the initial screens for the mobile iOS version, it was known there would be no back button. Placed at the bottom right was the primary action button. This is especially important in the onboarding sequence, where there was a built in requirement to create a first recipe to continue exploring the app. The implied hierarchy was this: you can do no more with your new shiny app if you don't create at least this one recipe (even if you have to import it from somewhere else).

Pictures

Onboarding means: Get the user to upload **while** they are onboarding.

Pictures in the flow does not draw this out successfully. Part of the vision was a sketch depicting exactly this first part of the process on mobile. The sketch part also brought to light: What if the user does not take the 36 screens pathway at all? It is a long way to a finally-cooked real meal. A successful flow within the app can be initiated by being inspired to action by the quality of the pictures.

Exploration

Many of us learn visually. A priority is to have the user upload images as part of the first action on the onboarding process. In tracing the initial flow, the first user input was not self-perpetuating and needed a look at what the user was initially there for. The final plan consisted of a wireframe and user flow, yet the fun was in what it told about the product. What was needed to keep the user exploring the app in this mobile app.

Cut down the time required to learn the various steps.

Every photo becomes normal food-photo lighting plays a role for user exploration.

With the newly-installed app, cook something from scratch.

Trying splitting up your work into following a recipe. It is important to address this effort because patience is limited.

In the span of 3 weeks, onboarding meant awareness of time within short deadlines, while questioning motivations for repetitious tasks.

Mobile App Design

June 2020