产品经理虽然致力于提升用户体验，但是由于先入为主的局限性，总是不能完全理解用户的需求，针对这个问题，笔者以出行产品为例，阐释可以从哪几个层面去加深对用户需求的挖掘和理解。
“用户体验”是指用户在使用产品过程中建立起来的一种纯主观感受，主观感受可以涵盖为以下两层含义：
既然是主观感受，那么肯定是基于使用者自身的行为习惯、使用场景等因素；
另一方也说明，用户往往对自身的真实需求并不明确，产品需要去挖掘。
作为用户，对一个产品的评价可以只是简单的总结为“好”与“坏”，但作为产品经理，就必须知道用户在体验的过程中，究竟哪里好、哪里坏。
这就像读一本书、看一部电影，你只要看过，就不可能只是简单的“喜欢”或者“讨厌”，一定会有一些自己的见解。
一、结合用户真实体验评测
想要了解产品的优缺点，就要和用户一起参与产品的使用，才能有依据的进行优化，进而提升用户体验。
就像“百度贴吧之父”俞军所说的：
用户体验不是一个静态页面，而是一个过程，要结合用户的真实使用过程来评测。
任何产品都是为了更好的服务用户生活，任何报告、数据都无法完整反映用户在使用产品过程中的喜怒哀乐，这些情绪和波动无法直接反馈在功能点或信息点上，经验往往更加真实。
你只有深入了解每个阶段可能出现的需求点，明白它们出现的各种因素，这样才能知道产品是如何影响用户生活的。
学会换位思考，与产品互动，借此与用户产生共鸣，藉由同理心去设计并优化产品，这是改善用户体验的好方法。
我们可以试着建立一条这样的用户体验路径，从头开始完整的体验产品全流程，了解用户在使用产品过程中各个阶段的出发点、触动点、关注点和需求点，而非局限在其中某一个功能或服务项目上。
二、用户体验路径拆解
我们可以将这样的体验路径代入到用户使用场景中，大胆假设，小心求证。
比如一个旅游出行APP，假设它拥有现在市场上主流旅行APP的基本功能，比如航班/酒店预定、景点购票、叫车等服务。
那么将上述用户体验路径代入之后，我们就能得出以下的用户使用流程：
这个路径能帮我们模拟用户使用产品时，各个阶段的原始需求、心理活动和行为感受。
1. 计划行程阶段（认知）
此时用户开始计划行程，主要是评估目的地的旅行价值，以及平台的服务能力。
明确出行目的：婚旅/度蜜月、商务出差、休闲度假、自驾游等；
提供出行方式：飞机、火车、汽车、打车/租车、高铁、邮轮等；
安排出行住宿：酒店、民宿/客栈、别墅等；
参考出行资料：用户评论、旅行攻略等；
预计出行价格：交通费、住宿费、餐饮费、门票费等。
用户实际考虑的角度：
尽量提供套餐式服务，直接包含多项服务，一目了然；
最好有直观的项目比价工具或套餐对比工具，直接进行横向对比；
在可以报销的前提下，商务人士出差更愿意坐头等舱；
在团体出行的前提下，企业或组织更愿意租别墅轰趴；
随时要有取消行程的功能，比如取消航班、酒店预订等；
第一次去目的地旅行，希望有更多的出行建议和替代方案推荐。
当然，我们还需要头脑风暴一下，用户在计划行程的时候会顾虑哪些特殊情况，产品有没有可能帮助他们应对这些情况？
出现突发事件、紧急情况下，有没有可能提供当地的SOS服务或客服热线；
遇到气候不利出行的情况下，APP要及时反馈，做出行提示，提醒带伞、防晒/防寒或注意安全。
计划出行阶段，用户实际上还处于一个需求模糊的状态，只要尚未出行，一切取消或延期都是有可能的。
因此这个阶段产品能做的，就是提供参考信息，帮助他们做决策，而不是简简单单的摆出一二三四的选项供他们选择，可以有更多个性化定制或推荐。
2. 行程预订阶段（决策）
做完旅行规划后可以开始确认订单，此时价格、安全、服务成为核心关注点。
显示到出行目的地的时间、距离、车次/航班等具体信息；
酒店住所的联系方式、地理位置、剩余房源等具体信息；
给出安全、合规的付款流程，提供尽可能多的付款方式；
显示优惠券的核销以及抵扣情况；
推荐会员/金融服务，促进多次消费，提高产品粘性。
用户实际考虑的角度：
下单时提供或者建议一些其他增值服务；
下单后由酒店/商家/司机/工作人员直接进行短信确认或电话沟通，会比平台单方面的订单完成显示更让人放心；
自定义备忘录或自定义行程模块，防止遗漏一些事宜；
商务人士更在意订单能否开发票及报销单；
境外旅游更在意电话卡、签证、换币、导游等事宜。
可能遇到的特殊情况：
由于各种原因导致的行程推迟、买错票、填错信息，客服及系统要有完善的应对措施；
系统BUG导致交易出错，需要提供客服或引导。
互联网产品，交易是用户最敏感的部分，行程预订的顾虑在于：付款前价格是否有诱惑力，付款中是否让人感觉安全，付款后的服务是否到位。
平台方可以作为交易的窗口，但要尽可能提供商家与用户直接的对话，永远比用户先想到一步，让用户在预订过程中始终保持对产品的信赖。
3. 正式出行阶段（行动）
正式出行要把握多个细节，同时要预防多种意外。
时刻反馈航班/车次的详情，确保准时出行；
提供商家信息，方便用户抵达目的地后联系酒店；
随时定位用户地理位置，以便提醒注意事项；
产品内对接并打通网约车APP、地图类APP、生活服务类APP。
用户实际考虑的角度：
最好有当地的出行指南，包括人文风情、历史名筑、美食小吃、视频介绍等；
当地特色娱乐项目推荐，比如日本的温泉、迪拜的冲沙等；
希望能提供当地景点的购票指南或购票通道；
境外旅游更在意翻译、支付、Visa等服务；
情侣旅游更在意旅拍服务或摄影设备租借；
共同痛点：附近的wifi、公共厕所、公共交通工具等。
可能遇到的特殊情况：
出行事故的医疗呼叫，保险服务等；
航班/车次晚点、取消等，随时更新并通知到位；
当地突发事件、紧急通知、气候变化等。
出行阶段的复杂性更多，但主要的体验旅程是由用户来完成，产品需要扮演管家的角色，随时通知必要的旅程，并提供一些必要的出行工具。
总之要考虑的点涉及方方面面，可以不主动介入旅程，但一定要备好这些服务，因为随时可能经受用户的考验。
4. 旅行纪念阶段（反馈）
旅程结束，是用户的收获和总结阶段，需要提供并引导用户参与反馈。
打通社交媒体，让用户参与旅程分享（朋友圈、QQ空间、微博等）；
提供日记/攻略/评分/评论区，满足旅程结束后的游记、心得记录；
便捷的酒店退房、航班/车次返航服务，以及相关通知；
行程结束后提供出行清单/发票/旅程图等。
用户实际考虑的角度：
提醒携带各种行李物件；
境外旅游更在意剩余外汇的兑换；
当地特产推荐，比如韩国的化妆品、瑞士的手表；
行程延长或改变，希望可以延长酒店时间或临时修改机票/车次。
可能遇到的特殊情况：行李丢失或遗漏，能否协助找回。
这一阶段主要是收集反馈信息为主，可以鼓励用户在平台上活跃起来，记录旅程情况供其他用户参考，丰富产品内容以及用户活跃度。
此时也正是用户处于兴奋点的时候，对收集用户对产品的评价和需求，是个不可多得的好机会。
三、处理需求
这样的用户体验路径可以用在很多场景分析。当然，找到需求点之后，更重要的是给需求排列优先级。
在拆解的过程中，还要明确哪些是伪需求，知道用户想要什么，而不是用户想做成什么，用户的原始需求>用户自身理解的需求，用这样的思路才能做成符合产品逻辑，又兼顾用户体验的APP。
举个例子，许多社交类、游戏类产品都有这样的原始痛点：下载后打开APP，要手动搜索好友名添加、手动搜索房间号进入，太麻烦了。
如果经过用户自身对需求的加工理解，他们可能会这样表达：我希望APP能一打开，好友就已经添加好了，或者一进入APP，就能与好友进行对战。
作为产品的设计师，我们当然知道手动搜索好友名、房间号是很麻烦的一件事，但APP也不可能读懂你内心具体想找的是哪个ID名、进入哪个游戏房间啊，那这是不是个伪需求呢？
其实换个思路我们就能打通这个需求。
首先翻看他们的原始需求，可以思考一下，什么样的使用环境下用户会产生这样的需求呢？
其实这种需求产生有一个共同的前提，即社交类、游戏类APP的老用户大多由新用户邀请而来。比如社交类APP需要好友积累才能进行互动、棋牌类游戏需要至少两个玩家才能完成体验；当我被朋友邀请一起玩耍时，自然就需要添加好友、搜索房间了。
那么从技术上看，集成openinstall这种渠道来源追踪的第三方，即可在老用户发送的邀请页面上携带用户名、房间号等ID参数，这样新用户点击该邀请页面进入APP，就能被自动写入ID参数。
从而达到被邀请人通过【邀请聊天/邀请对战】等链接进入APP时，APP将会自动添加该邀请人为好友、或者自动进入该对战房间，该需求也就大致得到解决了。
可以看到，从用户的角度提出需求时，他们的角度只会针对产品的内容进行评价，并不会考虑到“邀请环节”这些产品内容外的流程模式以及使用环境。
因此看到这种类伪需求时，我们的第一反应应该是回归本质，了解用户的原始需求是什么，置身于产品的整个使用流程中，而非其中的某个体验环节。
该案例同时属于期望型需求，处理得好可以给产品加分，起到锦上添花的效果。
如何辨别基本型和期望型需求呢？
在这个案例中，APP最开始采用的手动搜索用户名、房间号方案，事实上就能满足用户想要添加好友、查找对战房间的需求，因此属于基本型。
但经过我们升级进化后的版本，系统可以自动添加好友、进入房间，用户需求得到了进一步满足，因此属于期望型。
两者的结果是一样的，最终都能实现【互加好友、进入游戏房间】的结果，但过程完全不同。后者让用户在实现结果的过程中得到了更高级、更智能化的服务，产品的印象立刻从“可以用”变成了“很好用”，用户体验自然不言而喻。
四、总结
