Menu Zamknij

Prepare a tasty meal based on the products you already have.


Prepare a tasty meal based on the products you already have.


Please note

The project was designed for Polish users, therefore wireframes are in Polish.

My role

  • Designing prototype and the final product.
  • Designing information architecture.
  • Running user tests.


Problems to solve

  • Meal monotony.
  • Throwing food/products away.
  • Creating an enjoyable meal often requires additional products.

The User

The main user of the application:

  • Cooks at least twice a week
  • Looks for new recipes online or in apps

The expert user (early adopter):

  • Occasionally experiments in the kitchen.
  • Cooks large meals at least 3 times a week.

Personas description (in Polish).


Activities / Objects / Features

With the AOF tool, I defined key functionalities which will enable the user to perform specific tasks in-app.
List of general user's tasks:

  • entering the available ingredients to the app,
  • choosing the dish,
  • finding a dish that has been previously cooked,
  • adjusting the recipe to the quantity of available products,
  • cooking while using a smartphone.

User Flow

In order to describe the steps that the user will go through when performing a specific task, I made a few User Flow variations. App sketches created earlier were helpful in defining User Flow

Final user flows.


Designing a Flowchart helped me control the progress of prototype development. Also by creating Flowchart I came up with some hypotheses, that were later tested with the users.

The app structure presented as Flowchart.



In order to run usability tests, I created a low fidelity wireframe of the app. The wireframe had basic interactions that enabled me to test different user paths. All screens were designed in the Axure RP and tested on smartphone using the Axure Share on Android.

Wireframe used in usability tests (screens in Polish).

Usability Testing

I used low fidelity wireframes to perform the tests. The goal of this phase was to test how the user will handle:

  • the process of entering available ingredients to the app,
  • going through the cooking process divided into steps,
  • the process of calculating ingredients by portion,
  • adding and searching for favorite dishes,
  • when the application does not find results from the specified components.

For the test, I selected users who:

  • cook at least twice a week
  • look for new recipes online or in application

Problem found:

  • the most difficult activity for the user was entering available ingredients

The Problem and its solution

During the User Tests, the most difficult activity was entering the ingredients they currently have (ingredients can be hidden in various cabinets and may be overlooked). Foreseeing such difficulties, I designed a hint module on the first screen, with some basic ingredients. However, this approach caused problems with finding the search function. Moving the search bar above the hints made the hints unhelpful (everyone used the search engine right away).

After another series of tests, the screen was redesigned leaving the search bar on top and hiding the hints as autocomplete items (showing hints when the user taps on the search bar). This design, besides running another series of tests, was checked with a 5-second test. The test also allowed to check what the main application screen is associated with. In most cases, the application was classified as the culinary application. The search bar with hints placed in autocomplete seemed understandable, which was confirmed by further User Tests

In order to even better solve the problem with difficulty in entering ingredients, I designed additional hints with common entered ingredients and a barcode reader as an alternative method of entering products.

Different approaches to solve the problem (screens in Polish).

Net promoter score

During the final series of tests, I asked the question "How likely is it that you would recommend the product to your friends?" It is a phrase used to measure satisfaction with the NPS (Net Promoter Score) scale. Of course, due to a small research sample, NPS was not a determining indicator, but only a hint. 83% of the respondents answered 9 or 10.


Graphic design

With all usability issues resolved, I proceeded to design a high-fidelity prototype. Because the app will be developed for Android, I used the Material Design system because it is recognizable and intuitive for owners of Android devices. For the high-fidelity prototype, I used Axure with a library containing Material Design components.

User interface in Material Design (screens in Polish).


When I started this project, elements that initially seemed to be very important, later in the usability tests became irrelevant or less important than I thought.

The design process was different from the original one. Changes were caused by conclusions that appeared during each phase.

Running a lot of usability tests made it possible to create an intuitive and simple product. Focusing on user testing helped deal with the biggest problem, which was difficulty in entering ingredients.

Adam Klimas
Adam Klimas
Get in touch