A good human interface designer can usually work out a workable solution to an interface problem in short order once the problem becomes visible. The problem is usually spotting the problem in the first place.
User testing’s real benefit is spotting problems that the designers overlooked. Another way to get feedback on how well your human interface is working is to be the one who answers the tech support email. In this sort of small-shop scenario, an interface designer who wants to stay sane has a powerful motive to fix badly designed features–fast!
Every once in a while, however, a problem comes along which defies any sort of elegant solution. The underlying cause is usually conflicting design goals, or even a split in the way different groups of users view or use the system. More rarely, there’s a very lovely and elegant solution that’s possible, but for technical reasons, it can’t be implemented. Rare on desktop applications, I’ve come across this latter problem all too often in web design.
Take the following, very simple dialog as an example (and for now, I’ll break the cardinal rule of Interface Guru-dom and actually criticize a real product that I had a hand in designing: in this case, the web-based ComicBase registration screen):
On one hand, I quite like the sheer minimalism here, and if you can momentarily forgive that the “Save” button would be better labelled “Register”, at first it seems like a nice little screen.
The fatal quirk comes as a result the peculiarities of the registration system. ComicBase FREE doesn’t require (or have) a serial number; other versions of ComicBase do. The system figures out which product you’re registering using the serial # you’ve entered. In some cases, the user will have to select between a few related versions of ComicBase using the drop-down, but usually the drop-down’s list can be populated with the one or two choices that apply. As such, the user’s path through this screen is:
1. Enter a serial # (or select ComicBase FREE)
2. If a serial # was entered, click the “Check” button to validate the number (and populate the product drop-down with the list of possible products).
3. Choose which of the possible products you are registering
4. Click Save
It sounds reasonably simple, but you may have noticed that there’s a rather interesting set of dependencies and modalities implicit in all this—none of which are communicated to the user.
If the product being registered is the FREE version, the user is meant to ignore the Serial # field altogether and just click Save. While that’s a bit inelegant, the real problem that users reported on the tech support lines was that, “I can’t register my program, because I have ComicBase <x> and the only option is the FREE version!”
The culprit is the “Check” button (indeed the very need for it). The Check button is there to cut down a very long list of possible products—many of which have very similar-sounding names—to just the list of valid products for that serial number. At the same time, it ensures that the user isn’t entering invalid or garbage data. While it’s performing a very important function, however, many users never think to press it, so the drop-down list is left showing just ComicBase FREE.
And they call tech support (bad) or just give up and don’t register (worse).
What’s the solution? It’s hard to say. There are any number of possible redesigns that solve all the process problems by making the dialog much larger, breaking the process into multiple steps, and so on—all of which can be worse than the original problem.
What breaks my heart as a designer is that there’s a fairly effective and reasonably elegant solution that gets used all the time on the desktop, but which is hard to implement in a multiple browser-supported way on the web: simply get rid of the Check button and do all your checking in real time as the user types (or when they exit the field).
If we could do this, then—like magic—the list would always have valid data in it. If we could further control the Save (err… I mean “Register”) button to be dimmed once the user started typing a serial number, but enabled it again once they finished typing a valid one, we’d have the whole thing worked out. As a bonus, we’d have lost an interface element in the process, adding to the overall flow of the already minimalistic design.
Perhaps at some point, I’ll get clever enough to work out an implementable solution like that. In the meanwhile, however, I’ve been forced to use the Mark of Shame for interface designers: Help Text:
(As a nod to interactivity, the help text disappears when the user enters a valid serial number and clicks Check (an “OK” appears next to the Check button to indicate that the serial # is valid and the product list visibly changes).
The redesign hasn’t been user-tested yet, but I’d be willing to wager that it largely—if inelegantly—solves this particular problem. Even so, this particular interface bug won’t really drop itself from my mental “to do” list. Guideline to all interface designers: whenever you solve an interface problem by adding instructions, you haven’t really solved the problem.
Using help text to paper over an interface problem like this is like the folks who tape red cellophane over their tail lights after a fender bender so that their brake lights once again appear red. Yes, this sort of Band-Aid approach handles the most urgent problem and prevents disaster, but you’re not really fooling anyone. Unless you’re planning on ditching the car (or program) soon, you’re going to have to eventually scrape enough resources together to solve the problem properly.
