Instructive Labels--
I should have learned by now not to trust my instincts. Instincts are often the manifestation of programmed learning, which means that our creative and critical circuits have been turned off. That's why collaborative teams are so useful; members can challenge each other's programming.

Huh?

I'm working these days on a team designing an online, interactive workbook that helps a network administrator plan how to install and deploy a security appliance. The workbook has three purposes:

• Advise the administrator about some decisions that need to be made
• Provide a checklist at the end that lists the steps the administrator must go through (based on how he or she answers certain questions in the workbook)
• Direct the administrator to the correct deployment documentation (once again, based on how he or she answers certain questions in the workbook)

I wireframed an approach that I thought had great merit. (It turns out it had merit, just not GREAT merit.) A typical page asked whether the user would use the device in routing mode or transparent mode and was set up like this:

1. The page contained a short intro paragraph that explained the device could operate in two different modes and that the administrator had to designate which mode.
2. Two radio buttons were provided, labeled "routing" and "transparent".
3. Next to each radio button was a thumbnail diagram that showed a typical typography for that mode.
4. Next to each diagram was a description of when/why the user might want to select that mode.
5. Beneath that explanation was a link to provide more detail about the mode if the user wanted it.

//In my next post, I'll talk about why I rejected the design of explaining the required concepts before asking the user to select the mode. That's an entirely different topic.//

Step 2 is where my instincts did me in. It just seemed so right that a radio button group for selecting options should have the names of the options as labels. (Hence my lack of embarrassment--it's not one of those decisions that screams "stupid.")

Then one of the writers on the team asked one of those questions that just makes me go "huh!"

"Instead of labeling the buttons with the names of the modes, which we then have to go on and explain, can't we just label them as statements that get right to the main selection criteria?"

Example
Let's say you have a report output dialog box that includes selecting the output format. The two choices are HTML and PDF.

My instinctive approach is to have a radio button group with two buttons labeled HTML and PDF respectively. My user assistance instinct is to provide a tool tip or UI text that would elaborate on those choices, e.g., "Choose HTML to view the report online; choose PDF to have a printable version."

My colleague's suggestion in the first example would have the labels themselves say "I want to view the report online (HTML)." and "I want a printable version (PDF)."

Clutter or good user assistance? It depends. If you were going to take up screen text explaining the label (as in my first example), my colleague's approach is clearly better. In the second example, we have to make a judgment call about how well known the output labels of HTML and PDF will be. In an authoring tool meant to be used by tech writers--clutter. In a business intelligence application meant to be used by financial managers and analysts--maybe worth the screen real estate.

At any rate, it's always a question worth asking. Let your creativity and critical thinking challenge your instinctive approach.