设计帮助文件有许多方法，如何组织是首要任务。组织的好坏是使用难易的决定因素。例如：面向任务的帮助文件可以指导用户迅速地完成任务，当然其前提是程序设计者很清楚自己的应用是干什么的。而面向菜单的帮助文件可以指导用户快速查找菜单条目。
帮助文件的类型也会影响其组织形式。例如：帮助文件提供了强大的查找能力，这时您就会更多地用到面向任务的组织形式，以便用户能够随时查找命令信息。此外，使用HTML很难建立教程性质的帮助文件，采用菜单流控制的组织形式则相对比较容易，因为新增菜单项比在Windows帮助文件中实现还容易。
建立大纲
着手建立帮助文件的最重要一步就是编写大纲。大纲应反映出用户的需求，这有助于从一开始就组织好结构，从而把写作重点放在具体内容上。下面是我个人的一些经验，供大家参考：
菜单流 菜单流技术以应用程序的菜单系统为中心，从它开始并作为主线。先将所有菜单项列成层次清晰的结构化条目，再列出所有对话框；每个对话框下要包含其中用到的所有控件；最后，列出主窗口及其组件。使用这种组织方法有利于用户快速定位到应用程序的某一具体条目，缺点是用户往往只看到该条目的含义，却还是无法完成想要实现的任务。因此，这种方法适用于用户已经有一些相关经验的情况棗只需要告诉他们本应用程序的用途，不用再从基础一一教起了。这种帮助文件很适合于实用程序，因为这一类型程序的用户购买该软件时目的明确，他们知道买来做什么。也适用于配置程序模块，这时的问题直接了当，但用户还是需要一些帮助的。
任务 我接触到的大多数用户并不关心当今程序中新出现的“gee whiz”特性。用户只是希望在最短时间内能最快地完成工作，特别对那些整日在公司里忙碌于琐事的职员，他们没有时间去学习如何做某件事，你只能告诉他们。这时，这种帮助文件就很有用了。先列出用户可以实现的所有任务，再一一加以解释。建议您从任务本身的解释开始，用户可以完成什么功能呢？再告诉用户采取什么步骤完成它。这些用户如果对计算机一无所知，而且毫无兴趣倒反而好了！这种技术适用于数据录入和任务固定的应用程序的情况，而对于字处理和其它综合性的应用程序就不能胜任了。
通用菜单／任务 有时所开发的应用程序执行许多任务。例如：一个字处理程序不只是一个目的，而有多种用途。如果此时您宏篇巨箸地逐一解释每项功能怎么使用，对您和用户都是一件残酷的事。我常用的做法是：对各种任务先进行分类，再对每类给出常规指导，而不是对每项任务加以解释。对菜单系统给出总缆介绍也值得推介，这样用户就能很快了解应用程序的用途而不必陷于揣摩编者的构思之中了。由此引发了“气球帮助”的大量应用，这种气球是一种标志，鼠标在某一控件上停留几秒钟时它就会出现在鼠标指针旁边。
参考 编译程序和自带宏语言的应用程序经常使用参考手册类的帮助文件。这类文件是从控制的角度而不是具体结构上分析程序的。对一个字处理程序来说，按字母顺序列出宏命令清单就足够了，因为无法预测用户会怎么使用这些宏。通常还会具体描述这个命令，详述每个参数的含义，并给出一些用法的例子。显然也可以加入其它信息，如：提示不同版本的特殊性。用户常感到有用的信息有：“如果想做Ｘ，请使用此命令；否则请使用命令Ｙ！”，这非常有效。
教程 这是一类特殊的帮助文件。只用于教给初学者，实质上是要告诉他们如何使用您的程序。多数程序员觉得：当用户毫无经验时，这种帮助文件非常有用。用户只需稍懂计算机使用常识就可以了。我发现适用于使用这种帮助文件的情况之一是数据录入程序。一般我先对某项具体任务给出一个简要的解释，再给出一些使用问答。如果能对实际应用进行抽象，给出交互式的帮助会话也非常可取。可以用帮助文件的宏命令来实现，它指导用户输入正确的操作。这一类型帮助的不足之处在于：大量的主题难于组织在一起，而且用户经过长时间的操作可能还搞不清楚到底要做什么。费时费力地做这种集成还不如努力说服公司雇一、二个培训人员呢！
功能区 一些应用程序提供这种帮助是因为它们特殊的用法。比如CAD及其它的绘图程序，专门开辟有这样的功能区。CAD程序中有绘图命令组、颜色模板控制命令组及图形大小形状控制命令组。将许多命令分组，有助于用户快速查找。原因很简单：用户绘图时只关心绘图命令，等到要进行润色加工时就只关心颜色啊、效果啊等相关命令。
链接 如果您还是觉得编写帮助文件太麻烦了，可以使用现成的生成帮助软件。SheepNet的站点http://www.sheepnet.demon.co.uk/helpfile.htm就提供了建立高质量帮助文件的方法。当然您还是需要花时间学习怎么使用，而且要想最终给出一个很好的帮助文件还是需要下一番功夫的。
建立脚本
注 帮助文件一般保证在800 x 600的显示方式下不超范围。
大纲建立好以后，就要补充血肉了！这时，也有一些规则应该遵循：首先，尽量使一节帮助的内容只占一屏（这种“一屏规则”对HTML帮助文件尤其重要，原因在于它不支持书签和注释，用户在第一次找到信息后翻到其它页再想快速查找先前看过的页面就不那么容易了）。用户可不愿意为了查找一个信息来回翻页。大多数情况下，可以将大块的帮助文件分成多个子标题，以便于查阅。在目前的条件下，一屏的大小为800 x 600（不久可能是1024 x 768）。虽然有了更大尺寸的显示器，也还会有很多人用小的显示器。
技巧 大量新型电脑使用1024 x 768的显示方式，而老一些的用800x 600，甚至640 x 480。在编写帮助文件时，要牢记这些条件。
“一屏规则”也有例外，例如：不想把一个过程分成几个子标题。谁碰到这样的帮助都会很恼火：像“建立邮件合并主文档棗参见标题3A来实现”，您说烦不烦？类似的指南中的问题也常见于一些日用品的说明书中，比如音响的说明书。人们可能都听过这句话：“这东西读起来怎么跟音响说明似的，晦涩难懂”。
当不便于分开的时候可能也会打破“一屏规则”。例如：为了解释的直观性可能要加进图形，这时一屏就放不下了。多数情况下复杂的过程要调用多个屏幕，不要因为过程的复杂性而不使用子标题，只要有可能就尽量简化。所要做的是在过程的完整性和分割性之间取得平衡。要保证没有子标题的屏幕也同样容易阅读。我们常常把一些信息放在子标题下，这样用户看到的是一屏完整的信息，想阅读具体内容时只需再点击个别标题就行了。
以上我所说的可以总结为一句话：建立脚本。可能要做的工作像是写本书，但又不能用书的格式。不需要像书那样一个主题紧接着另一个（如果真把帮助文件做成书的形式不知要激怒多少人！因为有些主题只是介绍并没有实际意义），而要求每个主题都实有所指。当然，主题之间加入连贯性将有助于用户使用。
打脚本只进行了全部工作的一半，接下去就要将脚本变成Windows帮助引擎或HTML可识别的格式，从而用户才能使用。这时要将大纲分屏，并在需要的地方加进超文本链接。也有一些帮助文件编译器需要类似make文件的东西，用来告诉编译器在帮助文件中都包含哪些文件，并且可以用按钮进行选择。
以下各小节将完整介绍从脚本生成帮助文件的过程。之后，再介绍如何为用Visual 开发的应用程序制作具有上下文相关功能的帮助文件。那是建立帮助文件的最后一步。在把帮助文件放入应用程序之前应该确保所有的准备工作都已经到位。
词汇表的重要性
我们这些整天坐在机器前面编程的人随时会学到许多新的术语，这些术语就像是每天的调味品，而不会成为交流的障碍。常常自己不知不觉中就使用了没有专门去学习的术语。
而对多数用户来说计算机只是个半熟脸，不过是工作中用到的工具而已。（我的一个好朋友甚至把她的计算机叫‘死对头’，多好的形容词！）对这些人来说，新的术语就是障碍了。充满了晦涩难懂术语的帮助文件比没有帮助还糟糕，因为用户费劲读了半天啥也没弄明白。
我们必须面对这一事实，写帮助时不可能不用到术语，我们这个行业几乎每天都在产生新的词汇，只能尽量避免使用太专业的行话，却不可避免地要用到标准的计算机词汇。
一般在提交正式稿以前要打草稿，换句话说，先写个提纲，再逐步完善。我想要说的是一个简单的书本的格式。这时，可以请一、二个从没有看过的人读一遍，记下他们不明白的词汇，这些人最好是非专业的，这样得到的信息才更真实。做完以后，把这些词汇成表，就是一份很好的词汇表了，比你自己总结的要实用得多。
最后一步，将生词的每次出现都和词汇表进行热链接。这样，用户不知道生词的含义时只需单击链接处就可以了，Windows Help或HTML浏览器就会自动转入词汇表的相应入口处。
