Technical Translation: Usability Strategies for Translating Technical Documentation

Structure 
The way in which a user guide is structured is fundamental to the success of 
the user guide and the ease with which readers can use it. Far from being a 
vast, disordered repository where information is dumped and through 
which users have to sift in order to find the information they need, a good 
user guide presents users with the information they need and, just as impor-
tantly, when they need it. The way in which information is structured in a 
user guide can depend on such things as the nature of the product being 
documented, the background of the audience, the tasks the audience needs 
to perform and so on. If a user is bombarded with information, the likeli-
hood that they will find the information they need, much less understand it, 
is greatly reduced. To combat this, we can structure user guides in a num-
ber of ways: 
Chronological
: this structure is used, for example, to describe steps or 
tasks that need to be carried out in sequence
General-to-specific
: this can be used to describe, for example, the back-
ground, preparations and safety precautions needed before providing 
step-by-step instructions
Problem-Methods-Solutions
: this type of structure is particularly useful 
for providing tutorials, maintenance information and trouble-shooting 
sections or guides and it presents information according to specific prob-
lems and the measures needed to resolve them 
Cause-Effect
: this structure can be used in conjunction with the 
prob-
lem-methods-solutions 
approach for trouble-shooting sections or it can 
be used to describe the components of a product, e.g. the interface but-
tons and toolbars. 
78
in question. A drawing or diagram of the particular area would be more 
ef
focus attention onto the specific part while eliminating distracting visual 
•
•
•
•

---

Software User Guides & Quality
According to Weiss (1985:50), user guides are structured in that they repre-
sent a top-down approach to a particular task, e.g. providing information 
on a software application. By this we mean the user guide starts with the 
“big picture”, the largest possible overview and then progressively and sys-
tematically adds more and more detailed information. While it is generally 
held that this top-down approach involves breaking concepts into smaller 
and smaller ideas (cf. D’Agenais & Carruthers 1985:68-9) – a process 
known as “decomposition” – it is, in fact, only a small part of the structured 
approach to user guide design.
First and foremost, a user guide needs to provide a broad overview in 
order to explain how the various constituent ideas and tasks relate to each 
other. This can be explained as follows: using the example of a piece of 
website management software, the big picture is creating a website but in 
order to do this we need to create the web pages. We then need to create 
directories in which to store the pages and, once we have done this, we 
then need to know how to upload the pages and directories to the web 
server. 
As a result, we can see that we need to create the directories in order to 
store our web pages effectively and to allow navigation but these pages and 
directories cannot become a website unless we know how to upload them. 
Similarly, we cannot upload a site if it is not organised into directories. 
Neither is there any point in uploading directories if they do not contain 
web pages. So in addition to breaking ideas down into smaller tasks, we 
need to tell readers how these tasks all relate to each other. Thus, a user 
guide will generally consist of many small units or modules, all of which are 
connected in a way that will make it clear to readers what they are learning 
and why.