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.
Next: The First Date >>
More Practices Articles
More By Deepa L, (c) Melonfire
/ 4 
