设计师必备的用户体验思维框架
教你如何有效处理上游需求方的拍脑袋、一句话、「我觉得」型需求
作为用户体验设计师，我们经常会遇到的令人啼笑皆非的场景是「每一位悲催的设计师背后都有一群指点江山的神」。
这些「热情」的需求让我们的设计工作变得更高效？或者让我们的工作成果变得更优质？
实际上并没有，因为这些类型的需求皆是基于「表现层」的需求——任何基于「表现层」的用户体验需求本质上都是无效需求。
作为设计师，如何拒绝这些浮于「表现层」的伪需求，并从中发掘出真正对用户有价值的需求，从而切实的提升产品的用户体验呢？
作为需求方，如何提需求才不会被设计师、工程师鄙视和嫌弃，如何提需求会让对方认为你有理有据、有专业度？如何避免自己变成拍脑袋做决策的需求方？
这里和大家分享一个我工作中发生的真实案例。
但是在此之前，有必要回顾一下用户体验架构图：
我们去定义用户体验的过程，是从战略层、范围层、结构层、框架层、表现层这个顺序，从抽象到具体，层层搭建、逐渐细化的过程。
但是显然，所有那些「指点江山的神」给予设计师的，位置、颜色、尺寸方面的「需求」，实际都落在了最具体的「表现层」，因此这些需求完全没有经过下方四个基础层次的推理和思考，因此就如同无根的浮萍，自然也就经不起推敲和验证。
稍后在具体的实例中，我们会对层次模型进行更深入的解析。
有一天，我们遇到了一个问题……
我们的产品（App）里在同时售卖两种会员卡，用户经常买错，购卡的界面是这样的：
如图我们可以看到，两种会员卡的名称分别是「包月无限换（含3种会员卡等级）」和「包月穿新衣（含2种会员卡等级）」，两种卡的切换方式是在App顶部的导航栏TAB。
为了尽量减少用户买错卡的概率，我们的业务需求方马上就提出了他们的「需求」：
不同的售卡界面要使用不同的风格（包括但不限于卡面设计、权益描述等方面）；
两种卡切换的顶部TAB需要区分的更加明显。
仅以2来举例说，什么叫做区分的更加明显呢？比如：
或者比如：
这里请特别注意，我们的两种不同的产品线（会员卡）并不是如同于「电冰箱」、「洗衣机」，或者「最新」、「最热」之类用户已经熟知其含义的类型区分；
对于那些用户已经熟稔于心的概念，不用刻意着重，用户也能非常容易的理解其作为TAB切换的功能意义。
而在我们这里，没有一个新用户能够理解什么是「包月无限换」和「包月穿新衣」——虽然每个字都认识，但是当它们放在一起的时候，用户仍然充满了疑问：它们代表着什么？是不同的产品？同一产品的不同类型？同一个东西的不同表达？它们是否有区别？
用户遇到的这种困扰就如同是，几年前我们在巴黎旅行，法国餐厅的菜单一般不含图片，所以点菜是一件非常令人困扰的事情，以一家名为「Leon de Bruxelles」的餐厅为例，他们的菜单是这样的：
借助于翻译工具，我们可以将菜单上的英文/法文轻松的转化为中文，比如说第一行的「The Mariniere」，「mariniere」翻译为「水手服」，我们明白「水手服」里的每一个字，但是我们仍然不知道作为一道菜，它到底是个什么意思？
同理，我们可以想象一个外国朋友在阅读中文菜单如「夫妻肺片（Husband-and-Wife Lung Slice）」「佛跳墙（Buddha Jumping Over the Wall）」时深深的困扰——任何用户无法理解的信息，都是无效信息。
所以，当用户无法理解我们的两条产品线「包月无限换」「包月穿新衣」究竟有什么本质上的区别时，它们就变成了无效信息——特别是在当今信息爆炸的时代，用户的关注度在单个页面上停留的时间非常奢侈，因此用户不会花费时间精力去思考和研究那些他们无法即刻理解的无效信息，着重表达这些信息对于达成业务目标毫无助益。
如图，更明显的Tab栏并不能帮助用户有效的使用它，用户没有去切换Tab的欲望——因为用户对于Tab中的两个按钮没有理解，也就更谈不上对功能的预期，更为糟糕的是，这种刻意加深的视觉呈现，还有可能进一步增加用户的困扰。
我们再回过头来审视一下业务方的「需求」：
不同的售卡界面要使用不同的风格（包括但不限于卡面设计、权益描述等方面）；
两种卡切换的顶部TAB需要区分的更加明显。
无论是「采用不同的风格」、还是「更明显的TAB」，都是在破坏整个表现层统一的视觉语言和交互风格，是违反用户体验原则，也是用户体验设计师需要去极力避免的事情——特别是当我们发现，即便我们完成了这些「需求」，仍然无法解决业务上所存在的问题。
实际上就是这些思考简单的、拍脑袋的、直接基于「表现层」的需求，或者我们可以直接称之为无效的伪需求，对于产品的用户体验足以形成灾难性的打击。
我们如何有效的解决这个问题？
还是要从用户体验要素的层级去看待这个问题。
让我们回到这张架构图图：
这个模型看起来有些复杂，考虑到目前大部分的互联网产品，既不是纯粹的功能性产品、也不是纯粹的信息型产品，而是两者的结合，所以我们不妨来简化一下在我们这个案例里，每个层级的主要工作。
战略层：业务目标；
范围层：基于业务目标形成明确的产品需求；
结构层：基于产品需求完成的交互（流程）设计；
框架层：基于交互设计完成的界面布局设计；
表现层：基于界面布局设计完成的视觉设计；
所以最重要的是，本案例中的业务目标到底是什么？
是「避免用户买错会员卡」，即「促使用户购买正确的会员卡」。
要实现这个业务目标，其实有很多种设计产品的方式，最理想的方式可能是，我们对于不同的目标客群，智能化的推荐适合他们的会员卡——但是显然，这是一个从实现角度来说非常有挑战性的方案。
于是我们退而求其次，我们将产品需求定义为：「用户能够充分对比我们的两种会员卡，从中选择购买适合自己需求的会员权益」。
所以，基于这个产品需求，我们分层次完成的用户体验设计如下：
这里尽管暂时省略表现层的设计，我们仍然可以明显的看出，经过严谨的用户体验设计而形成的界面设计，完全满足「用户对比并选择适合自己的会员卡」的产品需求，从而也能够支持「用户购买争取会员卡」的业务目标，带来更好的用户体验。
从而再次证明，那些基于表现层、拍脑袋想当然的「伪需求」，对于实际用户体验的提升是毫无帮助的。
作为需求方……
如果作为提需求的人（业务、产品等），不能进行结构化的思考，只凭自己眼睛看到的和主观感受到的信息作为决策依据，就会轻易落入认知层面的陷阱，变成以个人喜好为标准进行结果判断，从而忘却了目标和战略是什么，本质是什么，要解决的根本问题是什么。
我建议提需求时，你至少要有以下思考：
战略层。我因为什么目标才产生这个需求，我想要解决的是什么问题，这个问题对公司有利，还是对用户有利，还是对我个人工作有利？
范围层。战略层想清楚后，我提的需求会在多大范围产生影响，是否乍看上去只是「想把界面做得更好看」，最后提需求变成了整个App要进行改版，从而导致牵一发而动全身，动用了超预期的资源（运营、市场、产品、技术、客服），但最后回报却很小。
结构层。范围层确定后，我的需求在落到产品实现层面时，对于产品结构会有多大影响，整个产品的信息架构和人机交互方式会产生何种改变，用户在产品中的使用路径和服务触点是否考虑清楚了，用户流程是否顺畅无阻碍。
框架层。结构层定好了，那么产品的每个界面应该如何布局，尤其是信息在整个界面上如何布置和摆放，用户浏览是最为轻松的。有的时候我们为一个下单按钮摆在中间或底部争执不休，这时候其实就是明确框架层如何设计才能最有利于目标的实现，让用户的转化率更好。
表现层。框架层设计完，最终才能设计表现层。表现层往往是UI的颜色、文案、按钮的效果、页面的视觉风格...表现层往往要求我们再次跳出来，在战略层面去考虑和讨论，也就是我们的用户是谁，他们会喜欢什么，他们平时习惯的场景和爱用的产品长什么样，而不是「我觉得这样好看」「我觉得这么做太丑」。
如果能基于这种结构化的方式进行思考和阐述，那么作为需求方，你将得到所有共事者的尊敬和配合，如果能辅之以数据的证明，那么无论是对业务目标的达成、工作的有效推进，还是你自己个人的认知水平提升，都将是突破性的。
作为用户体验设计师……
因为各种各样的原因，目前国内的用户体验（UED）设计师，绝大部分的日常工作仍然集中在表现层，基于其上的各个层次，多是由产品经理和业务方负责的——但是理想中在各自专业上「各司其职」的场景是可遇而不可求的，当缺乏专业度支撑的时候，从人性的角度上来说，每个人都喜欢能够看到的、简单的、直觉性的东西，而抗拒抽象的、需要深入思考的、逻辑性的东西，所以才会出现这些拍脑袋的、不靠谱的基于「表现层」的伪需求，才会有设计师身后那些「指点江山的神」。
很多UED设计师都反馈说，感觉自己日常沦为了人肉PS/Sketch工具，找不到作为设计师应有的存在感和尊严。
在这里，首先我认为，在表现层，设计师应该具备绝对的话语权，因为如果在选择一个设计师的时候都不认可他/她的审美能力和设计水平，那么还有谁在这个方面是可以被信任的呢？
但是我们在很多时候遇到的争议，并不是因为表现层出了问题，就如同我们在上面解析的这个案例，问题出在了表现层以下的每一层，而作为一名UED设计师，如果不想沦为人肉PS/Sketch工具，就应该对表现层以下的每一层有充分的理解。
我一直在团队内部重申，想要实现好的用户体验，一定要更加深入的理解业务和产品——但是说到底，业务和产品最终要通过一步步的落地形成为最终的设计，这其中任何一个层次、任何一个环节出现了偏差，都可能导致产品最终的体验分崩离析。
本案例中所介绍的用户体验框架，可以作为UED设计师们的方法论，协助我们去验证需求、争取话语权——最终切实达到提升产品用户体验的目的，也实实在在的精进自己的专业水平；同时也可以帮助我们迅速准确的评估需求方的专业度水平，判断与他们的合作是否能使得自己的职业生涯有所成长，在关键节点上做出正确的判断。
