Every Saturday my dad had sat down at the kitchen table with the local grocery ads and a binder of printed recipes. He’d sit there for hours at a time, pouring over the ads and comparing them to his recipes to see what we could afford to eat that week. This work ate into his limited weekend time, so I decided to design a tool to help him out.
To reduce the amount of time needed to plan, I had to know what the root cause of the duration was. I sent out a survey to better understand the meal planning process and conducted interviews with comparative user tests to learn the details of the problem and where the available solutions did not satisfy those needs.
Problems
- Paper recipes have limited organization & no search
- Hand-copying shopping lists is slow & laborious
- Finding new recipes on websites is overwhelming
Solution Needs
- Multifaceted & searchable organization
- Fast, low-effort shopping lists
- Straightforward recipe discovery
My first attempt at a design that satisfied those needs was colored by my own preconceived notions about what a meal planner was looking for. I thought it was about throwing 21 meals onto a calendar, but with user testing I learned that it was really about building on a personal relationship with food.
With the feedback on the importance of curation in mind, I started again with a design that centered around a personal food library, iterating and testing with much better reception from the target audience of meal planners.
I continued to refine the design to satisfy the needs of these users, eventually creating a high-fidelity interactive prototype to flesh out and validate the design. While the design satisfied their needs I didn’t yet have the construction skills to implement it, and in the end a new tool was released that came to many of the same conclusions I had made. I set my dad up with it and he’s happily using it to this day, and I’ve used the research and design experience from this in my projects ever since!