没有充分思考过的经历只是经历，不等于经验。——俞军《产品方法论》
本文以用户体验五要素为主线，结合笔者自身工作经验，对需求分析工作中可能会遇到的坑或需要注意的地方进行了描述。
引言
我们所生产的产品更多的是为人服务，让人可以从我们的产品中获得更好的用户体验。但是To G类的产品常常被认为达到目的、可以获得结果即可，容易忽略部分用户体验，那从完整的用户体验的角度审视需求分析，工作中会容易有哪些问题呢？
《用户体验要素——以用户为中心的产品设计》这本书将产品分为功能型产品和信息型产品两类，通过战略层、范围层、结构层、框架层、表现层五个层面阐述如何满足用户需求，这五个层面循序渐进，由抽象逐步具体。
下文也将按照该层级进行分析。
01战略层：产品目的和用户需求
To G可以归类为To B，To B相较于To C来说更重商业价值。这个商业价值是两方面的，于自己公司和于客户，即为战略层所强调的产品目的和用户需求。
想要确定用户需求，首先要对用户进行分类，这有助于我们了解用户的需求及需求的优先级。
1）第一个角度：对于To G来说，一个系统通常有两类用户——买方和用方。买方大多数是领导，需求来源为政策、工作实际需要等，其目的一般是向上汇报或向下管理。用方则包括部分买方和实际用户，其目的则包括向上汇报、向下监督和实际使用。从这里不难看出，买方提出的需求往往优先级较高（To G类客户的话谁的最应该听可以看我的另一篇文章）。
2）另一个角度：用户所在单位的信息化程度。从这个角度，用户可以分为信息化程度高和低的两类。信息化程度越高的用户，越容易用系统语言描述清楚自己的需求；信息化程度越低的用户，对于较为初级的信息化系统，接受程度也会很高。
从战略层本身来说，它明确了产品目的和用户目的，是产品第一个需要考虑的内容。从另一个角度来看，也说明了解决问题应该是以目的为导向的，需要首先明确做一件事的目的，剩下的才是如何做、如何高效地做（我的另一篇文章从目的出发阐述了需求文档如何写）。
俞军老师的《产品方法论》中也提到了一个更为升华的概念——理性决策三要素，按重要性由高到低的依次是：理性的信念、理性的目标、理性的行动。
02 范围层：功能规格
用户的问题决定了最终需求，需求决定了系统的建设范围。功能来源于需求，需求有强弱，功能亦有先后。
对于我常做的政府类项目，往往通过招投标形式获得，系统的建设范围相对来说是明晰的。但是系统范围下的功能是有优先级的，如何把控这个优先级将决定了用户的满意度和项目进度。
举两个例子，这两个例子来源于同一个项目下的两个子系统：
1）第一个子系统A是对全国特别重大自然灾害的评估系统。从08年汶川地震以来，近12年中，仅有6次特别重大自然灾害[注1]，从这个数据可以看出来，这个系统的使用频率并不高，但是一旦使用便是紧急且重要。
与此同时，我们的团队也在开发着常态化灾害评估系统，例如地震损失评估系统，这类子系统使用频率高，相对应的优先级也高。
基于这样的背景，按照现在的思路，A系统的需求分析应先满足基本流程，保证基本业务流程畅通条件下的精准评估，但之前的更多工作内容放在了如何让这个系统更为方便的目的上，导致了系统功能的部分冗余。
例如为使得用户可以在任一阶段使用本系统（考虑到由线下办公改为线上办公的过渡期），在有前后流程关系的多个模块下的多个页面中保留了【新建灾害事件】的入口，这也就需要在各个【新建灾害事件】时对事件进行关联控制，以保证同一事件的流程完整性。
结果可想而知，在后期实际开发过程中对所有功能进行了优先级重排，只保留了一个【新建】入口。
2）第二个子系统B是面向全国乡镇、县、市、省、部五级用户的上报系统，需要以乡镇为单位对需国家补助对象进行逐级上报审核。
这其中有一个很细小的功能，是通过选择本级补助对象进而上报。用过ArcMap的同学应该都知道，在图层属性中可以单独查看已选中对象。当时我觉得这个功能很好用，一定很有用，就引借了进来，开发过程中也遇到了些困难，为此开发人员没少找我麻烦。
但在开发完成后的反复测试过程中，实际上很少使用这个功能，往往都是全选上报了。返回来想想缺少这个功能，整个流程能够走通吗，答案是肯定的。
在刚进入这个行业时，很多前辈告诉我，“我们的需求应该是按照最全的去做，至于开发能开发多少和我们就没有关系了”。我一直对这段话保持怀疑，因为：
1）一来有些基本功能往往客户比较着急使用，如果我们不分优先级全部进行分析，分析完成后再传递需求给开发，必然会造成客户需求的延迟满足，这是一个很不好的体验；
2）二来虽然在招投标时项目范围已然确定，但一个大项目往往持续一年甚至更久，政策、用户的需求很可能会发生变更，如果从一开始就按瀑布式项目执行，则会造成大量人力成本的浪费；
3）三来需求分析成果的完备性很大程度依赖于需求分析人员的工作经验与能力，在分析过程中难免会有考虑不周到的地方，如果最开始做了全量，很有可能会因为中间的一点小问题而牵一发动全身。
从上面的任何一点来说，我都觉得需求也应该是PDCA不断滚动完成的，通过再分析、开发、测试等工作过程不断地验证之前地想法，并沿着正确的方向继续向前。
03 结构层：交互设计
通常一个系统是为多个人服务的，不是一个人，因此系统的流程及交互要符合业务流程及用户习惯，不能只从上帝视角（前后都清楚）认为用户是肯定知晓这个动作的目的，而要从“无知者”（对这个系统的流程甚至目的一无所知）角度思考拿到这个系统时，用户是否能够知晓或下意识地进行下一步动作。
举两个例子：
1）在开发专题地图[注2]（例如中国大陆2020年地震点位分布图）制作B/S端系统时，需要在创建一个制图空间后让用户从本地导入地震点位的矢量数据等所需数据，再进行后续的制图流程直至完成专题图制作。
在实际设计时系统在用户点击【新建制图空间】后打开本地文件夹，让用户选择数据文件。乍一看没什么问题，但在忽略本段第一句话的情况，重新审视系统流程，是否会有疑问：为什么忽然间就打开了本地文件夹，是要让我保存新建的制图空间还是要干什么呢？
如果修改流程——用户点击【新建制图空间】后，系统弹出面板，用户点击【添加数据】按钮后打开本地文件夹，让用户选择数据文件——便可让用户明晰地知晓动作的目的，并符合日常的工作流程及习惯。
2）继续上一个例子：在选择数据文件时，用户选择了.doc文件，点击确定后系统没有任何反应；用户又选择了一个.jpg文件，确定添加后系统依然没有反应，此刻用户下了定论：这个系统不能用。
但实际上，并不是系统不能用，也不是系统出了bug，而是仅支持.xls/.xlsx/.txt/.zip/.rar格式的数据导入。但系统并没有在任一过程中给出提示引导用户进行正确操作，这就是上帝视角下的“用户怎么不知道？”
04 框架层：界面设计、信息设计
好的设计是可以给用户提供好的引导且不会引起用户歧义，同时对于一些功能的修改风险具有一定的可扩展性。
界面设计--提供给用户做某些事的能力；信息设计--传达什么样的想法给用户
例如在使用“中国大陆地震点位分布图”专题图模板完成专题地图制作后，需要对制图成果进行保存和共享。因此有了如下原型设计：
这个界面中提供了用户保存成果的能力，但却没有告诉用户：
1）是否所有项均需填写（必填性说明）；
2）有哪些项是系统可提供默认值，无需用户每次都进行选择或填写（默认值）；
3）有哪些项是系统自动填充的，无需用户误认为需再次点击操作（例成图时间）；
4）有哪些项是想要引导用户进行适当信息补充，以便用户后期追寻的（例描述）。
对于信息量较少的页面，到这一步也可以了，但如果用户所填信息较多，为使用户可以更好地明确要填什么，避免因为看到一堆必填项而烦躁的心理，可以对信息进行分组重排。
05 表现层：视觉设计
视觉设计是产品设计的最后一个环节，但却是用户接受的第一个环节。
视觉设计可能承载了一个产品甚至是一家公司的理念，同时也向用户传达每一个页面的重点或是常用功能，用以引导用户更高效地达到目的。换句话说，一个页面中的按钮也有主次之分，如何能将主次凸显，是视觉设计的一大要点。
总结
一个产品的诞生并不一定会完整的走过这五要素，也不一定会完全按照既定顺序走到表现层，但可以通过这五要素返回来审视一个产品，总结经验。
注1：6次特别重大自然灾害：
（1）2008年5月12日汶川8.0级地震；
（2）2010年4月14日青海玉树7.1级地震；
（3）2010年8月8日甘肃舟曲特大山洪泥石流灾害；
（4）2013年4月20日四川芦山7.0级地震；
（5）2014年8月3日云南鲁甸6.5级地震；
（6）2015年4月25日尼泊尔8.1级地震。
注2：专题地图（thematic map），又称特种地图，是在地理底图上按照地图主题的要求，突出并完善地表示与主题相关的一种或几种要素，使地图内容专题化、表达形式各异、用途专门化的地图。
