产品设计与需求分析.pptx

产品与需求目录任务的目的是展示美国的几个城市在不同月份的平均降水量。体验设计要点用户体验目录目录项目是定制的，个性化的，为了满足一个或一批特定的客户需求；而产品是服务一个用户群的，通用的。这就意味着，项目要服务好那个特定的客户；而产品不能为了个别用户的需求去定制，必须考虑用有限的资源去满足更多的、能有更多回报的用户。
最基本的句式：解决了什么用户的什么需求？
练习的时候，切忌求多，说一点即可，找到你感觉最贴切的那一种用户，和他最迫切的那一个需求。
主要扩展有如下几种：
产生需求的场合是什么？
需求的应用场景，时间地点等，要有“故事感”，尽量找一个能让人会心一笑的。
产品的主要功能有哪些？
需求和功能的区别在于，前者是从用户角度说的，是一种希望，利益点，这时候还没有产品，后者是从产品属性上说的。

解决了什么用户的什么需求？
产生需求的场合是什么？
产品的主要功能有哪些？
技术基础是什么？
没有这个产品的时候，用户是怎么解决问题的？
竞争对手是什么？
顺应了什么趋势？
3+1思考法：测量产品/项目“靠谱程度”目录找到种子用户除了最终用户外，还有……不同层次的用户，其需求的价值不同目录产品设计是端到端的过程，端即用户，也就是从用户中来到用户中去，最最开始的源头就是“为用户解决问题，满足其需求”。产品需求过程三步骤：
产品创意源于三新产品灵感源于需求洞察需求的三层次意识：需求三要素意识：需求三要素目录用户为什么说不清需求需求问题就是沟通问题沟通哲学产品做出来，还要卖出去。前者是“需求到功能”，可以对应到“产品设计”的职能，后者是“功能到卖点”，对应产品运营。目录业务流程八要素业务流程分析业务流程vs.业务功能描述流程：选择正确的工具现场出图：流程分析加速器阅读用例图目录需求编号：
包含“采集时刻+采集者”信息目标用户：这件事，是为谁而做的，一旦售后填写这个就可以自己排除掉很多需求了；
问题描述：目标用户碰到的痛点，只说“何时/何地，怎么难受”即可；
严重程度：对问题严重程度的判断，“高/中/低”即可，具体的判断方法，可以根据用户重要程度，问题出现的次数、频率等因素考虑；
现有方案：现在是如何解决此问题的。一般来说，一个值得解决的问题，通常已经有人着手想方案了，也一定已经有一些解决方案，而没有现有方案的问题，通常不严重；
建议方案：建议的产品改进，催促售后换位思考，产品不一定采纳；
价值描述：改进方案带来的额外价值，比如：省时间；能更精准的找到某某……
改进成本：建议方案的成本评估，“高/中/低”，同样，仅供参考。
产品拿到一堆需求以后，主要根据性价比决定接下来做什么。
性价比=严重程度/改进成本，问题（用户需求）决定严重程度，解决方案（产品功能）决定改进成本。
质量属性的常见误区模块：一般来说，每个模块下分3~10个子模块是合理的，否则要考虑重新划分。
子模块：稍大一点的产品至少要给功能模块做二级分类了。
功能：要给用户提供什么功能，功能名字。
功能描述：这里可以说具体一点。需求确认采集产品干系人（广义用户）提出的各种需求，整理转化为产品需求，即“需求转化”。
“确定属性”即这个需求是属于产品的哪个模块？是基本/扩展/增值功能？是功能/性能/用户体验方面？等。属性的维度可按照产品的不同自由定义，原则是为了便于需求管理。
目录业务规划--Why？What？How？首先，明确目的，最最重要，其实做一个会议和做一个产品也是一样的。不要试图在一个会议中解决所有的问题，就算你要连着召集两个参与人大部分相同的会议，我也建议你把它们分开，甚至，更好的做法，合理安排一个会议中的议题，可以让部分人早点走，或者晚点到。依据目的，类似的日常会议一般在15min～2、3个小时不等。
会议前，做好资源的确认：会议室、投影仪等；更要做好人员的确认：确认好“必选”的和“可选”的，不要漏人，也不要叫闲人，把握“大会决定小事，小会决定大事”的原则。识别出会议的KP（KeyPerson，关键人物），通常是最大的一个或几个老板，提前当面或者电话知会一下，然后发出会议邀请。对于KP，争取提前与他讨论关键议题，达成一致，叫做“串供”，这会让会上省很多时间和精力。正所谓，要想让会议不流于形式，就要把会议本身变成走走形式。
所有事情，尽量在会上取得共识，给出“会议决议”，实在不行的可以作为“遗留问题”。最后，牢记很实用的“所有人提供意见，少数人讨论，一个人拍板”的民主集中原则。
回顾截至到上次会议结束时的信息
1．上次会议讨论的重点问题是什么？
2．关于这些问题我们达成了哪些一致意见？
3．上次会议中哪些问题由于缺乏信息考证，不确定性因素等原因而未能解决？
4．上次会议哪些执行计划被通过了？对于这些执行计划我们有哪些主要想法和设想？谢谢！