C端产品的发展促进了产品经理概念的普及和发展，在C端产品设计中很多新颖的设计方法论得到了推广应用，但是我们要认识到，B端产品设计和C端有着本质上的区别，我们可以有选择的借鉴吸纳C端产品设计的最佳实践，但也要意识到，经典的软件设计方法论的沉淀，更是值得我们深入挖掘的宝藏。作为一名B端产品经理，我们应该包容曾经的方法论，吸纳最新的方法论，在合适的场景下选择合适的工具，做到融会贯通。

　　通过前边的学习，相信大家都有所感受，B端产品经理的需求分析和设计工作，既包括了对业务和用户的洞察与分析，也包括了对软件产品的结构化抽象设计，我总结在下图中。

　　B端产品经理的需求分析与产品设计

　　需求分析的起点，是场景挖掘、业务洞察，通过对原始需求的探索，深入到业务中，挖掘背后的场景和诉求，这是一个探索、洞察需求本质的过程，同时还要找到不同的解决思路和解决方案。

　　一旦明确了需求的场景和解决思路，接下来要进行产品方案设计，需求建模是B端产品设计特有的工作，不论是对业务流程的进一步抽象梳理，还是对业务数据对象的识别和设计，都需要通过UML进行抽象设计。B端产品的灵活性和扩展性正是来自于建模的好坏强弱。

　　需求建模完成后，要进行交互界面的设计，包括绘制原型图。

　　交互设计属于用户体验的范畴，产品经理不仅要进行交互设计，还需要时刻思考用户体验问题，能够做到不仅在场景、功能和抽象的层面产出正确设计，还能够以用户为中心，从体验的视角切入去保证产品的易用性和满意度。

　　体验设计包括了交互设计、用户体验设计、服务设计三个层面，在下一章我们会进一步探讨。

　　对于每一个需求，产品经理必须清晰的判定其商业价值、业务价值、技术价值和用户价值。商业价值代表需求是否符合产品本身的定位以及商业化的诉求，业务价值代表需求是否能帮客户切实提高业务效益，用户价值代表需求是否可以赋能一线用户，技术价值代表需求是否能够提升未来的研发效能。

　　在C端产品设计工作中，产品经理需要关注场景挖掘、价值评估、用户体验，无需考虑复杂系统的抽象设计；

　　在传统的项目制软件设计工作中，需求分析师关注的重点在需求建模，将客户诉求转化成软件抽象设计，而容易忽略价值评估和体验设计；

　　在B端产品设计工作中，产品经理要同时关注场景挖掘、需求建模、价值评估和体验设计。

　　在敏捷开发流行以前，大家采用用例驱动的设计（UDD）来完成软件需求分析和设计工作，但是这两年，用户故事这种轻量级的设计方法论得到了广泛的应用和普及，于是很多人产生了困惑：

　　用例驱动的设计就过时了么？

　　用户故事的方式就一定好用么？

　　我认为答案是否定的。

　　不可否认，用例驱动的设计模式相对繁琐，通过7.3.5的用例图大家就能看出来，用例的编写有一定的复杂度。但是，用例本身是一种对系统分析高层次的设计抽象过程，通过对多角色的定位，基于流程来梳理结构化的功能块，虽然不是从体验和场景出发，但却适合对软件设计本身的抽象要求。

　　用户故事是一种非常细粒度的，基于场景的功能点描述，能够更好地贴合场景，应用灵活，但是缺少整体性的分析和定义，并且在功能细节的描述上也不够丰富。

　　用例可以被拆解成用户故事，但用户故事很难还原用例的全貌。对于B端软件设计，面临高度复杂的业务和抽象，单纯通过用户故事是不可能将软件设计的全貌呈现出来。我们可以采用用例和用户故事混合的方式，结合用例设计的思维方式对软件背后的业务和需求场景进行整体的抽象和梳理，然后在具体的单一场景下，可以通过用户故事进行需求描述。

　　如果说十几年前软件设计大家都会采用UDD的方式，尤其是基于RUP（Rational Unified Process，统一过程，Rational[后被IBM收购]公司发明的基于UML的经典的软件设计工程实践方法论，曾经被广泛应用）的软件设计实践，那么现代软件设计实际上在实践中已经变得更加自由开放，没有限定性的格式和要求。从PRD的编写就能看出，曾经的需求规格说明书都非常的严谨、繁复，但是现在各家软件公司的PRD模板格式各异，千奇百怪。

　　总体来讲，我认为现代软件工程实践，要遵循快速迭代、验证市场、小步快跑、紧贴场景的理念，但是同时也要认识到在某些情况，尤其是从无到有的设计过程中，用例设计所体现出的高维的抽象设计也是必须的。当然，如果是体量更加庞大的商业性软件，比如说Office、Windows这个复杂度，则超级详细规范化的设计和文档是必须的。

　　作为产品经理，应该知道如何将Use Case和User Story结合起来用，才是正确的选择。

　　最后，我们将两者做一个对比，总结在下表中。