本地化的目的是让不同地域的最终用户使用信息产品高效地完成任务，不论任务是客观的软件操作还是主观的购物决定。所以，设计者在文档源设计时要从用户的角度考虑信息的获得与理解，最终服务于用户有效、高效与满意地利用文档，完成特定任务。实现这一目标，至少可以从文档的准确性、相关性和易操作性入手。

（一）文档的准确性

技术文档反映客观现实，帮助人们了解事实，掌握产品操作，因此，信息准确无误是实现这一切的基础。与译者不同，本地化设计者不应只依赖已有的有关产品特性的语言文字资料，还应在设计之前亲自使用实际产品，获得第一手的可用性体验，才能提供更加准确的信息，提高文档的可用性。

设计者除了亲自接触产品外，还需要从本地化最终用户的视角判断文档信息的准确性，因为视角不同对同一事物的描述有时就会有出入。请看下例：（Lentz＆Hulst，2000：320）

What if you temporarily go abroad?…

这是荷兰政府为宣传机动车征税所发布的小册子中的一句，从荷兰语直接译入英语，同时还译为法语、西班牙语、土耳其语和阿拉伯语，目的是告诉在荷兰居住和工作的外国人如何交纳机动车税。这里的英译文是正确的翻译，但仍存在可用性问题。荷兰语原文是针对本国人的，原意是荷兰人临时离开荷兰仍需交纳机动车税。但是直接译入英语后，在荷兰居住的英国人会把“go abroad”理解为离开英国在荷兰居住，所以他们抗议身在荷兰却仍需向英国交纳机动车税。这一问题在其他几个语种的版本中也同样存在。造成原文信息准确性缺失的原因是写作和翻译时都没有从最终用户的角度出发。所以荷兰政府发现问题后重新改写了荷兰语原文，然后再把它译入其他语种。实际上，在荷兰语中把表示“go abroad”的短语改为“leave Netherland”就可以解决问题。

（二）文档的相关性与简洁性

文档的相关性是指从用户的视角判断文档没有与完成任务无关的冗余信息，或者说，没有无助于完成任务的信息。如果说用户获得利用文档所必需的信息是完成任务的基础，那么文档的相关性则解决利用这些信息完成任务的效率问题。用户为了完成特定任务不仅可以在文档中找到需要的信息，而且不必因为阅读那些冗余信息而降低工作效率。所以，文档源设计也应为实现文档的“最佳相关性”打下基础。但不同地域文化的用户对信息相关性的判断可能会不尽相同，被某目标地域的用户视为相关的信息有可能被另外地域的用户视为不相关，所以在文档源设计环节，本地化设计者无法完全解决该问题，而只能留待目标文档设计时彻底解决。但这也不意味着设计文档源时不用考虑文档的相关性，与用户完成任务无关的内容还是应该被排除在文档之外。

文档的相关性关注的是文档内容是否与用户所要完成任务涉及的话题有联系，而细节的充分性是在文档具备相关性的前提下关注提供背景信息的多少。此外，文档的相关性取决于信息利用的方式，而细节的充分性着眼于提供必要的背景信息，方便信息的理解。例如，用户购买产品需要了解产品的性能，一般不需要了解生产该产品的公司的治理结构，所以有关该公司治理结构的信息在这一使用情境中就是非相关信息。但是如果用户想要购买该公司的股票，那么有关该公司治理结构的信息就是相关信息。如果用户在阅读此信息时遇到“CFO”一词而不知道其全称时，那么这就涉及细节的充分性问题。

与文档的相关性类似，简洁的文档同样可以提高文档的使用效率，因为在不改变可读性的前提下，文字的减少往往可以减少用户的阅读时间，而且可以降低翻译成本。例如，微软风格手册中就对此做出两条规定：

“省略无用的词”，即一个词可以表达清楚就不必使用两个或三个词。

Follow these steps to change your password.（微软风格）

Follow these steps in order to change your password.（非微软风格）

“省略没有必要的副词”：

It isn't difficult to change your password.（微软风格）

It isn't terribly difficult to change your password.（非微软风格）

有些研究者认为，简洁的风格要求，如PACE中“省略多余的词”，会适得其反（Nyberg et al.，2003：257），因为这样的规定并没有明确说明哪些词是多余的或无用的，这会导致把一些有助于理解而从语法上可以省略的词省略掉，如that，who，the等。例如：

1.After a process creates a resource,any process it starts inherits the resource identifiers.(Kohl,1999:150)

