Mockups & Prototypes (Tue Oct 23, lecture 13)
Basics of designing attractive and usable interfaces

Homework due for today

Legend: : Participation | : Early | : PDF | : Team | : Zipped

  1. 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
  2. Two Screens of your App: Note, this is an individual not a team assignment! 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 www.balsamiq.com. 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
Ongoing work
  • Teams do more out of the building testing: Begin to work on Stage 2, which will be due on November 13. 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.

Discussion from meetings I had with teams

  • Going out of the building is hard
    • You have to go out of your comfort zone
    • It’s hard. It’s the hard work of entrepreneurship
    • Who are you trying to talk to?
    • Where are those people to be found?
    • Practice. You want to talk to
      • International students who want to sublet their apartment
      • Bike owners who would be concerned about safety on the road
      • College students who might need a tutor
      • Homeowners who want an alternative mowing and snow plowing service
      • Young professionals who don’t have time to do housework
  • Hypotheses
    • Don’t need one from each category
    • Go for quality not quantity
    • Its not a hypothesis if you don’t know exactly how to test it
  • Landing page as MVP
    • Why is it called a landing page?
    • What is the hypothesis?
    • How will you get people to see it?
    • How will you determine if the hypothesis is borne out?
  • Volunteers show off their two screen samples and we discuss and give feedback.

Examples of User Experience

Discussion: In each case, can you tell how to operate this device? And while you are trying to answer the question, be introspective, and tell me your thought process. How are you trying to find the problem, if any?

(Pito’s) Rules of thumb for good User Experience

  • Pay attention to AFFORDANCES
    • I want to make you become aware of affordances all around you
    • Visual (or other clues) that something can be pushed, pulled, dragged, clicked, etc.
    • Without them user is lost
    • How a UI problem caused a maritime accident
  • Know the answer to the question: WHO IS MY USER?
    • “Personas”. Note, often there is more than one.
    • Build on what users likely have seen before
    • Platform consistency (iPhone, Android … but then compare with Flash. Is that a platform? How about web?)
    • Conventions: back, home, undo, cut, paste, file menu, etc.
  • Guide the USERS’ CONCEPTUAL MODEL (sometimes called the user metaphor)
    • Some links:
      • This article talks about one kind of metaphor. I mean something broader.
      • This article has some more relevant examples.
      • This article has some interesting examples of misunderstood and obsolete metaphors
    • What this application or feature is about - that sets expectations?
    • What the USER (see above) is ‘expecting’ right now? What is she ‘reaching for’ right now?
    • Remember the importance of WORDS that match this metaphor and user expectations
    • Metaphors can become dated and inappropriate (file save icon in MS Word is what?) Any examples?
  • PROXIMITY Implies RELATIONSHIP
    • Put things that relate to each other near each other and vice versa
    • Pay attention to the Visual Hierarchy
    • Denote hierarchy/nesting of elements: posts->comments, projects->tasks, playlists->tracks, etc.
    • Use size (and type choice) consistently to communicate importance/role
    • Alignment and balance are important for aesthetics
  • Don’t user spend ANY mental energy on questions like this (see book by Steve Krug)
    • Where am I?
    • Where should I begin?
    • Where did they put it?
    • What are the most important things on this screen?
    • Think about DISCOVERABILITY
  • MOBILE is NOT DIFFERENT, but…
    • Assume mobile user is distracted, brief attention span
    • Does NOT think of device as a computer
    • Context: What is users mindset? Where are they, in a car, in line at store, at the theatre?
    • Screen is far smaller
    • “Mobile First”
  • Dealing with COMPLEXITY
    • “Simple things should be simple to do, complex things should be possible”
    • Principle of progressive disclosure.
    • What controls are only available at the back panel of the device, under a little door?
    • We all know that users don’t read manuals, right?

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
    • ACT ON WHAT YOU LEARN!

Applying this to real sites

Let’s look at these sites
  • Heroku. Lets look around it purely from a UX perspective and see what we like and don’t like about. Can you see principles that it satisfies and that it contradicts?
  • Noteflight - Can you or can’t you assume that the user is a musician, or knows music notation?
Split into groups of 2

Split into groups of 2, each pick a different one from below without checking what it is. Make notes about what’s good and/or bad about each one? And, specifically refer to one of the principles we have discussed.

Note: you need to create an account in some cases to get the real sense of the UI

Conclusion

  • I want you to always refer back to principles such as these when you design or present a user experience.
  • It’s very easy to say, “Oh it’s common sense.” But you submit designs that violate these principles left and right.
  • It’s important. Make it part of your toolkit. Internalize it! Take care!

Next Class