第 1 章 ToB 产品设计的本质
前奏里我们把视角调对了:ToB 设计的对象是组织,要在多层主体和多方诉求之间找平衡。但"找平衡"太抽象了。平衡向哪里找?判断的依据是什么?这一章我们要给出那个依据:ToB 产品设计的本质,以及由它推导出来的设计目标。
我先抛出这一章的核心判断,然后再慢慢论证它。
ToB 产品设计的本质,是用尽可能低的认知成本和操作成本,让组织的业务确定、可靠、高效地运转。它的三个关键词是:效率、确定性、可靠性。
注意这里没有"愉悦""惊喜""好看"这些词。不是它们不重要,而是它们在 ToB 里是手段,不是目的。目的永远是让业务跑得更好。把这个搞混,是很多 ToB 设计走偏的根源,也是我下面要反复用案例敲打的一点。
一、先厘清:ToB 产品到底是什么
在谈本质之前,我们得先有个清晰的定义。"ToB 产品"这个词被用得太随意了,有必要先把它框出来。
ToB 产品,是为组织(而非个人)解决某类业务问题、并嵌入其工作流程的软件系统。
这个定义里有三个要点,每一个都决定了它的设计气质。
"为组织",意味着它的价值要在组织层面兑现:提升效率、降低成本、控制风险、辅助决策。一个 ToB 产品好不好,最终不是看单个用户爽不爽,而是看它有没有让这个组织运转得更好。这是判断一切设计决策的最终标尺。
"解决某类业务问题",意味着它是高度场景化、专业化的。一个 CRM 解决的是销售管理问题,一个 WMS 解决的是仓储管理问题,一个 HRM 解决的是人力资源问题。它们各自扎根在一个具体的业务领域里,脱离了那个领域,设计就无从谈起。这也是为什么前奏里我反复强调"理解业务"。
"嵌入工作流程",意味着它不是一个孤立的、用完就走的工具,而是用户日常工作的一部分,甚至是必经环节。员工不是"想用才用",而是"必须用"。
这种嵌入性,带来一个极其重要、却常被忽视的设计含义,我称之为"高频与规模的放大效应":你的设计哪怕只优化了一点点,因为它每天被高频使用、被很多人使用,累积起来的价值是巨大的;反过来,一个小小的设计缺陷,也会被高频和规模放大成巨大的损耗。
举个例子。你在一个高频录入表单里,把某个字段的默认值设对了,让用户每次少选一次,单次只省两秒。但如果这个表单一天被填一千次,一年就是七十多万秒,合两百小时。一个"两秒"的优化,一年省下两百小时。反过来,如果你在这里多设了一个没必要的必填项,同样的规模,就是凭空给组织增加两百小时的负担。在 ToB,没有"小"设计,每一个细节都被高频和规模放大着。这个意识,是 ToB 设计师区别于随手画图的人的重要标志。
把这个定义和我们熟悉的 ToC 产品对照,差异就很清楚了。ToC 产品多数是"为个人、满足某种需求或欲望、可选择地使用"。两边几乎每个要点都是相反的。这再次印证了前奏的判断:ToB 不是 ToC 的一个变种,而是另一套游戏。
二、三个关键词:效率、确定性、可靠性
现在回到本质。我说 ToB 设计的本质落在效率、确定性、可靠性三个词上。我们一个一个来看,看它们各自意味着什么,以及它们如何指导具体的设计判断。
效率:让用户用最少的成本完成任务
效率是 ToB 设计最直观、也最核心的目标。但"效率"这个词常被理解得太窄,以为就是"点击次数少"。其实它至少包含三个层面,从浅到深,恰好对应了一个设计师能力的成长。
操作效率,是完成单次任务所需的动作成本:点击、输入、跳转、等待。这是最表层的效率。优化它的手段很多:减少不必要的步骤、把高频操作放在顺手的位置、支持批量处理、提供快捷键、让常用值有合理的默认。新手设计师,优化的是这一层。
认知效率,是用户理解界面、做出判断所需的脑力成本。这一层比操作效率更深,也更容易被忽视。一个界面可能点击次数很少,但如果用户每次都要停下来想"这个按钮是干嘛的""这个状态是什么意思""我现在该点哪",它的认知成本就很高,整体效率反而低。
我举一个真实的对比。某审批系统,改版前后点击次数几乎没变,但改版前用户平均要在每个审批上停留 40 秒,改版后降到 15 秒。差别在哪?改版前,界面把申请信息、历史记录、相关附件平铺成一大片,用户要自己在里面找"我做这个决定需要看什么";改版后,设计师把"审批这个决定真正需要的三项关键信息"提炼出来、置顶突出,其余的收起。点击没少,但用户"想"的时间大幅缩短了。这就是认知效率。省点击,不如省思考。熟手设计师,优化的是这一层。
流程效率,是完成一个跨越多步、甚至多人的完整业务所需的总成本。这一层最贴近组织效能。有时候单个界面都设计得很好,但整个流程衔接不畅,这个环节的输出对不上下个环节的输入,信息要在人和人之间反复传递和确认,整体效率依然很低。ToB 设计师必须有"流程视角",而不只是"页面视角"。高手设计师,优化的是这一层。
这三层效率,是检验你设计成熟度的一把尺子。下次做设计时,不妨自问:我优化的是哪一层?能不能再往深走一层?
确定性:让用户随时知道自己在哪、发生了什么
确定性,是 ToB 设计里一个被严重低估的关键词。
什么叫确定性?就是用户在使用系统的任何时刻,都清楚地知道:我现在处于什么状态、我刚才的操作成功了没有、接下来会发生什么、如果出了问题该怎么办。一个有确定性的系统,会让用户感到"一切尽在掌握";一个缺乏确定性的系统,会让用户处于持续的焦虑:"我刚才那下到底点没点上?""这个单子提交了吗?""为什么没反应,是卡了还是我没操作对?"
ToB 场景对确定性的要求,远高于 ToC,因为前奏里说过,ToB 是低容错的。在一个可能涉及真金白银、涉及合规、涉及安全的系统里,"我不确定刚才发生了什么"是一种危险的状态。它会逼着用户去做额外的确认动作(反复刷新、重复提交、打电话问别人),这些都是效率的损耗,严重时还会酿成事故,比如因为没看到"提交成功"的提示,用户又提交了一遍,结果一笔款付了两次。
确定性体现在很多具体的设计上:及时、明确的操作反馈;清晰的状态表达(一个订单现在到底走到哪一步,要让人一眼看懂,而不是甩一串像"S-3"这样的状态码);可预期的系统行为(同样的操作,每次的结果应该是一致的);以及对"正在发生什么"的诚实告知(在加载、在处理、出错了,都要说清楚)。
我常跟团队说,做 ToB,你要把用户想象成一个在陌生城市开车的人。他最需要的不是漂亮的路标,而是确定的路标:每一个路口都清楚地告诉他"你在这里,该往哪走"。设计师的工作,就是不断地消除用户的不确定感。
可靠性:让系统值得托付
第三个词是可靠性。如果说效率关乎"快"、确定性关乎"明",那么可靠性关乎"稳":这套系统值不值得用户把自己的关键业务托付给它。
可靠性首先是个技术指标:系统稳不稳定、会不会崩、数据会不会丢、性能扛不扛得住。这些主要是工程的责任,但设计师不能置身事外,因为可靠性最终是被用户"感知"到的,而感知很大程度上由设计决定。
举个例子。同样是后台在处理一个耗时的任务,A 系统什么都不显示,界面就那么干等着,用户不知道是死了还是在转;B 系统清楚地告诉用户"正在处理,预计需要 30 秒",并且给一个进度条,完成后明确通知。两个系统的技术可靠性可能完全一样,但用户感知到的可靠性天差地别:A 让人焦虑、怀疑、忍不住乱点,B 让人安心。设计在这里做的,是把后台真实的、可靠的运转,如实、安心地传达给用户。
可靠性还体现在系统对异常的处理上。一个可靠的系统,不是"永不出错"的系统(那不存在),而是"出错了也能体面应对"的系统:它能预防可预防的错误,能在错误发生时给出清楚的解释和补救的路径,能让用户即使犯了错也不至于陷入绝境。这就引出了前奏里提过、后面第六章会专门展开的"防错"与"可恢复"。它们既是效率问题,也是确定性问题,归根结底是可靠性问题,决定了用户敢不敢把重要的事交给这个系统。
三个词的关系是这样的:它们不是并列的三件事,而是层层支撑。可靠性是地基(系统得立得住、信得过),确定性是骨架(用户得看得清、有掌控),效率是目标(在前两者的基础上,让任务又快又顺地完成)。一个 ToB 产品,只有这三者都立住了,才谈得上好。如果你只追求效率而牺牲了确定性(为了少一步把关键反馈也省了),或者只追求可靠而牺牲了效率(为了"稳"处处设卡),都是没有理解三者的关系。
三、ToB 设计的目标与价值:回到组织效能
把三个关键词落到组织层面,ToB 设计的终极价值,可以归结为一句话:提升组织效能。
组织效能是个总账。效率高了,同样的人能干更多的事,或者干同样的事花更少的时间和人力,这是省下来的成本。确定性强了,出错少了、返工少了、扯皮少了,这是减少的损耗。可靠性好了,业务连续、风险可控、数据可信,这是规避的风险和增强的决策能力。这几笔账加起来,就是 ToB 设计为组织创造的真实价值。
这里我想特别强调一个常被误解的点,它是这一章最想敲打的:ToB 设计的价值,不在"美"本身,而在"美"所带来的效能。
这不是说美不重要。后面第七章我会专门讲 ToB 的视觉与美学。但 ToB 的美,必须是有用的美,它通过降低认知负担、提升专业感、增强用户信任,最终服务于效能。一个为了好看而牺牲了信息密度、牺牲了操作效率的"美",在 ToB 里是负资产。
我评审过一个数据分析后台的改版方案。设计师做得很"漂亮":大量留白、超大字号、卡片之间间距舒展、配色清新。从 ToC 审美看,赏心悦目。但问题是,这是一个给分析师每天盯着看几小时、需要同时对比大量数据的工具。改版后,原来一屏能看 30 行数据,现在只能看 8 行,分析师要不停地滚动、翻页,才能看完原来一眼就能扫过的数据。他们集体反对这个"好看"的改版。设计师很委屈:"我做得明明更美了。"问题就出在这里,他用错了"美"的标准。在这个场景,信息密度本身就是价值(第七章会细讲),牺牲密度换来的"舒展",是负资产。
我见过太多设计师在 ToB 项目里栽在这一点上。他们带着 ToC 养成的审美惯性,把界面做得很"精致",却让业务用户每天多花几倍的时间去完成同样的工作。业务方不买账,不是因为他们不懂审美,而是因为这种审美错配了场景。
理解了这一点,你才能真正理解"理性之美"这个书名的分量。在 ToB,真正的美,是效能的美,是秩序的美,是"这么复杂的业务居然被梳理得这么清楚"的那种美。它不喧哗,却经得起每天成千上万次的使用。
四、挑战与机遇:为什么是现在
最后,我们来谈谈 ToB 设计当下所处的位置:它面临的挑战,以及它正在迎来的机遇。把这一节放在第一章的末尾,是想让你对自己所做的事,有一个时代坐标上的认识。
挑战这一面,前奏里已经点过几个:业务复杂、话语权弱、价值难度量。这里再补两个更具体的。
一个是遗留系统的重负。很多 ToB 设计师面对的不是一张白纸,而是一个用了十几年、盘根错节、谁也不敢动的老系统。你想优化,却处处受制于历史包袱:数据结构动不了、流程改不了、用户的肌肉记忆也改不了,你一改,用了十年的老员工就炸锅。如何在约束中做出改善,是 ToB 设计区别于"从零做一个新 App"的现实难处。这需要的不只是设计能力,还有迁移、过渡、向后兼容的智慧。
另一个是个性化与标准化的拉扯。每个客户都觉得自己的业务是独特的,都想要定制;但过度定制会让产品变得无法维护、无法规模化,每个客户一套代码,最后谁也维护不动。如何在"满足个性"和"保持标准"之间划线,是 ToB 产品长期的张力,设计师身处其中,常常要在"再加一个配置项"和"守住产品的简洁"之间做艰难的取舍。
而机遇这一面,我认为我们正站在一个少见的好时候。
第一个机遇,是用户期待的觉醒。Slack、Notion、Figma 这些消费级体验的工具进入了工作场景,把企业用户的胃口养刁了。他们开始无法忍受那些笨重的老系统,开始要求工作软件也能像这些工具一样好用。这种"体验觉醒",正是 ToB 设计价值被重新看见的契机。十年前你跟老板说要重视体验,他可能觉得是浪费钱;今天,越来越多的组织意识到,糟糕的体验本身就是巨大的隐性成本(回想序章那笔"将就的代价"的账)。
第二个机遇,是数智化转型的深入。企业对信息系统的依赖前所未有地深,数字化转型从"要不要做"变成了"怎么做好"。这意味着大量的系统要被重建、被升级,而这一次,体验和设计被摆到了比以往更重要的位置。市场需要好的 ToB 设计师,这个需求是真实而旺盛的。
第三个机遇,也是最大的一个,是 AI 带来的范式重构。这一点我想多说两句,因为它会深刻地改变 ToB 设计这门手艺,这本书也专门用了一章(第十二章)来谈它。
AI,尤其是大模型和智能体,正在把 ToB 软件从"人来操作系统"推向"人和智能体协作完成工作"。过去,设计师设计的是"功能":用户点这个按钮,系统做这件事。未来,设计师越来越多地要设计"智能体":用户表达一个意图,智能体自主地拆解、决策、执行,人在关键节点介入和把关。这是一次设计范式的根本转变,它带来的问题是全新的:如何让用户信任一个自主行动的智能体?如何在"让 AI 替你干"和"让用户保持掌控"之间拿捏?如何表达 AI 的不确定性?这些问题没有现成答案,这正是这一代 ToB 设计师的机遇:你们将定义这套新范式的设计语言。
同时,AI 也在重塑设计师自身。当生成一个界面、套用一个模式变得越来越廉价,设计师的价值会进一步向上游迁移,迁移到那些 AI 替代不了的地方:对业务的深刻理解、对复杂权衡的判断、对人的真实处境的体察。前奏里我说,理解业务是 ToB 设计师在 AI 时代最该握紧的护城河,这里我再强调一遍。会被 AI 取代的,是把设计当"画图"的人;不会被取代的,是把设计当"解决组织问题"的人。
挑战与机遇并存,而且都很大。这恰恰说明,ToB 设计是一件值得认真对待、值得投入一生去磨练的事。它不是一个夕阳行当,而是一个正在被重新定义、充满可能性的领域。
本章要点清单
- ToB 产品 = 为组织、解决业务问题、嵌入工作流程的系统。
- 牢记"高频 × 规模"的放大效应:在 ToB 没有小设计,每个细节都被放大。
- 三个关键词,层层支撑:可靠性(地基)→ 确定性(骨架)→ 效率(目标)。
- 效率有三层,对应能力成长:操作效率(新手)→ 认知效率(熟手)→ 流程效率(高手)。"省点击不如省思考"。
- ToB 的价值在组织效能,不在"美"本身;美必须是"有用的美",牺牲密度/效率换来的好看是负资产。
- 当下挑战:遗留系统、个性化与标准化的拉扯;机遇:体验觉醒、数智化、AI 范式重构。
小结
这一章,我们确立了全书的判断基准:ToB 产品设计的本质,是让组织的业务确定、可靠、高效地运转,三个关键词是效率、确定性、可靠性,终极价值是提升组织效能。我们也看清了 ToB 设计当下的处境,挑战不小,但机遇更大,尤其是 AI 带来的范式重构,正把这个领域推向一个全新的阶段。
本质讲清楚了,但要真正做好 ToB 设计,光有本质的认识还不够。你还得能读懂那个具体的业务、那套具体的信息系统。下一章,我们就从"设计师如何像工程师一样理解业务与信息系统"开始,往"道"的更深处走。