如何从 0 – 1 设计 To B 产品

今天和大家分享的是我在工作中从 0 – 1 设计 To B 产品的经验，希望可以对初次把控整个产品设计的小伙伴有所帮助和带来启发。

B端产品（To Business）是企业为了提升工作效率使用的系统、工具或平台，通用的有：我们工作中经常使用的邮件、OA、HR、Jira系统等等，更加专业的有：财务、ERP、CRM、监控系统等等。大多数情况下，B端产品的用户为某个领域的专业人员，专业性较强，产品经理最好能对专业领域的知识有一定的了解才行。

但是，不要慌，完成一款 To B 产品的设计其实和将大象放进冰箱一样简单，只需要三个步骤：第一步，发现问题、第二步，寻找解决方案、第三步，解决问题+迭代。

第一步：发现问题

人类因为不想洗衣服，发明了洗衣机

人类因为不想洗碗，发明了洗碗机

人类因为不想扫地，发明了扫地机

……

从以上这些解放双手，提高效率的事情上，我们可以得到启发：人类不想做的事情、提高效率的事情，就是我们需要发现的问题点（痛点），是我们做产品的机会点。

那么，如何发现这些问题（痛点）呢？

可以通过这些方法来收集问题点：用户观察与访谈（必选）、专家访谈（必选）、用户故事地图（必选）、用户体验地图、服务蓝图等等。（可根据自己的情况进行裁剪使用）

针对B端产品的特点，这里我做了一个B端产品问题（痛点）的通用总结，任何B端产品都可以套用这个公式。

这里以运维场景为例，代入以下公式进行解释：

大批量、重复的手工劳作

运维中确实有很多大批量、重复分手工劳作，如：成千上万的服务器定期修改密码、巡检、资源分配&回收、持续集成&发布、应用部署、应用扩容&缩容等，这些偏日常和重复的基础运维工作，占用了运维人员大量的时间。

很大一部分公司还没有自动化或者自动化程度很低，这也是B端市场的一大现状。

2. 工作流程不规范、工作进展不清楚

运维高危操作事前无审核，事中无记录，事后无法追溯；运维变更流程，干系人多，未规定必选的干系人，变更失败几率大……

工作流程不规范，就无法进行追溯，工作的状态和进展也不清楚。

3. 操作无留痕，事后难追溯

线上操作，尤其是高危敏感操作，无记录、不留痕，事后无法审计与追溯。

4. 没有知识库，做不到知识共享

怎么安装打印机？怎么修改密码？怎么配IP？一个问题一天要被问百八十遍。

5. 数据收集难、分析难

周报表和月报表数据需要从好几个平台导出，然后再进行二次处理，易错又费事。

第二步：寻找解决方案

针对上面发现问题，我们需要跟用户、专家、工程师们一起想想解决方案，可以使用的方法有：用户故事地图、用户体验地图、头脑风暴、用户访谈、专家访谈、产品经理个人经验、MVP等，这里着重讲解一下用户故事地图法及MVP法。

用户故事地图

厘清问题，用户是谁，解决方案是什么，可以为带来什么价值？

写下用户故事：作为<什么角色>，我想要<什么功能>，得到<什么价值>。

构建全景图，广度优先，而非深度。不要管能不能实现，使用头脑风暴，尽可能的多想一些。

毕竟，乔布斯曾说过：“你必须先从用户体验入手，再回头解决技术问题，而不是相反”。先去想解决方案，然后再考虑技术能不能实现。

使用亲和图的方法，把收集到的大量的Story，按其相近性进行归纳整理分类，使问题明确起来，得到大家的认同，以利于问题的解决。

然后，再将这些Story进行优先级排序，哪些是我们最大、最头疼的问题呢？输出产品功能架构图。

从MVP（Product）到MVP（Prototype）

MVP（Product）最小可行产品

MVP是由《精益创业》的作者埃里克·莱斯提出，最小可行性产品的方法在已经有很多成功的案例了。

MVP（Prototype）最小可行原型

基于增长黑客的理论，MVP（Prototype）最小可行原型的方法被设计师和产品经理提出和成功应用，MVP（Prototype）和 MVP（Product），最大的不同是 MVP（Product）需要开发，而MVP（Prototype）不需要任何开发工作，拿着产品原型直接找目标用户进行商业论证，减少不必要的资源浪费。

商业被论证后，最主要的任务就是快速实现了。现在已经有技术领先的公司，可以快速的将产品原型进行技术实现——Frog超级原型，可以更快的把产品推向市场。

第三步：解决问题+迭代

第二章讲了如何获得解决方案的方法，第三章要回答一下如何解决第一章总结的B端产品的通用问题。

这里以运维场景为例，代入以下公式进行解释：

大批量、重复的手工劳作

可以考虑自动化、用户自助的解决方案。

比如：大批量的运维工作可以通过脚本进行批量管理，而这些脚本可以从系统工具库中获得。

2. 工作流程不规范、工作进展不清楚

工作流程需要业务部门和产品经理一起进行梳理，然后根据业务流程进行产品开发。

比如：根据ITIL，建立变更流程、故障管理流程、问题管理流程、配置管理流程、交接维流程等等。

3. 操作无留痕，事后难追溯

线上操作，尤其是高危敏感操作，都需要记录、留痕，事后可以审计与追溯操作日志。

4. 没有知识库，做不到知识共享

怎么安装打印机？怎么修改密码？怎么配IP？一个问题一天要被问百八十遍。可以使用自助机器人解决，或者FAQ功能解决。这些常见的问题和答案需要业务部门准备。

5. 数据收集难、分析难

业务部门需要的数据，可以从一个系统直接导出，同时具有可视化图表功能，支持pdf下载及邮件订阅。当然，数据模板由业务部门提供。

产品上线后，产品经理可以不断收集用户反馈及根据业务的变化，进行产品的优化和迭代。文中提到方法较多，产品经理们可以根据自己的项目情况，按需裁剪使用。

参考资料：

用户故事地图.（美）Patton，J 著；北京：清华大学出版社，2016

亲和图：https://baike.baidu.com/item/亲和图/10331945?fr=aladdin

苏杰：从MVP（Product）到MVP（Prototype）：

https://mp.weixin.qq.com/s/tYWQWRRCGKYP1184eooVqA

Frog超级原型来自温伯华的演讲：https://daxuepc.com/detail/v_5c2f495d23976_WGSwCBl5/3

作者：沈子砚，设计师出身的产品经理、PMP，江南大学设计学院硕士，专注于产品设计、产品体验与产品运营，公众号：UXHub