User Experience Flow (Wed Oct 29, lecture 16)

Homework due for today

  • An affordance is some characteristic of an object that communicates how it is to be operated.

    A keyhole in a lock tells me that I need a key and where to insert it. A handle on a fridge tells me how to pull it. A bottlecap on a bottle of beer tells me something. But does it tell me to use a bottle opener or just unscrew it?

    With this context, look around your daily world (room, office, campus) for affordances everywere. Find and photograph a few examples where (visible) affordances were absent, or communicated the wrong thing. Deliverable: Post your photos to Latte with commentary.

  • Practice Paper Prototyping and developing a user experience flow chart.

    Once everyone has read the above articles and thought about them, try to apply what you read about. With your team, develop a set of single screen paper prototypes connected by arrows that indicate when a user action or event leas to another screen or page. I refer to this as your application process flow.

    Focus more on the connections between the screens than making super detailed screens. Use separate sheets of paper, one for each screen with indications of how you get to another screen. I discourage you from using html or other tools because you are always better off doing a sketch on paper before going to any tools.

    Spend 1-2 hours as a team, divide up the work and come up with a process flow for your app. You don’t need to do more than 10 pages. Tape them to a whiteboard, draw the lines on the board.

    Team Deliverable: Submit one or more images with the result of your work. You can use your smartphone to just take pictures. But make shure they are legible!!! Because we will look at them together in class.

Creating an MVP / Prototyping / Mockups

  • Reminder: Minimum Viable Product
  • Paper Prototyping
  • Compare terms: MVP vs. prototype vs. mockup
  • You need to be able to articulate exactly why you are creating a prototype
  • Looks like vs. Works like
  • Purpose of prototype dictates the medium and fidelity
  • Why I insist on ‘paper prototyping’
  • How ugly can it be?
  • Fast iteration
  • Role of the UX Flow Chart
Excercise (experimental)
  • Setting the timezone. On Mac, Windows, iPhone and Android
  • 4 teams develop quick paper prototypes with UX flow
  • Put each up on the board
Making a User Experience flow diagram: P2P Tours
  • Let’s start with B2BTours, using this description:
pitch B2B Tours is a two sided market place, connecting individual tour guides with travelers seeking a tourguide. It increases access to great and novel tourguides, while opening up the market to those tourguides to a totally new set of clients.
  • Let’s explore these questions:
    • What are the personas? How many are there?
    • If I am the end user whats the first thing I want to see?
    • What are the actions I need from that state?
    • Etc.

Usability Tests

  • Don’t guess!
    • “Get out of the buiidling”! 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!
Some Cool Tools

Next Class