1.2 以业务为中心的设计

本书提到的以业务为中心的设计，参考了以用户为中心的设计。以用户为中心的设计是指在设计的每一步中，都要考虑用户的因素，并且把用户体验的设计分成了五层、十个要素，分别是战略层（用户需求、网站目标）、范围层（功能规格、内容需求）、结构层（交互设计、信息架构）、框架层（界面设计、导航设计、信息设计）、表现层（视觉设计）。

而以业务为中心的设计，就是要思考一项业务要如何设计。为此我们把业务设计分成了四层九要素，如图0-2所示。

图0-2所示的模型从上到下分为四层，分别是定方向、搭框架、做细节和画界面。这四个层次首先体现了工作的次序，即从上层的战略设计到底层的画原型图；其次，一项业务必须从大到小做设计。有的产品经理编写的文档容易出现结构混乱的问题，往往就是因为层次不分、次序不分、大小不分，因此需要重视设计的层次。下面，我们具体解释四个层次中的九个要素。

1.2.1 定方向：产品战略、解决方案

产品都要有方向，无方向的产品就如同在黑暗中远征。定方向包含产品战略和解决方案。产品战略定义了产品近期和远期的轮廓，划定了产品范围。解决方案在本书中特指在确定了产品范围后的较大决定，如某模块或某系统是否要开发。显然，只有确定了产品战略和解决方案，才能确定如何设计业务，否则业务设计就成了为设计而设计。

1.产品战略

产品战略是指，明确要进入的市场、要服务的用户和要做的产品范围。比如，企业决定要给中小餐厅开发本地餐饮系统，解决餐厅的营销和管理问题。这就是一个产品战略。而产品范围就是做本地餐饮系统，以后的产品设计都要在这个范围内展开。

产品战略的制定很复杂，要考虑企业情况、市场规模、竞争环境等因素。制定产品战略的理论众多，我们将讲解经典并常见的理论，并梳理各个理论间的关系，从而形成较完整的战略思考框架。

2.解决方案

在产品战略确定后，我们就要确定先做什么，后做什么。比如，先做点餐系统，再做预订系统，最后做排队系统。要想清楚这些内容，一方面要能想到各种方案，如基于线下场景的各种点餐方案。另一方面要能评估方案的价值，一个方案只有对使用者和开发者都有高价值，才值得开发。

基于以上两点，我们会讲电商、教育和企业服务行业的价值点，然后基于这些价值点，讲如何找到高价值的方案，以及如何排期。

1.2.2 搭框架：功能框架、非功能框架

在定方向完成后，产品经理就要做产品设计。产品经理不能一上来就画原型图，而应先搭建框架。该框架包括功能框架和非功能框架，是对这些内容的宏观定义。产品的框架仿佛是摩天大楼的框架，或者是人的骨骼框架，对产品起支撑和限定作用。

1.功能框架

功能框架要对功能做挖掘和限定。比如，企业决定要做线下的排队系统，就要明确该系统所具有的功能。梳理功能框架有两个难点。

首先，产品经理容易遗漏需求。比如，一个外卖平台的预订和排队系统，除了具备常规功能，还要具备给老板用的绩效统计功能，给维护人员用的故障排查功能，这些功能一旦遗漏，产品就是不完整的。

其次，产品经理往往梳理功能无层次。比如，一个外卖平台既要具备订单的待支付、已支付等功能，又要具备购物车、设置优惠券、查看物流信息等功能。尤其对于复杂系统，无层次地梳理功能，既不利于厘清需求，也不利于研发人员理解。

我们将通过用例的方法，解决上面两个难点，使用该方法就能没有遗漏、有层次地厘清产品的功能。对“用例”也许你很陌生，但“用户故事”你应该听说过。其实，用户故事就是用例的实践，用例可表达用户故事之间的联系。本书将综合运用这两种方法来梳理功能。

2.非功能框架

功能是可以被用户使用的。比如，排队功能和点餐功能，都可以被用户使用，属于功能需求。除了功能需求，还有非功能需求，如安全、可维护、性能需求等需求。

如果说功能需求是用户使用网站的原因，那么非功能需求则是用户使用网站的根基。从某种程度看，非功能需求和功能需求同等重要。因为如果安全没有保障，用户就不会使用该产品；如果网站访问速度慢，用户就会失去耐心而流失。

很多产品经理不会梳理非功能需求。一个原因是产品经理不懂这方面的知识，只能由研发人员代劳。另一个原因是，研发人员也能搞定这些需求。但情况并不是总如此。比如，给银行做的存取款系统。产品经理既要梳理该业务的发生时间、业务类型、并发人数等，从而确定性能需求，也要梳理监管部门、安全部门等提出的安全需求。在该场景下，产品经理要学习这些知识。

虽然非功能需求的知识点众多，但是内容比较固定，只要认真学习就能掌握。本书将梳理主要的非功能需求，解释其概念，并给出和研发人员进行配合的建议。

1.2.3 做细节：业务流程、业务操作、信息结构

