Mockups & Prototypes (Tue Oct 31, lecture 16)

Homework due for today

Legend: :Participation :Early :PDF

  1. Term Project Stage 1 Complete Look at the Term Project Outline and make sure you have completed all the deliverables stated there. In addition, write and submit the Team Retrospective. Deliverable: Iteration Retrospective as a pdf . (Begin work on Stage 2!)
  2. Principles of UI Design: Read this article about about principles for a clean visual design Select two of the principles and find two examples of web sites or mobile apps that VIOLATE those principles. Write a 1 page paper with images, explaining the two principles in your own words, showing the examples that you found, and explaining why they violated the principles. Deliverable: Submit to Latte, as pdf
  3. Two Screens of your App: Read a second article to inspire you on how to create cheap sketches and mockups: Everything you need to know about UX Sketching. * Now, design and sketches of the two most important screens in your app. Work independently to see how different ideas come out. Try to use some of the principles from the articles above. You may use any tool(s) you want - pencil and paper, watercolors, photoshop, but really I recommend It is important that you work neatly and clearly so we can appreciate your ideas. I will be looking specifically to see that you thought about hierarchy, placement, sizes, alignment, balance and so on. Deliverable: Post a pdf containing the two images, and your commentary. We will review them together in class
  4. Teams do more out of the building testing: Decide on and do more out of the building testing: survey, 1-1 interview, landing page, anything else you can think of. Make sure you know and indicate what the hypotheses were that you were testing as well as the methodology and results of the test. Record your work and the results. Remember we are looking for non-trivial amount of outside testing. You will need it for your term report.


  • Each team shows off their two screen samples
  • Each team discusses their out of the building experiences

What’s the difference between a mockup and a prototype?

  • Note that hardware and software are very different in this context
  • Mockup typically is static and non-functional
  • Prototype typically is somewhat dynamic and somewhat functional
  • But there is a definite grey area in between
What’s the purpose?
  • It’s a classic MVP testing one ore more hypotheses
  • Therefore the amount of “fidelity” depends on what the hypotheses are
  • Pick the approach that is the cheapest way to check those hypotheses
  • Only create one when the cheaper or more important hypotheses have been tested
(Software) Mockups and Prototypes, from cheap to expensive
  1. Paper sketch
  2. Paper prototype (Paper Prototyping Helper Kit )
  3. Wireframing or general drawing tool (Balsamiq, powerpoint, google drawings, etc.)
  4. Image editing tools (Photoshop and similar)
  5. Real HTML and javascript run in a browser
  6. Live prototype (can be done with Balsamiq
  7. Actual working code

Paper Prototyping

  • There are many media for doing this.
  • Advantages
    • Very cheap which saves money
    • But also makes it less painful when it has to be changed totally
    • Allows a user to take over and cross things out and suggest other ideas
  • You can take this as far as you want.
    • Smaller snippets for the various ui widgets (e.g. drop down menus)
    • Make a “screen flow diagram” by connecting the different sheets of paper with lines showing the transitions
    • It is similar to a movie ‘storyboard’
Here is my example: not good UI.
  • Why I insist on ‘paper prototyping’
  • How ugly can it be?
  • Fast iteration
  • Role of the UX Flow Chart

Usability Tests

  • Don’t guess!
    • “Get out of the building”!
    • It’s so much easier to grab one or two or more real humans
      • Evidence from 2 or 3 random people is often enough, but really you don’t need for than 5-10..
  • Can be conducted at any stage
    • Paper prototype
    • Online mockup or ‘wireframes’
    • Actual build
    • The difference is how hard/painful it is to make changes - which is inversely proportional to how open you will be listening
    • This could be testing a paper prototype
    • early, when it is easy to make big modifications,
    • or later with actual software - when it’s more difficult to make changes
  • Preparation
    • Decide on a task(s) for user. “Log in and post a picture”, “Check and update your privacy settings”
    • Decide on the type(s) of users.
    • Decide on what knowledge or assumptions they will start with (new user, experienced user, musician, programmer, etc.)
  • Rules of thumb to follow
    • Try to get the ‘victim’ to narrate their thought process
    • Make sure they know that if they are confused, it is the fault of the software, not their fault
    • If and when they get stuck, engage them in a conversation by giving them small hints
    • Ask them for a suggestion on how it would be clearer, for example:
    • “Let’s say you want a plain pizza and you see this screen, what would you do?”
    • “Oh you can’t decide, well tell me, what are you looking for right now on the screen?”
  • Running the test
    • Mistakes are ALWAYS the fault of the software not the user. Make sure they know this and don’t feel like they have to appologize when things go wrong.
    • Don’t help.
    • Ask them to narrate their thought process: “I am not looking for a button called security or privacy. Oh here’s one called settings, maybe that’s it. I am going to click it. Hm, I expected to find security related stuff here but instead I see…” etc.
  • Make notes
    • Keep it simple
    • You don’t need a one way mirror, video recording etc etc.
    • You don’t need 10 subjects. Usually after 2-3 you already know what the problems are

Next Class