The Importance Of Interface Text (part 1) - Form Versus Function (
Page 2 of 5 )
While
developing interface text would instinctively seem to be a very common sense
affair, there is more to it than that. The biggest area of disconnect found in
interfaces is that the terminology used indicates the technological function
being performed by the application, whereas, when users come to the application,
they're usually there for the purpose of performing a task and have little or no
knowledge of the technology being used to implement the task. This lack of
familiar terminology, added to the new dimension of an online interface, usually
succeeds in throwing users off.
Let's take an example, a form that
requires, say, a user to enter data about the hours of work logged in on various
projects. Prior to becoming an electronic process, this task involved a
timesheet log being delivered to the immediate supervisor, and the supervisor
"approving" the log. The point of disconnect, once this simple process becomes
electronic rather than manual, is the button on the supervisor's screen
containing the term "validate" - which, though accurate, is jargon and not
necessarily something the user is familiar with - instead of the term "approve"
- which the user is familiar with.
This is one of the most common
problems with user interfaces. A developer tries to make the interface
indicative by reflecting accurately what the application is doing at a
particular point. But the user never gains the benefit, since (s)he doesn't ever
relate to, or understand, many of the terms the application
sports.
Besides logical gaps between developer and audience, I have
noticed a habit of approximating the terms used, leaving the task of figuring
them out to the user, who would "anyway know what to do here". This may seem
harmless enough at first, but can often cause serious delays at the user's
end.
Let's take another example, this one from a real project I was
recently developing documentation for. In a form requiring the user to set the
frequency for a particular function, the fields provided looked like
this:
The confusion here should be obvious:
if the frequency can be chosen as "daily", "weekly" or "monthly", what is the
second field for? Or, if the interface allows the user (as it seems to) to
define the function to take place "5 times weekly", shouldn't it also allow the
user to specify the time at which each execution should take place?
To an
end user, a little more clarity here could mean the difference between a
utilized hour and a wasted one. And let's not forget the nagging feeling the
user now begins to have that maybe, just maybe, the application is not all that
reliable after all...
Having set the tone, and hopefully, the necessity
for this piece, let's get the ball rolling. Over the next few pages, I will
attempt to lay down some ground rules to help develop simple and indicative
interface text.
/ 4 
