Penn UI Conference Day 2 (07/22/10)

This post is a continuation of my notes from the University of Pennsylvania’s UI Conference. Notes from Day 2 are below.

Angry Dinosaurs

by Cory Ondrejka

• Beware of process theater
• Agility = develop the best thing you can for your customers
• Maximize innovation = maximize experimentation
• Chris Anderson “Free”
• Detect the change that’s occurring outside your organization
  -> who will detect it first?
• Institutional incompetence is accelerating
• Look at your data! Create value and build on it
• Gather more data cheaper and faster
• Communication and learning from each other
• Be ready for your customers to compete with you when you share all of your data
• Getting out of the way: don’t make your data proprietary or inaccessible
• Driving institutional change
  • Hard to be fearless and lead fearlessly
  • Are you bold enough to admit you’re not the best leader?
  • Can you get others to follow?
• Driving transformation
  • Focus on business goals
  • Admit reality
  • Communication
  • Find internal leaders
  • Embrace agility
• How will you keep up in a world of change and Moore’s Law?
  Reality is exponential, not linear
• Failure is a reality but hopefully you will fail fast, cheaply, and publicly
• Institutions should not punish failure, especially if you learned something from it
• Experiments need expectations, reporting, and measured outcomes to avoid burning money
• Data (1), interfaces (API) (2), bully pulpit (3), get out of the way (4)

Making Sense of Usability Results

by Dana Chisnell

• Get everyone to observe the users
  • More buy-in
  • Less reporting
• Observations before solutions
  • What we heard, what we saw
  • No interpretations!
• Data sources: usability testing, user research, sales feedback, support calls & emails, training
  -> Direct observation is the best
• Focus on behaviors and then make inferences
• Make sure you get everyone’s inferences because they can be subjective
• Inferences: judgments, conclusions, guesses, intuition
  -> The wrong inference can be disastrous
• Opinions: what could we change in the UI
  • Review the inferences
  • What are the causes?
  • How likely is this inference to be the cause?
    • How often did the observation happen?
    • Are there any patterns in what kinds of users had issues?
• Observing users in their own environment is more useful than a lab, which is overkill
• Observe from a few minutes to an hour
• Design direction
  • What’s the evidence for a design change?
  • What does the strength of the cause suggest about a solution?
  • Test theories
• KJ analysis -> uie.com/articles
• Usually not A/B testing -> iterative change is better for usability testing
• A/B testing is good for disagreement among teams but you need enough people to test for viable results
• Solution jar: pay for each time you jump the gun and suggest a solution (.25)
• If you do a review without usability testing make sure you delve in to who the users are and what their tasks would be and analyze those tasks being completed on the site
• Your time is not more valuable than your customer’s time
• Analytics is not useful because you don’t know why those things happened
  -> Could be useful in analyzing drop offs in clear navigation paths
• Motivation is important for usability testing -> the users must be motivated to complete the task and would complete those tasks in real life
• Download presentation for chart
• Observation -> Inference -> Opinion -> Direction
• Debate on whether you should ask your user how they feel during the process among usability professionals
• Debrief of user after testing
  1. How’d that go?
  2. What are two good things about the site?
  3. What are two bad things about the site?
  • Pay attention to the length of time it takes participants to come up with those answers
  • You’re in good shape if can’t come up with bad things
  • You’re in bad shape if can’t come up with good things
• Come up with 5 tasks you’re going to test
• usabilitytestinghowto.blogspot.com

Web Forms: Makeover Techniques

by Hagan Rivers

• Most designs fail as an aggregation of little aggravations (“death by a thousand cuts”)
• Forms are work! Too many barriers and rules
• Makeover techniques
  1. Use your words
     • Responsibility to choose good words for your labels and error messages
     • Use the appropriate amount of words, as few as possible while still being clear
     • Avoid jargon = words that make no sense; use your users’ jargon
     • Keep instructions near the task at hand
  2. Find your voice
     • All software has a personality
     • You can shape that personality or not
     • Forms are where users do a lot of reading
     • Your brand has a voice
     • Imagine who is speaking – who is that person?
     • Don’t let software engineers do the writing
     • Have one person monitor the voice of the app
  3. Say why
     • Tell people why you require certain information instead of just making information required because people will then lie
     • Tell the user why he should enter info
  4. Prevent errors
     • Good defaults really help (filling in city and state based on zip code)
     • Don’t play “go fish” (give users suggestions for user names that are available instead of making them guess on ones that would work)
     • Don’t require formats (phone #, etc)
     • Don’t “force” the user
  5. Handle errors
     • Tell the user what went wrong
     • Tell the user what should the user to next
     • Be specific
     • Use terminology from the interface itself
     • Submission vs. inline errors
     • Brief summary at top when on submission
  6. Be appealing
     • Beware of your alignment
     • 2 column form? Put required fields in the left column
     • Reduce clutter, lines, boxes
     • White form elements on a white background have no contrast

Web-App Navigation: Makeover Techniques

by Hagan Rivers

Look up “Blinksale.”

Part 1: Theory (Types of Navigation)

1. Global navigation
   • The same on every screen of the application
   • The goal is to get the user to the main screens of the application
   • Not just a site map but putting all of the tasks in an easy place
   • Supporting the initiation of tasks
2. Local navigation
   • The navigation for here and now -> the place where I’m at
   • Manipulating or interacting with a table for instance
   • For edit screens w/Save & Cancel, no Global Navigation needed
3. Cross navigation
   • Tool for jumping to related items
   • Concierge of navigation
   • Whole goal is to save you clicks
   • 3-5 crosslinks is enough
   • Not part of the task at hand
   • Need to be hand-crafted
4. Dashboard navigation
   • Links to screens
   • Does away with global navigation
   • Users shouldn’t need to edit the dashboard if implemented correctly so don’t provide this functionality
5. Application maps
   • OmniGraffle

Part 2: Practice (Improving Navigation Systems)

1. Never use icons for navigation
   • Direct correlation between the time it takes you to think up an icon and the time it takes your user to decipher it
   • Its hard to translate words in to pictures
   • Icons are good for status and representing actual objects, don’t use it in nav!
2. Trees
   • Are super “clicky” if not done well
   • Trees don’t work when they’re really long or wide
   • Trees are a slippery slope in that everyone will start stuffing stuff in to it
   • Collapsing never works to the left
3. Pull right menu (nested menus like the OS)
   • Harder to select items
   • Try to get rid of them!
   • Indent items and stick in one menu (multi-column?)
4. Site map
   • Put in footer as secondary nav system
   • Works for long pages
   • Can indicate where you are in the site
   • Haven’t seen them as much in web apps
5. Tab explosion
   • Save tabs to where your nav isn’t going to get too long
   • Hard to find stuff, they all look alike
   • If you color code your tabs it makes your app look like a bag of Skittles, people don’t make a strong association with color so not worth it to do this
   • Eventually you will outgrow tabs
6. Menubar (menus like an OS)
   • System toolbar tucked up right at the top of the window
   • Allow you to have many commands in one space
   • Careful that the navigation doesn’t start to eat in to that actual work area of the app
   • Commands are hidden
   • Work well for global nav
   • Don’t open menu on hover, only on click!

• Start designing from inside out
  • Work on screens before global nav
  • Design global nav last
  • Keep up the app map
  • Treat the global navigation as a mini application that is separate
  • Mix and match different nav systems
  • Test users