Q: What is usable?
A: That which is measurable.
When it comes to usability in software everyone has an opinion: “Put the button here”, “make the font type this”, “use this color as the background”, “make the click sequence like so”, on and on and on.
The sad little fact is that opinions are like fingers; just about everybody has at least one. And like fingers, you really don’t have to go through any special effort to have them.
So maybe usability is more than an “intuition” about how the software should work. Today just about everybody has an intuition as to what a Save button does and what a little red asterisk next to an empty textbox means. There’s a big difference between intuition and desire. To my observation, when someone says that a piece of software is not intuitive, what he or she really means is that the software “is not doing what I want it to do.”
So I’ll let you in on a little secret: Making software more usable is not about understanding what the user wants. It’s about understanding what we want the user to do with our stuff.
This I learned when I worked for the computer manufacturer, Gateway.
Back around 1996, Gateway built a Usability Lab in order to save a yacht load of money on tech-support issues. (They were getting mauled on the phones. Ten thousand phone calls a day, at $27 a call adds up!)
They hired a bunch of Ph. D. level Human Factors Engineers. Because I knew a thing or two about operating systems, desktop applications and component integration, being the Consumer Platform Architect, they invited me to join the team and go along for the ride. So I did.
The Ph. Ds taught me two essential things. The first was to put instructions directly on the screen whenever possible. Don’t make the user wade through documentation in a help window.
The second and probably most important thing that they taught me was this: if you can’t measure it, you don’t know it.
(Actually, I was introduced to the concept while studying Robert L. Ebel in an educational testing course that I took in graduate school. But, as I suffered through a typical high school educational experience in the late 60’s, I looked at testing as something akin to waterboarding. I dismissed that which I should have pondered. But, back to the story.)
The most meaningful work that we did at Gateway was based on quantifying what we wanted the user to do and then developing tactics to concretely achieve that which we had defined.
Computer setup time was a real problem for Gateway. We wanted to cut support cost in half. It was taking 30 minutes and one tech call on average for a buyer to setup a new computer. Our goal was to get it down to 15 minutes and no call.
In another case, users were not browsing the on-line catalog that shipped on each system. Knowing that the catalog was there and then being able to find the desired information was the problem. Putting the catalog icon on the desktop and coming up with tactics to get navigation down from 6 clicks to 2 clicks was the tactic that became the solution after passing the rigors of quantified observation.
Our pattern of execution was the same:
Believe me, there are a lot of people going through life looking for that which they have already.
But, this is supposed to be about usability, right?
When it comes to usability in software everyone has an opinion: “Put the button here”, “make the font type this”, “use this color as the background”, “make the click sequence like so”, on and on and on.
The sad little fact is that opinions are like fingers; just about everybody has at least one. And like fingers, you really don’t have to go through any special effort to have them.
So maybe usability is more than an “intuition” about how the software should work. Today just about everybody has an intuition as to what a Save button does and what a little red asterisk next to an empty textbox means. There’s a big difference between intuition and desire. To my observation, when someone says that a piece of software is not intuitive, what he or she really means is that the software “is not doing what I want it to do.”
So I’ll let you in on a little secret: Making software more usable is not about understanding what the user wants. It’s about understanding what we want the user to do with our stuff.
This I learned when I worked for the computer manufacturer, Gateway.
Back around 1996, Gateway built a Usability Lab in order to save a yacht load of money on tech-support issues. (They were getting mauled on the phones. Ten thousand phone calls a day, at $27 a call adds up!)
They hired a bunch of Ph. D. level Human Factors Engineers. Because I knew a thing or two about operating systems, desktop applications and component integration, being the Consumer Platform Architect, they invited me to join the team and go along for the ride. So I did.
The Ph. Ds taught me two essential things. The first was to put instructions directly on the screen whenever possible. Don’t make the user wade through documentation in a help window.
The second and probably most important thing that they taught me was this: if you can’t measure it, you don’t know it.
(Actually, I was introduced to the concept while studying Robert L. Ebel in an educational testing course that I took in graduate school. But, as I suffered through a typical high school educational experience in the late 60’s, I looked at testing as something akin to waterboarding. I dismissed that which I should have pondered. But, back to the story.)
The most meaningful work that we did at Gateway was based on quantifying what we wanted the user to do and then developing tactics to concretely achieve that which we had defined.
Computer setup time was a real problem for Gateway. We wanted to cut support cost in half. It was taking 30 minutes and one tech call on average for a buyer to setup a new computer. Our goal was to get it down to 15 minutes and no call.
In another case, users were not browsing the on-line catalog that shipped on each system. Knowing that the catalog was there and then being able to find the desired information was the problem. Putting the catalog icon on the desktop and coming up with tactics to get navigation down from 6 clicks to 2 clicks was the tactic that became the solution after passing the rigors of quantified observation.
Our pattern of execution was the same:
- define what we wanted the user to do
- establish a baseline
- set a goal
- create tactics to meet the goal
- test and measure
- rethink when the results are not those desired
Believe me, there are a lot of people going through life looking for that which they have already.
But, this is supposed to be about usability, right?
posted by Bob Reselman at 9:48 AM
0 Comments:
Post a Comment
<< Home