怎么样将用户需求转化为产品需求，将顾客需求转化成产品设计的方法有哪些

1，将顾客需求转化成产品设计的方法有哪些

交给第三方服务平台处理，如彩虹设计网

{0}

2，如何把用户需求转化为测试需求

测试需求其实就是对软件基本功能点的大概描述,从需求规格说明书里提炼出你能测试的软件基本功能点

例如说，用户要求一个系统注册时，用户名只能是大小写字母、数字和下划线，长度为12那么，你就可以采用边界值等方法来把用户需求转换为测试用例了

从需求写测试计划（策略）然后再喜欢需求得到功能点再编写测试用例

{1}

3，从一个需求开始怎么样转化为用户真正需要的应用

客户需求、市场需求、产品需求、设计需求、业务需求、内部需求、外部需求、特性、规格、功能需求 --- 需求工程的基本术语说明需求分析和管理对产品开发成败至关重要，这一点大家都非常清楚，正因如此，相关的管理体系都对需求进行详细定义和描述，不同体系不同的定义，导致需求术语混乱，笔者结合10多年的需求工程经验，详细分析不同术语区别如下：客户/用户需求：基于客户认知，更多是客户的直观要求，体现了用户个体的诉求，往往是理想状态，例如：“需要一个功能强大的手机，同时价格要相对便宜”、“我想要的汽车要外观时尚，性能卓越。”，用户需求往往无法直接开发实现，同时用户对自己的需求往往也是模糊的，实际开发中就需要借助类似原型（demo）、参照物等方法，使客户需求具体化。市场需求：很多人理解的市场需求就是客户需求，个人认为市场需求和客户需求还是有很大差别的，客户需求更多描述客户的诉求，而市场需求不但要描述目标客户的诉求，更需要描述竞争对手针对此需求的反应，例如，竞争对手是如何实现的？如果我们不实现被竞争对手替代的可能性有多大？如果实现我们是否如何做才能超越竞争对手？所以可以理解市场需求是经过产品经理分析后的客户需求，体现了客户和竞争的情况。产品需求：针对产品需求，个人认为IPD的定义是合理的，IPD把产品需求定义为“产品包需求”，之所以叫“产品包需求”是因为我们给客户交付的不是孤立的产品，而是一个解决方案，同时客户是否购买一个产品不仅仅看产品本身，还会关注品牌、服务、渠道等因素，产品需求要广而不深，需要把产品相关的方方面面都考虑清楚，而不是要针对一点定义的多么精细，需要更多从客户购买决定的全过程来思考，所以一般就会涉及：价格、渠道、包装、性能、易用性、保证、服务、社会接受程度、品牌等；另根据需求理论一般产品需求会在25~99条之间，实际研发项目时，产品需求会直接让领导层来判断该产品的价值、竞争地位等，最终判断该产品是否值得继续做下去。设计需求：设计需求故名词意就是设计 + 需求，经常遇到研发人员说设计与需求有时候很难区分开来，其实到了设计需求阶段，设计和需求已经融合在一起了，同时也正是融合在一起，需求才能落实为设计，设计也才能承载需求;对比产品需求，设计需求定义时一定要在深度上下功夫，细化到能够通过设计来实现，并且能落实到具体的物理模块来承载。那么设计需求怎么来的呢？根据需求工程理论设计需求是通过产品需求分解而来，业界常用HD（层次分析法）来分解产品需求，关键问题是大家一定要掌握，一个产品需求需要从哪些方面来分解，从而保证分解的完整性，根据IPD需求工程定义，一个产品需求通常需要从如下：功能、环境、性能、强健性（鲁棒性）、可靠性、可维护性、可用性、安全性、重量、电源、尺寸大小、可运输性/可移动性、灵活性等方面进行分解，当然并不是每个产品需求都要一定分解为这些方面，分解后就形成了与此产品需求相对应的设计需求清单。规格：我们经常讲：产品需求规格说明书，说明需求和规格本来就是一体化的，规格就是需求的具体说明，例如：“OA要支持IE浏览器” 是需求，那么如果具体定义：“需要具体支持Ie6、Ie7、Ie8”，那么就叫规格；“声音要达到120分贝~190分贝”，这本身就需求 + 规格。特性：软件行业和军工标准中，经常提到特性这个词语，例如国军标中定义：“特性 --- 识别和区分各类产品或服务的属性，这种属性包含物理、化学、功能或其他可识别的性质。”；所以模糊来讲特性就是产品需求，如果更精确来讲，特性是产品需求中的与其他产品有明显差异的个性化需求，通常我们把产品需求划分为3类：BSA（Basic、Satisfied、Attractive），分别为基本需求、最好满足的需求、更具有吸引力的需求；所以可以理解特性为：A的需求。测试需求：什么叫测试需求，很多人认为测试需求是基于对产品需求的分析，测试人员提炼出来的需要重点测试的点，故名词意：测试需求。不管别人怎么认为，本人认为测试需求是本身是个变态和错误的做法，只所以有测试需求，原因是实际研发中产品需求、设计需求定义不清晰，开发人员就糊里糊涂地进行设计和开发了，但测试人员无法基于需求提炼出来测试点，迫于无奈，不得不给需求定义人员擦屁股，将需求细化到能够提炼到测试点的级别。正规做法应该如此：需求定义人员详细定义产品需求和设计需求，而同时测试设计人员直接针对此需求分析该需求如何测试，重点测试哪些内容，所以测试需求，本身应该叫：需求的可测试性分析，其实是需求的属性之一，这样做的好处是：可以直接判断需求定义是否具体，是否可验证，凡是不能验证的需求都是错误的需求；后续测试用例开发人员针对需求的可测试性分析，直接编写对应的测试用例。内部需求：实际产品需求定义时，我们更关注的是外部客户的需求，因为外部客户直接给我们钱，但其实产品也有内部客户，也需要关注内部客户的需求，谁是内部客户呢？例如制造、客服就是内部客户，如果设计时，没有考虑到制造的要求，直接导致制造效率低下、良品率低，最终影响产品的市场表现；制造部门的需求、客服部门的需求，也需要在产品开发前期就识别，成为产品需求和设计需求的一部分，并在设计开发中实现。外部需求：对照内部需求，外部需求是客户、渠道、合作商、用户等，外部关联单位的需求，具体分析时就需要通过销售过程分析，详细分析产品从生产线下来，到最终客户手里需要经过哪些环节，而这些所有环节的需求统称外部需求，所有外部需求都是我们需要重点关注的，一个环节不满足，产品可能就到不了最终客户手里，就无法转化为实实在在的商业利益。业务需求：针对业务需求业界缺少标准一致清晰的定义，个人认为业务需求更多是从客户的业务发展、财务、战略出发，更多体现了客户高层的要求，涉及产品整体宏观上的要求；例如针对ERP，“库存周转率提高50%”，针对电信设备，“能够无缝升级到下一代网络，从而节约投资成本”，针对银行系统，“提高客户的资金周转效率30%”；针对网络游戏，“使单个用户的费用贡献提高50%”，等等

