说起软件界面操作手册的写作，相信很多业内人士都有各自推崇的宝典，秘籍。比如IBM style guide，Microsoft style guide， apple style guide(列在这里不会被认为是侵权吧?)。还有很多相关的的手册可以作为参考，比如日常使用Adobe软件的help文档。
从2017年初也零零散散看了一些相关内容 结合自己工作当中的一点直觉，把这些碎片化的碎碎念梳理一下。
1.术语要统一
比如对于UI元素。请试想一下，如果给你几分钟，说明什么是窗口，什么是页面，什么是对话框 ，有什么差别? 什么是按钮，什么是图标，什么是标签，是否能够说清楚。如果我们自己都搞不清，就不用拿这么多词去折磨译员和用户了。
或者再想想，在自己的文档中，单击，点击，选择，勾选，是否轮番上阵，有没有明确的定义，还是随心所欲不逾矩。使用受控的术语，刚开始会痛苦。但是规矩树立起来后，不仅减轻自身压力，还能方便维护者，用户，等等，何乐不为?
2.写作套路要统一
比如，"点击按钮，弹出xx界面"。然后下一步是"在xx界面内进行xx操作"。那么“弹出xx界面"这句话要不要保留呢?要统一，不能一会有一会没有。要尽量降低用户阅读手册的学习成本。用户的精力本来就有限，要用在刀刃上。
一般应该是不需要的，因为点了按钮就会出现，不会出错。而且下一步承接上面的操作。当然，如果用户水平参差不齐，担心用户点错，也可以在开始下一步操作前说明是在这个xx界面中。
3.严格与UI保持一致
看到最有力的一句声明是，即使UI错了，也要与其保持一致，避免引起用户的困扰。
不得不说，这个问题我还是经常遇到的。有时候非常纠结，恨不能在界面截图上ps一下。但是与界面保持一致是根本原则。要纠错，也要从源头做起来，或许从需求文档就要开始改起来，手册是链条最后一环，不能脱扣。这也算是技术写作对研发的一个反哺贡献吧。
4.合并简单步骤
步骤太多时，考虑合并简单步骤，同时要区分步骤和结果 。
比如，之前有看到手册中的句子非常精简。
1.点击xx按钮。
2.弹出xx界面。
3.选择xx按钮。
4.单击右键。
5.弹出右键菜单。
6.选择xx选项。
可能略有夸张。但是你看这个task到目前都6步了，可能核心操作还没有出现。用户如果是对着界面和手册，一步步操作，估计也要崩溃了。考虑合并简单步骤。比如，上面6句，加起来就是
1.点击xx按钮，再打开的xx界面中选择xx按钮
2.右键单击，在右键菜单中选择xx选项
当然，上面也不一定是好的做法，只是个人更推荐，也避免把拉低用户自我智商评价。
啰啰嗦嗦又是这么多，我能说我就是为了凑够一千字吗？终于到了，晚安。
