一个完整的B端设计流程｜长篇干货

步骤2：进入 [运费和费用] 模块，先看他们的预约规则，然后打开他们提供的PDF查看预定的日期和价格，来确定自己想要选的房间。这里房型价格和热门时间有关，官方分了A、B、C三个价格档来对应热门冷门时间。

步骤3：进入 [预定] 模块，填写个人信息和想预约的房型，房型选择有3个，如果前面的选择满房就向后递补，填写完成后，就可以点击发送预定信息。

步骤4：隔日等待反馈邮件，到邮箱中查看。还能预定的话就会有一个链接，进入链接中进行支付。之后就可以获得登船的凭证。

后续的细节就忽略，一个简单的买票缓解，操作起来这么麻烦，是不是感觉非常陌生，这是因为国外有很多服务的预定都需要到官网预定，和国内出行完全依赖综合旅游软件如飞猪、携程、去哪儿等不同。

而这个订票的流程，到审核（人工的）回复的整个过程，就叫 —— 业务流程，是一个被设计好并标准化的商业实践过程。

每家公司的经营都会包含大量的业务，房间预定只是它的其中一个业务，还包括登船、房间清理、物资采购等。而每个常规的业务的执行如果全凭员工自己的想法、感觉，那么企业的运转一定会一团乱麻。所以经营者就要针对这些常见的业务，设计出相应的流程出来进行标准化，让员工和顾客遵循这套流程来完成商业活动。

而业务只有流程框架还不够，必须包含大量的细节，比如前面提到的不同定价时段，满房的递补，退票的方式等等，这些都是业务流程中的细节规则，我们可以统称它们为 “业务逻辑”。

简单来说，企业经营要先确定业务，然后设计流程，再制定具体的业务逻辑，形成完整的商业闭环。但这和设计师有什么关系呢？

因为业务是产品的出发点，常规项目只有业务形式确定下来，才会进入产品的设计阶段，而不是先设计产品功能再让业务去适配它的特性。而产品后续一系列的复杂、抽象、晦涩的决策也全都和业务有非常大的联系，

这个预定过程对于熟悉国内互联网的我们来说肯定是太复杂了，用个线性流程表示的话，对比如下：

国内软件预定：打开软件 - 搜索船票 - 选择日期 - 选择房型 - 完成支付

官方网站预定：搜索官网 - 打开官网 - 查看房型 - 查看价格 - 填写信息 - 等待回复 - 查看邮件 - 完整支付

从字面上感觉可能不明显，但实际上操作时长、点击次数以及总消耗时间，它的做法远比国内的服务慢，加上细节里有很多会延长完成时间的逻辑，比如没有想要的房型就要重新去选一遍，而这在国内软件里一开始就能知道直接规避掉。

这个业务过程非常的原始，后台可能有一个简单的收件系统，由人工来逐一审核提交的邮件，创建订单，然后再提交回复。

如果我们要提高这个业务的效率，就必须要改进这套系统，将人工的机制进行简化，即客户可以直接在前端完成筛选、预定、支付的操作。相信大家都很熟悉这种操作过程，而这种改进就叫 ——

。就是本来使用人工或者很原始的方式执行的业务流程，引入数字化的系统、产品，来提升它的运行效率。

而产品经理要在这个过程做业务的分析，具体分析什么呢，可以简单总结成：

前两点前面已经解释过了，当前业务是存在缺陷的，而产品经理必须先理解完业务和找出问题，才能进行后续工作，而不是直接忽视背景打开 Axure开始画图。

有了问题，下一步就是建立产品的框架，比如这个业务会涉及到多个端，产品就要先创建多个端的功能框架出来，包含的端可以简化成下面三个：

用户端就是普通的网页预定模式（这里不讨论APP和小程序等），让用户直接选择日期、船型、房型后支付获取凭证，非常容易理解，不用多做介绍，我们重点放在管理端和后台服务的解释上。

在管理端上，管理员已经不需要手动审核预约了，所以只需要对订单和账单（这是两件事）有查看和管理的操作即可，来完成一些特殊业务事件的处理。

而在后台服务上，就要确定有哪些数据信息，以及处理它们的方式。比如订单的支付、退款，会涉及到非常复杂的后台处理过程，包括不同支付方式接入、对不同货币的支持、资金的转出等等。其它功能还包括房型数据更新、价格数据更新。这些都是用户端和管理端无法直接看见，但又在真实运行的功能。

根据上面对不同端的分析和构想，就可以创建产品的 —— 功能架构图，比如下面这个极简的版本：

对于一个成熟的产品经理来说，进一步制定产品的需求肯定不是直接打开Axure画原型，而是先围绕业务的需求制定 —— 数据字段。

