Usability Notes

Notes:

Attendees: Tim Ekl, Pete Brousalis, David Pick, Eric Stokes, Sriram Mohan, Mark Larew

• Ultimately, you want to see use in the target environment: either see them use it or have them use it and fill out a questionnaire
• "Users have a funny way of proving designers wrong"
• Do we want application to record what users do? Developers have had trouble identifying problems with this method - observation is "higher bandwidth"
• Developer presence influences user behavior, but that can be both good or bad, and generally it's a positive net outcome
• Provide only one device for developer & user (or a pair of users)
• Another possibility: run 'remote testing', where user is on phone with devs during usage
• In testing, be efficient: if you need a user to pay attention to something, tell them to pay attention to it. Ask for any additional comments, but provide a list of key ideas to watch. Structure list so that it doesn't give away too much.
• "It's more of an art than a science"
• Ideal for this app is to allow use however the user wants, but that can take a long time to hit all the features in completely natural testing
  • Hardest to get to is the reporting functionality - maybe set up a problem and ask users to report it, or do a "treasure hunt"
• Don't want users in harm's way during a test, even if it generates valuable info :)
• If users have a problem with Google Maps API or something similar (outside our scope), note it and move on
• Need to create user profiles (at least the following):
  • Technical users familiar with smartphones/Google Maps
  • Regular trail users not necessarily familiar with tech involved
  • New users who have no trail or tech experience
• Maybe do an interactive tutorial?
• If doing a questionnaire, ask specifically how comfortable the user is with the phone, platform, and Maps app
• How do we keep continuous feedback going?
  • One possibility is to keep web metrics server-side
  • Another is to ask users for direct feedback after a time or a number of uses; this relies on users willing to provide info
  • Ask for direct feedback straight on the phone (this is not uncommon, esp. on iPhone)
• Ask users for feedback as we cut/add features - this may become a marketing issue
• Could almost deal with some of the use cases in the lab: "Suppose you're on this trail, and you encounter..."
• Play on the natural instinct of people to have fun: set up an obstacle course or treasure hunt. "The sky's the limit."
• Instead of a maximum number of taps, give users guidance. Restricting taps should be a flexible goal; focus more on program flow and usability than on some arbitrary tap count.

References:

• Information In Place from Bloomington - talk to Sriram