Technical Translation: Usability Strategies for Translating Technical Documentation

participant’s session were marked with this ID exclusively. In order to keep 
a record of the participants’ details and their IDs, a separate Tester ID sheet 
was maintained (see Appendix 3). 
Task Sheets 
When conducting a usability test under the time constraints of a laboratory 
experiment, the participants must be told what work they should perform 
using the software if the experiment is to be effective. Of course, it is not 
uncommon for software companies to release advanced prototypes of appli-
cations (known as 
beta versions
) to a group of users who are simply asked 
to find errors or problems (Schneiderman 1998:131). However, such an 
approach, apart from being extremely difficult to standardise, would be im-
possible to use within the time constraints of a laboratory-based study. Also, 
open-type “bug hunts” such as this are generally performed by advanced 
users with more expertise than the participants in our study. 
217

---

Assessing Usability 
Instead, participants need to be guided through those tasks which will 
highlight potential usability problems. According to Dumas & Redish 
(1993:160-163), there are a number of ways of selecting tasks for a usability 
good idea of where potential problems lie. However, it is precisely this de-
tailed knowledge that can result in designers focussing on more complex 
and advanced problems while overlooking the lower level problems likely 
to affect non-expert users. 
The second way, which was adopted here, involves basing tasks on what 
real users will actually do with the software. So, for instance, users of 
DigiLog would create a new log, change the autosave settings, format the 
text, save the logs as well as actually logging a debate or meeting. A crucial 
factor in choosing tasks is to determine the size and scope. If an individual 
task is too short or too simple, it may take just seconds to complete and will 
be very difficult to observe and quantify. On the other hand, if a task is too 
long or involves more than one system concept or procedure, not only do 
we run the risk of exhausting participants we may find that it is difficult to 
quantify because of the difficulty detecting where one task or subtask ends 
and the next one starts. In choosing the tasks for this study, only tasks 
which corresponded to a single concept and which were as self-contained 
as possible were chose. 
Here, we need to address the issue of exactly how self-contained or in-
dependent tasks should be and whether tasks need to be performed in or-
der. Wixon & Wilson (1997:670) describe two methods of presenting tasks: 
results-based 
and 
process-based
. Results-based tasks require participants to 
achieve a specific goal without providing any indication of the intermediate 
stages. Process-based tasks provide participants with details of the various 
steps involved in completing a task. For the purposes of testing the usability 
of a user guide we are interested in finding out exactly what happens when 
users perform tasks, not just whether they complete the task or not. As 
such, a process-based approach was adopted. 
In their discussion of whether process-based tasks should be independent 
or interdependent, Wixon & Wilson (
ibid.
) say that independent tasks al-
low participants to move on to the next task regardless of whether the pre-
vious task was completed successfully. This contrasts with interdependent 
tasks where, if participants encounter serious problems, they may not be 
able to proceed to the next task without some form of intervention or assis-
tance from the test administrator. 
218
study. The first way is to use tasks suggested by designers. The authors 
argue that because designers know the system intimately, they will have a 

---

Experiment to Test the Impact of Iconic Linkage
In reality, however, the tasks performed by users in a typical working 
environment are rarely independent, i.e. they are performed as part of a 
user’s strategy for achieving some goal. Frequently, if users cannot complete 
a task or subtask, they will not be able to proceed or achieve their goals. 
This presents us with a compromise between convenience in the usability 
laboratory and realistic tasks which reflect realistic scenarios of use. In this 
study, it was felt that the nature and length of the tasks would not pose 
problems which could not be resolved with a minimum amount of interac-
alism 
stration. For this reason, all tasks were designed to be dependent on the 
completion of the preceding tasks.