一、整体模型构建
用户体验五大基本要素：
从抽象到具象分别是，战略层》范围层》架构层》框架层》表现层。
基于用户体验形成时人们对它的理解（传递信息或者提供功能服务），为了构建相同的用户体验体系方便人们工作，所以将产品划分为功能产品和信息产品，当然他们并不是完全割裂的，产品在传递信息的过程中往往需要依托一些功能，反之亦然。
基于这两类产品的特性，在用户体验的五大要素模型中也进行了对应的划分，其中：
战略层 范围层 架构层 框架层 表现层
功能产品 用户需求、产品目标 功能规格 交互设计 界面设计、信息设计 感知设计
信息产品 用户需求、产品目标 内容需求 信息架构 导航设计、信息设计 感知设计
在进行每一层工作计划安排时，也并不要求前一阶段工作完全结束之后，再进行下一阶段工作。而是保证在本层工作完成之前，能够基本结束（不会花费主要的人力物力资源）上一阶段工作即可。因为在实际工作过程中，市场、环境是动态变化的，而且预先就能考虑到符合用户实际需求或产品需求的全部的功能、信息细节是不现实的，所以我们只需要保证各阶段主体工作完成即可开启下一阶段工作。我个人认为有以下好处：1、完成主体工作，留出微调空间的同时为后续细节打磨留出资源。2、结合项目管理知识，在工作并行的情况下，可以保证人力等资源的高利用率。
除开以上提到的五大基本要素外，还有一些融入各个层级，渗透到方方面面的要素，最突出的两个分别是内容和技术，《用户体验要素》是作者结合Web网站建设经验编写，Web发展之初就是用于内容信息的交换，所以Web（或者说所有脱胎于互联网的产物）生来就具备信息内容传播的基因；技术更是影响到人类社会发展的方方面面，更别说产品设计了，技术往往是限制、影响用户体验设计的关键因素。所以为对产品来说，了解最新的技术，并思考、尝试如何应用于用户体验设计是一种非常重要的能力。新技术的成功应用，往往也更亦带来产品的成功。
二、层层剖析
1、战略层——用户需求、产品目标
用户需求和产品目标共同构成了战略层，这两者为我们指明了后续所有工作的方向，也就意味着后续所有的决策应该以有助于用户需求或产品目标的实现为基础。
那么战略层的主要工作目标就很清楚了，那就是“明确用户需求和产品目标”。这并不只是轻飘飘的11个字。编辑此文时，我已有2年产品工作经验，但由于公司体量和个人学习方式受限，并没有足够的产品理论知识支撑，这就导致我以为我清楚了用户需求和产品目标，但在进行决策时，往往是根据头部竞品或过往经验结合业务理解决策，偶尔还会“拍脑袋决策”，究其原因，便是没有明确用户需求和产品目标。那么何为明确？作者在书中指出“当产品目标无法用 口头表达 时，对于应该如何完成产品，不同的人就经常会有不同的想法”。
由于在产品细节工作工程中，往往容易遗忘产品建设根本的用户需求和公司的产品目标，为了加强产品经理的影响，我借鉴指标体系命名，将战略层级别的用户需求和产品目标统称为“北极星目标”，提醒我在产品工作的各个阶段、过程中，重视用户需求和产品目标的实现。
如何完整的表述我们的北极星目标？书中指出，我们对产品目标的表述应该满足以下三个要求：a.说明如何满足用户需求；b.解释如何支持企业目标。既不能太具体，也不能太宽泛。
我们在进行每一次决策时，都需要清楚这次决策的影响力和明确定义成功的条件。
产品目标：商业目标、品牌识别、成功标准（即一些可追踪的指标）
用户需求：用户细分（人口统计学法、消费心态档案法、用户对技术的看法、用户对网页本身的看法、用户对网站相关内容的知识储备程度。之所以需要对用户分群，是因为不同的用户之间需求存在差异甚至互相矛盾）、可用性和用户研究（问卷调查、焦点小组、访谈、现场调查、任务分析、用户测试、卡片排序法）、创建人物角色（用户分群、用户画像）。
团队角色和流程：进行战略决策需要了解各个层级项目参与人的意见，尤其是一线员工，最终形成战略文档（战略文档：列出目标清单，对不同目标间的关系进行分析，明确目标如何融入更大的企业环境）。即使战略文档包含某些敏感资料，但是也应该在项目初期就告知全体项目参与人员，这样有助于项目战略目标的实现，帮助他们进行工作决策。
战略是设计用户体验的起点，但不意味着战略是一层不变的，战略也是需要演变的改进的。
2、范围层-功能规格和需求内容
定义： 通过有价值的过程（不同阶段的工作计划）形成有价值的产品（项目中要完成的全部工作）。
方法：通过文档来定义产品需求。
意义：这样你才能知道你正在建设什么和你不需要建设什么。（明确工作职责）
在工作过程中，出现的一些新的想法和功能的可能性，使用文档记录下来，纳入长期规划，而不是立马去做。（这个过程积累的需求经过评估后，就是后续版本需要开发的内容。如果是外包类项目，那么主要关注甲方的需求即可）
功能和内容：通过“”功能规格说明书“”描述文档本身，通过“”需求“”描述文档内容。通常使用内容管理系统CMS对提炼出的有效内容进行管理（内容收集没有需求收集那么正式，但基本原则是一样的，即围绕用户需求和产品目标进行提炼）。
定义需求：需求是用户希望产品具备的特性。
小需求需要尽量详细，大需求一般化即可。
需求分类：明确的特征、用户期望的特征、用户提出的自己不知道是否需要的特征。（无论是哪种需求，都需要带入要求-问题-需求的分析流程中去进行验证，根据验证结果进一步进行处理）
进行产品需求创建时，必须要考虑硬件设备的限制因素。
我们往往也通过用户画像、使用场景、产品（直接竞品或其它产品）分析来或许用户需求。
功能规格说明：我们需要的不是文档有多厚、多详细，而是要足够清楚和准确。功能规格说明不需要包含产品的每一个细节，只需要包含在设计或开发过程中容易产生混淆的功能定义。
撰写规则：乐观、具体、避免主观的语气。
功能规格必须可验证，这样才能尽量保证多方人员对功能理解的一致性。
内容需求：我们需要对不同类型的内容进行定义，但不要混淆某段内容的格式和他的目的。内容特性想要达到的规模，将对用户体验决策产生极大的影响，所以我们需要预估内容规模。
在明确内容需求后，需要指定具体的负责人，负责监督内容落地及后续维护工作，明确更新频率。
确定需求优先级：决策依据：是否满足战略目标？实现的可行性有多大？与管理层的谈判。