Archive for April, 2008

UI for the People

3 April 2008

When I first started working with user interface (UI) design the process looked something like this: Take an existing paper template, copy it to the screen and make it work. What were the benefits of such approach? For one we did not have to spend much time on UI design – we simply added fields to the screen where they existed on paper. The other benefit was that people who were already familiar with the paper form had no problem understanding the UI page visible on the computer screen.

What were the drawbacks of such approach? For historical reasons paper forms were rarely ever “designed”. They simply grew over time until they were deemed sufficient for the task they had to perform. Using such forms as UI templates was hardly the smartest thing to do – they were a real pain to work with even in their original (paper) form, and only the most experienced of users could find their way around them. All new employees had to suffer the pains of learning those forms – no matter if on paper or on the screen – through trials and errors.

Then time came for full-fledged UI design. A new profession came into view – usability expert. Developers started to realize that copying paper forms was hardly the best and greatest when it came to user interaction. In all truth paper forms were downright evil when incorporated as-is into software – they simply functioned in a different way. The time came for input dialogs, task wizards, user-centered design – the works. Though an occasional experienced user grumbled a little after being forced to learn how to use the new UI all over again even he/she could see the benefits of the new – smarter – design. Users who were only starting with the new software were downright happy since the new UI was much easier to use than paper forms from hell.

Unfortunately it seems like the process of improving the UI stopped right there. Someone might ask what else could be done to make the UI better? After all the UI of today does everything what it needs to do, and in a sensible and efficient way.

Here is a question to think about: What is the real benefit of using computer software? Depending on who you talk to you might get a different answer:

“Computers are fast and they perform better.”

“You can undo and redo changes with ease.”

“Computers connected via network let you share data with other members of your organization.”

And so on.

All those answers are valid, but to me the greatest benefit of using computers in office work is capturing the business logic. A good UI not only serves as a tool but also embeds the knowledge of business it was designed for. When a bank clerk tries to enter alphabet letters into a field called “Amount” an error message appears: “Amount is a number – enter digits!” This simple input validation step captures certain amount of knowledge of the banking industry. And this is just a simple example. Whole scripts can be created to control financial securities trade. There is software that controls robots in car factories. Each of those programs encapsulates the knowledge of how to do something.

So what can be done to make the UI better? Here are some thoughts. How about not only give people the tools to use, but also the knowledge on how to use them? A simple hover pop-up box with information on what clicking the selected button does could teach a new user how to use the UI in no time. Providing the user with a list of possible work flows (for example a list of step-by-step wizards) could explain to him/her how the business works. Not to mention including links to examples right there, on the page the user currently works with.

It is a well-known fact that people don’t read FAQs, manuals, etc. Anything longer than a sentence scares users off. That’s why “sprinkling” the interface page with small bits of helpful information – not like “in order to open a banking account you have to …”, but more like “e.g. click this, click that, enter this …” – might be a better choice for information injection. Some good examples from among the existing software are examples at the bottom of the Linux manual (man) page, or at the bottom of Ant task descriptions. Once people get used to the UI they might not need those examples anymore, but such small bits of info should cut down the overall learning curve.

Such approach would make the UI not only a tool, but also a teacher. After all people are only people, and they do make mistakes, no matter how experienced they are. Mistakes can be made when using the software, but also when explaining to another person how to use the software in question. I’ve seen this happen: people running from cubicle to cubicle, looking for answers, when the only experienced person on the floor was out for lunch.

For developers with a bit of imagination it shouldn’t be too hard to see how expert systems – and possibly AI – could be incorporated into the business logic to make a complex task execution automatic. After all computers evolve much faster than people, so the computing limits we face today might not be there tomorrow.

It is important to remember that human society is changing and that computers play greater and greater role in it with every passing day. It’s old news that more and more human-performed tasks are represented in computer software. Creating a smart UI – UI that teaches users about the business it was designed for – is a step in the right direction.

Marcin Citowicki

css.php best counter