Code 5: UX Design and Paper Prototyping

Code 5

UX Design and Paper Prototyping

Learning Objectives:

In this unit, you will…

  • Learn about user experience (UX) design and minimum viable product (MVP)
  • Clarify goals for your app
  • Gather information about your users’ needs
  • Create a paper prototype and get feedback on it

You have learned more about App Inventor, and your team has an idea for a problem you want to solve together, along with some ideas for a solution. But you may be wondering how you can take these ideas and transform them into a mobile app that works reliably and does what the users want it to do. Creating a usable app is about more than programming. In fact, the actual programming part may only comprise about 20% of the project!

Imagine your friend asks you to make an app to help her get to school on time every morning. You create an app that uses GPS to track her route to school and let her know if she’s going to be late. When you show it to her, it turns out that she takes the bus to school. She really needed an app that could provide her with a bus schedule in real time. You spent several hours working on the app in vain because you didn’t understand her needs and now you have to spend more time on the redesign!

What would you do differently next time to ensure something like that this doesn’t happen again?

What is UX  Design and Usability?

UX Design (short for user experience) helps people create technology that is easy and intuitive to use. It has to do with the quality of the experience that someone has when using a system or a piece of technology. You can think of it as improving the ‘user’s experience’ which means that a user will have an easy time using the technology and will keep using it because they are satisfied.

While you are designing your app that helps to solve a problem, you want to create something that is easy to use, helps get the job done, and provides an experience that is fun for the user. You will want to make it usable. But what makes an app usable?

Usability is the extent to which a system, product, or service can be used by specific users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.

It’s not just a matter of what you think might look good, or what you think you would like because you consider yourself a user of the app you will be creating. It’s about context. Think about who else will be using the app and what their needs are. Will people use it once a year, once a week, or once a day?

Where will people be using it? We used to think of applications as something that people use while sitting at their desk. What are some of your favorite apps, and what do they do? Where and how do you use them? Do they do many things, or do they do a few things really well? In order to save your team wasted hours of engineering time, you will be focusing on creating an app with minimal features. This is called Minimum Viable Product, or MVP.

Minimum Viable Product (MVP)

In the world of product development, the MVP is a product with just enough features to get the job done and test with users so that improvements can later be made. The goal is to create the most desirable end product. In general, products with more features involve increased costs and risk of failure. This can happen because of incorrect assumptions about users.

It’s especially important to think about where the app will be used and what would work well on a small screen, portable device such as a smartphone. You wouldn’t want someone to stop using your app because it is too hard understand and use.? How do you learn more about your users to prevent this?

User Centered Design

In User Centered Design, you keep the user in the loop while you are researching, designing, developing, and testing. This is an iterative process, meaning that there will be a sequence of operations that will repeat until you get closer to your final, most desirable product. The steps involved are:

Analysis and Research



These steps repeat until the product is ready to build!


The most valuable thing you can do before you start is to be clear about the goal of your app. This part of the project is called analysis because you need to know what your app needs to be able to do, and getting the details right can be a little tricky.

Activity 1: Review Your Problem Statement and Create a Goal

Remember the problem statement your team worked on in the Ideation Unit? You will want to revisit this now and you will probably want to come back to it again so that your team remains focused on the problem and your original goals. This is an important part of the process because it will help you to analyze the needs of the people using your app, and to understand the technical requirements for your app.  

To summarize, the problem statement is a brief piece of writing that explains the problem that your team is addressing. It should outline the basic facts of the problem, explain why the problem matters, who it affects and how, and present a direct solution.

What you will need:

  • Your initial problem statement. Here is a template for creating your problem statement if the team has not yet done this in the Ideation Pre-Unit.

What you will do:

  1. Review your problem statement, or work on it if you have not yet done so. It should answer four questions:
    • What is the problem? In design terms, this also translates to: what is the need
    • Who does the problem affect and how? This is important because the people who are affected by the problem will be the users of your app. They will be your stakeholders
    • Why is it important to solve? Why is this problem compelling and do you have any evidence of the problem to back up your argument?
    • What is the solution? You may have an initial idea for a solution. You will be experimenting more with the solution in this unit as you get to know your user and through paper prototyping!
  1. Now, can you condense your problem statement into one sentence that says what problem you app is trying to address and how it will address it? This will be used as your goal moving forward.

Once you clarify your goal, you need to define your stakeholders, which are the people who would use your app or would be impacted by your app. These are the people that you need to talk to learn more about what they need the app to do. You and your team might think you are typical users but you should still  talk to other people, interview them, get their feedback, and observe them in the environment that they would be using your app when possible.

Imagine that you are making an app that allows students to pre-order food from the school cafeteria. They can use the app to request the food in the morning and then go and pick it up at lunch time. The idea is that this will help reduce the waiting line in the cafeteria. Who do you think your audience  in this situation will be?

The potential stakeholders for this would be:

  • Students (who will be using the phone app)
  • Cafeteria staff (who will be receiving requests through the app)
  • Parents (who would need to buy their kids a smartphone so they can use the app)
  • School administrators (who might not think phones should be used during school hours)
  • School IT support (who would need to help students who can’t figure out how to work the app or connect to the network)

Activity 2: Make a Map of Your Stakeholders

What you will need:

  • Post-its
  • Markers

