从点餐小程序说起，谈谈如何从0到1设计一款toB类产品

本文转载自公众号一鸣说 作者一鸣 十二赞产品经理
摘要： 本文以笔者实际工作经验为例，讲述了 toB 类产品从0到1的过程。
本文章节
– 前言
– 第一章 概念
– 第二章 产品价值
– 第三章 定位
– 第四章 产品设计
– 第五章 交互和视觉设计
– 第六章 后续
前言 最近一阵子有一些总结，刚好周末有空，就来谈谈自己的想法吧。本期谈的是「餐饮应用」，对很多人来说，这是一个既陌生又熟悉的行业，熟悉的是大家或多或少都去过餐厅里面吃饭，陌生的是很多人并不了解餐厅的运作模式。行业经验一直是我的薄弱项，针对一个行业做的应用，如果产品经理本身对这个行业不甚了解的话，那么做出来的产品一定是有问题的，目前的我只能摸着石头过河，一遍摸索一遍前进。
前面的很多文章，我讲得几乎都是方法论的东西，谈到了产品经理的分级问题，这里可以插入一点谈谈我对不同等级产品经理的分级概念：
第0级是为未入门的产品经理，俗称门外汉或产品新人，是对「产品设计」有一定了解，但是不具备方法论的人，只能观察到产品的表象，所有对产品的理解停留在表现层，做竞品分析停留在产品A有某个功能而产品B没有等等。很多人说的产品设计这个行业门槛低，其实指的就是成为产品新人门槛低，凡是会说话的，都可以对产品发表意见：「我觉得这个功能不好用。」等等。
第1级是初级产品经理。初级产品经理算是真正进入了这个行业，标志就是能够熟练运用各种前人总结的方法论，（说是前人，实际上也就近10年）设计产品遵循一定的规则。成为初级产品经理，一个简单的要求就是熟读业内关于方法论的书籍至少20本以上。实际上，当我读到第18本关于方法论的书籍时，突然顿悟，无非就是这么一回事。做产品和以前我学数学是一样的，先学理论，再用理论去解题。做产品设计也是一样，先学这些产品方法论，再把方法论应用于产品设计中，这就是初级和为入门的差距，未入门的产品经理设计产品是根据自己喜好而非理论。他们没有办法理解自己虽然是其中一个用户，但是不能代表用户。低阶的初级产品经理具备了独立设计一个功能模块的能力，而高阶的初级产品经理已经具备的独立设计一款产品的能力。目前我的自我认知是我仍处于初级。
第2级是中级产品经理，他们已经对自己所处的细分行业有较深的了解。设计产品更多的是「道」而非「术」，中级产品经理已经几乎不会去关注产品的交互、视觉和功能，因为这是初级产品经理考虑的事情，中级产品经理更多的是分析这个行业的走向，开始逐渐以商业的角度去分析问题。高阶的中级产品经理一般已经成为了本细分行业内的知名人物，频频出现在各类会议现场做主讲。
第3级是高级产品经理，这一级别的产品经理是凤毛麟角的存在，恐怖如斯！吾辈恐怕是难以望其项背，我也难以描述这一级别的产品经理到底是什么样的了。（发现一激动又扯远了。我们回到正题。）
本文其实是前一个月工作的总结。本文的重点还是方法论，以实际的案例来展现产品经理在设计一款新产品从0到1的整个设计思考过程，对于产品新人应该会有一些帮助。（如果需要更深入了解产品，可访问 www.12zan.cn）
另外，由于笔者水平有限，文中难免有疏漏之处，恳请前辈批评斧正！
第一章 概念 1.1 toB类和toC类产品的区别
toB类产品和toC类产品在初始设计阶段就有很大的不同，更多的是设计理念的不同。简单讲，toB类重实用，toC类重易用。
toC类产品只要「好玩」「爽」就可以了，主要目的是占据用户的时间。toC类产品重点关注的大多是在用户体验层面的东西。而toB类产品除了要考虑以上这些以外，最重要的toB类产品必须提供一定的「用户价值」，企业级用户首先关注的一个问题，这个产品能否解决他的问题。能够解决问题就提供了用户价值，这才是他们选择一款产品的原因。不是说toB类产品的用户体验不重要，而是说这些都只是锦上添花的东西，这里面的「锦」就是「解决用户的问题」。例如解决中小企业搭建服务器成本高的问题，诞生了云主机；解决中小企业内部管理及沟通问题，诞生了钉钉和企业微信等。
在做toB产品的时候，产品经理必须「死扣」一点，那就是这个设计或者这个新功能解决了什么问题？
第二章 产品价值 2.1 用户价值
用户价值指的是产品给用户带来的价值，其实就是上面讲的解决的用户的问题，解决问题是产品的核心价值。很多新手在前期独立负责产品设计工作的时候，容易走进一个误区，那就是做「功能的叠加」，逐步给产品增加功能本身没有错，关键要看增加的这个功能有没有「提供用户价值」，更准确地讲，对要解决的问题有没有帮助。对于有明确目标的用户，他并不会关注你提供了多少功能，而只关心这个产品是否真正满足了他的需求。
对于低阶初级产品经理而言，最大的能力就是「知道如何去做」，也就是在明确一个功能之后，能够准确无误地设计出这个功能。然而对于高阶初级产品经理而言，最重要的能力就是「找对问题」的能力，找到的问题越真实，产品能够提供的价值也就越大。
当我们在推销我们产品的时候，面对目标用户，如何打动他？你是告诉他：「我们这款产品有A功能，B功能和C功能，功能很多。」还是「我们知道你遇到了XX问题，这款产品刚好能够解决你的XX问题。」如果你是用户，哪种说法更吸引你。（这里突然想起来苏杰先生说的一句话：任何产品需求，挖到最后都是人性。写到这里突然感同身受。）
2.2 痛点
痛点是什么？痛点就是没有解决的问题。我们来分析餐饮行业存在哪些痛点，我们以商圈内的中小餐饮店铺为例：
（1）曝光度问题，也就是推广问题，餐厅本身产品味道很好，口碑也很好，但是大家都不知道。
（2）到店排队问题，店内顾客多的时候，后到店的顾客就是排队，如何管理排队的顾客的问题。
（3）点餐问题，从把餐单给顾客到顾客店外餐确认再传递后后厨，这个过程可能有10到20分钟。
（4）结账问题，部分顾客可能存在着逃单的情况。
（5）评价问题，餐厅并不知道用户对餐品的看法，顾客觉得哪款好吃哪款不好吃。
以上只是粗略地按照顾客消费的流程大致列了几个痛点，实际存在的痛点远远大于以上说的这些。产品经理能够挖掘到的痛点越多，离用户也就越近，同时离产品成功也就越近。
2.3 最小可用产品
开始准备着手设计产品后，是一开始做一个行业的全流程解决方案，还是从一个切入点着手，再慢慢发散形成行业解决方案？在互联网早期，这是一个需要思考的问题。而现在，这一点已经形成了常识。互联网行业区别于传统行业的特点是直面用户，能够快速的收集用户的反馈。互联网产品一般都是首先推出一个最小可用版本，然后聆听市场反应，根据用户反馈快速地迭代更新。
如果从一开始就把一个大而全的产品开发完毕再推广上市，可能存在的问题是，由于开发周期较长，这个东西早已不流行或者竞品早就已经抢占市场，从而造成了浪费。
产品的最小可用版本并不是指设计一款粗陋的产品，附加几个功能就推上去了。而是指最初的版本需要直指这个行业最核心的问题，去解决这个问题而做的产品。每个行业都会遇到很多问题，有的是小问题，有的是大问题，而有的是核心问题，能够把这些问题都解决的，那就是行业解决方案。
我的一个思路是，做行业的解决方案，第一个版本的产品必须要做一款「效率工具」，能够提升工作中某个环节效率，减少时间成本的工具。设计产品的第一个版本的时候尤为谨慎，需要直击硬核需求，用最小的开发成本撬动产品萌芽。
所以经过反复几轮的产品讨论，最终决定以点餐应用作为餐饮行业的切入点。主要原因有：
（1）点餐环节是餐饮解决方案中最核心的需求，任何流程都避不开这个环节。
（2）将点餐环节信息化，能够大大提升餐厅的效率，直接节省人工成本，以餐桌数50桌的中型餐厅为例，一个月光点餐环节可以省下5到10万的人力成本。
第三章 定位 3.1 产品定位
有句话是这么说的：「一个好的产品只要一句话就能讲清楚。」这句话的含义就是一款定位明确的产品能够用一句话就可以讲完，如果一句话说不完，那就说明这款产品要么是定位不明确要么就是想做成微信这一类的巨无霸应用。简单讲，产品定位就是告诉用户，这款产品是做什么的。那么我们回到这款「点餐小程序」，他的定位是什么？初版的定位就很明确，这是一款提升顾客点餐效率的工具。
我们明确了产品的定位，之后在设计功能的时候，就有了一个基准，符合定位的就做，不符合定位的就不做，这就是产品定位的用途，限定了产品功能的一个大框架。
做产品，经常讲究一个「极简」思维，那就是「功能一个不多，一个不少」。要做到这个并不容易，一个小技巧就是，每款产品都当成一张白纸，不要预设什么功能，只有确实需要，再往上加。
3.2 用户定位
用户定位决定了这款产品是给谁做的。用户千差万别，需求场景更是迥乎不同。从街边的沙县小吃到富丽堂皇的大酒店，餐饮行业的跨度非常大，他们的需求可能完全不同。
为「某些人」做，而不是全部人做，这就是「用户定位」。显然我们没有办法支持所有人的需求，只能选择相似度较大的中间群体而做。用户定位是否准确决定了产品之后的走向。
还是以点餐应用为例，街边比较小型的店铺面积在10平方米以内的沙县小吃可能不是我们的目标用户，因为他们的痛点不在点餐环节。居于城市中心的大酒楼，也不是我们的目标用户，他们的点餐环节承载的意义不仅仅是点餐，这个环节没有优化的意义。基于此，这款点餐应用的目标用户应该是：「商圈内餐桌数在20到100桌的餐饮店铺」。
3.3 市场调研
市场调研的用途是探究产品所在市场的容量。这一块几乎是我的知识盲区。
市场调研只要是探讨整个市场的规模有多大，已经目前是否已有成熟的竞品等。
第四章 产品设计 4.1 产品设计
对产品进行定义之后，就要开始设计产品。这种从0到1的设计最考验产品经理的思考能力和逻辑分析能力。
第一步要做的是，搭建产品架构，常见的要求就是模块化，低耦合度，高拓展性。如果产品不迭代，那怎么设计都没问题，只要能用就好。考虑迭代，那么整个产品架构非常重要，需要充分考虑之后的拓展性，这就需要考验产品经理对业务发展的前瞻性了。各个模块之间相互独立，降低耦合度，避免出现牵一发而动全身的情况。
4.2 流程
确定了产品要解决的问题，下一步就需要思考这个问题出现的场景，以及解决这个问题的流程。以点餐环节为例，我们先构想一个初步的流程，再把流程逐步完善。
首先，商家需要在后台上传商品，用户在前台看到商品，然后选择商品下单，商家看到用户的点餐信息。这是一个自然的、基础的流程。到这里就出现了两个平台，「前台」和「后台」，有什么区别呢？一般来说，前台面对的是终端用户，而后台则是为前台服务的。从上面这个例子可以看出，用户（实际上，这里的用户有两类，直接用户和间接用户。下面把直接用户称为商家，间接用户称为用户。）想要在前台看到商品，总要先把商品给上传上去，从哪里上传，谁去上传？自然是商家在后台上传商品。
显然上述的流程并不完善，只是一个粗陋的描述，我们需要把每一个环节精确到「操作」。还有这里的前台，用什么呈现显示，这些都是问题。每一种呈现方式的优缺点分别是什么，这些都是产品经理需要思考的问题。可以预料的是，让用户自己扫码打开小程序，这是一个比较完美的方式，将各方的成本降到最低。对于商家不需要购买额外的设备用于点餐，对于用户不要安装APP或者其他的东西，使用小程序可以「用完即走」。
我们继续完善流程。站在用户的视角，进店引导入座，告知扫码，打开小程序开始点餐，点餐完毕提交订单，商家看到订单开始配餐。
再仔细思考，上述流程还有哪些环节可以继续优化的。既然点餐都到线上了，那可以同时把付款环节也留在线上，全流程的信息化。
上述的流程还可以再继续细化和优化，涉及到保密要求，再往下讲就涉及到真实的业务场景了。剩下的环节读者可以自行思考，思考用户的操作流程的意义在于为后续的设计功能提供依据，功能是围绕着流程来的。流程中需要的功能一个都不能少，流程中不需要的功能也不用添加。做到这一步，就达到了功能的「极简」。
在考虑用户操作流程的时候，需要注意的是，要细化到每一步操作，这里的操作指的是：点击一次按钮，扫码，滑动，长按等操作，用户每接触一次屏幕，便算一次操作。如果能做到将用户流程细化到这个程度，后续设计功能和交互将非常容易。
4.3 功能
确定完流程之后，下一步就是设计功能了，之后再往下的设计工作将越来越简单。后续设计工作基本就考验一些基本功和方法论。
设计功能时最重要的就是取舍了，这是一个很大的难题。任何一个功能进行深入研究，都有无限拓展的可能。功能设计宜精不宜广，十分考验逻辑分析能力，尤其在考虑功能的完备性和自洽性方面。任何一个功能都会涉及到多种可能，每种情况的判断如何，每一次用户的操作可能引发的结果分别是什么，这些都是产品经理需要考虑的问题。
即便是同一个功能，在针对不同的用户群时，操作逻辑可能也会不同，高频操作或是低频操作，使用较难理解的方式去实现复杂的功能，还是用更简单的操作逻辑，多做几步去实现这个功能，每一次决策都考验着产品经理对行业以及用户的理解。功能设计这部分，是产品设计的重头戏，后面还有几篇文章会详细讲解，这里不赘述了。
4.4 产品文档
确定了产品功能之后，需要依据要实现的功能撰写产品文档。可能在大公司会要求写各种完备的PRD文档（即便这些完全用不着），如果开发团队超过100人，那么完备的产品文档是很有价值的。如果开发团队在10人以内，用这种裹脚布似又臭又长的PRD文档就不合适了。在团队较小时，首先看重效率，而在团队大到多一个人少一个都无所谓的时候，这时候就首重不出错，不背责，最后才是效率问题。没有人会喜欢面对一个一句话就可以说清楚的开发需求，结果要照着百科全书般的文档去做开发，发现其中99%的话都是废话。
常有人问，什么才是一份好的产品文档？我认为只要能够把要开发的内容说清楚的文档就是好文档，文档的形式并不重要。文档的作用就在于减少开发过程开发团队和产品团队的沟通，不用针对其中的细节反复确认。我们考虑一个场景，产品经理就坐在技术人员边上，一遍开发一遍告诉技术人员下一步做什么，时刻保持沟通，这个实际上也是没有问题的，但是效率太低了，产品文档就是解决这个问题而生的。
我们平常用的产品文档常以「原型图 + 注解」的方式呈现，而不是通篇累牍的文档。在一段时间的磨合后，产品经理明白什么内容需要额外注解，什么内容不需要注解，已经达成共识，这对提升开发效率十分有帮助。
产品文档不重形式，甚至很多时候，一句话就能把需求说清楚的话，连原型图都不是必要的。当然这一切建立在产品和开发有一定程度的磨合上，已经建立了一定的默契。如果当开发团队人数到达100人以上，那只能写那种又臭又长的99%都是废话的PRD了。
第五章 交互和视觉设计 交互反映了用户操作产品的流程。在设计交互环节，要考虑的两个问题是：如何组织各环节的页面，如何组织各页面中的元素？这些在设计功能环节就已经决定的。在做toB类产品的时候，面对B端（通常是后台部分），通常不会去做花里胡哨的交互效果，只要遵循基本的用户体验原则去做就可以了，关于常见的用户体验原则可以见上一篇文章。
在交互设计环节，我认为最重要的有亮点：一是符合用户预期，二是别让用户思考。
「符合用户预期」的意思是，当他做完某一步操作时，他预期这时候应该出现一个提示，但是实际并没有出现，这个用户体验就不好了。做到这一点并不能，只要克制住自己的「小点子」的想法，不要去搞「瞎创新」就可以了，很多现有的成熟产品早已提供了一整套的交互逻辑，不要为了创新而创新，在这里用户「习惯成自然」的环节因循守旧就可以了。对于这些，我的态度是，不拘泥于传统，同时也不会为了不同而搞不同。
「别让用户思考」的意思是，用户不需要被引导就知道怎么操作，一个页面上的「说明」越多，就说明这个功能越难用，但实际上这是很难避免的。将「别让用户思考」这一点做到极致的产品就是iPhone的「滑动解锁」了。
第六章 后续 实际上，到了这一步，产品设计部分工作就已经结束了。后面就会开始产品开发和后续的迭代。
写完才发现，这篇文章有种头重脚轻的感觉，本想结合实例来讲解的，结果最后又没有用到实例。终究还是个人行业积累不够，很多东西心里明白却不知道怎么表达出来。但终归还是在进步的。这就像打怪升级的过程，每一次进步，看待问题的方式都会不同，只能说「只缘身在此山中」。
最后，欢迎打赏。
转载自十二赞官方【原文链接】