How a Interaction Design Course made me rethink how people interact with food delivery (and every interface, really)

I always had a dream to be a UI/UX designer. In my comfortable chair, I thought UI design was about sitting and designing screens straight and for long hours. How I was wrong!

The first thing you learn in a Interaction Design course (mine was offered by the University of California through Coursera, if you're interested) is that you are not the user. It doesn’t matter if the interface is intuitive to you and if you followed best practices, included right sized tap targets, made an appealing interface and used hierarchic correctly… it won’t be intuitive for a lot of people. And you only discover why if you do extensive user testing.

But first things first: You also don’t know all the problems your product must solve. You need to watch people. Really, close-eye, pen-on-paper watching. You need to know how people solves problems today, and which problems they are trying to solve. If your first step in interface design is putting elements on a page, you've already failed. You must start with the users, completely user centric. Mind you, not the user in your mind or yourself. Actual people.

Interviews: AKA "the first surprises"

I chose the "eating behavior" realm of problems to solve with my interface. At this point, I didn't know what kind of product I would make: this is a good thing. Searching for the problems with a preexistent solution in your mind is the way to go blind on UX design.

I used a Diary method approach — I couldn't follow my subjects for days to watch every single meal they’d make. Instead, I asked them to log with a photo and explain why they made their eating choices: only thing available at home? Cheap? Special diet? Easy to cook? Any reason at all. Also, I asked if they were eating exactly what they wanted. If not, why, and what they'd prefer.

Suddenly, a few days later, I learned problems I wouldn't come up on my own. One of my subjects ate exactly the same things all day (they were on a prescribed diet).

Apples, Chocolat Milk and Sandwiches, anyone?

Really. This one made me come up with a feature on its own. Also, they were a vegetarian.

Another subject of mine couldn't eat anything that had milk or gluten for health reasons. She had a hard time finding anything to eat she didn't make herself. Another one wouldn’t eat anything that wasn't readly available. And so on. With the problems I found, I've made a "Dietary Restrictions Filter" feature, a "Schedule and repeat order" feature and a "Saved locations for delivery" feature.

My point is: you won't figure out the real problems sitting in front of a desk. You need to explore the world.

Problems meet pen and paper

Now that I know all the problems, I should open Sketch, or Photoshop or Adobe XD, or whatever I use, right? No. What you need is paper. This is not the time to worry about fit and finish and if you're like me, you won't resist: if you use a computer, you'll worry about the pixels. This take too much time. Besides, it's a good time to do some storyboards if you're going to present to someone or… for yourself. Imagining the use cases of your app proves valuable. Here's the (horrific) sketches:

This looks like shit. Put it's not the point, I swear.

You shouldn't worry about buttons on theses storyboards. It's all about the context real people are going to use your interface. And speaking of which, here's my first sketchs of the interface itself:

"These also look like shit, why are you showing us this?" — Would say anyone.

There are no details here. This is just a mental model of "how the interface would work" in the making. All I can say is I'm glad I implemented a Tab Bar thereafter.

Use a computer now, please

So, after you've done all this… it's finally time to use a computer and do some UI. Let me remind you that everything that went prior to this (and the user testing after your first prototypes) should take almost all the time you invest in the entire project.

For the course, I was required to make some sort of interactive prototype, but not a final and usable product, and that's what I did. Not all screens are implemented on the prototype. It's a food delivery service, so the menu part would take millions and millions of screens alone. It's meant to be a prototype and that's it. If you're interested in taking a look, you can click here. I would polish it more, but the deadlines didn’t help me (this post included, which is required for me to finish the course, by the way.)

Users will find problems, don't you worry

For the assigment I had to do at the time, I had to document every interface change I would make taking into account the problems that came up in user testing. I feared at first they wouldn't find any problems whatsoever. My interface is super duper intuitive, right? How wrong I was. Here are a few things I learned the hard way:

• Buttons should be buttons: Really. It doesn't matter how clean the interface may look if you forego these damn borders. People will take much more time to notice buttons or they won't notice it at all. I knew this was important, but only with user testing I discovered HOW MUCH it was important.

These screens are completely different in the eyes of a everyday user. You wouldn't believe.

• A keyboard with no blank field might as well not be there: in my first take of the interface, a keyboard would pop up when you touched the "add to cart" button. This keyboard was invisible for a tester of mine. It didn't make sense to them if it wasn't coupled with a blank field or a question asked. So they touched outside of the keyboard, thinking they've already added the item to the cart. This is how valuable instant feedback is. I changed it to a "touch it and it's added to the cart" behavior and the problem suddenly vanished.

• Redundancy is important: Some users will expect a feature in one screen and some in another. What would be the right approach? Maybe both. If you have screen real state and it makes sense… maybe redundancy is the solution. This advice is highly dependent on yout ability of discernment, though — I would advise to ponder with care and watch for possible uses in user testing.

The experience

As a whole, the experience with the course was great. I discovered how things matter and what matter. I think this is everything a course should do. The rest is about your goals and hard work :)

For everyone who didn't catch the prototype in the middle of the story, here it is.

I was also required to make a promotional video for the course: