I was part of some
usability testing of software. Basically the setup was running
through some tasks with a "fake" version of the software (just
images) in front of the people who were participating the tests.
Lots of good things came out of it, but I had a new idea (to me)
about the relationship between the types of questions or tasks and
types of interface expected.
It came about because one of the tasks was to find "whether or
not a particular server being backed up" (this software performs
backups). Because the phrase was in the form of "yes or no"
-"whether the server: is or isn't - it made more sense in my head
to look for a checkmark. Or maybe a column in a field indicated yes
vs. no.
There was information on the screen that said "when" a server
was being backed up - but this didn't immediately answer the query
(it did, indirectly) and didn't seem natural to me.
Let's look at some examples, shall we?
Q1
Ok, yes or no question: "Is a program being recorded on my
Tivo?"
And we see checkmarks. Very clear. No wonder people love their
Tivos.
Q2
Ok, a when question: "When was the last time that my file was
modified?"
Here there is a field of text. We know to look in a column with
text for the answer to a where question.
Q3
How about another yes or no question: "Is my iPod charging?"
Yup, that's a curve ball. This is, by my simple maxim above, the
interface to answer a yes or no question. And, in a sense, it is:
there isn't a charging icon (or, there is): so it is an icon, and
it is binary. But it's found in the location of a "how much" type
of location and indicator.
But this brings us to another point of usability: it's the right
design if that is where your user expects it. And we've learned
(not just on iPods, but laptops and other electronics) that the
"charging" indicator is with the "how much battery" indicator. They
are both about power.
My point is not to draw out all the design issues possible, but
to point out that good design "rules" have exceptions.
BTW, the "yes" state of the iPod charging:
What question is being asked?
So, it bears asking yourself:
- What is your user (or your reader or learner or buyer)
asking?
Specifically, how are they phrasing their question?
And set up your information to answer not just the question: but
the type of question being asked.