- 18 interviews (2 rounds)
- 12 usability tests
- 30+ screens
- 5 project team
- Role
- UX researcher & designer on the team
- Methods
- Desk research, IDIs, usability testing, design studio, UX/UI design
Waste less, spend less — a home budget app
A concept app for household budgeting — built in a team of five. Two rounds of desk research, two rounds of interviews, two rounds of usability testing. We started with a question about saving money and ended with a different one: the easiest savings don’t take willpower — just knowing what’s already in your fridge.
Desk Research_v.1
We started our project with a literature review and analysis of available reports. We studied materials on financial management, savings, shopping habits, and conscious consumption.
The gathered data shows that the majority of Poles assess their financial situation as uncomfortable, and a third fear it could get worse. Nearly half of the respondents declare choosing cheaper products, and four out of ten people give up pleasures and expenses that are not essential.
More than half of Poles have savings, but as many as 47% of respondents have no financial cushion at all. Those who cannot save most often point to high inflation (42%) and earnings too low relative to expenses (40%) as the main reasons.
First round — finances and habits
We interviewed 8 people. Our aim was to learn about the following areas:
- Spending planning: how often they do it, how they do it, what tools they use.
- Emotions, feelings, thoughts, and issues related to spending planning.
- Saving: methods and tools.
- Conscious consumption: how they understand it and what they do about it.
- Knowledge of and involvement in various types of social initiatives.
What we heard
- 01 / 12
Rent and food eat up most of our budget.
- 02 / 12
Saving always seems to mean settling for worse quality.
- 03 / 12
Budgeting just feels boring.
- 04 / 12
Food is where we could actually save — if we tried.
- 05 / 12
We eat out or order in whenever time or will runs out.
- 06 / 12
Being conscious means not buying on impulse.
After collecting data, we felt that some of the questions remained unanswered. We decided to narrow down the research area and re-examine our discovery stage.
Desk Research_v.2
We decided to focus on food management and shopping habits, as it was one of the main themes that emerged from our earlier insights.
According to the Food Rationalisation and Reduction Programme, we waste 5 million tonnes of food a year. This means that nearly 160 kg of food ends up in the bins every second. Bread, meat, and fruit are most often thrown away.
Main reasons for food waste
Second round — food and waste
We interviewed 10 people aged 26–45. We focused on the following areas:
- Meal planning methods and cooking regularity.
- Shopping planning methods and frequency.
- Shopping behaviour (spontaneous vs. planned).
- Food waste.
- Managing food supplies at home.
What they actually said
- 07 / 12
Throwing food away feels genuinely awful.
- 08 / 12
A shopping list would keep our food and spending in check.
- 09 / 12
Without a list, we overbuy and waste more.
- 10 / 12
We rarely check the pantry before heading to the store.
- 11 / 12
We don’t know what to cook — or we cook the same things on repeat.
- 12 / 12
We shop a few times a week and end up with things we don’t need.
Persona
Based on the gathered data, we created hypothetical personas that became the reference point for further design work.
What’s already out there
After better understanding potential users, we moved on to analysing the competition — both direct and indirect — to see how it addresses the needs we identified.
What we’d actually offer
With a clearly defined user vision and an overview of the existing competition, we defined the value we wanted to deliver to users.
Elevator Pitch
We’re building an app for people who want to cook more often but keep throwing food out — or watching it expire in the fridge.
It helps them buy only what they’ll actually eat and cook with what’s already there.
User-Story Map
We mapped out the interactions that users go through to achieve their goals within our product.
Patterns worth borrowing
Before moving into design, we analysed well-known digital solutions. We drew inspiration from various sources and design patterns to better understand possible directions.
Design Studio
During the design workshop, we iterated and refined our solutions multiple times. In the process, we also created a system of points and rewards to support user engagement and product adoption.
Turn points into discounts
Points earned for activity in the app can be exchanged for discounts in the OK Poznań application.
A badge for seasonal cooking
Every meal cooked with the seasonal vegetable of the month earns you a dedicated badge.
Rescue food, earn a badge
Using a product that’s about to expire rewards you with a special badge — no food wasted.
Stay regular, stay rewarded
Opening the app and cooking consistently brings ongoing loyalty rewards.
Wireframes
Based on the developed solutions, we created wireframes and a simple information architecture. This allowed us to prototype the main user flows and begin testing.
First test — what broke
We examined 6 participants via remote, semi-structured studies. Prepared tasks were made to unfold the experience of proposed solutions.
Example research tasks
"A few of your products can be added to your virtual pantry. Add 4 apples, 2 onions and 1/4 jar of tomato sauce to it."
"You've planned your meals, but you don't want to do all the shopping at once. Make a list of what you need just for today's (Monday) meal."
"You're home, prepped, and ready to cook. Open today's recipe and cook it using the app."
We found 8 concerning errors, which we fixed and tested in another iteration:
- Critical errors 2
- Significant errors 3
- Small errors 2
Barcode scanning
Before
Users noticed that there was no preview of the shopping list; instead of streamlining the shopping process, it was extended (the user had to go back to the list screen and enter the scanning functionality again each time).
After
We added a preview of the shopping list on the bottom sheet, which allowed users to check the list easily.
Finishing cooking with the recipe
Before
Users could not update the system about the state of the dish without using the easy cooking mode.
After
We added a button that allowed users to finish cooking even on the overview of the recipe screen (the button appears if a recipe is planned).
Menu planning
Before
The process of planning required going through two screens. The slider component used as a date picker was unreadable.
After
We changed the flow of the recipe planner; we shortened possible actions and displayed a calendar on the main page.
Adding to the pantry
Before
While in the pantry, participants had problems adding new products; they couldn't find functionality to add new products.
After
We have changed the components we were using for adding products. By using FAB, we have made the action of adding new products visible and always near the thumb.
Navigation on the cooking mode
Before
Not all users knew how to go from one step to the next (SWIPE). Moreover, users felt overwhelmed by the number of actions in the simplified cooking mode.
After
We have added a button that allows users to move between screens. To simplify the process, we dropped additional actions and reworked how the timer behaves.
Meal summary
Before
Users said the happy path required more clicks than they wanted. The summary screen was one of the places that felt overwhelming.
After
We simplified the summary screen view by removing proposed actions and placing them inside notifications.
Second test — what held
We examined 6 participants via a remote, semi-structured study. We found 4 concerning errors:
- Critical errors 1
- Small errors 3
Generating a menu
Before
Users didn't know the difference between an automatic and manual dish planner. Additionally, the manual process was assessed as time-consuming and unintuitive.
After
We dropped the manual dish planner — the choice felt unclear and ultimately pointless, and the automatic planner did everything the manual one did, faster.
What we shipped
After many iterations, fixes, and polishing of details, we brought “Spiżarnia” to its final version.
Looking back
What I Learned
Story mapping turned out to be a pivotal moment in the project — laying out the entire user journey on a map helped the team see the product as a coherent whole rather than a collection of separate screens. This exercise clarified priorities and gave us a shared language for making scope decisions.
Complex functionality must be hidden behind one obvious action — replacing several scattered paths for adding products with a single FAB eliminated the most common point of confusion in testing.
What I Would Do Differently
I would start with a narrower research question. Our first round of research covered the entire topic of personal finance — it was only the interview insights that revealed the real problem lay in food management. Had I formed a hypothesis earlier, I would have saved the team time. The second thing is testing iterations — we introduced six changes at once before the second round, which means I cannot definitively say which fix accounts for which result.