数据字段即前、后端服务中要存储、计算、展示的具体对象。比如一个房间，前端页面会展示房间名、价格、人数、面积、类型、评价等各种数据。但这些数据不是凭空出现的，而是要先计划和开发才能实现的内容，且不同字段背后可能还包含复杂的设置或计算规则。

所以产品要花很多时间分析应该记录哪些数据字段，这些数据怎么产生，背后有什么逻辑，在前端显示的标准是什么。

用个更具体的案例来解释，比如要创建房间价格这个字段，这个字段的值就具体价格值。但是房间的具体价格不是固定的，包含三个档位，根据日期决定的档位进行灵活的变动。所以要实现正确的价格显示，光有一个房间价格字段是不够的，我们需要建立更多字段来满足它的使用，包含：

这是个非常简化的版本，除了使用基数x系数的逻辑外，也可能直接给房间制定A、B、C三个价格的字段直接填价格不做系数计算。在真实项目中，该功能会创建得字段数远不止这些，产品还需要去明白数据的来源、计算逻辑、应用规则。

对于成熟的项目来说，项目的数据字段就是业务需求的延展，是整个业务正常运行的基石和原材料，产品制定的需求就包括它们的内容和规则，再让后端工程师去实现出来（而不是后端自己凭感觉想）。

有了上面这些准备，那么产品应该做成什么样就清晰很多了。下一步，产品经理就可以先用思维导图去规划管理端的页面结构与内容，而这种思维导图通常被称为 ——

。

规划完产品地图后，下一步才进入正式的产品原型设计过程，将我们对产品应该做成什么样通过原型线框图表现出来，只要能让其他人理解我们的意图即可。

当然只看图是不够的，很多细节的决策和逻辑就需要添加文字的说明，这种结合原型+文字的需求就交 PRD需求文档。它的作用是让设计师、程序员、测试工程师可以看懂并把它们做出来的 “施工方案”。

而作为B端UI设计师就要在了解业务和获得这些需求后，才能明白我们后面应该完成哪些工作，输出什么样的界面内容。

在项目中B端设计师的工作可以分成三个步骤，即：

前期准备要做的事情很多，包括参与立项的各种会议，接收各种信息和要求。但占据我们最多精力的工作，就是展开对项目设计的 —— 前期分析，这也是很多同学在作品集包装中看到的大段分析文本的来源。

每个项目前期的分析内容都有差异，但我们大体可以总结成以下几个模块：

项目分析就是了解整个项目背景的过程，比如这个企业的背景、提供的服务、业务的内容等等，最重要的目标就是 ——

，即项目要实现什么成果的预期。在这个渡轮项目中，项目的目标可以总结成提高顾客预定的效率和体验，同时降低人工审核处理的工作量。

了解这些信息是最起码的要求，假设你不了解这些项目的信息，直接开始跟着产品原型画图肯定是非常迷茫的。就像一个士兵被分了把枪到前线接收指令，你并不知道自己为何而站，为什么要占领前面那些陌生的高地。

业务分析则是了解项目具体面向业务的具体流程、规则、逻辑。渡轮的预定业务逻辑我们上篇已经探讨过了，很容易理解。但我们的项目是对原先业务流程的优化，这就意味着业务端必然会发生一定的改变，我们就要清楚这个改变的原因，旧业务的模式和缺陷，以及新业务的形态和优势。

这些信息主要从产品经理那里了解，或者他在特定的会议中会提供，就看你有没有认真听了。即使没说也可以主动提问，这个问题并不复杂。

再接着就是产品分析，这个分析是理解产品经理规划的产品是什么样的，即通过查看原型和文档来理解他的意图。虽然只是看，但理解起来并不会太轻松，越复杂的项目理解起来成本越高，所以我们也称这个过程是一个分析过程。

如果不能理解这个逻辑，就可以找一本相机说明指南仔细阅读，即使这本指南写的事无巨细，你要彻底搞懂它有哪些产品功能和对应操作逻辑，也要花费大量的精力和时间。

再下一步，就是体验分析部分，而这里要我们发挥主观能动性的部分就多了。通常，体验分析的目标，就是在产品需求确定后去找到有哪些可以提升体验的地方，确保最终设计的成果能让用户感觉体验更好。

要实现这个目标就要尽可能了解用户，即 ——

。因为体验是基于用户产生的，只有足够了解用户你才知道怎么面向他们做什么。虽然用户调研的方式多种多样，但在B端领域中用研却很简单，因为我们更容易直接和系统的操作员（不是用户端消费者）沟通，了解他们的诉求。

然后根据他们的诉求，来推导产品应该怎么设计、怎么优化更能满足他们的诉求，技术处体验方案。这个过程可以讲的内容有很多，篇幅关系不在这里展开，了解体验分析对B端项目来说是非必须的，大致理解概念即可。

