通常，User对系统的体验都是老司机，你只要告诉这个系统会提供什么功能、能给他带来什么，即刻他便明白他将在系统里能怎么操作，能得到什么。因为User永远会在最大程度地想让自己在使用某个系统或者某款产品的时候得到最大的灵活和便捷，以及满足感。所以，功能和用户体验才会成为所有系统和产品研发的最根本的出发点和立足点。
USER在这个界面是单纯的浏览，还是编辑，是操作的主流程，还是分支流程都需要有清晰的定义和描述。例如，一个互动功能，不论是点赞、关注还是评论，我们要从用户体验的角度和先后次序去阐述它：鼠标/手指触控/点击后控件的样式变化， 取消的时候又是什么变化等等。
很多时候，User是不愿意告诉PM实际的目的和想法，只是纯粹在争取他们想要什么，强调一个系统/一款产品必须要能够解决掉User在业务流程里的难点和痛点。这没有错，但PM需要能够站在User的立场上，去思考对方的真实想法，需要去分辨那些才是真正实际的、有利于业务发展的需求，然后前瞻性地考虑功能页面的交互。在这过程中，需要不停地将很多需求点，进行转换和变通。把需求的理解，从User的角度、演化为系统/产品的理解：交互和功能层面。而后，抛开体验层面，回归到需求层面，不断地验证和完善系统/产品设计背后的逻辑。
所以，你看到了吗，PM的地位在User面前就像低到了尘埃里，并且还开不出花来。
4.3.系统产品业务逻辑和规则
基本上有80%的PM都停留在这一阶段，认为自己完成了基本功就是长久之能，懂得画图懂得做原型懂得项目跟进，就是懂做产品了。
我也是一样的，目前在一家新公司。也是处在这样的一个边思考边行走的阶段。但我明白，对业务的理解非常重要，只有你对业务逻辑相当熟悉了、明白和领悟了基于这一系列业务逻辑之上的各种业务规则，你才有可能把产品做好，不然你沦为的只是老板或领导的画图工具，这个时候你规划设计的产品的价值是很难体现出来的。
业务逻辑，呈现在系统里就是一个合理的架构业务的框架，并不是具体的一个交互。深入的了解业务逻辑和规则，以及对他们的思考，明白业务为何是这样的逻辑流程、为何这些业务流程逻辑上要设定这么多的规则？你不要试图去改善业务流程和逻辑，因为大公司很多时候轮不到你思考业务或者提出更好的业务。而且业务框架也定了，但你可以把业务梳理好，可以把需求方服务好，要一起前进。
这也是提升的地方。明白了业务流程逻辑是什么样子，这些流程规则上为何设定这么多的业务规则。就已经成功一半。把这些内容分主题、分类别、梳理出来，归属到规划好的功能模块当中，当然还是从User的角度、习惯、意愿去梳理规划这一切。
5.非功能性需求非功能的需求，本身跟User无关。比如用户体验的需求，这个User不用说，PM自己要考虑。就简单的响应方面，如果一个报表系统，User选好组合条件，点击查询后，数据或者可视化图表要经过很久才能展现（比如超过10秒或者更久），那基本这个系统/或者产品已经接近失败了。另外还有一些系统性能和安全方面的隐性需求，都是需要进行规划和设计的。我在此就不一一叙述了。
