这个问题我们开发的时候有时也会见到。不过我个人的习惯还是：

1. 产品的价值不体现在高保真原型上，但是体现在你的设计上。尤其是涉及到各核心业务线的操作与交互逻辑与信息传递逻辑需要考虑清楚。你可以不画，但不能不考虑，一般考虑过总要找个地方记下来。

2. prd和原型是写给开发看的，所以第一优先级肯定要匹配开发的阅读习惯和他们的认知习惯。你需要了解开发需要知道什么信息，才能完成什么样的工作。有一些开发过程中会碰到的问题，你们可能需要磨合一下才知道开发具体需要啥。

3. 你现在碰见的问题其实，理论上可以在测试阶段cover一部分。如果是上线之后发现的这个问题，那你们的测试流程问题蛮大的。如果是测试的时候发现的问题，那其实蛮正常的，依次改就好了。另外，这种细节能“积少成多”，你们这个开发管理也有那么一些些小问题，正常如果开发成本不高的话，可以顺手就迫害开发改了。

4. 要在需求评审的时候提前给到开发和测试你想要实现的东西预期是啥样的，长成啥样是好的和合理的（当然这个我们也在努力ing，任重道远，而且挑人），这样就可以在开发的过程中有一部分没关注到的问题开发就不会“俺寻思”式开发，而是会思考一下是否可以达成最终目标。这样配合起来效率更高。
   

跟产品复杂性有关联，对于复杂的产品，需要更详细的原型设计，以便更好地解释产品的功能和交互。简单的产品可以相对地减少细节，最终目的还是展现你的观点与思路；

还有的是跟团队有关联，团队越大面对的人越多，每个人的理解能力都有不一样，原型就得越细化，有规范，限制他们得想法；

最后就是根据公司规范有关，有些公司会对这方面输出有要求，根据公司要求处理细节就行。

关于这个问题，个人觉得要具体问题具体分析，有的时候，不是详细程度的问题，是一些约定没有公示出来。比如，你提到的按钮“禁用”和“开启”的问题，可以作为一个公认项放在开发设计规范中。类似的还有，如果没有特殊说明的文本框长度、字体大小、按钮默认选中状态展示等等。

对于这个规范外的东西，当然有多详细就要说多详细了。有很多没有言明的内容，不能指望别人知道你的想法。比如，定义页面元素时，用什么控件、默认长度、默认值、是否唯一等等。

另外，补充一点，觉得需要加强团队内的沟通和协作。因为作为一个有基本常识和责任心的软件工程师（不是码农），他看到“禁用”首先应该想到的是，为什么没有“开启”？那他就应该来问你了，而不是等到验收的时候才发现。还有，你们的测试工程师在测试的时候也没有发现这个问题，也说明了同样的沟通障碍。

所谓的详细程度包括2个方面。第一个是你的逻辑梳理是不是考虑到每个维度，第二个是输出内容是不是足够规范。把我自己的经验分享一下：很多时候我们考虑空间交互的时候会不够完整，举个简单的例子：设计登入页面在你考虑顺流程的时候输入密码完成登入，同时要考虑到逆流程登入不了如何处理，1.根据这个分支线可以分析各种异常场景，是用户输入密码错误处理机制。2.网络不通，接口不通处理机制。登入页面中返回上一页处理机制。逆流成分析完成需要从用户5个场景做一遍分析：用户，行为，场景，媒介，目标。从场景上分析密码联系登入错误要加入锁定账户机制。从媒介上考虑，要考虑cookie保存有效期，多久失效。从用户上要考虑到登入角色。行为上分析要考虑到预留手机号失去焦点时，可以加入检测手机号码是否为空，是否符合11位手机号码规则。

根据团队来，开发水平不行的时候，越细越好。

合作比较久了，有些常见的地方就不用写那么细。

一开始我和达内刚培训出来的人合作，几乎是全程参与，我说一点他做一点。

后来和几个大牛合作，出个草图大牛就能把剩下的完善了。

交付时必须保证技术在处理每一个功能点时，知道自己该做什么！这就要求我们要站在技术的角度考虑问题，比如用户要点击购物车去结算，那么如果当时用户没有勾选任何商品，这个时候应该怎么提示用户？诸如此类的常见异常提示，PM不告诉他，让他自己去猜嘛？

沟通到位大于一切的文档格式，互联网产品讲究敏捷开发，敏捷最重要的一个原则就是当面沟通、多沟通，如果我们能够做到沟通顺畅，在开发有疑惑时能够立刻找到产品，那就不会存在这样的问题。

产品经理不要将自己定位为只做功能规划、原型输出的工具，细节钻得越深越容易迷失自己，产品经理的核心任务应该是寻找正确的产品运营方向，帮助公司挣到钱、挣到更多的钱。

