Kicking off the MHCI+D program with a design sprint (redux)

Paper prototypes, pens and electronics cover a round table
Photo by Winnie Chen

I wrote this piece as a course requirement in October 2019, but since I was in a period of transition, it was clear that I didn’t yet grasp the language of UX. I thought I would refine it and focus on others like myself who have made (or are about to make) the plunge into UX research and design through the MHCI+D program.

For me, this master’s program signaled a transition in careers, which isn’t easy for anyone. I came from film production and games, so I wasn’t used to expressing my thoughts on index cards, and I thought linear tools like Airtable and Google Docs were the ultimate forms of collaboration (my heart is now with Miro). I may have been a sound designer but my thinking was closer to that of an engineer in that I focused on feasibility first. More importantly, as I changed industries I felt like I was giving up a part of my identity, which made me a little insecure. Many times, I wasn’t sure if a one-year program was the right decision. I know I’m not the first and I won’t be the last to have these feelings when joining the MHCI+D program.

And this brings me to you. Perhaps you’ve come across this story as you wait for an acceptance letter, or you’re moving into an apartment along 15th Ave NE and are taking a break from assembling your bedframe.

Regardless, if you are attending the UW Master of Human-Computer Interaction and Design program, remember this: you are now part of a cohort, and you were chosen for your dedication, insight and diversity. It doesn’t matter if you just finished your bachelor’s degree or that you have many years of experiences but the words designer or researcher never appear in your work history — you now have a group of people who will support you, and your experiences in and outside UX are part of the value of the program.

This also means you will start Immersion Studio soon. For me, I had heard of design sprints, but my closest experiences were game jams. They may share a similar structure in their ideating, prototyping and testing phases, but the priorities are quite different. I honestly wasn’t quite sure what the point was in creating an idea based on hasty research and a prototype that ignores the most severe technical challenges.

I was missing the point. I will expand on this at the end, but just know that if you approach this week with an open mind, positivity, and trust that your team will benefit from your thoughts and background, you will have a great experience, and it will set you up for the rest of the year with its marathon of weightier challenges.

And remember to take a lot of photos.

With that said, here was my experience in Immersion Studio.

Five people look up groups of post-it notes on a blackboard
Ideas selected from the braiding process (photo by Matt Bartels)

Day One: Research

Often in university courses, the first day might be an overview of what to expect and a chance to learn about your instructor. Perhaps you’ll get out a little early. Not so with Immersion Studio.

As we trickled into the studio, we received a quick introduction to our cohort and immediately began an ice breaker: to draw the faces of all 43 members of our cohort and introduce ourselves. Knowing the wide range of talents the program attracts, it was immediately clear we had some illustrators in our group.

After the timer went off, we had a minute to admire each other’s work before quickly moving onto the MHCI+D staff introductions and beginning the first phase of the design challenge:

How can we use computer-supported cooperative work (CSCW) to encourage civic engagement?

Mind you, I had never heard of CSCW, but it didn’t matter. We jumped right in, putting our thoughts on to post-it notes. We then placed these on large poster boards (seen above) and were grouped into teams of three.

My teammates were Winnie Chen, interaction designer, and Rene Goldfarb-Ilyashov, product designer. We discussed the topics we liked from the wall of ideas. Staying in my comfort zone, I leaned toward accessibility in tech, but Winnie had a wise suggestion: we only have a few days; why don’t we stick to something we can easily test?

Together we settled on potlucks — that is, gatherings where everyone is expected to bring a dish. For me, potlucks bring up memories of church dinners and fundraisers, but they could be any event around food, like themed socials, meal planning parties, or recipe exchanges.

We first thought about the challenges of hosting a potluck, such as coordinating meals and keeping everyone informed. We also thought of the guests, since cooking for a group can be tough to gauge. I thought of when I brought lefse to a Christmas party and it went untouched (potatoes, sugar, flour, butter — how can you go wrong?). Luckily I stored the rest in my freezer, but I felt a bit of a disconnect. Perhaps if I looked at a list of suggestions I would have been more aware of what others wanted instead following my own cravings, especially since lefse is not quick to make.

After deciding on a general topic, my team began to research the various types of CSCW, as well as event apps and the benefits of sharing food with others. We hoped to find ways in which they could all come together that did not yet exist.

Day Two: Synthesis

The next morning, we rejoined at the studio—a place where we would eventually spend too many hours on our subsequent projects — and shared our findings. Winnie found this story by Fabian Pfortmüller, “The most powerful & undervalued community tool: potluck dinners”, and its valuable quotes:

Breaking bread is probably the most natural way for us to connect with other human beings. We all have done it since we were born.

allowing people to co-create, even if the experience becomes much more messy and allover the place, makes the experience so much richer.

… until we realized that allowing people to contribute wasn’t making the experience weaker or less comfortable: it strengthened the sense of community ten times. So we started doing it potluck style.

