第 4 章 需求分析与设计建模
欢迎来到第二篇"建造"。
如果说第一篇"理解"是在打地基,搞清楚 ToB 是什么、业务怎么运转、用户要什么,那么从这一章开始的第二篇,就是在地基上把房子盖起来。这是全书最厚重的一篇,也是一个设计师赖以安身立命的核心手艺所在。
盖房子的第一步,不是砌墙,而是把图纸画准。对应到设计里,就是这一章要讲的两件事:需求分析(把要解决的问题想清楚、排好序)和设计建模(把模糊的需求,转化成精确的结构)。这两件事,都发生在你打开 Figma 画第一个像素之前。它们是"隐形的设计",做得好不好,外人看不见,但它们决定了后面所有可见设计的成败。我甚至认为,一个 ToB 设计师真正的功力差距,大半就拉开在这两件看不见的事上。
一、需求不是用来"满足"的,是用来"分析"的
很多设计师对需求的态度是被动的:产品给一份需求文档,我照着做。这种态度,从一开始就把自己放在了"执行者"而非"设计者"的位置。它的结果,往往是产品要什么你做什么,做出来不对再改,改了还不对再改,你成了一台没有判断的画图机器。
一个成熟的 ToB 设计师,对需求的态度是分析性的。需求来了,他不会马上想"这个界面怎么画",而是先问一连串问题:这个需求要解决的真实问题是什么(回到第三章,穿透表层诉求)?它服务于哪个角色、哪个场景、哪个任务?它和现有的功能是什么关系,是补充,还是冲突,还是重复?它的优先级有多高,不做会怎样?它会给其他用户、其他场景带来什么副作用?
这种分析,在 ToB 里尤其重要,因为 ToB 的需求来源特别杂、特别多。客户提的、销售带回来的、业务方拍的、老板临时想到的、竞品有我们也得有的。如果照单全收,产品很快会膨胀成一个谁也用不明白的怪物。
需求分析的第一要务,就是节制:分清楚什么该做、什么不该做、什么该现在做、什么可以以后做。
"不做什么",常常比"做什么"更能体现一个设计师的判断力。每多加一个功能,都是在给系统增加复杂度,都是在给所有用户的认知负担上加码(第五章会从认知负荷的角度论证这一点)。ToB 设计师要有一种"为简洁而战"的自觉,替用户挡掉那些看似有用、实则只会让系统更臃肿的需求。
我讲一个真实的拉锯。某产品,一个大客户强烈要求加一个很定制化的功能。销售为了签单,极力主张做。但我们分析后发现:这个功能只对这一个客户、且只在一种很边缘的场景下有用,而它一旦加进通用产品,会让所有其他客户的某个核心流程多出一个让人困惑的选项。这就是典型的"满足个性 vs 保持标准"的拉扯(第一章提过)。最后的处理是:不把它做进通用产品,而是用配置开关的方式,只对这个客户开启,默认对所有人隐藏。既满足了个性,又守住了标准。这个判断的前提,正是认真的需求分析,如果照单全收,通用产品就被一个边缘需求污染了。
当然,挡需求需要底气,而底气来自分析:你得能说清楚为什么不做、不做的代价是什么、有没有更好的替代方案,而不是凭感觉拒绝。一个能讲清楚"为什么不做"的设计师,远比一个只会"接需求做需求"的设计师有分量。
二、需求优先级:把主观争论变成结构化判断
需求多了,就要排序。而排序,是 ToB 项目里最容易吵架的环节,每个人都觉得自己提的需求最重要:销售觉得签单的最重要,客服觉得投诉多的最重要,老板觉得他想到的最重要。要让排序不沦为"谁嗓门大谁优先""谁官大听谁的",得靠框架,把主观的争论转化成相对客观的、可讨论的结构。介绍两个我常用的。
Kano 模型:理解需求的"性质"
Kano 模型把需求分成几类。基本型需求,是用户认为理所当然该有的,有了不会加分,没有却会让人无法接受,比如报销系统能保存草稿、能查到自己单子的状态。这类需求是"不做就出局"的底线。期望型需求,是越多越好、与满意度成正比的,做得越好,用户越满意,比如审批速度、批量操作的便利、查询的精准。这是投入产出的主战场。兴奋型需求,是用户没预期到、一旦有了会带来惊喜的,它能制造差异化和口碑,比如系统自动识别并填好发票信息、自动提醒你"这笔报销可能超标"。
这个分类的价值在于,它告诉你不同需求该用不同的策略对待:基本型需求必须无条件满足,否则产品根本立不住;期望型需求是投入产出的主战场,做得越好回报越直接;兴奋型需求是锦上添花、塑造差异化的机会,但不能本末倒置。
一个常见的错误,就是本末倒置:基本型还没做好(草稿都不能存、状态都查不到),就急着去做那些炫酷的兴奋型功能(AI 智能推荐之类)。结果是,基础体验稀烂,花哨功能再多也救不回来,用户连最基本的事都做不顺,谁还在乎你那点惊喜。Kano 模型提醒你:先把基本型和期望型做扎实,再谈兴奋型。
RICE 框架:计算需求的"分量"
RICE 是四个因素的缩写:Reach(影响范围,这个需求能惠及多少用户、多少次使用)、Impact(影响程度,对每个用户的价值有多大)、Confidence(信心,你对前面判断的把握有多大)、Effort(成本,实现它要花多少力气)。把前三者相乘再除以成本,得到一个分数,用分数来给需求排序。
RICE 的好处,不在于那个分数有多精确(它本来就是粗略的估算),而在于它把"为什么这个比那个优先"的讨论,拉到了几个明确的维度上。当大家争执不下时,你可以问:它的影响范围有多大?对用户的价值有多深?我们有多大把握?成本有多高?把争论锚定在这几个问题上,讨论就从"我觉得"变成了"我们一起来估",理性多了。
这里要提醒:这些框架是辅助判断的工具,不是替代判断的公式。别迷信那个算出来的分数,更别为了凑一个好看的分数去硬填参数(这是很容易掉进去的陷阱,为了让自己想做的需求排前面,把它的 Impact 填高一点)。框架的真正价值,是提供一个共同的、结构化的讨论语言,让排序这件事从拍脑袋走向讲道理。这本身,就是"理性之美"在需求环节的体现。
三、设计建模:被设计师忽视的核心能力
需求分析和排序完成后,到了这一章的重头戏,也是我最想让你重视的部分:建模。
我必须坦率地说,"建模"是当下很多 ToB 设计师能力版图上最大的一块空白。大家熟练于画界面、做交互、调视觉,却很少有人认真训练过"把模糊的需求转化成精确结构"的能力。但恰恰是这块能力,把"懂业务的设计师"和"画界面的设计师"分了开来。
什么是设计建模?它指的是,在动手画界面之前,先用结构化的方式,把需求背后的信息、流程、状态,精确地表达出来。这跟上一章 DDD 讲的"让设计结构忠实反映业务结构"是一脉相承的。建模,就是建立这种结构的具体动作。至少有三种模型,是 ToB 设计师该掌握的。
信息模型:把"有哪些东西、它们什么关系"想清楚
任何业务系统,本质上都在管理一组信息对象及其关系。订单、客户、商品、库存,这些是对象;一个订单属于一个客户、包含多个商品、扣减相应库存,这些是关系。信息模型(工程上叫数据模型、实体关系模型),就是把这些对象和关系画出来。
为什么设计师要关心这个?因为界面是信息模型的呈现。你界面上的每一个列表、每一个详情页、每一个字段,背后都对应着信息模型里的某个对象或关系。
如果你脑子里没有清晰的信息模型,你画出来的界面就会逻辑混乱:这个页面该显示什么、字段之间什么关系、点进去能看到什么,全凭感觉。我见过一种典型的混乱:设计师把本属于"客户"的信息和本属于"订单"的信息混在一个页面里平铺,因为他没想清楚这两个对象的边界,结果用户看着一头雾水,开发实现起来也别扭。
反过来,当你心里有一张清晰的信息模型图,界面的结构就有了坚实的依据:客户是一个对象,有它的详情页;订单是另一个对象,有它的列表和详情;它们之间的"归属"关系,体现为"从客户能看到他的订单"。我强烈建议每个 ToB 设计师,在做一个新模块前,先和研发一起把核心的信息模型画出来。这半小时的投入,能省掉后面无数次的返工,还能让你和研发对"我们到底在做什么"达成精确的共识。
流程模型:把"事情怎么一步步发生"想清楚
这接续第二章讲的"流程是业务的骨架"。流程模型,就是把一个业务从开始到结束的步骤、分支、条件,用流程图的方式表达出来。它回答的是"事情按什么顺序、在什么条件下发生"。
ToB 设计离不开流程模型,因为 ToB 的核心价值就是支撑业务流程。一个审批流、一个履约流、一个工单处理流,你只有先把流程的每一步、每一个分叉、每一种异常都画清楚了,才能设计出不漏态、不卡壳的界面。
重申第二章的提醒:最容易出事的是异常分支和回退路径。很多设计的 bug,比如"这个状态下用户该怎么操作没人考虑过""驳回之后回到哪一步没人定义",根子都是流程模型没画全。画流程时,务必把"失败怎么办、反悔怎么办、卡住怎么办"这三句话在每个环节都问一遍。
状态模型:把"一个东西有哪些状态、怎么转换"想清楚
这是三种模型里最容易被设计师忽视、却极其关键的一种。
在 ToB 系统里,几乎每个核心对象都有"状态":订单有待付款、已付款、已发货、已完成、已取消;工单有待处理、处理中、已挂起、已解决、已关闭。这些状态之间的转换是有规则的:从哪个状态能到哪个状态、什么操作触发转换、什么条件下允许、什么时候不允许。
把这些用"状态机"画出来,是 ToB 设计的一项基本功。状态机会逼着你回答那些容易被遗漏的问题:这个状态下,用户能做哪些操作(直接关系到第六章的"防错",不该做的操作就该禁用)?这个转换,谁有权限触发(关系到第十三章的权限)?这条回退路径,存在吗,从"已发货"能不能退回"待发货",什么条件下能?
一个画全了的状态机,能帮你堵住界面上几乎所有的逻辑漏洞。我见过太多上线后才发现的问题,"咦,这个已取消的订单怎么还能点发货""这个已完成的工单怎么还能被重新分配",本质都是状态机没画清楚。花点时间把核心对象的状态机画出来,是 ToB 设计师最值得养成的习惯之一,也是和研发对齐逻辑、避免扯皮的利器,因为状态机是设计和开发都看得懂的共同语言。
这三种模型,从三个不同的角度,把一个业务的结构精确地刻画了出来:信息模型刻画"静态的结构"(有什么),流程模型刻画"动态的过程"(怎么走),状态模型刻画"对象的生命周期"(怎么变)。三者结合,你对要设计的东西就有了立体、精确的把握。在这个基础上画界面,你画的就不是凭空的图形,而是有结构支撑的、经得起推敲的设计。
四、从模型到原型:让设计可被验证
建好了模型,才轮到画原型。注意这个顺序:模型在前,原型在后。原型是模型的可视化表达,而不是凭空的创作。
原型的核心价值,是"让设计可以被验证"。在投入昂贵的开发之前,用低成本的原型把设计方案表达出来,拿给用户、业务方、研发去看、去用、去挑刺,尽早发现问题。这是设计科学性的一个重要体现:不靠"我觉得这样好",而靠"我们验证过这样行"。
ToB 原型有几个值得注意的实操点。
保真度要匹配验证目的。不是所有验证都需要高保真原型。如果你要验证的是流程是否走得通、信息架构是否合理,低保真的线框图甚至纸面草图就够了,而且更快、更便于修改。只有当你要验证视觉、要验证细腻的交互、要做正式的可用性测试时,才需要高保真。别一上来就抠高保真的细节,那既慢,又容易让评审者纠结于颜色字体而忽略了更重要的结构问题。我吃过这个亏:早期拿一个精致的高保真稿去评审流程,结果一屋子人全在讨论"这个蓝色好不好看",没人关心流程对不对,真正重要的问题被漂亮的外壳盖住了。
用真实的数据和场景。ToB 原型最忌讳用"张三李四""测试数据 123"这种假数据。ToB 的复杂性,很多时候恰恰藏在真实数据里:一个超长的客户名称(会不会撑破布局)、一个有几十条明细的订单(列表会不会太长)、一个状态异常的记录(界面怎么显示)、一个金额为零或为负的特殊情况。如果你的原型只用规整的假数据,你会漏掉这些真实的边界情况,而它们往往是设计最容易崩的地方。尽量用接近真实的、甚至故意取最极端的数据去填充原型,你的验证才靠谱。
让原型成为沟通的媒介。在 ToB 项目里,原型有一个常被低估的作用:它是设计师和业务方、研发对齐认知的最佳媒介。一份文字需求,十个人能读出十种理解;但一个原型摆在面前,大家的讨论立刻就具体了、聚焦了。很多隐藏的分歧和遗漏的需求,是在围着原型讨论时才暴露出来的("哦,你说的提交是这个意思啊,那不对")。所以,别把原型只当成"设计稿",把它当成一个促进对齐的工具,尽早拿出来、反复地用它去对齐。早暴露问题,永远比晚暴露便宜。
本章要点清单
- 对需求要分析,不要照单全收;"不做什么"比"做什么"更见判断力;挡需求要能讲清代价与替代方案。
- 个性 vs 标准的拉扯:边缘定制用"配置开关只对特定客户开启",别污染通用产品。
- Kano:先做扎实基本型、期望型,再谈兴奋型;别本末倒置。
- RICE:用(范围×程度×信心)÷成本 锚定讨论;是讨论语言,不是替代判断的公式,别为凑分硬填参数。
- 建模是被忽视的核心能力,区分"懂业务"与"画界面"的设计师:信息模型(有什么)、流程模型(怎么走)、状态模型(怎么变,用状态机堵逻辑漏洞)。
- 原型:模型在前、原型在后;保真度匹配验证目的;用真实/极端数据;把原型当对齐媒介,早暴露问题。
小结
这一章,我们走完了从需求到原型的科学路径。我们先确立了对需求的分析性态度,节制,分清该做不该做;再用 Kano 和 RICE 把优先级排序从主观争论变成结构化判断;接着重点讲了设计建模这项被忽视的核心能力,用信息模型、流程模型、状态模型把模糊需求转化成精确结构;最后讲了如何从模型走向可被验证的原型。这一整套,就是把第一篇的"理解"转化为扎实设计的科学方法。它发生在画像素之前,却决定了像素的成败。
但需求理清了、模型建好了,真正的挑战才刚开始:ToB 系统天然复杂,如何组织这么多的信息和功能,让用户不被淹没?下一章,我们进入第二篇的第一个旗舰章,信息架构与复杂度治理,去学习如何驾驭复杂,而不被复杂驾驭。