用户交互、用户体验方面的工作在较完善的产品团队会有专人负责，但很多公司忽略了这个岗位的重要性，导致产品经理除了兼网管、美工、开发、测试的任务外，还要做较细的交互工作。即使如此，我们还是能够想办法减少些工作量，如制定一些通用的交互规则，让开发的同学知道你的想法、知道在什么情况下他们可以做主。另外在UI出设计稿的时候，我们就可以让UI将交互的细节考虑进去，即使我们不让UI做开发的同学迟早也会找上门。

加强你原型的交互细节，效果的实现以及附带的操作场景说明，尽可能做到原型输出完毕后，研发直接照做就行了，而且要和研发建立频繁沟通的机制，有问题要尽快反馈，你做为产品也要每天跟进，不要等

团队跟团队不一样，只能在力所能及的情况下尽可能详细的完善prd文档；说实话为了不是让技术人员更加明白需求，更大程度是为了有据可查；重要的是沟通，和对工作的态度；有时候问题用文字很难描述出来，这个就必须要口口相传；对于产品来讲，只能尽可能的完善prd文档，和不厌其烦的去和技术讲需求；对于技术来讲更应该花上一些时间去把prd文档通读一遍，就算哪里不明白大可以勤问呀！

我本身就是技术出身，有时候不是需求没写清楚，而是下意识的忽略一部分需求，会忽略自己认为或者觉得少做这么一点需求看不出什么来，所以我觉得重点还是要放在沟通上，至少我们要对自己设计出来的产品要了如指掌。

我觉得产品主抓方向，原型主要看和你合作的人，有的开发不是能替你想到周边的东西，有的就是你给我多少我做多少。有的开发原型上少一个字都不做，有的能从大局上把握产品。毕竟产品不仅是自己的。

除了写特别完善的prd文档的同时，也要注意程序员的阅读习惯，他们到底看什么样子的文档才能清晰的了解交互流程及细节说明；是图文的形式or数字标签的形式or原型交互的形式

根据他们的习惯来专门进行设计说明，与此同时也应该时长保持沟通，因为肯定会有一些细节考虑不到的地方，经常的沟通与完善细节才能减少更多的错误出现

页面的各种状态，包括控件的状态

页面的各个字段的来源以及用处，各个字段的变化，限制，格式

复杂一点的页面：单独画和流程图，业务图，让看的人知道这个页面是要解决什么问题，达到什么目的

不仅你要看得懂，RD也要看得懂，测试也要看得懂，这就也是一个同理心的问题

细致到评审的时候不会再和技术**，除了技术指向的问题外，都心中有数，文中有数。

两个偷懒的方向，不想后期沟通细节就在需求里把细节写清楚，包括按钮各种状态的设置，可不可点击，颜色，点击效果，列表页的排序规则，细节越多后期开发人员问题就越少，也不容易扯皮。

还一个方向，人员少，相对固定的情况，磨合好开发团队，掌握好一个整体的规则，以后就可以画草图了，技术知道什么地方大概做成什么效果，因为以前都是这么做的。

1. 先看团队的水平，水平一般，就尽量详细，减少沟通成本。

2. 时间与技能足够，详细一点没坏的，便于各方人员都能理解，特别是后面接手的人。

3. 看公司规范要求，无要求的情况下，像我们现在为了减少又做一档需求说明书的输出，我都是让下属都把需求详细一点写在原型，直接了当，提高沟通效率与工作效率。
   

文档详细是基础，也需要加强建设过程中沟通，减少信息差。

团队是需要磨合的，刚开始的时候每个数值的小数点位数，展示形式啥的我都得写清楚。现在不写研发都知道应该怎么设置了。基本现在都是画个草图或者截图改改

1.需求总体描述，干系人有权知道，可能会提出比自己更好的建议，解除开发疑惑。

2.业务流程图，正常和异常流程都要考虑，一些交互提示你以为他知道就不画，你少页面，ui 也少页面，开发有些就是不考虑的，ui怎么画他就怎么写，你没画，最后你背锅。

3.功能结构图，便于开发理解的同时也能帮助后期查漏补缺。

4.需求概述，交互说明，数据来源，状态变化，字段说明等，分全局说明和具体说明。

5.你是产品的负责人到不是唯一负责人，推动每个干系人参与到其中，需求出版评审时提前给出文档，评审时让干系人提出问题，我基本制作解答，和记录缺失。终审才是我主讲。

看合作对象吧。如果是新手，文档必须细致点。如果是老鸟，手绘图都行。

产品需求的初始阶段，功能概念都比较模糊，大部分想法都停留在脑海和口述上（工作中典型的场景，如团队风暴、需求讨论、会议评审）。需要我们不停地理清概念想法，验证需求的合理性、目标是否正确。

