As our final project for the General Assembly UX Design Immersive, UX designers were paired up with software engineer students to create a responsive website given the following persona and problem statement:
Problem Statement
Amanda needs to use the ingredients in her fridge because it’s convenient and cheaper than going out and buying specific ingredients. How might we make it easier for her to use recipes that require the items she already has?
Feature Prioritization using MoSCow Map
To avoid featuritis and focus on achieving our user’s goal using minimal features, we determined what they would be through MoSCoW mapping. These features informed how we would ideate and design our responsive website. The features that we knew we MUST include in our product are as follows:
Assigning a time estimate to each recipe and only populating recipes that take less than 60 minutes, following our persona’s needs.
Allow our users to plug in existing ingredients or items in their fridge to come up with a recipe.
Create a login / login to account, allowing users to save and edit recipes.
Ideation and Design Phase
Part of the collaboration between the two teams was to teach the developers part of the UX process. To begin, we asked them to join us in a design studio to get ideas flowing. We then did our first round of usability testing using the below paper prototypes.
Main Takeaways
The biggest challenges for the developers was pressing the ‘x’ button and getting an ingredient to disappear and then re-populating a new set of recipes. Another challenge for them was centering said ingredient in the button. Since their cohort experience has been primarily learning functionality, the CSS took them awhile to figure out. The major thing the developers learned was how UX designers do our process. It not only brought out their creative side, but it challenged them to match what we designed. They learned that there is a reason behind why we chose the designs we did.
The major thing the UX team learned from the developers was how to implement an API into a product and how they find which one to use. If an API doesn’t have good documentation they won’t use it. They looked at several recipe APIs but ultimately decided on Edamam because it had the capability we were looking for. We also learned the software Zeplin to handoff our designs and styleguides with accurate specs.