最近准备开始学 B 端的零基础学员表示 ，对 B 端的速掌产品 、业务、握个完整设计毫无概念，端设每个方向找资料看似都能看懂 ，新手但没办法把它们串起来 ，教快计流缺乏整体的速掌、全面的握个完整认识 。
所以我今天要用一个简单的端设案例 ，来深入浅出的新手介绍 B 端的业务-产品-设计链条 ，让大家快速理解 B 端设计项目的教快计流全貌 。
一 、速掌从渡轮预定 ，握个完整认识业务概念
这次案例是端设一个我最近在预定的船票预定服务 ，由一家叫名门大洋的渡轮服务公司提供 。下面是对它预定的简单介绍：
步骤1 ：打开官网 ，到 [船上生活] 模块查看有哪些船（只有两艘）和房型 ，以及船上有哪些服务设施等。
步骤2 ：进入 [运费和费用] 模块 ，先看他们的预约规则 ，然后打开他们提供的 PDF 查看预定的日期和价格 ，来确定自己想要选的房间 。这里房型价格和热门时间有关 ，官方分了 A 、B 、C 三个价格档来对应热门冷门时间 。
步骤3：进入 [预定] 模块 ，填写个人信息和想预约的房型，房型选择有3个 ，如果前面的选择满房就向后递补 ，填写完成后 ，就可以点击发送预定信息 。
步骤4 ：隔日等待反馈邮件 ，到邮箱中查看 。还能预定的话就会有一个链接 ，进入链接中进行支付 。之后就可以获得登船的凭证 。
后续的细节就忽略 ，一个简单的买票环节 ，操作起来这么麻烦 ，是不是感觉非常陌生 ，这是因为国外有很多服务的预定都需要到官网预定，和国内出行完全依赖综合旅游软件如飞猪、携程、去哪儿等不同 。
而这个订票的流程 ，到审核（人工的）回复的整个过程 ，就叫 —— 业务流程 ，是一个被设计好并标准化的商业实践过程 。
每家公司的经营都会包含大量的业务 ，房间预订只是它的其中一个业务 ，还包括登船、房间清理 、物资采购等 。而每个常规的业务的执行如果全凭员工自己的想法、感觉，那么企业的运转一定会一团乱麻 。所以经营者就要针对这些常见的业务 ，设计出相应的流程出来进行标准化 ，让员工和顾客遵循这套流程来完成商业活动 。
而业务只有流程框架还不够 ，必须包含大量的细节 ，比如前面提到的不同定价时段 ，满房的递补 ，退票的方式等等 ，这些都是业务流程中的细节规则 ，我们可以统称它们为 “业务逻辑” 。
简单来说 ，企业经营要先确定业务 ，然后设计流程，再制定具体的业务逻辑 ，形成完整的商业闭环 。但这和设计师有什么关系呢？
因为业务是产品的出发点 ，常规项目只有业务形式确定下来 ，才会进入产品的设计阶段，而不是先设计产品功能再让业务去适配它的特性 。而产品后续一系列的复杂 、抽象 、晦涩的决策也全都和业务有非常大的联系 。
如果设计师不先理解业务，就可能无法理解产品的需求和决策 ，导致最终的设计结果和目标相去甚远 。
二 、从业务到需求的制定过程
这个预定过程对于熟悉国内互联网的我们来说肯定是太复杂了 ，用个线性流程表示的话 ，对比如下 ：
国内软件预定 ：打开软件 - 搜索船票 - 选择日期 - 选择房型 - 完成支付
官方网站预定 ：搜索官网 - 打开官网 - 查看房型 - 查看价格 - 填写信息 - 等待回复 - 查看邮件 - 完成支付
从字面上感觉可能不明显 ，但实际上操作时长、点击次数以及总消耗时间 ，它的做法远比国内的服务慢 ，加上细节里有很多会延长完成时间的逻辑 ，比如没有想要的房型就要重新去选一遍，而这在国内软件里一开始就能知道直接规避掉 。
这个业务过程非常的原始，后台可能有一个简单的收件系统 ，由人工来逐一审核提交的邮件 ，创建订单 ，然后再提交回复 。
如果我们要提高这个业务的效率，就必须要改进这套系统 ，将人工的机制进行简化 ，即客户可以直接在前端完成筛选 、预定、支付的操作 。相信大家都很熟悉这种操作过程 ，而这种改进就叫 —— 企业数字化升级 。就是本来使用人工或者很原始的方式执行的业务流程 ，引入数字化的系统 、产品 ，来提升它的运行效率 。
而产品经理要在这个过程做业务的分析 ，具体分析什么呢 ，可以简单总结成 ：
- 当前的业务是什么样的
- 当前业务存在的具体缺陷
- 构思产品的整体框架形态
- 确定产品的具体功能需求
前两点前面已经解释过了 ，当前业务是存在缺陷的 ，而产品经理必须先理解完业务和找出问题，才能进行后续工作 ，而不是直接忽视背景打开 Axure 开始画图 。
有了问题 ，下一步就是建立产品的框架 ，比如这个业务会涉及到多个端 ，产品就要先创建多个端的功能框架出来 ，包含的端可以简化成下面三个 ：
用户端就是普通的网页预定模式（这里不讨论APP和小程序等） ，让用户直接选择日期 、船型 、房型后支付获取凭证 ，非常容易理解，不用多做介绍 ，我们重点放在管理端和后台服务的解释上。
TIPS ：这里有个可以思考的小点 ，没做用户系统你们可以分析下为什么 。
在管理端上，管理员已经不需要手动审核预约了 ，所以只需要对订单和账单（这是两件事）有查看和管理的操作即可 ，来完成一些特殊业务事件的处理 。
而在后台服务上 ，就要确定有哪些数据信息 ，以及处理它们的方式 。比如订单的支付 、退款 ，会涉及到非常复杂的后台处理过程 ，包括不同支付方式接入 、对不同货币的支持 、资金的转出等等 。其它功能还包括房型数据更新 、价格数据更新 。这些都是用户端和管理端无法直接看见，但又在真实运行的功能 。
根据上面对不同端的分析和构想，就可以创建产品的 —— 功能架构图 ，比如下面这个极简的版本 ：
对于一个成熟的产品经理来说 ，进一步制定产品的需求肯定不是直接打开 Axure 画原型 ，而是先围绕业务的需求制定 —— 数据字段。
数据字段即前 、后端服务中要存储 、计算、展示的具体对象 。比如一个房间 ，前端页面会展示房间名 、价格、人数 、面积 、类型、评价等各种数据 。但这些数据不是凭空出现的 ，而是要先计划和开发才能实现的内容 ，且不同字段背后可能还包含复杂的设置或计算规则 。
所以产品要花很多时间分析应该记录哪些数据字段 ，这些数据怎么产生 ，背后有什么逻辑，在前端显示的标准是什么 。
用个更具体的案例来解释 ，比如要创建房间价格这个字段 ，这个字段的值就具体价格值 。但是房间的具体价格不是固定的 ，包含三个档位 ，根据日期决定的档位进行灵活的变动 。所以要实现正确的价格显示 ，光有一个房间价格字段是不够的 ，我们需要建立更多字段来满足它的使用 ，包含：
- 房间基础定价：房间的基底价格，用于做计算的基数
- 房价当前系数 ：根据忙时和闲时变更定价的系数 ，比如忙时是原来的1.5倍 ，闲时是原来的0.8倍
- 房间当前价格 ：根据定价基数x 系数得到的当前价格，是前端展示和付款的具体金额
这是个非常简化的版本，除了使用基数 x 系数的逻辑外 ，也可能直接给房间制定 A 、B 、C 三个价格的字段直接填价格不做系数计算 。在真实项目中 ，该功能会创建得字段数远不止这些 ，产品还需要去明白数据的来源、计算逻辑、应用规则 。
对于成熟的项目来说 ，项目的数据字段就是业务需求的延展 ，是整个业务正常运行的基石和原材料，产品制定的需求就包括它们的内容和规则 ，再让后端工程师去实现出来（而不是后端自己凭感觉想）。
有了上面这些准备 ，那么产品应该做成什么样就清晰很多了 。下一步 ，产品经理就可以先用思维导图去规划管理端的页面结构与内容 ，而这种思维导图通常被称为 —— 产品地图。
规划完产品地图后 ，下一步才进入正式的产品原型设计过程 ，将我们对产品应该做成什么样通过原型线框图表现出来 ，只要能让其他人理解我们的意图即可 。
当然只看图是不够的 ，很多细节的决策和逻辑就需要添加文字的说明 ，这种结合原型+文字的需求就交 PRD 需求文档。它的作用是让设计师 、程序员 、测试工程师可以看懂并把它们做出来的 “施工方案” 。
而作为 B 端 UI 设计师就要在了解业务和获得这些需求后 ，才能明白我们后面应该完成哪些工作 ，输出什么样的界面内容 。
结尾
下一篇 ，我们就会接着需求输出后 ，设计师如何完成工作来开展，讲解 B 端设计师具体工作和设计的相关流程 。如果有疑问或想知道的要点也可以再评论区中发出来 ，我会尽量在后续更新 。
作者 ：酸梅干超人
版权声明：全国天气预报查询_天气生活资讯 | 空气站k7z.cn ，转载请注明出处：https://www.k7z.cn/news/72c80299125.html