修改阶段：理清目标-根据用户诉求、业务目标、运营需要等不同目标点，逐步梳理出原型上需要展示哪些功能内容（界面布局、信息取舍）。

我回来答题了。

这个问题，其实好不好这个定义，可能每个公司的要求不一样，所以对于每个公司来说，好的定义也不一样。

我就说我目前看过我最喜欢的产品原型，不说美观，就说功能方面，功能是完整的，最重要的是对于功能描述十分细致，细致到每一个表格的字段，输入什么值，限制长度等。（这肯定很花时间，实际上要不就是粗糙一点，要不就是加班搞）

一、功能分布合理(利用脑图进行设计)

一个产品的功能多种多样，在进行原型设计时，要根据这些功能规划出各个页面，这非常考验产品经理的思维能力。如何合理地布置这些功能呢?首先要对产品有宏观的了解，其次就是保证功能设计过程中思路清晰。一个很好的方法就是使用脑图，来快速地反应思路，规划需要的模块(页面)。脑图的好处不仅仅在于此，它还方便产品经理对产品的整体功能进行演示和讲解。其次，如果原型工具能做到随时导出基于脑图的文档，也便于筹划PRD文档。

二、逻辑清晰的流程图

原型，脑图，项目树，流程图这些看似是相互独立的个体，但我觉得后三者都应是原型的一部分，就好像一本小说的写作背景，目录，主体和结语，其实都是构成小说的部分。这其中，流程图反应了不同页面之间的逻辑关系，一个逻辑清晰，意义明确，简洁明了的流程图不仅有利于帮助客户了解产品的结构，也有利于设计师不断完善产品的逻辑。目前一些原型工具本身就自带生成流程图的功能，至于他们在该方面的特点和优缺点，之后我会专门写一篇文章来介绍。

三、必要的页面批注及充分的交互说明

正如开头所说，原型不是必须做到高保真才好，很多情况下，我们没有足够的时间去精雕细刻，此时为了准确地表达想法，就要用到批注或文字说明。虽然产品原型中的图片、功能和交互能够很好的表达产品经理的思路和观点，但是一些特殊场景下，简单的文字说明，能够让产品团队成员，更快、更好的理解产品经理的想法。

有些原型工具如Mockplus会提供各式各样的批注组件，方便设计师或产品经理在原型图的基础上进一步说明自己的想法。

四、统一的风格及符合规范的界面设计

产品的内容可以是丰富多彩的，但风格最好要保证统一。只有这样，用户在使用过程中才不会感到“意外”，体验才能流畅而自然。 至于界面设计规范，则是无数设计师总结出的经验，重要性无需赘述。

我个人认为产品原型真心不需要做到哪种高保真，除非你们公司是缺少UI设计团队的，否则产品经理没有必要花大量的时间在原型上，其实你只要在原型中，把让人产生歧义的控件标记清楚就可以了，包括prd文档，尽量语言精简，不要啰嗦，因为技术是没有那么多时间看你的长篇大论的，可以做一下换位思考，如果你是产品经理，你会去看长篇大论的文字么？比如说，订单状态变更是如何定义的？这些点是要具体描述的，而且要描述的非常清晰。想法其他的，比如说，什么列表只显示10条记录，这些文字只要做一个公共描述就可以了，不要再每个页面中都描述，让人看起来就很费劲~~~

原型达到“以假乱真”的程度最好，看得见的交互、看不见的逻辑都要清楚。开发拿到原型能直接开发，而不是一会儿问个这，一会儿问个那。当开发找你确认的次数越来越少时，你的原型就差不多了。

我们的PM不会画原型图，不懂交互，每次我拿到原型图的时候我都一脸懵逼

           
            情况和我差不多，我这边一般是在前期画好初稿的原型图后就会拉着相关的研发人员（反正人不多）和一两个市场销售针对原型图一页页讨论过去（大概花费1天，这一步很重要），基本上要让研发人员和你达成共识，让他们知道每个功能是干嘛的（让研发有产品思维代入感），这个能保证他们主体不会跑偏。确保功能达成共识后，UI细节在小团队很难做到高保真，所以这时候一些常规控件的规范化很重要，像按钮、表单、列表等常规的元素应该及早制定规范（哪怕后期会改动），除此之外其它的细节有精力的话就自己平时改一个就沟通一个，没精力的话只能说他们完成一个页面（有内容就行）就去体验一个提出修改建议，这时候的强交流很有必要。

画原型和写文档的时候不能想当然，细节，细节，一定要到位，除非是合作久了的团队，否则会出现很多问题，不仅耽误工期，而且开发改起来也是怨声载道，在调研需求的时候一定要挖的够深，不能别人提一点，你就按照这一点去做，要根据这点去找到线，面，你的产品原型细致有说服力，团队自然愿意按照你的思路走，反之要么重复改稿，要么重复改代码，对产品和团队氛围都不好