Introduction

During the COVID lockdown in Denmark, my girlfriend and I got quite into making homemade pizza. The nerd within me wanted to take this new hobby to the next level so I decided to do some research. 

I quickly got recommended an app that could help me calculate my recipe in terms of preparing the dough, ingredients, and dough resting time.
The app is called PizzApp, and works extremely well for doing the calculations. It gets my highest recommendations, and it made us some amazing pizza! 

While using it, I couldn't hold myself back from noticing the “not-so-modern” UI, and quite unintuitive interactions. Meanwhile, I was in a period where I wanted to do some kind of personal project where I could focus on styling and animation - and especially playing around with the prototyping software Protopie. 

This post is about how I combined two different hobbies: pizza and product design. Not a big case study for a major company, just something for the fun of it 🍕

Role 
I made everything from research to the final concept

Company
100% a personal project. No connection to the company/person that made PizzApp

Time period
December 2020 

Problem

Since my main focus was on style and animation, I still wanted to fix some of the problems I found while using the app. 

Here are the main headaches I found while trying out the app for the first time: 

• Nerdy terminology
  
  The app is generally using quite advanced words that are only known by people who are deep into the field of homemade pizza. This makes it hard for new users to understand everything. This could for example be the way the app communicates different yeast types, where they are using abbreviations but not explaining the meaning of it in the UI. You have to dig in the hidden menu to find an explanation overview of all of the abbreviations. 

• No onboarding
  When launching the app for the first time, it takes you directly to a screen that has a very complex form.
  
  From my experience, I thought a simple onboarding flow could help explain the purpose of the form. 

• Promoting the option to save recipes
  
  The app has a great feature where the user can save recipes for later use, and also document pictures of the final baked pizzas. But it’s quite hard to find this feature, and I thought this was a shame.
  
  Going back to the previous problem regarding onboarding, I had an idea that both of these problems could be solved by changing the way users experience the first time they launch the app. More about that later…

So let's try to see how these problems could be solved

Research

Normally I would spend quite a lot of time figuring out the user needs, and trying to understand how they use the product and user jobs… But since the main focus is to increase the overall look and feel while trying to solve some personal problems I found, the research is focused a lot on looking at competitors for inspiration.

With that mindset, it helped me find new ways of doing specific interactions, but it also got me to reflect on solutions that I find confusing and thereby not making the same mistake. You could call it a mini “UX case study”.

Mini case study of the: Onni Pizza Ovens

Try out the app for yourself here

Instead of taking you through all the findings, I want to show some examples. Process wise, I documented all findings in a Notion document, where I took screenshots of the main interface and added small notations for each finding.

You can find the document here - and I’m sorry but everything is in Danish, it was supposed to be my personal notes. 

The main focus was on the recipe calculator in the app since it’s the same feature as the PizzApp. 

Example of findings: Missing feedback on inputs

Since the feature is built around the calculation of the recipe, I found that the user input on the form was quite difficult to follow along with the recipe changes, since the recipe box is placed so far down on the screen. 

This would be an even bigger problem on smaller phones than mine. 
I wanted to incorporate a solution to this in combination with all the other findings. 

Feel free to dive deeper into the findings, or even try the app for yourself. But now, let’s take a look at the process for my solution!

Process

After finding some kind of overview of which things I wanted to solve in this little project, I documented the primary goals in order to be clear on the objective. Something I like to do in any kind of project, so I have the possibility to go back and check if I’m on the right path. 

Main goals

• Help first-time users and pizza beginners understand the variables that goes into making pizza

• Give more attention to the feature of saving your recipes, (hopefully) increase usage and avoid having the user type the same things multiple times

• Optimize the usability of the recipe form 

Let the sketching begin

On almost all my projects I love starting with doing some low-fi and ugly sketches, to prevent myself from coming up with a solution too soon. Currently, my preferred tool is using my iPad together with an Apple Pencil and the app Notability.

Navigation (from burger menu to tab bar)

My first thought was that I wanted to make it more clear where the user was while using the app. Since one of the goals was to promote the feature of saving and storing recipes, I wanted the recipes to have a clear and upfront placement in the navigation.

But since the current navigation was in the (quite small) burger menu at the top, I wanted to add a more mobile familiar navigation: The bottom tap bar. 

Adding established navigation to the app also required me to understand and apply the best practices for this navigation type. Here I decided to lean on Apple’s documentation in their human interface design guidelines. 

By considering and sticking to the rules: 

• Make sure the tab bar is visible when people navigate to different areas in your app.

• Use concrete nouns or verbs as tab titles. 

Introduce the recipes list from the beginning and add onboarding

To give more attention to the “save recipe” feature, I decided to make the list of recipes on the main and first screen in the app. Hereby the user will see this when opening the app for the first time. But since the user wouldn’t have any recipe from the beginning, the empty state ends up being important for the introduction and understanding.

The feeling I had, regarding being overwhelmed when jumping straight into the recipe form, was still there. This made me consider adding a step in between to soften the information load for the user.
I saw this step as a small onboarding flow into the feature, and I, therefore, figured out which information and inputs it should include. 

When configuring your pizza recipe there are some primary variables you have to input and some secondary variables. These could be spilled up by the following: 

Primary

• Number of pizzas

• The total time you got for resting the dough

Secondary

• Style (Neapolitan or Roman)

• Hydration and salt percentage

• Total weight of each ball 

• Distribution of resting times by normal or cooled temperature

• Yeast type you’re using (or have access to) 
  