2.After a process creates a resource,any process that it starts inherits the resource identifiers.

第1句和第2句语法上都正确，虽然第2句不如第1句简洁，多了that一词，但该句对所有读者（母语为英语的读者和母语为非英语的读者）以及机器翻译系统来说更容易正确分析出句子结构（Kohl，1999：150）。

我们认为，简洁风格本身并没有问题，关键是设计者在执行这一风格要求时不应把它与其他风格要求孤立开来。例如，微软要求省略无用的词，但同时在针对世界范围内受众的风格指南中明确规定应“使用像that和who这样的可选择性代词（optional pronouns）与像the这样的可选择性冠词（optional articles）”，因为这些词可以为母语为非英语的人标明句子结构或名词词性，消除潜在的歧义。（Microsoft，2011：34）所以，可选择性代词和可选择性冠词在微软风格指南中都不属于无用的词，不能因为遵守简洁风格而省略。与此类似，PACE的第二条写作规则规定“省略多余的词”，同时第七条规定“不能省略连词或关系代词”，所以连词和关系代词也不属于多余的词，不能省略。（Nyberg et al.，2003：255）总之，文档源设计时注重文档的简洁性应以不妨碍用户对文档的理解为前提。

（三）文档的易操作性

程序性文档（procedure document）是技术文档中很常见的一类文档，如用户手册、在线帮助、使用说明等，主要是帮助用户掌握产品的具体操作。随着现代电子产品的功能日趋复杂，这类文档对产品的重要性愈发突出，它们的质量直接关系到用户对产品的满意度。程序性文档与概念性文档不同，除了提供真实准确和容易理解的操作信息外，还要具有易操作性，即方便用户依据文档进行相关的产品操作。

文档源的设计者由于通常比目标文档的设计者更容易接近产品的研发人员、市场营销人员和产品本身，在实现最终文档的易操作性上具有先天的便利条件。所以，程序性文档在文档源设计环节就应当注重文档的可操作性。设计者通常可采用语言手段和非语言手段来实现这一目标。

语言手段指进行以任务为导向的写作；非语言手段主要指图文配合与排版布局。我们先讨论语言手段，再探讨非语言手段。

用户使用程序性文档通常是为了完成具体的操作任务，因此，设计者应当从用户所要完成任务的角度进行文档源设计，主要处理好以下两个关系：第一是真实任务与人为任务之间的关系；第二是任务话题与概念话题之间的关系。前者多见于简单程序性文档，即只包含程序性信息的文档；后者多见于复杂程序性文档，即同时包含程序性信息与概念性信息。

真实任务（real tasks）是无论用户使用何种产品都想要完成的任务，而人为任务（artificial tasks）是产品强加给用户的任务。（Hargis et al.，2004：27）例如：用户想用软件编辑表格，“编辑表格”就是真实任务，而“使用表格编辑器”就是人为任务，是从产品功能的角度来描述该任务。设计者应当从真实任务而不是人为任务入手设计程序性文档，因为这样的文档与用户的关联性更高（Hargis et al.，2004：29），更利于用户理解与使用。但在产品开发与设计过程中，设计者如果长时间关注于产品功能，就很容易忘记真实任务与人为任务之间的差别，并往往以人为任务替代真实任务。请看下例。（Hargis et al.，2004：29）

如图5-2所示，“Using the Address window”这一帮助话题告诉用户如何使用“地址窗口”以及怎样填写其中的字段，但并没有解释用户的真实任务是什么，而且还包含了与真实任务无关的人为任务。(www.daowen.com)

图5-2　人为任务“Using the Address window”

如图5-3所示，改进后的“帮助”，“Finding an address”从标题到目的信息到操作步骤再到结果信息都围绕着真实任务：找出他人的地址。用户读了一目了然，并且不受人为任务“填写方位字段”的干扰。

有些产品设计使用户完成真实任务之前必须先完成人为任务，所以设计者写作时不得不涉及人为任务。例如，用户想要制图，但在特定程序中他必须先创建一个容器来存放图形。制图就是真实任务，而创建容器就是人为任务。遇到这种情况，设计者需要巧妙地把人为任务融入真实任务中，例如，他可以把标题写成“在容器中制图”（creating your graphics in a container），再在正文中把创建容器作为制图的前提条件写在操作步骤之前，而不是分别写“创建容器”（setting up containers）和“制作图形”（creating graphics）。

