第 2 章 读懂业务与信息系统
前奏里我下过一个断语:一个 ToB 设计师如果不懂业务,他就没有资格谈设计。这一章要回答的,正是"怎么才算懂"这个问题。
懂业务,不是知道几个行业黑话那么简单。我见过不少设计师,能熟练地说出"履约""核销""授信"这些词,但你一追问"核销具体是哪两笔数据在对、对不上会怎样、谁来对",他就答不上来了。这种"懂",是鹦鹉学舌式的懂,撑不起设计。
真正的懂,指的是你能像这个领域里的内行一样,理解业务的运转逻辑:它由哪些对象构成、这些对象之间是什么关系、信息怎么在系统里流动、不同的人在其中扮演什么角色、规则在哪里。这种理解,本质上是一种"建模"能力。而建模,恰恰是软件工程最核心的能力之一。所以这一章,我想请设计师们暂时戴上工程师的眼镜,学几样工程世界里打磨了几十年的利器。
一、先有全局观:信息系统的两大类
要读懂一个具体的系统,先得知道它在整个信息系统的版图里处于什么位置。这就像看地图,先得知道自己在哪个区域,再谈具体的街道。
按照所处理的对象,组织的信息系统可以分为两大类:作业信息系统和管理信息系统。这个分类朴素,却非常好用,因为它直接对应了两类完全不同的设计诉求。
作业信息系统,处理的是组织日常的、具体的业务操作。它又可以细分为三块。
一是业务处理系统。它的任务是迅速、及时、正确地处理大量事务性信息,比如产量统计、成本计算、库存记录、订单录入。这类系统的设计核心是"效率与准确":用户要在这里高频地录入、查询、修改大量数据,所以表格、表单、批量操作的设计质量,直接决定了一线人员的工作效率。它对体验的要求,是"快而不错"。第六章讲的那些中后台核心范式,主要就是为这类系统服务的。
二是过程控制系统。它用计算机去控制正在进行的生产过程,比如炼油厂通过传感器实时监测生产数据并自动调节。这类系统的设计核心是"实时与可控":信息要实时呈现、异常要醒目报警、关键控制要防误操作。它对体验的要求,是"看得清、控得住"。后面讲数据可视化和监控大屏时(第十一章),我们还会回到这类场景。
三是办公自动化系统。它用各种自动化设备支持人的办公活动,比如文字处理、电子邮件、流程审批。这类系统较少涉及复杂的管理模型,它对体验的要求,更接近通用软件:顺手、好上手。今天的协同办公工具(钉钉、飞书、企业微信这类),很大一部分就属于这一类。
管理信息系统,则是另一个层次的东西。它是对一个组织的信息进行全面管理的、人与计算机相结合的系统。它综合运用计算机技术、管理技术和决策技术,辅助管理人员进行管理和决策。如果说作业信息系统服务的是"把事情做对",那么管理信息系统服务的是"做对的事情":它把作业层产生的海量数据汇聚、加工成管理者能用来决策的信息。
这里有一句话值得每个 ToB 设计师记住:管理信息系统不只是一个技术系统,同时还是一个社会系统。它嵌在一个由人、权力、流程、文化构成的组织里。
这句话的设计含义极其深刻。它意味着,你设计一个管理信息系统,设计的从来不只是界面,还有它所固化的权责关系、它所改变的人的工作方式、它所触动的组织里的微妙平衡。
我举一个例子。某公司上一套新的项目管理系统,技术上无可挑剔。但它要求每个项目的进度必须实时录入、对所有人透明。结果遭到了中层管理者的集体软抵制,因为过去,进度信息是他们手里的一种"资源"和"缓冲",现在全透明了,他们的某种掌控感和回旋余地没了。系统不是因为难用而推不动,而是因为它无意中动了组织里的某种平衡。一个不懂"管理信息系统也是社会系统"的设计师,会百思不得其解:我做得这么好,为什么没人用?答案是:他只设计了技术系统,没看见背后的社会系统。
为什么要先讲这个分类?因为它给了你一个快速定位的框架。每接手一个项目,先问:这是作业系统还是管理系统?如果是作业系统,是业务处理、过程控制还是办公自动化?定位清楚了,你就大致知道这个系统的设计重心该往哪放、它的用户最在乎什么。这是"读懂业务"的第一步:先读懂这个系统的"类型基因"。
二、读懂业务的三个抓手:流程、角色、规则
定位完类型,接下来要钻进具体的业务里去。我的经验是,抓住三个东西,业务就读懂了大半:流程、角色、规则。
流程:业务的骨架
任何业务,本质上都是一连串有先后、有条件的活动。一笔订单从生成到履约,一个员工从入职到离职,一次报销从提交到打款,背后都是一条流程。
读懂业务,首先要把这条流程画出来:有哪些环节、每个环节谁来做、什么条件下流转到下一步、什么情况会回退、什么情况会分叉。当你能完整地画出一条业务的流程图,你对它的理解就上了一个台阶。
这里要特别提醒:真正的难点不在主干流程,而在异常分支。主干流程("一切顺利时怎么走")往往简单清晰,谁都画得出来。但真实业务里,大量的复杂性藏在异常分支里:审批被驳回怎么办?中途要撤回怎么办?某个环节的人离职了、不在岗了,任务卡住怎么办?数据填错了已经流转到下一环,怎么追回?这些"不顺利时怎么办"的分支,才是业务真正复杂的地方,也是设计最容易遗漏、上线后最容易爆雷的地方。
这里有一个自查方法:画完主干流程后,在每一个环节都追问三句话——"这一步如果失败了怎么办?""这一步如果要反悔怎么办?""这一步如果卡住了(人不在、超时)怎么办?"把这三句话问完,你的流程图才算完整。很多设计的 bug,根子就在这三句话没问够。
角色:业务的主语
流程的每个环节,都由某个角色驱动。前奏里讲过个体、群体、组织三层,落到具体业务里,就是一个个角色。同一条流程,不同环节由不同角色驱动,而每个角色看到的、能做的、关心的都不一样。
读懂业务,要把角色一个个识别出来,搞清楚他们各自的职责、权限和诉求。一个特别值得注意的点是:角色不等于职位。现实中,一个人可能身兼多角色(小公司里老板既是审批人又是采购人),一个角色也可能由多人共同承担(一个"复核员"角色由三个人轮班)。
设计要对的是"角色"这个逻辑概念,而不是某个具体的人或职位。为什么这点这么重要?因为如果你对着具体的人或职位设计,客户那边一个岗位调整、一次人员变动,你的设计逻辑就崩了。而如果你对着逻辑角色设计,无论谁来当这个角色、一个人兼几个角色,你的设计都站得住。这是设计稳定性的来源。
规则:业务的法律
业务之所以是"业务"而不是随意行为,因为它受一套规则约束:什么金额以上要二级审批、什么客户享受什么折扣、什么情况下库存要预警、什么交易要触发风控。
这些规则往往散落在制度文件里、在老员工的经验里、在"我们一直都这么干"的默契里。读懂业务,很大程度上就是把这些隐性的规则一条条挖出来、显性化。
规则是设计中最容易遗漏、也最容易出事的地方。你漏掉一条规则,界面上就会出现一个逻辑黑洞,等着在某个边界场景里崩给你看。而且,规则最难挖,因为它常常是"隐性"的。业务专家自己都未必能完整说出所有规则,很多规则是"遇到了才想起来"。所以挖规则要靠几招:看制度文档、问老员工"什么情况下会例外"、以及最有效的一招——拿着具体的边界案例去问("如果一个客户既是 VIP 又超了额度,听谁的?")。用具体案例去逼问,比泛泛地问"有哪些规则"要有效得多。
流程、角色、规则,三者交织成一张网:角色在流程的各个环节上行动,规则约束着流程的流转和角色的权限。把这三者及其关系理清,你手里就有了一张这个业务的"地图"。有了地图,才谈得上设计。
三、像工程师一样建模:领域驱动设计的启发
光有地图还不够。地图是平面的,而真实的业务是立体的、有内在结构的。要真正驾驭复杂业务,设计师需要一种更结构化的思维工具。这里,我要隆重介绍一个来自软件工程的方法论:领域驱动设计(Domain-Driven Design,简称 DDD)。
DDD 听起来是个很"技术"的词,很多设计师一看就想躲开。但请别急着关掉这一节。DDD 的内核,其实是关于"如何理解和组织复杂业务"的智慧,它对设计师的价值,丝毫不亚于对工程师。
DDD 最核心的主张是:软件的复杂度,主要来自业务领域本身的复杂度;要驾驭它,就必须深入理解这个领域,并让软件的结构忠实地反映领域的结构。这句话翻译给设计师听就是:界面的复杂,根子在业务的复杂;要把界面做简单,先得把业务想清楚,并让界面的结构对应上业务的结构。这跟我前面说的"界面是流程的投影"是一个意思。
DDD 里有两个概念,我认为每个 ToB 设计师都该掌握。
统一语言(Ubiquitous Language)
这是 DDD 给团队协作开的一剂良药。它的意思是:业务专家、产品、设计、研发,所有人在谈论这个业务时,必须使用同一套术语,而且这套术语要精确、无歧义,从讨论到文档到界面到代码,自始至终保持一致。
为什么这件事这么重要?因为 ToB 项目里大量的返工和扯皮,根源都是"同一个词,各说各话"。
我举一个真实的例子。业务、销售、财务三方在一个项目里反复用"客户"这个词,但谁也没发现,他们说的根本不是一回事:销售说的"客户"是"签了合同的",市场说的"客户"是"留过资料的线索",财务说的"客户"是"付过款的"。三方开了无数次会,每次都聊得很"顺畅",因为大家都在用"客户"这个词,以为达成了共识。直到开发到一半,做"客户列表"时才发现:到底该显示哪些人?三方吵翻了天。光是厘清这一个词,就让项目延期了两周。
对设计师来说,推动和维护"统一语言"是一项被严重低估的工作。你画的原型、你标注的字段名、你界面上的每一个文案,都是在为这套语言投票。一个好的 ToB 设计师,会有意识地去厘清业务术语、统一各方口径,甚至主动维护一份"术语表"(这也是为什么我在全书附录里专门放了一份术语表)。
怎么落地?一个实用的做法是:在项目早期,拉着各方一起,把核心业务术语列出来,逐个钉死它的精确定义,形成一份共享的术语表,并约定从此所有文档、界面、代码都以它为准。这份术语表,就是项目的"宪法"。当界面上的语言精确了、一致了,用户的认知成本就降下来了(这直接关系到第六章的"措辞一致"),团队的协作成本也降下来了。语言的秩序,是设计秩序的前提。
限界上下文(Bounded Context)
这个概念稍微抽象一点,但极其有用。它说的是:一个庞大的业务领域,应该被切分成若干个相对独立的"上下文",每个上下文内部有自己一致的模型和语言,上下文之间通过明确的接口交互。
还是用上面"客户"的例子。与其强行让全公司对"客户"达成一个统一定义(这往往做不到,因为不同部门的业务诉求本就不同),不如换个思路,承认:销售上下文里的"客户"、市场上下文里的"客户"、财务上下文里的"客户",本来就是三个不同的概念,各自在自己的上下文里自洽,在边界处做好映射(比如约定"市场的线索转化成销售的客户时,数据如何对应")就行。
这个思路一下子化解了"必须全公司统一"的死结。有些东西本来就不该强行统一,承认差异、管好边界,反而更清楚。
这对设计师切分产品模块,是直接的指导。当你面对一个庞大复杂的 ToB 系统,不知道该怎么拆分、怎么组织信息架构时,"限界上下文"给了你一把刀:沿着业务的自然边界去切。每个上下文,大致可以对应产品里的一个相对独立的模块或工作台,模块内部保持模型和语言的一致,模块之间定义清楚的衔接。
这样切出来的产品结构,既符合业务的本来面貌,也符合用户的心智,因为用户本来就是按角色、按业务域来理解自己的工作的。后面第五章讲信息架构、第九章讲复杂系统拆解时,你会看到"限界上下文"的思路反复出现。
我不是要把设计师变成 DDD 专家。DDD 还有很多更技术的部分(聚合、实体、值对象等),设计师不必深究。但"统一语言"和"限界上下文"这两个思想,是设计师驾驭复杂业务的利器。它们让你不再是被动地接受产品给你的需求文档,而是能主动地、结构化地去理解和组织业务,这正是从"画界面的"走向"懂业务的设计师"的关键一步。
四、一个完整实例:用工程的眼睛看一笔银行业务
讲了这么多框架,我们用一个例子把它们完整地串起来,感受一下"用工程师的眼睛读业务"是什么体验。
设想你接到一个需求:为某银行设计一套对公账户的管理系统。如果只用设计师的本能,你可能直接就开始想"首页放什么、菜单怎么排、表格长什么样"。但如果你戴上工程师的眼镜,你会先做几件事。
第一步,定位类型。这套系统里,柜员每天处理开户、转账、对账,这是典型的作业信息系统中的业务处理系统,设计重心是"快而不错";而行长要看的全行对公业务的汇总报表、风险概览,则属于管理信息系统,设计重心是"辅助决策"。一套产品里,两种基因并存,不能用一套设计逻辑套到底:给柜员的界面要追求录入效率,给行长的界面要追求决策清晰,它们是两种东西。光是看清这一点,你就避免了"用一套模板套所有页面"的常见错误。
第二步,抓三个抓手。画出"开户"的完整流程:资料录入、初审、风险评估、核准、激活。然后在每个环节追问那三句话:初审被驳回怎么回到录入?核准人不在岗,任务怎么转交?已激活的账户发现资料有误,怎么冻结更正?接着识别涉及的角色:客户经理(录入)、复核员(初审)、风控(评估)、主管(核准),注意这些是逻辑角色,小网点可能一人兼数职。最后挖关键规则:什么类型的企业需要额外尽调、什么金额的交易要触发反洗钱核查、什么情况下账户要被监控。用具体案例去逼问规则("一个刚成立三个月的贸易公司要开户并立刻大额转账,要走什么额外流程?")。
第三步,建模与切分。用"统一语言"把"账户""交易""对账"这些核心术语的精确含义和团队钉死,比如明确"账户"在"开户上下文"里指"正在申请中的账户实体",在"交易上下文"里指"已激活、可交易的账户",这两者状态含义不同,必须说清,否则前后端理解一错位就是大返工。用"限界上下文"把系统切成开户域、交易域、对账域、风险域几个相对独立的板块,每个板块有自己自洽的模型,板块之间定义清楚衔接(比如"开户域激活账户后,如何通知交易域")。
第四步,才是做信息架构、画界面。走完前三步,你再去做设计,你会发现一切都顺了,因为你的设计结构,忠实地长在业务结构之上。导航怎么分,对应着限界上下文;每个角色看到什么,对应着角色分析;每个状态下能做什么,对应着流程和规则。它不是你拍脑袋拼凑的,而是从业务本身生长出来的。
这样的设计,经得起业务方的追问("如果遇到 XX 情况呢?"你早就想过了),也经得起边界场景的考验(那些异常分支,你都画进去了)。这,就是"读懂业务"带来的底气。
对比一下不懂业务的做法:直接开始画界面,凭感觉排菜单、设字段。等业务方一追问异常情况就卡壳,等开发一问"这个状态下该显示什么"就答不上来,等上线后边界场景一出现就爆雷,然后陷入无穷无尽的返工。两种做法的差距,不在画图能力,而在前三步,在"读懂业务"上。
本章要点清单
- 先定位系统类型:作业系统(业务处理/过程控制/办公自动化)还是管理系统?重心不同。
- 记住"管理信息系统也是社会系统":设计会触动组织的权责与平衡,别只设计技术、看不见社会。
- 三抓手:流程(骨架,重点画异常分支,每环节追问"失败/反悔/卡住怎么办")、角色(主语,对逻辑角色而非具体人/职位设计)、规则(法律,用具体边界案例去逼问)。
- DDD 两件利器:统一语言(早期钉死核心术语、维护术语表,防"各说各话")、限界上下文(沿业务自然边界切模块)。
- 设计流程:定位类型 → 抓三抓手 → 建模与切分 → 才画界面。让设计结构长在业务结构上。
小结
这一章,我们请设计师戴上了工程师的眼镜。我们先用"作业系统/管理系统"的分类建立全局观,并提醒了"管理信息系统也是社会系统"这个易被忽视的设计含义;再用"流程、角色、规则"三个抓手钻进具体业务,特别强调了异常分支、逻辑角色、用案例逼问规则;最后借 DDD 的"统一语言"和"限界上下文",学会结构化地理解和组织复杂业务,并用一个完整的银行案例,演示了从读业务到画界面的全过程。
读懂业务和信息系统,解决的是"设计的对象是什么"。但还有一个同等重要的问题没解决:这些系统是给人用的,而人的需求,远比业务文档上写的要复杂、要隐蔽。下一章,我们就从业务转向人,去谈 ToB 场景下的用户研究,如何用"角色—场景—任务"的方法,挖出用户真正的、甚至他们自己都没说出口的需求。