This gave me a good starting point to figure out which inputs should be used in the onboarding, and which could be placed in the form afterward. The focus was to have everything configurable in the form afterward by giving the primary inputs more attention. 

Since the “time you got for resting the dough” is two variables combined: 

1. Resting time at room temperature
2. Resting time at cooled temperature

I still wanted to ask a more “normal” question to the user, and let the app come up with a suggestion on how the total time should be divided into the two variables. Generally, the majority of the resting time is cooled, and then you take the dough out to room temperature a few hours before the pizza baking starts. 

Therefore, I decided to add a small feature to the app, where it takes the user’s inputted total time and divides it into a percentage for each variable. It’s always something the user can change themselves afterward. 

Optimizing the recipe form

Whenever I have to work on a feature that is form-input-heavy, I always like to ask the following questions: 

• Can something be removed or combined?

• For each input: How can this be optimized for its input type and accessibility?

• What’s the default state, and can we come up with a better guess of what the user wants to input? 

To collect my thoughts on this, I took every input and information on the form screen and started categorizing inputs into fellow groups, brainstorming on how each input could be optimized for input, and thought of additional information that could make sense to show. 

I collected everything in a Notion document to have the full overview. 

The main takeaways were to add keyboard support for all inputs, and also make a more logical grouping of information and inputs.

Sidenote: I thought about making input suggestions above the native keyboard, whenever the user activated an input. It didn’t make it into the final concept, but I still think it would be cool. 

One of the main findings of the mini-case study was the importance of having clear feedback when inputting something into the form. With adding the short onboarding flow, the insights about feedback, and the goal of having a clear focus on the form… 

I then got a crazy idea…

What if the form was the first thing the user saw after creating a recipe, and then the recipe animated into the frame as if the app had processed the user's input and made this custom recipe for them? It could even be designed as a paper receipt. It sounded crazy in my head, but I had to sketch it out and see if it would work. 

Afterward, I thought about where that idea may have come from, and then it occurred to me that MobilePay (a Danish money transfer app) does something similar when you complete a transfer. 

It’s time for pixels

After figuring out the structure and main flows, it was time to build the UI and also experiment with the animation for the recipe paper receipt. 

At first, I had to find an overall style before making all the components. One of the tools I use for such tasks is creating moodboards, so I decided to give that a try. I also wanted to find inspiration for the form styling, since it’s the core of the app. 

After this I wanted to understand how a paper receipt is structured, in order for me to have some inspiration for making a digital version later. Here are some screenshots from the moodboard: 

Filled with inspiration, I started making each screen, a component toolkit for all the form elements, and figuring out the animation transitions for the prototype.

Low fidelity wireframing

My focus here was to figure out if the idea would work on the phone screen and onboarding dynamics and navigation.

While making this, I connected all the screens so I could click through them. Once I tried the wireframe for the first time, I realised that the paper receipt had to have two versions: Full and compact. 

Since the form is scrollable, I couldn’t make the full version sticky all the time - it would just take too much space from working in the form. So I added this compact version so that the full version would transition when the user scrolled or wanted to change the inputs. 

High fidelity design

This is where all the styling comes into play. I wanted the overall design to yell “PIZZA!” (get the reference?). It took some time to get the paper receipt just right. I had to work a lot with the texture, font composition, tear marks on the bottom, etc. to make it feel somehow realistic.

Components

Onboarding screens

Recipe form (start and scrolled state)

Save recipe dialog

Adding animations and transitions

Up until this project, I wanted to try the prototyping tool Protopie - so I thought this was the right time to give it a go!

This is where I worked on the transition going from onboarding to the form.

It quickly occurred to me that I had to enhance the transition with a small delay after reaching the form, to prevent it from having a million things happening at once. 

I also added some friction to the paper animation, to make it feel like it’s either sliding on the background or coming out of a machine. 

Start screen - empty state for recipe list
A clear call to action, and design that communicates what the user can expect to see on this screen after they make and save recipes. 

Onboarding - How many pizzas and how much time do you have? 
Clear and simple questions, with support for keyboard input (it’s important to only rely on stepper control since the user in some cases has to click a lot to get to the desired number) 

Transitioning from onboarding to recipe form 
A smooth transition that presents elements in short steps. First the form and then the recipe created by the app.

Scroll transition
Navigation from the full recipe paper to a compact version on scroll. Which gives more space for the user, and clicking on it takes them back to the full version. 

Having a sticky compact version makes it possible for the user to see how the recipe changes when they change the inputs.

Save recipe
A custom dialog with a summary of information so the user can confirm it’s correct, and the option to give it a name. 

List of recipes
Showing the most important information (Type, number of pizzas, total resting time, etc.), and with a clear call to action to create new recipes. 

Learnings

Having personal projects where you just try to explore and get to express your creativity, are not necessarily the projects where you learn the most about processes. But I still had a lot of insights while creating this, that I afterward have used in other projects. 

Protopie
Getting the chance to explore the software and getting familiar with the tool, really makes me more confident that I can use it for projects in the future, where there is a need for more complex prototyping. 

Let your creativity run free
I often get caught up in “following the correct process”, “data-driven and evidence-based decisions” and “we have to do it the right way”. It was a relief to just make something. To just nerd out a small animation or get the styling perfect. It felt like all of the build-up creativity just got released all at once. It’s something I will try to do more in the future!

Adopting platform conventions can make a product feel more… fitted. 
Adding the tab bar and using normal app conventions really can make the difference when you want to make an app feel more platform native.