We also found these insights:

  • People who are inexperienced and build something may have more feelings of ownership and pride than those who receive something without putting in work (the IKEA effect). In the context of sharing food, everyone cooks and everyone wins.
  • Competitor apps like Facebook Events, Airbnb Experiences, and Meetup help people coordinate events, but they won’t help attendees coordinate meals or inspire the guests’ recipes.
  • We shouldn’t make another recipe database (Allrecipes, Yummly, etc.).
  • If we did have a database, negative star ratings (that is, 1 and 2-stars) for the quality of the recipes could discourage participation from newcomers. Since we wanted to sort and recommend recipes to users, we thought we could use “likes” instead of stars so people would only receive positive feedback. (In revisiting this point, I don’t think we actually found enough data to support this. I was stuck on this idea and too eager to follow a hunch.)

With these ideas in mind, we spoke to the other teams about their insights and formed a How Might We (HMW) statement:

How might we make it convenient for home cooking enthusiasts to partake in food-sharing experiences?

Yes, this statement follows that designerly trend of saying three words when one might do and making it vague enough so we don’t box ourselves in (everything is an experience after all). But from this statement, we were able to rapidly develop 36 ideas through the braiding technique (sketch for 2 minutes, share for 1 minute — it’s stretches your brain!). This expanded our boundaries and forced us to approach potlucks from different angles — no idea was too strange.

Day Three: Ideation

We now had 36 ideas, but most of them were half-baked, so we down-selected and combined them to develop three more fully formed concepts that would push the edges of our HMW statement and un-stick us from our original ideas (and any ownership of those ideas — though luckily no one on the team was overly possessive). These were our three concepts:

A short user flow demonstrates how a woman coordinates her potluck
Potluck Hosting Platform (drawing by Winnie Chen)

Potluck Hosting Platform

Mei wants to have a Mexican-themed potluck dinner with her friends, but it’s a big task to coordinate with 12 people. The Taste Buds app can help! With it, she creates an event, selects a theme for the dinner, and invites her friends. The app automatically suggests the number of entrées, appetizers, deserts and drinks, confirms with Mei, and informs everyone with an RSVP. Each guest opts for a dish and receives recommended recipes based on the party’s theme.

Another flow shows how a venue would start an event
Venue-Hosted Potlucks (drawing by Winnie Chen)

Venue-Hosted Potlucks

A venue wants to attract the attention of the community, so they create an event on Potlucky and allow attendees to vote on the theme. After a period of time, voting is closed and each attendee receives a notice about what dish to bring — which will be a mystery to everyone else. As attendees try each other’s dishes, they can scan the QR codes next to the platters, and save and “like” the recipes.

The final flow shows a man finding new recipes popular in Chennai
Food Feed (drawing by Winnie Chen)

Food Feed

Ray is hungry and loves spicy food. He feels like whipping up an Indian entrée, but he doesn’t know how to get out of his comfort zone with plain old butter chicken. He checks out the Food Feed app to explore what’s trending in Chennai. It pops up with plenty of homemade recipes and delicious photos from around the city. A picture of meen kozhambu captures his eye, and he tries it out. It’s his new go-to!

Each team posted their three ideas on their blackboards, and then we rotated around the room, taking note of what worked, what needed improvements and any cautions we had. One cohort-mate asked who is responsible if someone gets sick or has an allergic reaction at the venue? Hmm, good point. We also rated our ideas by how exciting, relevant and achievable they were.

With the group’s feedback in mind, we decided to pursue the potluck hosting platform —Taste Buds — an idea that we may have too quickly locked on to because of its feasibility (more thoughts on this below) and perhaps the pun in its name (I still think it’s cute). We also noticed from our exciting, relevant and achievable ratings that our potluck idea was a bit straightforward and boring, so we took a note from the venue-hosting idea and added a sense of mystery by not allowing guests to see what others will bring to the potluck.

Day Four: Implementation

A whiteboard has interface wireframes and post-it notes
Prototyping phase of Taste Buds (photo by Winnie Chen)

The next day we were off and running with our whiteboard. As we diagramed the flow of the app, we realized we had an issue with our scope. We initially envisioned the prototype to show how hosts would coordinate potlucks, but we also wanted to show how guests would RSVP and receive recipe recommendations. In the end, we focused on the guests’ experience, because we had a better idea of what it would be like and we knew we could prototype and test these interactions by the end of the day.

And time was of the essence. Not only were we to present the next day, we also wanted to test our idea outside the studio with strangers. However, if any of the passersby on University Ave were to talk to us, we’d need to be out there before dark (and though we weren’t yet aware, the UW alerts for muggings, robberies and worse often originate on University Ave).

