Welcome To The
Good Guts Food Truck!
About
Good Guts Food Truck is the product of a ten-week group project for Design Thinking Studio at Global Innovation Exchange (GIX). As a team of 3, we went through stages of the design process which includes: identifying the problem, investigating, generating requirements, prototyping, and evaluation tests to produce a viable solution.
Meet the Team
Zewen Pan
Design
Michael Lai
Business
Jason Cui
Technology
Design Question
How can we save time for UW students to prepare lunch in advance?
​
Who What When Where Why
Out of three potential project domains, our group chose nutrition & health with constraints confined 1) in urban Seattle, 2) easy access to target population and 3) the solution can be achieved in 3-5 years.
Reflection: Personally, I was excited that our team chose the nutrition & health topic because I am a big believer in personal health. Our team had a few conflicts when formulating a design question (e.g. primary focus on cooking, awareness of nutrition of food items).
​
I also found it surprising how as a team we would always try and figure out a solution. As much as we tried to be broad, it always resulted in us thinking of an immediate solution.
Research
In order to understand the scope of our design question, an extensive amount of primary and secondary research was performed to justify the problem space. The research questions were split into three categories: 1) user experience, 2) business and 3) technology. Techniques utilized were online market research, observational studies and surveys.
Primary Research
For our primary research, our team performed two methods.
Observational Studies
Cross-sectional Surveys
Our team took to three observational spots located on University of Washington's campus: 1) Husky Den, 2) Starbucks and 3) Center Table.
We logged all observation results (by minute) in a 30 minute timeframe with key indicators being consumption time and type of food bought.
Reflection: I observed the Starbucks location where many students were on the go and bought something quick. I conducted my studies off-lunch hours (2-2:30pm) which might've given faster consumption times. Looking back, I would revisit observing around a traditional lunch period (11am - 1pm).
To gather more quantitative data, our team drafted a 12-question survey that honed in on student lunch preparation habits.
The survey was distributed in person, facebook, wechat and email. A total of 52 students took our survey.
Reflection: I thought this was a very good way of obtaining quantitative data in determining UW student's eating behaviors. On the bus, I found it easy to go around and ask students if they could take a quick minute survey and all agreed.
Analysis
Fig 1. Quantitative pie chart survey results
After conducting three different types of research we have worked together as a team to produce affinity analysis over the gathered data and came up with a few dozen key insights guiding our research. 16 design requirements were produced from our investigation.
​
Reflection:
This is where our team-working became efficient.
After turmoiling through refining our design question,
the team finally had a clear solution on how to
combat our issue.
​
From here, I took on the responsibility of making
sure everyone wason task in completing their part
of the investigation. The affinity analysis surprisingly
did not have as much conflicting opinions as I expected.
Everyone was on the same page and we almost
immediately moved into the ideation phase.
Fig 2. Affinity Analysis
Secondary Research
In order to scope who our design question would affect, our team performed extensive online research on cooking, nutrition, and student behaviors. Afterwards, we identified affected UW students and bucketed into two groups:
​
Negative Group - Always favoring unhealthy fast food
Vulnerable Group - Susceptible to eating unhealthy fast food
From there, we were able to calculate the negative and vulnerable group numbers based on our surveys (out of 16,402 core students)
​
Negative Group - 10,491 students
Vulnerable Group - 5,551 students
After revealing these numbers from our research, we were confident in proceeding with our design question.
Reflection: I thought this was one of the most time-consuming aspects of our design process. The team was finding a lot of good data to alter the design question and it was fluctuating every 30 minutes when we would meet up.
It got to a point where one person was manipulating the document before submission. I had to set an intervention rule of everyone unanimously agreeing before changing something. This helped mitigate any confusion we would have later on in the design process.
Requirements
From the research insights, we prioritized ones that represents the clear need of users. Then we dug deeper into the insights relating to user dynamics and market aspects to figure out "who exactly are we designing for" and "how can we let them use our product".
We divided these requirements into three sections based on priority. And the requirements that we believed to have high priority are as follows:
High priority:
[User Experience] Solution shall cost students no more than $10 on average per lunch to meet users’ strong interest in saving money.
​
Justification: To save money is the most popular reason for cooking at home rather than eating out. According to responses of Survey Question “How much did you spend for your last lunch?”, $10 is the average expectation of lunch cost. Therefore, in order to save money, lunch should cost no more than $10 with our solution to attract more users.
​
[User Experience] Our solution should make lunch duration around 20min.
​
Justification: According to our field study, average lunch duration is 20 min, which is also the suggested length to maintain health. This is one of the basic requirements we need to satisfy to attract more students to use our solution.
​
[User Experience] Our solution should prevent students from eating junk food at daily basis.
​
Justification: Based on our field study, nearly 50% of students have junk food for lunch for various reasons.
Our logic is to guarantee the overall user experience. At this point, we are familiar with the subject and dynamics of users. Therefore, we modified our design question as follow:
How can we prevent UW students from purchasing and eating junk food for lunch on a daily basis?
​
Who What When
Reflection: I found this to be the pivotal part where our group starting meshing well. We talked about the earlier incident of changing a document without notifying the group and immediately squashed any subsequent issues. I took on the lead of setting up deliverable times so we would always be on track with any upcoming submissions.
​
Here we did a lot of brainstorming. I found it interesting how much information we were able to produce from an hour of brainstorming. We were able to pitch and give constructive criticism for every idea. I also thought it was amazing how we managed time. We were in and out of meetings within an hour unless we were producing a paper, which would take a bit longer. If we needed to leave, we would meet up later remotely.
Ideation
We derived our requirements from insights. Due to time constrain, we could not satisfy all requirements. Therefore, we create a ranking system based on priority and feasibility. Our goal is to change the health aspects of lunch eating habit, which means we should let UW students eat healthier and should not conflict with other aspects such as cost and duration. Feasibility, in this case, means Easy to realize, Direct to user's need, Effective in solving user's problem and Comprehensive.
Our Solution should...
•Cost no more than $10
•Prevent eating junk food on a daily basis
•Reach 2,000 users within 3 months
•Help make lunch decisions
......
As at this point, it's hard for us to picture every detail in our mind to form a comprehensive list of core tasks. To help us visualize our requirements, we drew up personas and scenarios from different angles at different locations and behaviors, to demonstrate varying functions. Based on the different scenarios, our team came up with the core tasks as follows:
Purchase food in app
Find nutrition label and price for food/ingredients listed in app
Locate the food truck in app
Pick up ingredients at food truck
Order food at food truck
Recommend lunch on app & food truck
Then we performed a Sketch, Storyboard, Walk Through process to provide us a vivid demonstration of core tasks
Walk Through: UI Design
Fig 3. Walk through draft
StoryBoard: User Attraction
Fig 4 & 5. Storyboard draft
Sketch: Interaction Flow
Fig 6. Sketch draft
With the help of sketch, storyboard, walkthrough, we were able to add detailed features to our solution to meet user needs better. We had originally pictured our solution to be a cooking education app. But we decided to pivot this plan since app is only useful when user already has the motivation to cook. The solution was not comprehensive enough. At this point, we came up with a detailed solution, which, in general, is the combination of food truck and companion app.
Reflection: I'm not the best drawer and thought this part was one of the hardest. It was reassuring hearing the professor saying it doesn't need to be a high fidelity drawing to showcase the functionality. I was tasked with creating the walkthrough and drafted up the mobile app interaction design.
​
After a few rough sketches, I finally drew a final walkthrough picture that I felt confident in. I also felt way better after seeing my teammates drawing of the sketch. Such low fidelity but I was able to understand what the picture was trying to say.
Prototypes
To test the feasibility of the features of our solution and gather feedback for user interaction, we built prototypes as follows:
​
Low fidelity to save time
Demonstrate core steps during use
User friendly
​
Interaction: Low Fidelity
Visualization: Low Fidelity
​
Purpose: To show the basic look of the food truck and to bring testers to the scenario.
Interaction: Medium Fidelity
Visualization: Low Fidelity
​
Purpose: To bring users into the scenario and to test the ordering process at food truck
Interaction: Medium Fidelity
Visualization: Low Fidelity
​
Purpose: To test the "Healthyspin" function and gather feedback
Interaction: Medium Fidelity
Visualization: Medium Fidelity
​
Purpose: To online order, cancel order, "I'm Hungry" and locate the truck function. To test the UI design and find functions users may need
At this point, we did not spend much time to reach an agreement to the test plan. We each built a part of the prototypes and did several rounds of demo test before we did the evaluation.
Reflection: This was one of the funnest parts of the entire design thinking process. I liked how we were able to determine the fidelity of the product we would like to present and try to get a real user's experience with it.
​
I utilized another class's makerspace experience to develop the menu poster and refinement of the food wheel. At the conclusion, I was happy how everything turned out. The team was still moving as a well oiled machine, and I think it's because no one stepped on each others toe and was open to feedback for their part.
Evaluation
The test evaluations measured 2 key metrics: 1) user interaction with our food truck scenario and 2) ease of use for our mobile app prototype. A short 5 minute survey concluded each session. The survey provided participants to voice out sources of confusion. Combining the metrics and survey results, we will be able to evaluate the usability of our food truck and mobile app prototype to design a more usable solution in the end.
Fig 7. Performing the evaluation tests
Fig 9. Team Good Guts: Jason, Zewen , Michael(left to right)
Fig 8. Setting up the evaluation tests
6 participants were invited and asked to interact with our food truck and mobile app. Each session lasted 10-15 minutes with metrics recorded between tasks.
Fig 10. Example user (LeAnn)
Fig 11. Example user (Ricky)
Fig 12. Example user (Bhakti)
Vid 1. Example user evaluation tests (LeAnn)
Vid 2. Example user evaluation test (Bhakti)
After the evaluation, we shared each one's findings since we each participated in the test as different role. We classified our findings in 4 importance rings.
0
1 Issue Found
Blocking issues that prevent user from accomplishing the task
​
Example
Inform affected groups of allergies and undesired diets when they order food.
1
4 Issues Found
Fidelity-agnostic issues that degrades solution effectiveness
​
Example
Incentivize users to favor healthier, more expensive food over junk food
2
4 Issues Found
Fidelity-specific or cosmetic issues that are within our expectation
Example
Make sure food wheel spins smoothly.
3
9 Issues Found
Findings/issues are identified, no change is proposed for now
Example
More advanced ordering.
Reflection: I really enjoyed performing the evaluation tests. My part was the food truck server and in scenario persona. It was interesting to see how users behaved differently especially regarding diets. I was shocked at how many issues we've found, however most were deemed to be fidelity related issues and would likely be ironed out when a higher fidelity implementations were to happen.
​
Looking back, I would like to have more than 6 people do our evaluation tests. There is no such thing as too much data! The only constraint I think would've gotten us in trouble would've been the amount of time.
​
In conclusion, I had a lot of fun doing this design process. It took a lot of time and there was definitely some sweat and tears getting everything together, but I'm happy with what my team was able to turn out and feel confident performing the design thinking process in future endeavors.