The Importance Of Interface Text (part 1) - Matching It All Up (
Page 5 of 5 )
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:
- There is now no voucher in existence. What the users are filling and
submitting is an online form.
- 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!