We quickly transferred our whiteboard ideas onto paper screens in a cardboard iPhone X outline (see below). A tester could then “press” a button, we’d remove the page, and they would see the next screen (or we’d explain what button leads to the next page, as we only had one option). Our four screens were as follows:

  • An invitation in Gmail with a prompt to RSVP to Joe’s holiday party
  • The Taste Buds home screen, which shows the party will be a vegetarian potluck with 12 people and prompts the user to select an available category for their dish
  • The secondary screen that asks the user to choose a specific entrée
  • And finally a confirmation from Taste Buds that allows the user to add the party to their calendar and browse recipes for their chosen entrée
Four app screens have buttons and directions for the tester
The first version of our paper prototype

We quickly tested the prototype with ourselves and wrote up a script for the usability interviews. We then tested these with a classmate, and as the streetlights began to turn on, we rushed out to University Ave and stood outside the H-Mart (my favorite grocery store). We looked a little silly for sure, but luckily four of the pedestrians we approached were willing to play along, knowing this is something to expect around a campus.

We introduced ourselves, asked if we could record the interview, let them know what to expect (“there’s no wrong answer”), and went through our paper prototype. Overall, they found the prototype delightful as it was simple but familiar. However, there was some confusion, which I’ve come to embrace, since it always leads to progress, and we still had time to make changes.

What we learned from the usability tests were that:

  • After pressing the button in the Gmail invitation to RSVP, testers were disoriented by the next screen. They weren’t sure if they were still in their email or if they were now in a browser or another app. Were they already logged in? Did they need to create an account?
  • Testers were also unsure what the numbers below each category on the second screen meant. Do these show how many people are bringing that dish or how many dishes are still needed for the party? Does a zero mean that type of food won’t be at the potluck?
  • Finally, they were confused by their entrée options in the third screen. Even when they understood it was a vegetarian party, they were underwhelmed by the options for noodles, rice or tofu and wanted to choose something else.

At the end of the interviews, we asked the participants what they thought of the prototype as a whole, and they all felt it was a straightforward process. They also liked that the app ended with recommended recipes.

With this feedback and a studio with 24-hour access (though we were not looking to lose sleep, since we had time the next day to compile our slides), we made three key changes to our prototype, which are shown below in pink.

Bright pink indicates the changes from the earlier app screens
Adjusted screens
  • First, we decided Taste Buds would follow the Doodle model by allowing users to confirm their details in the browser rather than force them to create and log into another profile or download another app.
  • We also added the word “left” underneath each category to indicate this is the number of dishes still needed.
  • Finally, we added a refresh button to allow users to see other types of vegetarian entrées (though now I would prefer to tap or scroll left or right to see new options).

With these changes, we recorded this video of our final low-fidelity prototype in action.

Day Five:

On the last day, Rene designed these beautiful high-fidelity prototype screens based on our updates.

High-fidelity prototype (design by Rene Goldfarb-Ilyashov)

And with that, we created our slides (which can be downloaded here) and gave our presentation.

What We'd Do Differently

When the three of us first sat down together, we wanted to create an app that would help people coordinate potlucks using CSCW to gather recipes from a community of guests. In the end, we designed a rather straightforward app for coordinating events that was light in CSCW capabilities. We decided afterwards it might be more practical to integrate an existing recipe database rather than create our own from the ground up through submissions.

Our other misstep was that we saw a vision too early and this kept us from developing broader, crazier ideas during the braiding process. Since we felt the time crunch and that we had a good solution, we ended up creating features for our vision during the ideation process instead of going completely out of the box and pushing the boundaries of what it means to be a “home cooking enthusiast” or attend a “food-sharing experience”.

These quotes might look like sarcasm since I chose the wordiest parts of our HMW statement, but I honestly mean it. What makes someone enthusiastic about cooking at home and what would help them share their passion with others? If someone didn’t know how to cook a meal for a group, could they be helped by a community? What does food sharing mean to those who don’t have food to provide? And the obvious question, what does convenient mean?

There many larger questions we didn’t explore when we became stuck on the coordination aspects and, as I mentioned before, the feasibility of the design. Feasibility is a safety net, and a design sprint is not the time to play it safe. At a game jam, you want a playable prototype, but in a design sprint, you can create whatever you want — an app, a service, a new way of interacting with technology, a room designed to promote certain behaviors, a system that changes how business owners interact with employees, anything. I didn’t understand this at the time.

Going through the design process multiple times since then has helped me appreciate how design pulls thoughts and perceptions out of our of heads through drawing, picks them apart through ideation, encourages us to talk to others and see how they interact through prototyping, and ultimately change our own perceptions and expectations of the topic we chose. We learn just how fascinating people are.

And this is the experience you will get from Immersion Studio if you’re open to it. Enjoy — and again, take lots of photos. Winnie saved us!

Me and Michael Smith (photo by Winnie Chen)

Accessibility researcher