范围层
带着“我们想要什么”、“我们的用户想要什么”的明确认识，我们才能弄清楚如何去满足这些战略的目标。当你把用户需求和产品目标转变成产品应该提供给用户什么样的内容和功能时，战略就变成了范围。
范围层定义
我们做一些事情，是因为这个过程有价值，或者做出的产品有价值。而定义项目范围是同时在做这两个事，这是一个有价值的过程，同时能产生有价值的产品。
过程（process）的价值在于，当整个事情还处在假设阶段的时候，它能迫使你去考虑潜在的冲突和产品中一些粗略的点。我们能确定现在能解决哪些事情，而哪些必须要再迟一点才能解决。 这个就像是需求优先级的排序。
产品（product）的价值在于，被定义的这个产品给了整个团队一个参考点，明确了这个项目中要完成的的全部工作，它也提供了一门用于讨论这件事情的共同的语言。定义好你的要求能保证在设计过程中不会出现模棱两可的情况。这个就像是排完序的需求的具体描述。
同时呢，在定义过程和产品需求的时候，必不可少的是工作流程、日程安排和里程碑，没有这几项，到了实际做的时候，项目就不可控了。
做什么和不做什么
范围层的定义重要性实际上体现在了两个层面，一个是“知道我们要做什么”，另个一个是“知道我们不做什么。”如果我们不能确定这两项，会陷入书里提到的可怕的“范围蠕变”scope creep的情况，这个情况在我们实际工作中，体现出来就是需求不断变，产品不靠谱，项目不可控。
在软件开发中，范围层确定的是全部的功能需求或功能规格。书里面用“功能规格说明书”来描写这个文档，实际上，在我们产品工作中，这个就是需求文档。
第一步，就是先定义好需求。需求来源总是来自于用户，因此，有一个好的办法就是用户故事。一个场景下一个简单的故事，描述我们的用户是如何完成这些这些用户需求的。
书里提到，在写说明书的时候，最好用乐观、具体、和避免主观语气的话语。比如这个系统不允许用户购买没有线的风筝，这句话，就没有另外一句好。如果用户想买一个没有线的风筝，这个系统应该引导用户到风筝线页面。再比如，最受欢迎的视频要重点标注。实际上，最受欢迎没法定义，点赞最高，还是播放最多。这些都是些说明书要注意到的点。
而对于内容需求来说，谁来更新，谁来维护，频率如何，这些更是要定义的清晰一些。网站就靠内容活了。
定义清晰之后，就是优先级排序了。这时候其实可以从技术角度、时间角度、功能之间的联系，用户满意度等方面去考虑如何排序。
当我们把这些做完之后，就到了下一步。
结构层：交互设计与信息架构
在定义好用户需求并排列好优先级别之后，我们对于最终产品将会包括什么特性已经有了清楚的图像。然而，这些需求并没有说明如何将这些分散的片段组成一个整体。这就是范围层的上面一层：为网站创建一个概念结构。
在软件开发行业，涉及“为用户设计结构化体验”的方法被称为交互设计（interaction design）。它曾经被归类在“界面设计”的范畴之内，但近些年来交互设计已经成为了一个独立的学科。
在内容建设方面，主要是通过信息架构（information architecture）来构建用户体验。这个领域涉及多个学科，包括向来都要考虑的组织管理、分类、顺序排列，以及与内容呈现有关的：图书管理、新闻学，和技术通信等其他学科。
交互设计和信息架构都强调一个重点：确定各个将要呈现给用户的元素的“模式（patterns）”和“顺序（sequences）”。交互设计关注于将影响用户执行和完成任务的元素。信息架构则关注如何将信息表达给用户的元素。
一个好的交互设计，就是对于用户而言，他用的好，用的爽。而做一个用户用得好，用的爽的方法称之为：概念模型。
举个例子来讲，“购物车”在电商网站里面，它就是一个概念模型。这个概念模型同时影响了它的视觉设计和在界面上使用的语言。它是一个装东西的容器；作为一个容器，我们“放进东西”到“推车”中，以及从里面“拿出东西”来，系统必须提供能完成这些任务的功能。
但在任何一个交互设计，其中很大的部分都会涉及到如果用户出错了，怎么办？有两个方法，第一个是，将系统设计成不可能犯错的那种，就是用户犯了错的话，系统根本不运行。第二个是使错误难以发生，如果发生了，系统帮助用户找出错误并改正。比如Word的错误提示和修改功能。
而一个好的信息架构，就是让用户高效率、有效地浏览网站的内容。达到这样一个目的，在信息架构设计的过程中，就是要处理好，信息架构基本单位——节点node的组合。节点可以对应任意的信息片段或组合—它可以小到是一个数字（比如产品的价格），或都大到是整个图书馆。一般有以下几种方式，层级结构，又叫做树状结构或中心辐射结构。矩阵结构，自然结构以及线性结构，比如教材资料就是线性结构的，而树状结构，就是长的像树那样子的。
最后，当按照上面所述方法，做完交互设计或者信息架构后，也要形成一个文档，就是范围层的文档，在互联网早期，这个文档被称为“网站地图”，比如这两张图：
而在我们现在的产品工作中，这个文档，分成了两部分，上面那部分，我们现在称之为产品架构图或者功能框架，下面的这一部分是业务流程图。
ps:结构图，或者框架图，我通过查资料，搜集各种人的解释之后，我的发现就是：结构图，一般PPT做的，做汇报展示用。框架图，一般是思维导图做的，放在需求文档里的。这俩张图，本质描述的是一个事情，都是产品具备哪些功能点。
