Matching It All Up - Practices

Having set the boundaries and the process for the delivery of interface text, it is now important to understand the approach required. Developing interface text requires two areas of knowledge: knowledge of the domain for which the application is being developed, and knowledge of the principles of developing good interface text. I'll address the first one, domain knowledge, right now and leave a discussion of the principles behind interface text to the second part of this tutorial.

I think you would agree that knowledge of the domain for which the application is being developed is essential - and by the time you are through with designing the application's labels and messages, you will have a thorough understanding of the processes which are being addressed by the application.

The important thing from the perspective of interface text is to imbibe the verbiage of the users and to understand the changes that your application will bring to their workspace...and how the changed aspects are to be worded to retain association.

What happens usually is that tasks otherwise manually performed by the users change drastically in appearance when they become application-enabled. Let's take a simple example: all workers in organizations submit vouchers for reimbursement of cash expenses. Enabling this in an intranet-based aoftware application would (most probably) require them to submit a form detailing their expenses for approval by the cashier, the cashier approving it at his/her terminal, and the amount getting deposited in the user's account as a result of the approval.

There are two levels of change being introduced by the application-enabling of this process:

1. There is now no voucher in existence. What the users are filling and submitting is an online form.
2. The actions required to perform this task change. - The user no longer gives a voucher to the cashier - The cashier no longer signs his approval - There is no separate act required by the cashier to deposit the amount in the user's account - the deposit happens via automatic trigger.

Now, if we were to consider the online and real-world equivalents for this task, we would have the following table:

--------------------------------------------------
Real-world | Online
--------------------------------------------------
Voucher | Expense form
|
Give voucher to cashier | Submit
|
Sign voucher | Approve
|
Dispatch cheque | NA
--------------------------------------------------

In order to reduce user confusion and quickly familiarize them with the new world, the application's interface should use the original term for the task, and the newer, unfamiliar online terms for actions related to the task.

For example, here is a simple menu tree for the example application above:

Main menu
|
|-- Vouchers
|-- Submit
|-- Approve

Users know and expect that your application will change the way they do things. As long as your terminology is indicative and can easily be referenced against the old way of doing things, they will live with it, and probably learn to love the efficiency. But if your terminology is hard to understand, or makes them re-learn what they already know, they will hate you, your software and your organization. Making sure they pick door one, and not door two, is really the prime task at hand.

In the next article, I will be continuing this discussion with a quick roundup of the principles behind writing good interface text, together with a series of examples that will illustrate my point. Make sure you come back for that!

Note: Examples are illustrative only, and are not meant for a production environment. Melonfire provides no warranties or support for the source code described in this article. YMMV!

>>> More Practices Articles          >>> More By Deepa L, (c) Melonfire

blog comments powered by Disqus