The world is full of glasses wearers, and there are many different styles of glasses. Many of them wear theirs on their nose. But there are other kinds of glasses that are not set directly on the nose, but rather are secured to our heads.
User interfaces are an example of both eyewear worn by developers and users alike.
The developer of a machine sees their user interface function-specific with his glasses. He sees which functionality a button triggers, and he knows the result of the process. So if the developer calls a button "Locking Pin 2 at End-Position", then he will be very pleased when his glasses read the button’s name. It precisely reflects the function that he already knows in detail. The developer knows that this function will lock a door.
The user’s glasses are easily task-specifically "tinted". He doesn’t necessarily realise that the product has a Locking Pin, and he probably doesn’t know what the End-Position of Locking Pin 2 is. The user maybe just wants to lock a door. His glasses require a button with text that will be appropriate for the solution of his task. Maybe he will actually press the "Locking Pin 2 at End-Position" button. Maybe he does this without consulting the operating manual because he suspects that a Locking Bolt has something to do with locking. In the best case, he scores a fluke, and in unfavourable cases, it causes property damage or someone gets seriously injured. He probably reads something like "Locking Pin 2 at End-Position" after pressing; he frowns, and still doesn’t know whether he’s really locked the door.
If the user goes into the operating manual to look for help, he may also happen to have reading glasses. However, this might not help him much, even though the operating manual was written by developers who, above-all-else, cherish technical detail. Perhaps the user will find specific content to lock functions, process sequences, and machine states. The same terms may be used to refer to the buttons that are displayed on the user interface. There are probably differences, because at some point a Lock Bolt may have been used instead of a Locking Bolt. The operating manual could not have been updated, since the developer had to return to his main task. The user therefore reads a sentence in the operating manual such as "Press the Button Locking Latch 2 to End-Position to Activate the Blocking Function of Inlet Flap 1". Not only that the user doesn’t understand how to handle the product. He’s also defeated by the feedback from the product and the real assistance of the operating manual only leads to even more confusion. High quality is perceived differently. At this point, the user just wants to put on his sunglasses and simply head home because he’s had enough.
Products that do not take the requirements and expectations of the user into account are nowadays quickly tossed aside. But how can you fulfil these requirements and make complex products and operations both simple and understandable? How do you create "Usability" and "Smart Information"?
Here, Technical Editing comes into play. As a Technical Editor, I’ve developed an awareness that there are glasses, and I’ve acquired a few pairs. So I can put on the glasses of the project’s developers’ every day, in order to understand the many functions. This is the most important requirement for me to understand what I’m writing about. In my editorial work, I switch to the user's glasses, because I want to prepare the content so that it can be easily understood.
So it also makes sense to participate in the design of user interfaces. For this I analyse, for example, the essential characteristics of the user, his or her objectives and tasks. This allows me to help design interfaces that avoid operator error and are intuitive to use. By taking usability aspects into account as well, target group-specific terms (Terminologies) of the user interface can be built up according to a pre-defined concept. It would be really exciting if Content Management Systems and the Programming Environment would be linked together so that the software texts come from one source, and thus the designations in the documentation and product interface are always consistently the same.
This makes the creative process more efficient, and the user gets along much better – a win-win situation that serves everyone. By the way: The button is now called "Lock Door".