在业务框架搭建完毕后，就要做细节规划。这好比盖一座摩天大楼，要先设计外部框架，再设计内部的细节，细节包括房间的空间结构、水电布局等。对一项业务来说，细节包括业务流程、业务操作和信息结构。搭框架强调了功能有什么，而做细节就是要把功能细化，是一个从粗到细的过程。

有的功能比较简单，产品经理就不需要梳理这三类内容。但是如果功能复杂，产品经理就必须先梳理这些内容，这样做的一个原因是，研发人员要根据这些内容来设计系统，而不能只看原型图。另一个原因是产品经理需要理顺设计思路，为画原型图打下基础。下面，我们就介绍这三类内容。

1.业务流程

我们从业务的定义了解到，业务都是有流程的。比如，排队业务的流程是，首先服务员询问顾客是否有预订，然后服务员输入就餐人数，服务员打印排队小票，最后呼叫就餐顾客。再如，一个外卖订单，在用户支付完毕后，就需要运营人员确认发货，再到物流人员进行配送，这也是一个流程。面对一项复杂业务，产品经理需要先梳理好流程，再画原型图，这是一个完整的过程。

2.业务操作

我们用流程图梳理了业务流程，还要用状态图梳理业务操作。状态图表述了在一项事务的不同状态下，人能做什么操作，该操作会改变事务的状态。比如，一个订单在用户支付完毕后，其状态就变为已支付；在运营人员确认发货后，订单状态就变为已发货。在该案例中，人的操作就改变了订单的状态。

产品经理使用状态图，可让思考更全面。比如，用户下单了但未支付，谁能取消订单呢？可以是用户，可以是商家，也可以是系统。要做到这些，产品经理只需看着状态图进行思考就可以。状态和流程既有区别又有联系，我会在相应章节中讲到。

3.信息结构

信息结构表述了信息内容之间的关系。比如，一个订单含有该订单的下单时间、购物金额等信息内容。而一个订单可由多个物流运输，就是在表述信息之间的数量关系。显然，订单支持一个还是多个物流，其前台和后台的原型图是不同的。因此，信息结构决定了前台的展示、后台的交互。信息结构可用类图来表达。

如果信息结构设计错误，将导致信息冗余和系统无扩展，这也是造成研发人员返工的主要原因。本书将讲解如何梳理信息结构和类图，从而避免这些问题的产生。

4.本节小结

以上就是业务流程、业务操作和信息结构的内容。其中，业务流程和业务操作在梳理业务的动态部分，信息结构在梳理业务的静态部分。这些内容都在描述业务的细节。本书将分三章讲解，包括最关键的流程图、状态图和类图。当然，绘图不是目的，我们的目的是通过绘图，厘清业务的动态部分和静态部分，从而为画原型图打下基础。

1.2.4 画界面：交互设计、信息设计

一个建筑的细节包括房间的水电结构等，而在房屋的细节做完后，还要做好外在装饰，如给墙面刷漆，配好地砖等。一项业务也要有装饰，这就是要有界面。搭框架和做细节都是一项业务的内在表现，而画界面则是一项业务的外在展示。一个界面对使用者来说，是可直观看到的部分。画界面分为两部分，分别是交互设计和信息设计。

1.交互设计

交互设计的范畴很广，本书的交互设计特指人机交互，侧重在界面上的人机互动，其过程是用户输入信息，系统展现信息。C端和B端的交互设计有所不同，我们分别做介绍。

1）C端的交互设计

C端的交互包括信息展现类的交互和业务执行类的交互。

信息展现类的交互。比如，列表页按价格筛选，详情页单击看评价等。这种类型的交互，在很多书中都被讲到，不是本书的重点。

业务执行类的交互。用户在决定购买后，就要发起一项业务，如进行注册、下单或视频认证等。这些交互往往比较复杂，比如，在用户进行登录时，系统就要判断手机号格式是否对、用户密码出错次数是否过多、该手机号是否注册过等。这些交互设计是本书的重点。

2）B端的交互设计

C端发起一项业务，B端就要处理。比如，当用户进行实名认证时，B端员工就要进行审核，员工可以选择拒绝或通过。这些页面交互并不难，也不是本书的重点。

2.信息设计

信息设计包括信息有什么，以及该信息如何展示和操作。关于C端的信息设计，已经有很多书阐述，本书将侧重阐述B端的信息设计。

B端的信息设计和C端的不同，B端用户看信息是为了高效地工作，因此产品就要从业务出发，如思考列表页要有什么信息，从而便于用户区别、决策和操作。B端的信息设计包括导航设计、列表设计和详情页设计等。本书侧重讲解列表设计，如商品列表、订单列表等的设计方法。

1.2.5 业务设计整体框架的运用

业务设计整体框架中的四层九要素定义了业务设计的过程。然而业务是复杂的，类型是众多的。在工作中，我们不一定要按照本书的顺序做，即不一定只有第二层的搭框架做完了，才能做第三层的做细节，反过来做也是可以的。我们要具体情况具体分析，要灵活运用。本书的第13章会讲如何灵活运用。