最近做事情的时候，在交流过程中会牵涉到很多的用户场景，所以打算从自己了解的一点知识来梳理一下，大致是自己对用户场景的一些看法。
我们需要用户场景来做一些什么？
通过模拟真实的用户场景，来提炼出用户需求（在当前环境下，我会有什么样的问题需要去解决），简化操作流程（如何快速找到解决方案的入口），提升产品的操作体验。
把产品比喻为一个大蛋糕：
这个蛋糕的口味和造型根据最典型的用户场景来制作。
用户从不同的推广渠道走过来吃蛋糕（使用这款产品）。
获得饱腹感（满足用户需求）。
他们各自可能会带着不同的盘子与刀叉（各自明确的目的，使用产品的不同功能）。
开始使用的时候，就会出现很多细化的场景，暴露出一些逻辑上不够严谨，功能缺失的问题，而这些就是我们需要收集起来进行反馈，利用到产品的改进中去。给想要加果酱的用户果酱。
那么在确定用户场景的时候又会出现其他需要进行思考的问题：
（1）模拟的用户场景是否真实，贴近实际的使用环境?
我们需要更多的用户场景来丰富产品的内容，但具有代表性的用户场景才具有参考价值，当你提出：宇航员在空间站里失重的情况下使用微信聊天怎么提高体验？这样问题的讨论价值就会低很多。我觉得把自己扮演成一位产品的用户，带着明确的操作目的去使用产品，可以在一定程度上帮助我们建立一个较为真实的场景。或者是直接在生活中去找志愿者，让他在真实的生活环境下去体验产品，观察用户的操作行为并收集用户反馈的意见。再通过和产品线上的相关人员一起头脑风暴，给出解决方案。
（2）如何解决用户场景上的耦合？
当用户场景讨论多了的时候，自然之间就会出现一些耦合的地方，一款产品年轻人和老年人使用会有不一样，学生和白领使用也可能会有不一样。我们应当尊重大多数用户的需求，同时再兼顾到一些不同年龄层次职业划分上的差异。在实际的解决过程中，往往会遇到是“改变”还是“增加”的问题，是该对当前产品的布局做调整，还是为了一类用户人群而去增加新的功能？调整之后可能会让原先的用户感到不适，而增加之后又会让产品变得繁复冗杂。就像移动端产品的界面改版，有些改变自身原来的风格，有些会选择添加更多的皮肤供用户自行选择，到底是哪一种方法更好呢，还是要联系上具体的产品来思考，或者这两种都不是好方案呢？
这段时间自己也在和产品交流，想着作为一个用户在实际的任务流中会有哪些不够流畅或者无法达成的问题，会发现很多细碎甚至偏向于极端的问题，但是产品上线有相应的日期，所以在现阶段对于细小问题的解决办法是禁止相关操作，或者不提供这样的功能，是为了减少研发人员的工作量，那么将这些问题整理起来，可以为下一版本的迭代工作确定方向。如何在一个复杂的用户场景下对各个方面都作出平衡呢？可能需要更多的理论支撑和实践训练吧。或者说，是不是有时候我们能通过产品的一致性来尽量避免一些体验较差的场景的出现呢?