What you will do:

  1. Brainstorm and write down all the possible stakeholders for your project - one per post-it
  2. Cluster the stakeholders into similar groups, such as “adults”, “kids”, “school staff”
  3. Decide which stakeholders you will focus on for your app
  4. Write down questions you want to ask them
  5. Plan interviews with stakeholders - individuals on your team can interview people separately to save time, or you can go together if that is more comfortable for you.

Once you have clarified your goal and have identified the stakeholders you would like to interview, you will be ready to learn more about how they think.

Activity 3: Conduct Stakeholder Interviews, Gather Personas and User Stories

To find out what stakeholders want the app to do, you will need to interview them. You can ask them questions to help you find some functional requirements of your app. Functional requirements are things the app needs to do. Using the example above, the app needs to allow students to choose the food they want to order. It should then send the order to the cafeteria, along with the student’s name so that they can be easily identified when picking up the food.

Interview a set of people who are potential stakeholders of your app to learn more about the problem and get their thoughts about the solution. If you know of apps that already exist to help solve the problem your team is focusing on, you can ask users about the app and what they like about it or what doesn’t work so well for them. This will set the groundwork for what you'll do later in Market 3.

What you will need:

  • A print out of the questions you wrote down in the stakeholder map activity
  • Printouts of the Persona Template
  • Printouts of the User Story Template
  • Paper
  • Something to write with
  • Voice recorder or app if you want to record the interview

What you will do:

  1. Introduce yourself and give the person you are interviewing a short overview of what your project is about. Why are you interested in receiving her or his feedback?
  2. Ask the questions your team prepared.
  3. Use the Persona Template from the Goldman Sachs Web UI Toolkit to gather more information. A persona is a description of a person (real or fictitious) who will be using the app. A persona lets you design with a specific user in mind, rather than designing for ‘everybody’. Create as many personas as you need to capture the main categories of people who will be using the app. Be sure to ask them what their goals would be for your app, what their particular needs are, and what their pain points are. Pain points are problems, real or perceived, that people struggle with. Your app will essentially try to help provide solutions to those pain points.
  4. Use the User Story Template from the Goldman Sachs Web UI Toolkit to go a little deeper into what functions your user would like the app to have and why.
  5. Come back together as a team and share your experiences from the interview process, along with your personas and user story templates.
  6. If there are any more stakeholders you feel you need to interview in order to get the information, do this now before moving on to the next step, which is design! You will soon create a paper prototype, which is a fun and creative process.

What is a Paper Prototype?

Prototyping is a way to model ideas or concepts so they can be communicated to people as soon as possible and tested out.  

There are different kinds of prototypes, but we will be focusing on paper prototyping in this unit. A paper prototype is a hand-drawn representation of the user interface which typically looks like screenshots. It can help serve as a walkthrough of how users would navigate the app.

What are the benefits of paper prototyping?

  • You can quickly and communicate your ideas in a visual way. For example, you can show what happens when you click on buttons in your app
  • It’s collaborative! When you work on paper, it’s more casual and conversations spring out of experimentation
  • It’s inexpensive! You don’t have to spend a lot of money to create a paper prototype. You can use materials like paper, magazine cut outs, post-its, markers, stickers, tape, glue
  • You don’t have to be a technical expert for this part of the process
  • You can observe human interaction with the interface and will learn fast about what might and what might not work in your design
  • Prototypes can help to confirm design decisions before you spend more time developing the technology

Keep in mind that design of your app may change to accommodate user need after it has been tested and you have received feedback. This is fine, because you will want to know these things sooner rather than later! Some of you might be afraid to test out your ideas because you think you might receive feedback that isn’t positive and you would see this as failure.

The Importance of Failure

Remember—failure is part of the process and there is a lot you can learn from it. Find out what Richard DeVaul has to say about it in this short video. He is the Rapid Evaluation Team Lead for Google’s top secret lab called the Design Kitchen. You can also learn more about how failure and the rejection of ideas is part of the innovation process there in this article.

Are you inspired? We hope so! You are now ready to move on to the design stage!

Coding Challenge: Paper Prototype Your App

Every product has to start somewhere! Sketching is a fundamental part of the design process and can help you make key decisions about what to design. It can be as simple as drawing on a piece of paper and is helpful when you are working with your initial ideas. You can show your basic app structure and experiment with how people will interact with your app. You can also test color and where buttons will go. Spending time now to test your ideas on paper will help save you time later when you transfer your ideas to your digital prototype.

Before you start, you can learn more about paper prototyping, user flow, and color theory in this short video with Melissa Powel who is on the Google Developer Relations team, and Mariam Shaikh who is a Senior User Experience Designer at Google.

Ready? Find instructions for the challenge here:

“My best successes came on the heels of failures.”


–Barbara Corcoran, businesswoman, investor, and author


You have come really far and you definitely deserve some congratulations! You are almost done with this unit.

While the feedback is still fresh, now is the time for iteration! Analyze the feedback with your team, make the necessary changes to your paper prototype, and repeat the process as needed!

Your team may be tempted to simply move on and transfer the paper prototype design to a digital prototype. But have you checked to make sure that you have a plan for your minimal viable product before moving on? Do you know which of the app's features are truly essential, versus which would be nice to have?

It wouldn’t hurt to do one more iteration or your paper prototype and share with your mentor and peers!

Additional Resources