Eddie

A gamified nutrition education experience for kids

CONTEXT:

Eddie 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 including: identifying the problem, investigating, generating requirements, ideating, prototyping, evaluating and producing a solution.

MY ROLE:

No official role was assigned to the 3 of us, but we each had backgrounds in either Business, User Experience and Technology(BXT), so I led the user experience design efforts for Eddie.

TEAM:

Ze “Bob” Tian, Yi Fan “Ivan” Yin and myself:)

Primary & Secondary Research

While doing our secondary researches, we found that the current nutrition education for kids is quite ineffective, resulting in nearly 1/6 of all children and youth in the US being either overweight or obese. Parents rely heavily on nutrition education programs offered by elementary schools, but these programs do not really change eating habit of kids. Developing a healthy eating habit is not a one-day-task, it will not be solved by a couple class periods of nutrition education. We want to integrate nutrition education into a kid’s daily life, and create a fun educational experience for them to improve their nutrition awareness over time. At the same time, we want to get parents involved in the learning process, help them monitor their kids’ daily nutrition intake, resulting in an all around healthier eating habit.

For our primary research, we went to Audubon Elementary School and did a field study observing their lunch session. What we saw was quite shocking. The lunch options were far from what we imagined. In fact, most entree options were extremely unhealthy, such as corndogs and pizzas. We also interviewed a couple of the cafeteria staffs to understand how lunch sessions were conducted. Looking back, I think we could spent more time with the staffs and ask for their opinion on nutrition and more.

Using notes from the field study, we conducted an affinity diagram and generated a few key insights.

At this stage, we took a step back and looked at the big picture. There is definitely issues in kid’s nutrition education, but where should we get involved in? While we communicated with the principle at Audubon Elementary School, we learned that it is tough to change anything in school due to regulations and rules. So we re-adjusted our scope, and shifted our focus from school to home.

Online Survey and Personas

We then created an 2-minute online survey for parents to further test out our assumptions.

Being a heavy user of Reddit, I knew that redditors are alway willing to help. So we posted our survey to a few subreddits such as r/parenting, r/nutrition and r/SampleSize. The support our survey got was incredible! We ended up collecting 32 responses in 3 days! These responses confirmed our assumption that parents do care about their kids’ nutrition, but don’t act on it due to time, budget or other constraints. Furthermore, they ARE relying on schools to teach their kids about nutrition. We then refined our design requirements for the next step.

Identifying our core users was a critical step. We created three Personas using knowledge gained from secondary research, covering most of our potential customers.

Scenarios

Next step was sketch out some scenarios and determining user tasks.

From our survey, we knew that our solution has to involve parents and has to be useful for them, while being fun for kids. Therefore, we decided that it would have two core users: parent and kid.

At this point, we are finally ready for ideation!

Ideating , Prototyping and Evaluation

Ideas were overflowing during our session, each of us came up with a set of features for Eddie. Our scenarios and tasks in addition to our list of design requirements kept us grounded and guided us in narrowing down the list.

Next step is creating the prototype and evaluating it. Having a background in UX and design, I naturally stepped into the role of creating user flows and wireframes. For the first prototype we wanted to keep everything low fidelity, so user aren’t afraid to tell us what is wrong.

After completing the prototype, we did a few pilot studies. During these studies, we gave our test users the context, had them perform a few tasks that we assigned for them(e.g. we asked them to check the leaderboard for their kid, or to check on their kid’s daily progress). We would only intervene in extreme conditions.

Observing the pilot testing and talking to test users were quite informative, we learned that some of our labels were not clear, and the lack of actual graphs or data points made it hard for them to understand the app. But overall, users were able to find what they need without out intervention.

After the pilot testing, we modified our prototype according to the feedbacks. We put in actual icons for the tab bar, and we included graphics for clearer illustration of statistics. And we implemented a couple small features suggested by test users.

One thing that I learned during pilot testing was that everyone interpret cues differently, and everyone does different things upon opening the app for the first time. And those are the exact reason why pilot testing and evaluation are crucial parts of the design process.

Final Presentation

Even though the final presentation isn’t traditionally part of the design process. I found it quite helpful in moving the process forward. In making the presentation, I took a step back and looked at our process as a whole. Rather than presenting the whole process, we decided to focus on our solution — Eddie, and spend more time walking through different tasks and scenarios.

CONCLUSION

At the end, we are very happy with what we have achieved with Eddie, and the paths we have taken. There were two things that stand out for me in the process:

1. Delay coming up with a solution.

2. Do not take shortcuts

In the beginning of the design process, everyone is eager to propose solutions. In our first brainstorming session, everyone is already thinking of end products, and the viability of these products, without even getting an in-depth understanding of the problem and need. And the second brainstorming session was the same. Gradually everyone settled down and focused on the preliminary tasks. We all learned to take a step back at different point of the design process.

It was easy for us to take shortcuts and disrupt the workflow. For example, instead of making screens specifically for each scenario and not caring about how users get there, we kept updating our user flow, and made sure each screen is connected to the previous. That was quite important for us, because it meant that we need to thoroughly consider whether the structure of Eddie made sense.

APPENDIX

Final Presentation