我们会遇到两类讲软件产品的书，一种是偏传统开发视角的，会讲到需求和系统设计。很多这类书所描述的要设计的软件都是偏向于客户买单，用户使用的。软件涉及到多方利益，所以软件并不是直接把关注点投射到用户，而是在满足客户的需求的基础之上，再考虑到用户的需求。如果客户的心里，用户需求是需要第一满足的，那么我们自然也可以把大部分时间聚焦到用户身上，但是如果客户的心里，用户的需求，不是第一需要满足的，反而有其他的一些意图，那么用户的需求反而会弱化。在一般的软件设计中，都需要平衡各方利益（也称为涉众利益）。
例如银行的自动取款机，如果是满足到用户需求为第一位，就用户使用的便捷性考虑，但是取款都需要密码录入，而密码录入这件事，却是一个让人取钱不便捷的部分。密码的使用主要从银行这个组织本身的财产安全性考虑。最终，为了平衡用户使用便捷，和银行的财产安全性，采用密码进行安全保障，同时密码设置的长度也不至于过长。
刚刚说到的是偏传统开始视角的书关注的需求。而另一种偏互联网设计视角的书，会偏重于讲用户使用场景，用户交互，信息框架，以及ui设计等，你会看到，这些书描述软件产品的切入点，会弱化需求分析，而是比较多谈到设计的完整流程。这主要是因为这类软件的属性，它们主要是给大众用户使用，由大众用户买单，所以，这类软件的涉众中，大众用户是最重要的一个服务对象，它们一般会把重点放在用户，而用户的需求通常涉及到的业务流程是较为直接的，短平快，且功能较为单一，但是会在每一个细节的功能上面增加提供情感价值的特性，自我实现的特性。每一细节功能的用户体验摆在了需要花最多时间考虑的地方，所以这些书会看起来，更偏重体验和交互部分。
我一直有种直觉，这两套体系似乎并不是完全割裂开的。在我们做b端产品的时候，越来越多地会考虑到用户使用的实用性，便捷性，会慢慢考虑更多的交互和体验的部分。而在c端软件产品，虽然因为建立吸引，销售的属性特征，而更多地考虑交互和体验部分，但是是否在需求层面，也希望能有更规范化的需求分析思路，真正地在领域的知识范围内，提出正确的问题，帮助挖掘用户的痛点和痒点。这应该也是两个体系的相互融合给各类软件系统带来的好处，做到更好地为客户创造价值，以及为用户提供更好的服务的过程获得一个最优解。
把它们融合到一起的话，首先需要区分为需求侧和设计侧。
业务分析，和软件需求分析，都可以归纳为需求侧，而系统架构分析，数据库设计的部分，是属于设计部分。但是这里就有一个问题了，融合进来的用户体验设计，究竟是属于需求侧，还是设计侧呢。
假如用户体验设计属于需求，为什么它用的都是设计的词汇，产出的结果，如界面，交互细节，视觉稿等，都是具体的解决方案，它表达了外观以及交互逻辑。
假如用户体验设计属于设计，那么为什么传统的系统设计，为什么没有它的一席之地？
我们依然回到IT的发展历史。传统的IT软件更看重的是系统内部稳定，能用就好。就像农民一样，长得漂不漂亮并不重要，它强调功能性，憨厚能干，吃苦耐劳，他的作用就是种田，能有农作物收成，收成了之后，提供粮食等食品给到需要的人。
但是新的互联网软件（如APP，网站等），它更像是一台表演卖座的舞台剧，除了表演人的表演功底之外，还要上舞台表演的人长得美，或长得有特色，才会更有特定，更叫座。所以我们听到“台柱子”，这三个字，我们想象到的人，定不是一个满脸长着雀斑，长相一般的普通人。即她既要有功底，又要长得美，才能吸引人。
从上面的转变，我们可以看到，用户的需求，逐渐地从功能性需求，转化为功能性需求+情感性需求。所以这也是为什么会划分这两个派别的原因。传统的系统设计，我们还可以起个通俗的名字，叫做“系统内部设计”。而用户体验设计，则偏向于外观和交互设计。是涉及到和用户视听嗅味触有交互的部分。
那么，当一个系统想要内外兼修的时候，就可以结合传统开发视角，和互联网设计视角，进行产品设计，我将融合的设计归纳为“产品设计双管道模型。”
图1:双管道模型
完整的产品设计，需要各类人员的参与，项目经理，产品经理，开发，测试，算法，大数据人员的等。产品经理就像是在打造这个产品的母亲一样，会关注完整的需求和设计，无论大事小事，都要时时关注。
最终定好需求规格（完成上图步骤1和2），一方面提供给到系统设计（上图步骤4）成员进行系统架构设计，数据库设计，以及重要接口设计。而另一方面，提供给到用户体验设计方进行用户体验设计（上图步骤5）。
当然产品经理也可能会参与到用户体验非视觉表现层的设计部分（很多国内中小公司的现状，这个部分的工作，偏向于产品设计，而非需求分析），包括交互流程，信息框架梳理，以及原型设计等工作。而在UI设计阶段，产品经理则承担着评审是否符合需求等工作职责。
在系统设计和用户体验设计完成了之后，才能真正进到到产品的开发阶段。而开发阶段，产品经理需要时常了解是否开发按照需求的规格，以及用户体验的规格，来进行产品的开发。
网友评论