Have you ever heard about Norman doors? You know, these kinds of doors where you wanted to pull, but they are intended to be pushed – or the other way around? While Donald Norman never wanted to become famous by this quite simple, but effective example, he wrote a great book I can only recommend to all of us: The Design of Everyday Things (DOET).

You think that you are no designer? Your concern is about locators, extraction design and recognition rates? Think twice. Where do you users spend the most time at once a project has been completed? In validation. And this module offers a lot of ways to make their life easier – and even more to make it much more difficult. And still, much of the time allocated in order to complete a project is dedicated to extraction design, while validation design is neglected. Fine tuning a locator may yield to better extraction results, which may affect your recognition rates by increasing them by, let’s say, to 70% percent – but what about the cost of the other 30%? A poorly designed validation interface may cost a lot of time and can upset your users. So I decided to dedicate this post to validation design. About what you need to do in order to completely upset end users.

DOET and KTM?

So exactly how is Norman’s The Design of Everyday Things related to Transformation Modules? Quite simple. In his book, Norman analyses what makes some common so special – in both a positive and a negative way. Probably the best example is the Apple iPhone – most mothers and even some grandmothers can work with it. But sometimes you encounter bad design – think of the light switches in your house or your office: do you know which one operates which light?

For your users, Kofax has become an everyday thing. Some of your operators start their computers in the morning, and except for some breaks they constantly work with Validation. Hell, that’s a lot of time. And now imagine doing your day-to-day tasks NOT with your fancy iPad, but with an old Windows Tablet. Yes, with a stylus. That’s where DOET and KTM do meet: design for your users.

Making things worse

I do not want to elaborate about the whole book (I want you to read it), so I focus on the most important section for KTM: Chapter six, The Design Challenge (p.178f), How to do things wrong. Norman suggests how to screw up in six simple rules. Let’s apply them to KTM.

Rule 1: Make thinks invisible

“Widen the Gulf of Execution: give no hints to the operations expected. Establish a Gulf of Evaluation: give no feedback, no visible result of the actions just taken. Exploit the tyranny of the blank screen.” (Norman 2002, p.179)

To be honest: it is not that easy to follow that rule with KTM, as usually the cursor is already positioned in the first invalid field. Also, when a user enters a value into a field and hits the enter button, the field goes from red to green. So we have a hard time screwing up here, haven’t we? But fear not, it is possible. Have you ever implemented a fancy validation rule that made something you were really proud of, just to find out it was never used by your users much later? Great, then you probably hid it in a perfect way. So while it always was there, you never exposed it to your users. Or you probably just wrote it into a manual, which nobody did read anyway (which is great, because you can blame it on the users, see rule #5).

Another great example is not giving any feedback whatsoever. You may have written an innovative script that fetches a supplier from a single field only – a name; so, if your users type Quipu, the full name “Quipu Wolfgang Radl KG” will be exposed, including the (more important) supplier id. But, most important: make sure that you don’t provide the user with any hint whatsoever if no supplier can be found. Punish them with a white screen and no indication no dataset was returned, and they’ll stop using the function sooner or later. The next screen shot shows what I mean: the button has been pressed, but there is no feedback whatsoever.

Want to break that rule? As I stated in another post, ActionEvents or a similar approach are great for telling your users a) what is about to happen, and b) what just had happened.

Rule 2: Be arbitraray

“Computers make this easy. Use nonobvious command names of actions. Use arbitrary mappings between the intended actions and what must actually be done.” (ibid)

