产品设计与需求分析.pptx

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