从点餐小程序提及，谈谈如何从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的「滑动解锁」了。
第六章 后续 实际上，到了这一步，产品设计部分工做就已经结束了。后面就会开始产品开发和后续的迭代。
写完才发现，这篇文章有种头重脚轻的感受，本想结合实例来说解的，结果最后又没有用到实例。终究仍是我的行业积累不够，不少东西内心明白殊不知道怎么表达出来。但终归仍是在进步的。这就像打怪升级的过程，每一次进步，看待问题的方式都会不一样，只能说「只缘身在此山中」。
最后，欢迎打赏。
转载自十二赞官方【原文连接】