My role
I conceived and created this project during my User Experience Design course with General Assembly. I was responsible for identifying the problem and creating a hypothesis through user interviews, determining an effective information architecture, and iterating on a visual design to help users achieve their goal. Finally, I validated my decisions via usability testing with a clickable prototype.
The users
The target audience for this project is individuals who are learning to cook for themselves for the first time. These individuals are frustrated with the lack of knowledge they have in this domain, and tend to feel ambiguous about the act of cooking—meaning that they neither love, nor hate the activity. Often times, the mere act of completing a meal successfully brings a feeling of accomplishment, and even joy. The individuals in our target audience will also have access to smartphone, tablet, or laptop, and usually rely on these devices while cooking.
The problem
Beginner home cooks need a way to learn to cook for themselves without the time and financial investment of culinary school, cooking classes, cookbooks, or cumulative hours of Googling. Most home cooks work during the day, and don’t have time to research complicated techniques before cooking their meals when they arrive home for the night.
The hypothesis
I believe that by creating a centralized, self-guided learning platform for beginner cooks to educate themselves at home, Sous will be able to lower the barrier to entry for these individuals to create expertly-crafted meals that they will proud to eat. I will know this to be true when newer cooks become active users of the app, and start to feel comfortable attempting more complex cooking techniques on their own.
Discovery phase
The discovery phase for this project involved interviewing potential users to identify the problems they experienced while cooking at home, and conducting competitive research to determine where Sous could potentially fit into the competitive landscape. I boiled down my findings in the form of a persona to help guide my decision-making process into the next phase of the project. These findings culminated in the problem statement and hypothesis found above.
Key user interview findings
The users interviewed all shared similar problems including a lack of knowledge of cooking terminology, and the habit of only learning new cooking techniques when completely necessary. These users currently use cookbooks and Google for finding recipes. They avoid cooking recipes that seem too complex, and also stay away from recipes that take too long (each individual interviewed worked a full-time job, so time was tight after work). The users are frustrated by the fact that recipes often use vague and confusing terminology, and lack consistency in their formatting across different resources. They also would like to attempt more complex recipes, but do not have the time nor ability.
The affinity mapping diagram to the left breaks down these findings.
Persona
I was able to use my findings from the user interviews to create a persona: Niall Reynolds. This individual's goals while cooking involved creating good habits, learning to differentiate between specific terminology and techniques, and creating a meal with minimal extra effort. He struggles when recipes use terms he does not understand, and when he has no gauge of his performance when cooking. It's also hard for him to find time to learn when he is exhausted after work. Niall feels frustrated at his lack of cooking knowledge, and doesn't hate cooking, but doesn't really love it either. He does, however, feel accomplished when he successfully cooks a meal.
Ideation phase
The ideation phase for Sous involved taking the findings from the previous discovery phase, and beginning to flesh out more of the granular details to start shaping a potential solution to the user's problem. This involved creating several task flows to map out the primary goal of our persona, and the steps he would need take to achieve this goal from beginning to end. I also worked on prioritizing the most impactful and expected features for the users, and determined the information architecture for the solution during this phase.
User flow
I started the process of creating my task flow by asking, "How might we help beginner home cooks get the information they need to more quickly and comfortably follow recipes while cooking at home?" This led to the decision to help the user learn about specific cooking terminology that may cause them to struggle while cooking—this was a major pain-point that came up in my user interviews, after all. From there, I was able to map out a flow for searching for specific terms using the app.
Feature Prioritization
To determine the important features for users, I conducted a feature prioritization exercise. This helped me to decide which features to focus upon to help users achieve their goals. The features that were the most expected from a self-guided learning service that provided to the highest level of impact for users were prioritized first, followed by unexpected and high impact, then expected and low impact, and finally unexpected and low impact. The latter two quadrants were found to be unnecessary, and were omitted.
Original site map
Given my original task flow, feature prioritization, and vision for the potential solution to users' needs, I created the site map seen to the left to determine the initial information architecture for the app. This contained four primary navigation items (home, cooking terms, learning paths, and settings), and drilled down into sub-content for each. I created this site map with the expectation that the IA would change based on user feedback attained in an open card sort.
Open card sort results
To better understand how users would group content themselves, and how they would expect to navigate the app, I conducted an open card sort using the items identified through my feature prioritization. As seen in the similarity matrix and dendrogram to the left, the feedback I received indicated that users found cooking terms and learning paths to be similar enough to be grouped under the same category, while also combining several of the items into what I would come to call the "Explore" section of the app.
Revised site map
After deciphering the results of my cart sort, I created the newly revised site map seen to the left. Since the card sort yielded a fairly different structure from the initial site map I created, this encouraged me to restructure my information architecture into four new primary navigation items (explore, search, favorites, and settings). I decided to focus the "explore" section on learning paths, so that users can learn about specific courses that appeal to them. Additionally, I decided to display results for both cooking terms and learning paths in the search tab to give users users the option to view a quick result or deep dive into a full course.
Design phase
After iterating on the structure of my app in the previous phase of the process, I was ready to move onto the design phase. I started off by creating paper wireframes before steadily increasing the fidelity of the designs to the point where I had a clickable prototype that could be tested with users. Once I got feedback from these individuals, I iterated on my designs a second time before arriving a high fidelity version that I could present to my stakeholders.
Paper wireframes
I started off using paper and pencil to flesh out some ideas for the general layout of the app, and to help avoid falling into the trap of pushing pixels around the screen. I chose to wireframe three of the primary screens that would provide the most benefit towards helping users achieve their goals—the explore screen, the course detail screen, and the search results screen—keeping in mind the patterns and guidelines for designing for iOS.
Low-fidelity wireframes
Once the general layout was nailed down, I was able to move to digitizing my designs using Sketch. I intentionally kept this design at a lower fidelity to allow myself to more rapidly iterate, while helping my stakeholders focus on the important aspects of the design: the layout and general flow. If the fidelity was too high at this point, the stakeholders may have gotten too caught up in the fine details, and could have lost focus on the goal of this step.
Low-fidelity prototypes
In order to get feedback on the designs at this stage, I found it necessary to link together the screens of the low-fidelity wireframe to create a clickable prototype using Invision. This way, I had something with which the users could interact when I moved into usability testing. Keeping the design at this lower fidelity was important because it helped remove some of the pressure from my users, and allowed me to make changes to the prototype more quickly if necessary.
Click here for low-fi Invision prototype.
Usability testing
With my low-fi prototype ready, I ran usability tests with four different individuals who fit into my target persona. I asked these users to complete three common tasks within Sous, and analyzed their behavior using the rainbow chart seen to the left. From these tests, I found that my design had room for improvement in a few areas, the largest of which was on the "explore" tab where I was missing clear signifiers to tell the user how they could interact with the content.
High-fidelity mockups
After analyzing the data from my usability tests, I iterated on my design to account for my findings. This included updating the "explore" tab to better guide the users' exploration and to provide signifiers for the different sections of content on this screen. Beyond the "explore" screen, I made some tweaks to the remaining views to account for my observations from the test sessions. I also updated all of the screens to include more realistic content, such as images and color, to replicate what the users would see when viewing this as a real app.
High-fidelity prototypes
The final step of the design phase was to link the newly completed high-fidelity mockups together to form a realistic prototype to present to stakeholders. At this point in the process, it was necessary to give the users/stakeholders an idea of what the app would look like with more realistic content so that I could get a true gauge of how they might interact with the design. This would allow me to see just how well Sous could help users achieve their goals.
Click here for high-fi Invision prototype.