Oh, this is easy as to follow as well. Ever had a field that remained invalid, no matter how many times you hit enter? Just connect a validation rule, but don’t not give any indication that an error occurred (following rules #1, #4 and #5 as well). Even better: make a multi-field validation rule that sets many other fields to invalid. So, what the user did expect when hitting enter? One field turning green, or at least a helpful hint why the input was rejected. What your returned instead was not only one field being invalid, but many others as well. Have a look at the next image: the user expects the field to turn to green (=expected action). Make sure it does not.

Non-obvious commands? Use your fantasy. When doing a vendor lookup in validation, have one button per field that is searchable. Put one button there for looking up by name, one for the VAT id and one for the bank account number. Oh, and yes, name them with “N”, “V” and “B”. No one will ever know what each button does.

Want to break that rule? Be precise with your commands. Usually, you got plenty of space on your validation screen. If you run out of it, put another tab on the mask and make sure your users do not have to scroll up and down. And for example, write an intelligent vendor lookup function that does not care about which fields the users has pre-filled. Just make sure they don’t have to re-type them again.

The image above shows: an intelligent lookup does not care what the user entered. Even the street or a city in combination with a vendor name would have yielded fitting (fuzzy) results!

Rule 3: Be inconsistent

“[C]hange the rules. Let something be done one way in one mode and another way in another mode. This is especially effective where it is necessary to go back and forth between the two modes.” (ibid)

Especially easy to follow with hot-keys and the general layout. Think of a customer who operates two different invoice scenarios with your solution (your customer might be a service provider). Each kind of project is unique, so make sure they do look unique as well. It is very likely that both projects will have a supplier lookup button. Well, assign the hot-key F6 in the first project, and F7 at the other. You can even increase the effectiveness if you have one project with many classes: make sure that you make as little use of specialization as possible. Even if all classes do have some similar index fields, swap them on the validation design.

The sample above is pretty nasty: class A starts with the First Name, class B with the Last name. I saw that once, so don’t say no one would implement it that way. This actually is consistency by its finest: it works until to that point where KTM did not recognize the names automatically.

Just a small thing, but nevertheless helpful: use different font types (the smaller the better), define different widths for text boxes, make sure they are not aligned. Ignore psychology that eyes follow objects by size, and make the least important field as large as possible. Have a look at the next picture and consider that being your user interface from now on.

Want to break that rule? Create design guidelines in your company and make sure they are followed. Supplier lookup button? Always F6. Font type and size? Use a monospaced font, at least 11pt in size. Copy validation layouts from already existing classes. Create one document class right under the project that acts as a generalized class, containing all the index fields your more specialized classes do share (KTM implements the concept of inheritance perfectly – use it)!

The above image shows an example of a clean UI design. For labels, the font Georgia is used. Text fields use Lucida Typewriter, a monospaced font which will make it much easier to work with numbers (yeah, I know that you can not right-align numbers with KTM, which is a shame). Also, viewers and text boxes are arranged vertically, as humans do have a harder time comparing text which is arranged horizontally.

Rule 4: Make operations unintelligible

“Use idiosyncratic language or abbreviations. Use uninformative error messages.” (ibid)

Great news: this rule is especially easy to obey. Odd language? Just stick to our techie speak, or even better: directly return err.description:

Uninformative error messages? No problem, the default validation rule already offers one of the most uninformative message possible.

Want to break that rule? Start thinking like an operator. They are no programmers, so your language needs to be a different one. Even better: don’t tell them what went wrong alone, but also give a hint on how to overcome that obstacle.

Rule 5: Be impolite

“Treat erroneous actions by the user as breaches of contract. Snarl. Insult. Mumble unintelligible verbiage.” (ibid)

This is my favourite as KTM already provides you with all you need. Again, the default validation rule is pretty impolite here. Remember the user violated a contract, but refrain from telling them how they could improve.

But even better – when working with invoice projects, the invoice (amount) validation is a perfect example of being not only impolite, it even reminds the user of how bad their calculation skills really are. The next picture is literally telling the user: A + B is not C. Detention for you it is. Go on – can you see what the problem is, in let’s say, under 10 seconds?

Want to break that rule? David Wright from Kofax once provided my with a great metaphor: KTM behaves like a robot. But you decide if that robot is a Cyberdyne Systems Model 101 Series 800 Terminator, or that helpful Lt. Commander Data from Star Trek (okay, for the Star Wars fans among you) . So how about that: instead of telling the user that their calculation is wrong, provide them with suggestions for the missing amounts?

In the above image, we have replaced the Terminator with Lt. Cmdr. Data (or R2D2, if you prefer). He’ll still tell you that the amounts are not valid, but will also provide you with an indication what the issue could be! Turns out that 200 Euros are responsible for our mess. Either Net Amount 0 is wrong (200 to much), or Sub Total and Total must be raised by 200. While the original error message just tells you that something is wrong (you still need to calculate those 200 Euros by yourself), this little adoption does rub the solution under your nose.

Rule 6: Make operations dangerous

“Allow a single erroneous action to destroy invaluable work. Make it easy to do disastrous things. But put warnings in the manual; then, when people complain, you can ask, ‘But didn’t you read the manual’?” (ibid)

While it was hard to follow rules #1, this one is very easy – because of the reason that KTM unfortunately does not offer any undo-function out of the box. Except for single fields, where you always could hit ctrl+z. But for everything else: operations in validation are pretty dangerous. Delete a table row, or even the whole table. Oh, you want it back? Too bad. Select a new supplier using the lookup function. You want to restore the supplier that previously was filled in? Nope.

My favourite one: don’t warn the user once the documents have been validated, just close validation. Oh, you needed to go back? Too bad, the batch already is in export. Sure, you could do that with the batch manager, but you’d better be fast. Oh look, you’re too late, the batch is gone already.

Want to break that rule? Well, I have to be honest with you: this might be the most difficult thing to do, yet it is possible. While it’s kind of easy to implement an undo-button at the supplier lookup (just store the supplier id in the field changed-event, so you could go back at least one step), a table undo is more tricky. Well, maybe I’ll write my next article about that.

References:

Norman, Donald A., 2002. The Design of Everyday Things (2002 ed). New York: Basic Books, 1988.