甲方常问的一个问题是，到底该先出原型还是先写需求文档。这个问题背后其实是想知道，钱该先花在哪一步，以及做完哪一步才算踏实。
先说结论，两者管的不是同一件事，不冲突，但顺序上确实有讲究，取决于项目类型和甲方的参与程度。
一、两者各自管什么
原型图管的是界面长什么样、怎么点。它回答的是这个页面有哪些按钮、点了之后跳到哪、列表显示哪几列、填错了提示什么。原型的好处是直观，不懂技术的人也能看懂，容易提意见。
需求文档管的是规则和逻辑。它回答的是这个单据什么状态下能改、谁能改、改完要不要留痕、金额怎么算、逾期怎么判定、数据从哪来又流向哪。文档的好处是严密，能覆盖界面上看不见的部分。
只画原型，会漏掉大量规则。用户看着一个漂亮的界面点头，做出来发现审批条件不对、计算口径不对。只写文档，业务人员很难看懂，评审会上会冷场，最后变成开发方自说自话。
二、什么情况适合先画原型
界面复杂、操作步骤多、面向一线人员使用的系统，先画原型更划算。比如移动端的应用、面向窗口人员的受理系统、需要大量表单录入的模块。
这类项目的特点是要用的人对界面非常敏感，但说不清自己要什么。给他一份文字文档，他提不出意见，给他一张能点的图，他马上能说出这样不行那样要改。原型在这个阶段的价值，是把隐性的意见逼出来。
先画原型的时候，用的工具不必讲究，能点、能跳转、能看清楚布局就够。不要在这个阶段纠结配色和图标，那些是后面的事，早纠结等于浪费评审时间。
三、什么情况适合先写文档
规则复杂、计算密集、涉及多方权限的系统，先写文档更划算。比如涉及费用计算、考核评分、多级审批、数据统计口径的系统。
这类项目的难点在逻辑，界面往往很朴素。一张表格配上几个按钮就是全部，但表格里每一个数字怎么来的、什么时候变色、能不能修改，规则能写好几页。如果先画原型，画出来的界面看不出这些规则，评审也就评不到点子上。
写文档的时候有个技巧，把规则写成可以被否定的句子。比如写成当申请金额超过两万时需要分管领导审批，而不是写审批流程视金额而定。前者可以被反驳，后者只能被点头，评审的价值完全不同。
四、两者都做时怎么不打架
多数中等规模的项目两者都要做，这时候要防的是两份东西对不上。
有个简单办法，在原型上加编号，在文档里引用编号。原型上每个页面标好唯一编号，文档里写规则的时候注明它管的是哪个页面的哪个字段。改的时候两边同步改，改动记在同一份变更记录里。
另外要注意先后。比较顺的做法是先把业务逻辑和规则梳理清楚，形成文档的骨架，再做原型。原型做出来之后拿文档回头核一遍，看界面上有没有漏掉文档里写的东西。反过来的顺序容易出问题，先定的界面会限制对逻辑的思考，很多规则会被界面框住想不到。