最后就是设计分析，即根据前面的获取的信息，思考接下来的设计应该完成哪些工作，以及交付什么样的结果。用更直白的话说，就是足够了解自己的工作目标和任务。

因为产品需求不会清晰的写着设计师要完成多少个页面，画多少个图标，制作多少动效，如何和程序员协作等，所以我们要自己对 “确定要做” 的和 “可能会做” 的事情进行分析，才能确定工作量。

以上就是前期准备中要分析的内容，根据项目的大小会花费不同的精力和时间，但不会太多。它们远没有大家想象中复杂，准备做的越多，后续设计的效率也就越高，过稿率也会更高。

前面完成分析工作以后，下一步就可以展开设计相关的工作了。而正常设计流程绝不是打开Figma 创建第一个画布开始一次性画完所有内容就结束了，而是要分为不同阶段，逐步完成不同内容的设计。

我们可以简单分为下面几类设计对象：

首先是交互设计，交互是B端最重要的设计对象，决定产品界面的布局和操作方式。很多新人以为交互是产品经理完成的，但实际上他们制作的产品原型只包含了少量的交互信息或是完全没有。

所以设计师需要去填补交互信息，即产品怎么使用的规则。如果项目简单，比如我们这次设计的预定系统，因为操作和交互很少，是可以先把设计做完以后再考虑交互的问题。但如果项目很复杂，就肯定要提前通过原型的方式把交互先确定下来，再完成后续的界面视觉设计。

为什么要做交互设计，我们假设房间的退款流程非常复杂，要经过人工操作和审批还有检查等十几个流程才能完成退款，中间有非常多的操作。如果我们不先做交互直接做页面，很可能会因为各种错误、意见要重做，这会造成巨大的时间浪费。在项目中先完成交互的最大贡献就在提高效率，而不是增加额外的工作量。

确定了功能、布局、交互以后，完成界面就变得轻松了也容易理解，而主要的难点就是你想做出什么风格的界面，就是设计师自己发挥和探索的部分了。

对于小型项目来说，完成界面的设计基本就可以进入后续的交付工作了。但如果是规模较大的项目，就需要再设计过程中制定 ——

，来确保多人协作或未来迭代时设计的一致性和效率。

而B端项目设计规范主要包含三个部分内容，即 ——

。

布局规范是B端界面框架、全局组件、响应式规则、栅格参数的标准，这些内容决定了项目的整体布局和框架的一致性。

样式规范则是UI元素上使用的样式参数标准，比如色彩、字体、字号、圆角、投影等。在Figma中提供的Style样式功能，就是解决样式规范应用的重要工具之一。

组件库是将设计好的UI元素进行统一整理的地方，因为B端不同B端界面中有大量重复应用的设计元素，所以我们会这些元素进行汇总，存放到固定的位置方便后面复用，而不用每次都重新设计一遍。

Figma提供的Component，就是帮助我们将组件进行存储并复用的功能，通过它可以很快的完成对同一个组件的汇总、编辑、复用。

设计的最后一个部分，就是动效设计了。但在B端中，这部分的设计需求其实非常少，比如我们本次项目的界面就很简单，完全不需要画蛇添足去添加动效。只有在完成界面设计后确实需要制作动效演示的地方，设计师才会去制作相关的动效演示。

所有设计完成且通过团队的评审以后，那最后的工作，就是协助程序员交付你的设计了。而交付部分包含 ——

两个步骤。

标注切图就是提供项目的标注文件，让程序员可以看到设计的具体参数和说明，比如字号大小、间距、色号等等，他们需要根据这些信息完成对页面开发的参数设置。切图则是提供图标、图片、LOGO等无法用代码实现出来的视觉元素，它们需要将这些图形置入到前端项目文件内，才能在页面中正常显示。

标注和切图的实现方式有很多种，今天最主流的方法有两种，一种是直接使用 Figma的团队协作完成，另一种是上传蓝湖这类专属的标注、切图工具。

最后的设计走查，是前端工程师在完成前端页面开发以后，设计师去检查软件界面的 “还原度”。前端界面开发类似室内装修的施工，即使有详细的图纸最后的施工结果也可能想去甚远。

所以作为最熟悉设计稿的角色，设计师就需要去检查开发出来的结果存在哪些问题，并通过特定工具来提交这些错误并监督程序员完成对它们的修复，让前端实现的界面和设计稿尽可能一致。

在B端项目中，往往留给设计走查的时间很少，所以最终上线效果大多和设计稿的差距极大。而专业B端设计师就要依靠自己的经验，尽可能在整个项目的开展过程中避免两者的差距过大，这就是另一个话题了。

完成以上这些步骤以后，我们在本次项目的设计工作就基本结束，最终就是等待项目被开发完成并最终上线了。

讲完啦，我们下篇再贱~