Designing on the world’s flattest screen: paper prototyping

After creating persona and storyboards, it’s time to start thinking about the app itself. More specifically, we started designing the graphical user interface. Ideal for this is paper prototyping: drawing the GUI on pieces of paper, then testing that with a small number of subjects. Using paper enables us to quickly adapt their feedback.

First off, we thought about which platform we would develop for. After all, different platforms have different guidelines for design. From Android, iOS and Windows Phone we chose the first, Android, because it has the highest market share and its usage within our group (2 Android, 1 WP). An alternative would be to design a web app, but since we require push notifications (dinner invitations), that choice would have been tricky to implement.

Then we split up and started to draw GUIs for different scenarios, namely making a dish and adding/deleting ingredients from the fridge. These are the resulting sketches:

Preliminary sketch of the GUI to choose a dish and friends to cook and eat with.

Preliminary sketch of the GUI to choose a dish and friends to cook and eat with.

Preliminary sketch of the GUI of receiving and replying to a notification

Preliminary sketch of the GUI of receiving and replying to a notification

Preliminary sketch of the GUI to add ingredients to the fridge (since this is a boring task, speed is of the essence)

Preliminary sketch of the GUI to add ingredients to the fridge (since this is a boring task, speed is of the essence)

As you can see in the last sketch, we were interrupted. Professor Duval told us to focus on the core functionality for now, which is the first scenario.

We then started to make the actual paper prototypes on A6-sized pieces of (surprise surprise) paper. There were two iterations, the first of which was tested with four users. The second iteration is yet to be tested. These are the five most important cards of the first version:

The first version of the "Cook dish" scenario

The first version of the “Cook dish” scenario

From left to right:

  1. The user taps the search box (a keyboard appears) and starts typing “Spaghetti”. Some suggestions are shown underneath. The user picks the first one.
  2. The ingredients of the dish are displayed, each with an indication of whether the user already has them. The user taps ‘Cook’.
  3. The next screen is composed of three elements: on top we have small pictures of the people that have been selected. In the middle the checklist of the ingredients is shown. At the bottom, a list with available friends is displayed with the ingredients they can provide. The user taps ‘invite’ for Elke.
  4. Only paprika is missing. The user invites Freddy as well.
  5. The list of people that can be invited turns into a message that all ingredients are checked, and that you must bring spaghetti’s yourself. The user taps ‘GO’ and the scenario ends.

The feedback was clear:

  • Most of our testers thought they could tap the check boxes on the second card. Since this is not the case, we decided to use V’s and X’s to indicate whether ingredients were already available.
  • Testers also asked where and when the pasta feast would take place. To keep it simple, we decided that that would be in the kitchen of the user (= inviter) . As for the ‘when’, in version two we added this to the second card.
  • We also decided to add a title to the list of candidates to help the user understand what he has to do.

The second set of cards took these remarks into account:

The second version of the "Cook dish" scenario

The second version of the “Cook dish” scenario

What we need now are people to test this second version. If other groups need those as well, leave a comment so that we can exchange testers.

Advertisements

17 comments

  1. Looks good, only one question, could a person see a list of the ingredients he should take care of? And could anyone see which person was responsible for which ingredient?
    PS: haha I love the blog title!

    1. The inviter sees these on the last screen (in the middle: “BRING”). Invitees see these in the notification. Normally only the inviter knows who takes what. After the invitations are sent, I guess there will be a way to find this information.

      PS: The original blog title was something about Inverse Skeuomorphism, but we felt this was to far fetched (and not exactly right either).

  2. As Duval already said to you, it’s important to focus on the core with paper prototyping: in the start of your post you said you decided to build for android but I don’t think that’s important right now. I even think it’s more important to keep this decision in the “open”, don’t let this limit your design at this stage! You can still possibly build a web app that’s wrapped in a native app that supports push notifications (it’s even not that difficult, see http://bit.ly/1fMlI4A). So my advice: don’t pin on the OS right now 😉

    1. The design is currently not targeted to any specific platform. I agree that iOS and Android have quite similar design styles, apart from some minor differences. Web apps using jQuery Mobile fit quite well in their design styles as well. Windows Phone is quite different though and would require a very different design if we want it to look native.

      We have already done a bit of research on platforms though, we want to be aware of the consequences of our design decisions. We’ve come across some solutions for cross-platform mobile development which include support for push notifications.

      Apache Cordova for example allows developers to program in HTML/CSS/JavaScript against a JavaScript API to interact with the device (access contacts, camera, push notifications etc.). This is then compiled and run in a platform-specific custom web view. Since the whole thing is built upon web technologies, libraries like jQuery Mobile can be used to make the UI. Notice that the UI – although built upon web techologies – still runs locally on the device, so no Internet connection is required just to run the app.

      We’re not sure if we want to take the leap towards Cordova. In our team, I am the only one with a background in web development, Vital and Milan would first have to learn about HTML and JavaScript to get started. We’re not talking simple web pages here, full-blown apps are much more complex and thus advanced knowledge will be required. Android development also comes with a learning curve, but at least we already know Java sufficiently well. (Don’t even get me started on developing for iOS in Objective-C, that’s just madness! 😛 )

      Android is quite attractive as a development platform. We can use the user’s Google account on his Android device for authentication, so we don’t need a separate login or deal with Google OAuth ourselves. Integrating with a backend running on Google App Engine is also easier since Google already provides Cloud Endpoints specifically for that purpose. Simply put, we believe development would be faster on Android.

      1. I understand but although I should not underestimate the learning curve for android development, it was a lot steeper than I thought it would be (when I started with some android developement in the past). I also still think web development is still a lot easier than using Java (but ofcourse it works less).

        Ofcourse this discussion is not the right time now ;).

      2. I’ve done a tiny bit of Android development before, so that should help to get started a bit faster. Besides, web app development is a different beast than regular web development. 😛

        Anyway, nothing is decided yet, and it’s still too early to make a definite platform choice. 🙂

  3. I don’t see a cancel button. I can imagine that you click on the button ‘find partners’ and then see that only that one person you really hate is a match with your fridge :s

    1. Up until the “Make Spaghetti” screen(s), there’s a back button at the top which should work like the back button in Android, Windows Phone or a web browser.

      When the user reaches “Make Spaghetti”, we don’t want them to accidentally go back and cancel the party. We’re not yet sure how we want to go about that, one option would be a confirmation dialog popping up and informing the user that going back now means cancelling the party. For simplicity reasons, we simply left it out the paper prototypes for now.

  4. Have you thought about the kind of device you want to develop for? Your screens display a lot of information which wouldn’t fit on a smaller phone (3,2″ screen)

    1. I don’t think it’ll be that much of an issue, you can still fit quite a few things on a smaller screen. The text sizes on paper are often bigger than on screen, since you can’t really draw small and thin text on paper. Anyway, we’ll make sure to test the actual user interfaces on a multitude of screen sizes.

  5. It looks like a great app and something I would use. One remark: are the ingredients of the dish pinned? Because I can imagine that some people make their spaghetti differently than other people.

  6. Maybe in stead of boxes, you could just use the checkmarks without the box, when there is a checkmark inside of a box, I would still try to press it.

    1. That’s what we thought: “Most of our testers thought they could tap the check boxes on the second card. Since this is not the case, we decided to use V’s and X’s to indicate whether ingredients were already available.”

Comments are closed.