{2}

4，需求是如何变成产品原型的

说其暧昧，是因为在很多互联网公司里面，这两个环节所做的事情是有重合的，这就意味着，他们或许也是整个流程中合作最紧密的两个环节。相对比之下，产品经理更关注的是产品的内部逻辑、操作流程、策略等；而交互设计师更关注的是产品的易用性、流畅度和操作感受。总的来看，似乎可以认为，产品经理是从一个更加宏观的角度去设计产品，而交互设计师，则是从更多的细节出发，去提升用户体验。这两种不同的视角决定了只有产品经理和交互设计师密切配合，深入沟通，才能够最高效最合理的将产品策略转化为产品原型，从而为流水线的后面环节提供精确的参考资料。下面以人人网广告平台的一些产品和交互细节为例，使用对话的形式来分享一下我个人在做交互设计过程中的一些体会和想法。入门级文章，高手请绕行。在广告平台其中一个投放系统中，有一个产品需求，是要根据广告受众所在的地区做广告的定向投放。也就是说，可以控制广告只展示给固定地域的受众。这就意味着，需要设计一个「区域选择器」，供用户选择区域。产品经理的原始需求是这样的：产品经理：“我们这次的投放系统需要设计一个区域选择器，就是让用户选择广告定向投放的区域的。可以精确到城市，可以多选。另外，区域作为一个投放广告的限制条件，如果用户没有选择任何选项，那就代表用户忽略该条件，则该广告会面向全国投放。”交互设计师：“哦。”产品经理：“嗯，我能够想到的这个东西的原型，可以提供两个下拉框，让用户分别选择省和城市。当用户在第一个下拉框里面选定了省以后，第二个下拉框中会显示该省下面的地级市。我做了一个简单的框图，大家看一下。”产品经理：“大概就是这个样子。每选定一个城市，点击后面的添加按钮，可以将该城市添加到下面的列表中。同时，如果点击已经添加的城市名称后面的「删除」链接，则会将该城市从已选列表抹去。”交互设计师：“等一下，我有一个问题。按照产品的策略，如果用户一个城市都不选，那么就会默认投放全国。但是这个概念很难表达给用户，比如说，如果在「区域选择器」旁边放提示，估计没有多少人会注意到。”产品经理：“一个都没选，就是等于忽略条件啊。因为这些都是限制条件。” 交互设计师：“问题是用户很难意识到是这样。在中国人的观念中，大家都是觉得，选上的，是我要的。但是大家没有「不选就等于全要」这种思维习惯。”交互设计师：“我觉得可以这样。我们在现在的「区域选择器」上面放两个单选按钮。一个叫「全国」，另一个叫做「指定」。打开页面时，默认选中「全国」项，并隐藏「区域选择器」。只有用户选择「指定」项时，区域选择器才会出现。这样表达就很明确了，你不是「全国」就是「指定」。”产品经理：“哦~听起来不错。试试。”于是得到了下面这个版本的原型图：交互设计师：“嗯，我想，现在这个版本已经基本上从界面的层面解决了全国投放的选项问题，我想，用户应该不会因为不知道怎么选而卡在这里了。”交互设计师：“我看下一步，需要对一些关键的元素做一定的视觉设计，以便于引导用户操作。比如「添加」按钮，应该更明显些。我觉得可以请UI设计师出一个简单版本的UI了。”产品经理：“稍等一下，我看咱们还是把细节再讨论清楚一些再去找UI吧。比如，字的颜色啊什么的都没定呢。而且，我觉得选中的区域中，每个城市名称后面都跟着一个删除链接，很奇怪。”交互设计师：“嗯。的确。我的想法是这样，字的颜色，就用黑色吧，或者是深一些的灰色也行。虽然从视觉设计的角度来看，视觉设计师觉得稍浅一些的灰色比较养眼，可能黑色太抢。但是咱们的系统毕竟是给人用的，灰色的话，可能会让人误认为这些选项是不可操作的。你看如何？”产品经理：“同意。” 交互设计师：“关于已经选中的区域列表。我看可以把「删除」链接换成×，事实上，用户对于×这种符号比汉字更敏感。你看，大家不论是用Windows还是 Mac，关闭窗口的时候都是×，早就习惯了。另外，为了让所选定的城市名称看起来是一个整体，并且跟其他城市名称区分开。我看，可以给每一个城市加上背景色，每个城市一个色块，这样也一目了然。”产品经理：“颜色呢？”交互设计师：“蓝色吧，人人网都是蓝色的风格。”产品经理：“ok”于是，配合UI设计师，得到了下面的界面：产品经理：“我看现在这个地方已经基本上成型了。咱们也已经讨论很很久了。该问问别人的意见。”———-时间分割线———-产品经理：“Hi~ 各位。我收集了一些内部测试的意见。有用户提出，搞不太清楚两个下拉菜单和「添加」按钮之间的关系。”交互设计师：“什么意思？”产品经理：“就是说，有人意识不到选完了省，选完了城市以后，还得点「添加」。他们觉得，选完了就完事了。” 交互设计师：“晕。”交互设计师：“可能是已选列表框在空着的时候长得太秀气了，大家没意识到它是用来装东西的。”交互设计师：“好吧，我有两个方案。1、把「添加」按钮上面加一个向下的箭头。指向已选列表框。2、在已选列表空着的时候，添加一条提示语，来提示用户他并没有完成区域选择操作。”产品经理：“提示语那个，你的意思是说，当用户添加了城市以后，会自动消失是吧？”交互设计师：“是的。”产品经理：“我觉得加提示吧。感觉放箭头有点儿傻。”交互设计师：“嗯，而且，可能放了箭头以后，用户依然不知所云。”产品经理：“那提示语怎么说呢？您尚未添加任何区域，请选定城市后，点击上面的「添加」按钮，该城市会被添加到…”交互设计师：“停！太长了，大部分人不会认真看完的。”产品经理：“的确…”交互设计师：“我看就一句话就可以。写您尚未添加任何区域。”交互设计师：“你看。下拉列表后面的按钮叫「添加」。提示中又明确的传达出了尚未「添加」的状态。这样既说明了这个框框是用来放东西的，又可以告诉用户，这个东西是可以选多个的。因为「添加」的概念就是一个一个往里面放。如果只能放一个，那应该叫「选择」。”产品经理：“顶。” 交互设计师：“而且，我觉得这个控件最初的原型你设计的不错。嗯，用户只要成功的进行一次操作，以后就可以非常高效的进行操作了。这个东西的学习成本和认知成本都比较低。”产品经理：“oh,yeah~”那么，现在的UI是这样的：产品经理：“哎，对了。话说，我最开始的策略是，用户如果不选，相当于全选，要全国投放的。你说如果用户选了「指定」，但是并没有添加具体的城市，直接提交表单，怎么办？系统是应该直接把用户的广告设置成全国投放，还是报错，阻止用户继续？”交互设计师：“我看啊，报错吧。因为现在「全国」和「指定」这两项，已经明确的把整体和局部给分开了。我觉得你那个策略没必要再应用了，因为现在这种已经达到了你最初的目的，而且还好理解。再有就是，咱们的平台是涉及到钱的，是要让用户花钱的，如果让用户不明不白花了冤枉钱，本来想投北京的投了全国，那我们会被用户骂死的。虽然感觉上报错会让用户有挫败感，但是在这种细节上，还是用户利益应该放在第一位，用户体验，可以稍微往后放一放了。”产品经理：“好吧。”交互设计师：“呵呵，你看，这个故事告诉我们，不能每件事情都听产品的。产品提的只是需求，但是如何实现需求，还是得从多个角度来讨论。”产品经理：“好吧。那么，技术兄弟们，下面的工作就拜托你们了。”个人观点：1、产品经理和交互设计师需要时刻密切配合，深入沟通。2、有时候，产品策略和用户体验会发生冲突，这时应该从多种角度去考虑和探讨最终解决方案，不应该有谁一定比谁重要的说法。3、优秀的产品经理，相当于半个交互。同样，优秀的交互设计师，相当于半个产品。二者虽然职位不同，但是应该在一定程度上考虑对方的工作内容。4、产品提出的只是策略和需求，并不是一定要按照产品人员所描述的细节去设计具体的产品细节。交互设计师以及团队中其他所有成员，有义务有权利对产品需求提出自己的见解和更好的设计方案。有不同意见可以讨论，但是最终决定权，应该依然属于产品经理。5、产品经理之所以叫经理，是因为，他们除了设计产品，还需要时刻把握整个流程。比如，当细节没讨论清楚的时候，不要去找UI做设计。更多打印 | 类别：信息和交互 | 源地址

一、捋顺业务流程二、梳理产品流程三、整理产品结构，可以多看多学，对一些常见的产品结构要足够了解四、拆分页面，保证用户能够顺畅完成操作五、原型设计，可以使用Mockplus等快速简单的原型设计工具，根据相关需求快速搭建原型，并一键分享演示，带入场景模拟用户操作，看看是否有不合理的地方。通过这五步，基本可以实现需求到产品原型的转变。

文章TAG：怎么样将用户需求转化为产品需求怎么怎么样用户