上面这些话很有意思，这些现象也很普遍。
我相信大多数公司现在都是这种情况：产品负责人或架构师(或叫系统工程师)先把地层逻辑和结构设计好，然后才会去具体的体验设计。

2、多少年来我们都在这样做，我们甚至认为一定应该这样。就好像在日本人没有设计出来很轻巧的家电之前 美国人一直以为家电一定要放到柜子里面做成家具。
现在，我们应该整体的思考一下：产品设计的过程是不是必须这样？ 这样是不是一定合理？
3、不。

4、产品的存在是因为需求，用户因为需求才去使用产品(无论这种需求是主动还是被动的) ；用户通过界面达到和系统的交互 从而完成”需求”。

5、可以肯定地说：”用户不知道也不关心系统底层的逻辑架构是什么？ 他只知道呈现给他的界面和他体验到的交互过程是什么。”

6、”用户的需求决定产品的方向，用户的使用和交互过程决定了产品的设计“。
（记住：并不是”产品的设计决定用户的使用和交互过程”。）

7、在用户体验设计领域有很大一部分人在做”交互设计”的工作，这些工作可以大致的描述为：
“我们在了解产品思路和用户群特征以后(用户研究)，会作一些典型用户的角色模拟（角色设计）和使用情景模拟（情景设计），通过情景的再现演示来总结和逐步细化用户使用中的各种交互需求（任务分解），最后用流程图和线框图的形式把设计结果表现出来”。

8、需要说明的是，交互设计画出来的流程图是”用户使用流程”，而不是”底层业务逻辑流程”。
虽然他们很相近，但本质不一样：一个是从用户的角度出发，一个是从技术实现出发；使用流程图是在描述用户的交互过程和需求，底层业务逻辑流程是为了满足用户的需求。
把用户使用流程演变成底层业务逻辑流流程，是在满足用户需求；把底层业务逻辑流程演变成用户使用流程，是在想当然的认为用户一定会按照你的设计是用产品。

9、很明显”先设计底层业务逻辑流程再考虑交互流程的设计”是标准的工程师思路，这和整个行业先前都是工程师背景有关。
最后会发现：产品是给技术实现设计的，而不是给用户设计的。（虽然做底层逻辑架构的人也会以为他们是在给用户设计，但不可否认他们的特长不是这些。）

10、这种产品设计过程也无法催动技术的提升，而且经常还会导致：
用户体验设计师做了某些好的必须的体验效果时，得到反馈 — “我们底层的逻辑不是这样的，这个我们实现不了。只能放弃这部分的体验”、”用户为什么会这样做呢？ 按照我们的设计他们不会这样做呀！”、”按照现在的底层逻辑，这样的交互流程设计作不了，不要考虑了…”等等底层架构规定了体验设计的现象再普遍不过…

11、记住：用户使用的交互流程是底层业务逻辑流程的需求，而不是底层的”表现”。

所以，用户体验设计的工作不只是应该在项目之初就参与进去，而是很多体验设计都应该放到底层设计的前面去。这是一个循环的迭代过程，但站在这个过程前面的应该是用户使用的交互流程设计。
我建议：作产品需求的PM们先去作一下产品的交互设计，然后再去考虑底层的业务逻辑和架构。