近来主导了几个项目操作手册的编写。有新斥地的项目，要从头编写操作手册；有半途接办其它项目，自后效力迭代，须要更新原操作手册；有客户对操作手册存心睹，须要调解；零零落散写了数万字的手册。
原本写操作手册或者叫用户操纵仿单可能算作一个需求来收拾。既然是需求，那么收拾需求的几个重要设施看待产物司理来说即是轻车熟道了。
编写方针：操作手册即是先容体系若何操作。看待交付型的项目，正在交付的时分须要有这个文档。看待to B的项目，平常也会为客户供应该文档。即使目前有众种为用户先容体系若何操纵的体例，然则这个手册动作一个周密、周密的文档，正在极少场景下仍是有须要的。
倾向用户：客服职员、体系用户（注意能够会有众个脚色，例如束缚员、操作员、被束缚职员等）。
操纵场景：客服职员众是软件的斥地方的职员，当体系大到必然水准后，极少周密的原则单靠回忆很难笼盖，正在遗忘的时分可能拿操作手册动作参考。一个是软件的本质操纵职员，正在遭遇题目又找不到客服时，可通过操作手册实行敏捷查找。归纳来垂青要时两个场景：一、从新初步理解一个效力。二、查找某个效力的某一步的周密原则。
针对编写方针、用户、场景，总结出操作手册必备的几个因素。一、明晰的目次布局，既能让用户对体系有个全部周密的理解，又能轻易用户查找；二、效力概述，遵照目次的划分，对效力实行扼要先容，分析这个效力是干什么的；三、周密操作设施，先容每一步该何如做，有什么注意事项。
平常操作手册会遵照区别的人有区别的版本，然则倘若为每局部独立写一份，这个职业量就太大了。最好正在写的时分就按操纵人来划分，云云就可能只写束缚员（具有体系全盘权限）版本，然后将束缚员版本中的个别摘出来即可酿成众个版本。例如一个别系有搬动端和PC端，倘若PC端动作束缚、摆设效力，给操作员用。PC端是显现，给束缚者用，那么目次可能分搬动端和PC端，然后再分更细的效力；倘若统一个用户既可能正在搬动端实现该效力，又可能正在PC端实现，那么目次可能根据效力实行划分。根据云云的逻辑划分就可能抵达上述方针。
倘若体系目次划分较量真切，周密的效力可能根据目次来划分。这里to B体系的产物司理应当很熟谙。倘若不真切，提倡先优化体系目次。或者体系效力自己很琐碎，操作手册可能根据事项来划分。例如某项讯息要正在前端显现，须要通过讯息的上传、审核、颁发等流程。那么既可能分散先容某各流程全部何如操作，也可能将讯息何如颁发动作一个模块来全部先容，或者写一个全部的流程框架，全部某设施参照某章节。全部写法需遵照体系的本质景况来判定。
效力概述的方针是让手册操纵者（很能够对体系一律欠亨晓）对某个效力有一个全部的理解，了然为什么又这个效力，这个效力是干什么的，通过哪些设施可能实现合联效力。可能让其它生意线的小伙伴来看你的描画，倘若一看就懂，分析写的不错。没看懂的话可能与其实行疏通，看疑义的点正在哪里，有针对性的调解描画。
每一步全部何如操作，点击哪个按钮，填写哪些字段。各个按钮点击有什么效率，字段填写有什么旨趣会影响到哪里。这些实质该何如写，重要是遵照页面和效力的品种。例如列外页，倘若都是些遵照名称能了然寓意的字段，那么就不须要先容。倘若有些容易殽杂的词，例如“更新时光”是只要用户正在如今页面临数据修正实行纪录，仍是正在其它页面做修正，导致该页面的数据出现改变时也做纪录。这时分须要分析，不然用户正在操纵进程中会实行大宗的提问。倘若体系有专闻名词，也须要实行描画。（最好独立用一末节对其实行团结先容）
图片是操作手册的紧张个别。但不行把体系上的图直接放正在操作手册中。有几个须要注意的点：一是圈出每个设施需重点击的按钮的处所。二是标明第一步点击哪里第二步点击哪里。做到这两点仍旧很真切了。正在大宗的试验中，我创造最好把统一个效力里的几个设施做一个长图，云云正在文档中查看时不会酿成大宗的空缺个别，可能更疾的看出每个设施是什么。倘若客户没有看操作手册，直接问，客服可能把长图给他。
写好后，可能让公司其它小伙伴看一下，最好是倾向用户。例如你手册的倾向用户是运维，可能找其它产物线的运维伙伴来看。例如你的倾向用户是客户，可能先小领域发给样板客户或合联较好的客户，搜罗题目，对操作手册实行调解。这个雷同于产物的开头验证，用草图、原型种种能让用户明了理解到产物流程的体例，对产物实行开头的体验并提出观点。
倾向用户对操作手册的反应重要有两个方面。一个是用户的直接反应，一个是用户的操纵体例。
用户阅读手册后，可能与用户疏通使蓄谋睹，看哪里阻挠易明了，哪里查看起来不轻易，以此来调解手册的布局及外达体例。此外可能考查用户若何查阅手册，看针对几个奇特场景（首次操纵时的全部阅读及盘问某个细节时寻找处理本事）的操纵景况，来挖掘文档能够存正在的优化点。这个相当于既要通过访说的体例疏通用户对产物的观点，又要通过考查的体例寻得用户正在操纵中遭遇的题目。
最先有一个操作手册基线版本，正在第一次写完后纪录如今操作手册对应的体系版本。然后遵照体系的升级景况，会逐渐往操作手册中添加实质，此时需纪录每次都添加了哪些实质，对应了体系的哪些版本。由于体系更新后不必然每次都有时光马上更新操作手册，况且当操作手册的领域大到必然水准，再去查对手册跟体系的区别，将花消大宗的时光且操作起来极其繁琐。
可正在手册中添加一个末节对此实行特意纪录，写明手册版本、更改人、更改时光、更改实质。如有须要可添加审核人及审核时光。
将体系中特闻名词实行证明。这些实质正在体系计划之初应当有合联描画，可遵照须要实行摘录。明晰了观点技能顺畅疏通，况且许众题目自己也是不了然观点才出现的。
重要是为了轻易阅读。查看起来文档面子，查找合联实质也较量轻易。写之前先定好外率，审核文档时动作审核项。修正文档前先看一下其它章节，不至于每次添加实质有效新的体例。文档体例重要有下面两种。
外达体例。例如描画按钮时团结用【】，描画体系提示时团结用“”等等，这个正在手册内团结即可。
看待容易出现疑义的地方，用简短的提示文字证明。可能直接写正在页面上，也可能添加小图标，点击后查看提示；遵照提示的紧张水准实行计划。文字必然要简短易懂。
这个模块可正在操作手册中添加，也可能正在体系中供应合联页面。体系中供应页面的上风正在于随时可查看，况且可能遵照用户如今的页面，将与页面合联的题目排正在前面。
最好的操作手册是不必操作手册用户上手即会用。操作手册是体系的一个别，那么手册的理念状况是没有手册。通过优化体系、将提示融入体系等等体例可向这个理念穷苦前行。