用户体验要素中的战略层说的是用户需求和产品目标，那么将这两点转变成范围层则应该解释为产品应该提供给用户什么样的内容和功能
范围层的确认需要做两件事：一个有价值的过程中产生有价值的产品
过程：潜在冲突和产品中一些点，能解决哪些事情，哪些事情稍后解决
产品：产品的价值在于整个团队有一个参考点，我们要做的产品或者要迭代的产品，会产生什么样的价值？
哪怕优化一句提示文案，这句文案是否为用户产生了价值，这是设计的依据
用文档定义产品
你正在建设什么：详细的记录下你正在建设的内容，知道这个项目的目标是什么，什么时候将达到这个目标，拥有一些列明确的要求，能让你把责任分配的更加清晰，这样可以大大提高协作效率，工作过程中我会考虑三个维度
自己的工作流程：明确如何进行市调，如何进行需求评审，每一步的流程是否清晰是否可优化等，每个产品人都是需要非常清晰的，尤其是当出现错误的时候，复盘自己，一定会有可优化的环节
设计产品的迭代流程：产品一定会从一个demo到一个完整的产品迭代，整个过程中，产品应该以什么样的速度和方向来进行迭代，也是需要思考的，在整体过程中尤其考察了产品人的决策需求和把控优先级的能力
团队配合的工作流程：比如，定义产品的时候是某几个部门还是全部，迭代产品的时候是只要需求方还是都需要考虑进来，团队应该如何配合并且透明的了解产品成长进度，是需要各个部门来协调的
你不需要建设什么：许多功能很诱人，或者当我们讨论时看到很多各种各样的功能，我们应该用文档把他们都记录下来，这些是可以提供评想法评估的架构，长期来看，现在的想法收集才是真正的价值所在
大概可以用需求池文档来定义，既然是需求池那么一定涉及到需求的来源与去处
来源：需求来源一般来说分为内部和外部，内部大多是职能部门职责部门的一些业务性需求，而外部可能是和竞品，用户反馈的需求，无论是哪些需求，一定是站在战略性角度去看，是否满足用户或企业的点来进行分析，更接地气的说，这个方案是否能起到实际的作用？
去处：需求池的后置需求有可能是因为工期、技术、运营等因素而决定，这些可以放在日后，作为下一个版本的优先目标去考虑，这样才会形成一个不断循环的开发过程
定义需求
一些需求适用于整个产品，比如品牌需求是最常见的一种，某些技术需求比如适配浏览器等，是另一种
其实最用之不竭的需求总是来自用户本身，但更多的时候你的需求将来自与项目利益相关的同事——那些在企业中总想影响你的产品的人。
企业各个部门的成员或不同类型的用户搞一场头脑风暴会议，是一种打开思路，考虑以前从未想到的可能性的、非常有效的工具——不同部门的交集头脑风暴，这样其实可以更好的全方位地思考开发中的产品遇到的问题以及解决方法
竞品的思考
任何一个竞争对手都在试图满足用户需求，那么竞争对手是否找到一种特别有效的特性，能完成其中的某个战略目标？他们是如何权衡和调整我们所面对的那些问题的？除此之外，在一些非竞品的产品中是否也能得到一些思路？我们做的是竞品，不是“抄”
当我们在思考某些功能如何设计的时候可以借助这几个纬度
人物画像：我们的用户是什么样的人群，这类的人群到达某个节点的时候会怎样做下一步？是否可以结合用户画像来进行思考
数据：以往的埋点数据和用户的行为路径可以更好的告诉我们我们接下来该如何做设计调整改进
竞品：真正的竞品分析是看，当我们遇到了某些问题，竞争对手是否有更好的解决方案可以借鉴
非同类竞品：我们可以根据用户的属性去找一些不是非同类的竞品，看看具有大数据的产品上，哪些设计会让用户兴奋（比如，用户会在游戏里面进行组队打怪，那么我们里面能不能这么做？可以参考下【增长黑客】）
小小的补充
日程安排：如何排期，更好的进行部门间协调配合
里程碑：拿数据说话！产品上线、产品人数破万、产品交易破亿等，都可以创立里程碑，每个里程碑创建完毕之后紧接着下一个目标是什么需要考虑，里程碑可以使产品有种仪式感！
里程碑，应该是跟市场、政策、公司发展等相结合，比如不能一味地为了数据而在市场环境不好的情况下进行强推等等，要有理想，但要符合客观规律
范围层更好的连接了战略层和功能层，我们知道了要做什么，我们知道了做出来是什么，这一层中，我们需要思考的就是做哪些，不做哪些，如何做这些···
网友评论