图5-3　真实任务“Finding an address”

任务话题是所有与操作直接相关的话题，多为程序性信息；而概念话题与操作间接相关，主要解释操作中的概念，多为概念性信息。在复杂的程序操作中，设计者往往需要对与操作相关的一些主要概念做出解释，以便于用户理解掌握操作的内在逻辑。但概念话题如果组织不当就会影响用户学习产品的使用，降低文档的可操作性。请看下例“Creating test cases”（如图5-4所示）。

图5-4　Creating test cases

该帮助主要存在两个问题。第一，概念话题内容太多，条理欠佳。第二，任务话题不突出。一是因为概念话题以及其他相关任务占据了开篇大部分篇幅，用户需要读一大段文字才能接触到真正的任务话题；二是以上相关信息与任务的关系不够清晰。

图5-5　Creating test cases（修改稿）

如图5-5所示，改进后的帮助不在正文中解释概念与相关操作，但在最后通过“相关话题”把上述概念与任务分开，并且链接到独立页面，这既突出了任务话题，又方便需要了解概念话题的用户查找，还可以把相同概念话题链接到其他帮助话题。此外，在描述具体操作任务之前，明确了原稿中概念话题与相关操作与该任务话题的内在联系，所以修改后的帮助有利于用户完成任务。

总之，设计者应当突出任务话题，把概念话题与之明确分开。任务话题通常由五部分组成：

1.执行该任务的原因；

2.执行该任务的条件（如必须提前完成的任务或使用的软件）；

3.任务的步骤；

4.用于说明步骤的建议和实例；

5.关于后续任务的说明。

凡是与以上五部分没有直接关系的概念话题都可以从任务话题中分离出来。熟悉这些概念的用户在阅读帮助时就可以节省时间，提高学习效率。而不熟悉这些概念的用户则可以根据需要在正文后找到相关解释，而不会破坏对整体操作程序的理解。

以任务为导向来设计程序性文档的理念已被一些全球化的大公司所接受，并写入它们各自的风格手册。微软公司明确要求文档设计者要做到“移情”（Be empathetic），因为“我们理解用户的需求，我们视满足其需求符合我们双方的利益。我们注重帮助用户完成任务和解决问题，而不是描述产品或服务特征。我们的内容应尽力回答‘我如何使用✕✕？’与‘我在使用✕✕之前需要知道什么？’等问题，而不是传达‘让我来告诉你有关这个产品的一切内容’这样的讯息”（Microsoft，2012：4）。

除了语言手段，非语言手段对提高文档源的可操作性同样有效。研究表明，在程序性文档中，图文配合比只用文字或图片描述操作步骤可以使用户操作起来更快更准确更容易，而且出错更少（Glock，1981；Booher，1975；Dechsri et al.，1997；Hiruma＆Kaiho，1991；Fukuoka et al.，1999；Ganier，2007；Gellevij＆Meij，2004）。这些研究涉及美国、日本、法国和荷兰的用户，在一定程度上证明了图文配合效果的普遍性。这是因为：第一，图片使用户更快更完整地在头脑中形成图景；第二，图片使操作更迅速和准确；第三，与单纯的文字相比，图文配合减少了用户信息处理时的工作量。（Ganier，2007：308）而且对美国和日本两国用户的调查还发现，用户在图文配合的三种形式（每一操作步骤都配有图片，部分操作步骤配有图片，只在操作开始之前有一张总图）中，更喜欢每一个操作步骤都配有图片，认为这比只有一张总图更有助于操作。（Fukuoka et al.，1999：175）所以设计者在文档源设计时在条件许可的情况下可考虑适当增加图片数量。

文档的排版布局同样可以影响文档本身的可操作性。这与用户使用程序性文档的习惯有关。有不少用户在使用操作手册时喜欢边看边操作的切换方式。这种工作方式的好处是把操作说明放在产品旁边，看完一个操作步骤，立刻开始操作，可以有效减轻用户的工作记忆负担。（转引自Ganier，2007：306-307）所以，如果文档的目标用户中多数人有此使用习惯，那么排版布局就要考虑到这一点，设计出有利于切换阅读的版面布局。有时双排并列的版面布局就不如单排布局方便用户使用，因为用户需要一手拿手册，一手操作产品，双排版式不如单排版式查看方便。例如图5-6就是一个高压锅的操作手册，改为单排（如图5-7所示）后受到了用户的肯定。（Ganier，2007）

图5-6

图5-7