Here’s a screen from an application I’m building at work. For ease of reference, I’ll call this screen Figure 1.
Figure 1: Requisition screen.
You can’t complain about the design unless you’re willing to send me a comment on how I can fix it. Besides, I’m going to be complaining about it anyway.
Some simplified definitions:
- A requisition consists of a collection of samples and study data.
- Samples are matter taken from a body: various tissues, blood, urine, etc.
- Study data includes the study identifier, some patient information, and some information for billing purposes.
The interface in Figure 1 uses tabs to break up the sample and study data datasets. This provides a sparse, cleanly-laid-out UI. But is it too sparse?
Yes. It is. Here’s the problem (as I observed it) from user testing. It’ll probably help to have the screen figure up as you read the below text, unless you already know what the problem is.
Users would progress in a downward motion through the form. This was expected. After that, they’d click “Save Changes”, which is a quite logical thing to do, considering its position relative to the form.
This is permitted — neither the application logic nor the data model places any restrictions on data entry order — but it’s not the interaction model that I had in mind. I thought that users would progress through each tab first and then press “Save Changes”.
The upshot of all this is that users became confused about sample entry, and wondered why entering samples required two trips to the same page. After I explained that clicking “Save Changes” saved data for both tabs, they immediately understood the implications and began to use the interface in the way that I initially thought they’d use it.
(An aside: Why did I even use tabs the way I used tabs? Well, to be honest, it’s based off of my own experience. When I see a page of tabs, I go through each tab, provide the data, and then assume that any controls outside the tab apply to all datasets. Whether or not this is how the majority of computer users think is irrelevant; the real lesson here is that trusting your own experience in UI design is a very bad idea. Because you’re always wrong.)
Anyway. The fact that they didn’t use the interface in the way I meant it to be used meant that I had a problem. My test group wasn’t everyone who would use the application; there would be future users, as well, and they would be starting out from square one, just like my test users did. They’d probably do the same thing, and hit the same frustrations. What to do?
The obvious solution is to document the application, but I didn’t want to burden the application with lots of inline documentation. That’s too hard to read, and it clutters the UI with stuff that people will read once and never read again (which makes said documentation useless). Besides, I don’t like the idea of applications that try to force you to match their expectations. Man-machine relationship and all that.
A much better solution is really, really simple, and I bet that everyone reading this has already come up with it.
I’m going to put “Next” buttons at the bottom of each tab, and put the “Save Changes” button on the last tab. In this way, it’s possible to let advanced users use their own workflow (which is one thing that tabs facilitate) which guiding novice users with a gently-defined procedure (which is one thing that tabs, by themselves, are totally inappropriate for).
There’s another UI problem in this same page (second tab, really) that I’ll write about later. I’m interested to hear, though, how many people reading this immediately saw my design as problematic. (I obviously didn’t.) If so, how do you know? What principles do you use for UI design?
There’s a couple books I’ve got on my to-read list for this sort of stuff (since it’s obvious that I don’t know jack about UIs), but personalized insights would be great, too.
