前奏 · 重识 ToB
在过去十几年里,我一直在做企业服务相关的工作。从最早画一个个孤立的页面,到后来负责整条产品线的体验,再到带着团队去啃那些没人愿意碰的硬骨头。越往后走,我越发现一件事:我们这个行业,对"ToB"这两个字的理解,普遍是浅的。
很多人以为,ToB 就是"给企业做的软件",跟 ToC"给个人做的软件"相对。这个理解不能算错,但它停留在表面。它解释不了一些最基本的困惑:为什么同样是一个"审批"功能,在企业里能复杂到让人头疼,而在个人 App 里点一下就完了?为什么 ToB 的设计师常常觉得,自己学的那套用户体验方法,一到企业场景就处处碰壁?为什么明明把界面做得很"好看",业务方却还是不满意,说"这不是我们要的"?
要回答这些问题,我们得先把"ToB 到底是什么"这件事,重新想一遍。这一章不讲方法,只讲认识。因为认识不对,方法就会用错地方。这是我交了很多学费才换来的教训。
一、ToB 的本质:你设计的不是产品,是组织的运转
先说一个我自己花了很久才真正想明白的判断:ToB 设计的对象,从来不是一个"用户",而是一个"组织"。
这话听上去有点抽象,我们把它拆开。
当你为一个个人用户设计,比如一个记账 App,你面对的是一个完整的、自洽的人。他自己产生需求(我想记账),自己做决定(用这个 App),自己使用(每天记一笔),自己承担结果(月底看报表)。需求、决策、使用、付费,这四件事统一在同一个人身上。你只要把这一个人伺候好,产品就成了。
可当你为一个组织设计,这四件事会分裂到不同的人身上,而且常常彼此冲突。
我们把那个常见的报销系统例子讲透。一家公司要上一套报销系统,围绕它至少站着四拨人。提出需求的,是财务总监,他要的是合规、可审计、每一笔钱都有迹可循、能卡住不合规的报销。做采购决策的,是 CIO 或者老板,他关心的是成本、安全、能不能跟现有的 OA 和财务系统打通、上线快不快。每天真正在用的,是公司里几百上千个普通员工,他们的诉求特别简单:让我快点把这张该死的报销单填完,别让我为了报销几百块钱加班到半夜。为这套系统付费的,又是另一个预算口子,他关心这笔钱花得值不值。
四拨人,四套诉求,而且彼此打架。财务要的"严密",落到员工那里就是"繁琐",每多一道审核、每多一个必填字段,对财务是多一重保障,对员工就是多一分折磨。老板要的"省钱",可能意味着砍掉那个能让员工少填三个字段、却需要额外开发的功能。
这里就引出 ToB 设计第一个、也是最根本的难处:你不可能同时取悦所有人,你必须理解他们各自要什么、谁的诉求在什么时候优先,然后在这张关系网里找到一个能让组织整体跑得更好的方案。
我讲一个自己的教训。早年我做过一个员工培训系统,需求方是 HR,他们想要详尽的学习数据:每个员工看了多久、暂停了几次、考试考了几遍。我们老老实实照做,做了一套对 HR 极其友好的后台。结果上线后,员工怨声载道:为了那些数据,系统强制不能快进、不能后台播放、暂停超过几分钟就要重新考试。员工开始用各种办法糊弄,挂着视频干别的、互相代考。HR 拿到的数据很漂亮,但培训的实际效果一塌糊涂。我们取悦了需求方,却伤害了使用方,最终连需求方真正想要的(员工真的学会)也没实现。这个项目让我第一次痛切地体会到:只看见出钱的人、看不见用的人,是 ToB 设计最常见、也最致命的失误。
所以我常说,ToB 设计师的产出,表面上是界面,本质上是"让一群人的协作变得更顺畅、并让组织目标真正达成的那套秩序"。界面只是这套秩序露出水面的部分。
二、三层主体:个体、群体、组织
为了把"为组织设计"这件事说得更具体,我习惯把 ToB 的设计对象拆成三层来看:个体、群体、组织。这三层像同心圆,一层套着一层,每一层关心的东西都不一样。理解这三层,你就有了一副观察 ToB 的眼镜。
最里面一层是个体,那个具体的操作者。他是真正把手放在键盘上、对着屏幕干活的人:仓库里的拣货员、医院里的护士、银行柜台后的柜员、客服中心戴着耳机的接线员。在这一层,设计要解决的是最朴素的问题:让他这一次操作更快、更准、更不容易出错。这一层的诉求是"效率"和"顺手"。一个为这一层设计得好的系统,会让操作者感觉"这东西懂我":按钮在我手会去的地方,信息在我需要时出现,我快犯错时它拦得住我。很多设计师只看到了这一层,以为把单个操作者伺候好就是 ToB 设计的全部。这是个常见的、也是不够的视角。
中间一层是群体,协作的团队。个体很少是孤立干活的。拣货员的上游是仓管员,下游是打包和物流;护士的工作要跟医生、药房、检验科衔接;柜员的每一笔业务背后是风控、是后台、是审批。在这一层,设计要解决的是协作问题:信息怎么在角色之间流转、一个人的操作如何成为另一个人的输入、谁能看到什么、谁能改什么、出了问题责任在哪一环。这一层的诉求是"协同"和"一致"。同一个"订单",在销售眼里是业绩,在仓管眼里是出库任务,在财务眼里是一笔应收,它们是同一个对象,却要在不同角色面前呈现出不同的面孔。设计师在这一层的功课,是让这些面孔彼此对得上、传得顺、不打架(这一点,第九章讲复杂系统时会深入)。
最外面一层是组织,业务系统与权力结构本身。再往外,是整个组织的运转逻辑:它的业务流程、它的规章制度、它的权限层级、它要达成的经营目标。在这一层,设计要服务的是组织效能:系统是不是让这家公司整体上更快、更稳、更可控了?它产生的数据能不能支撑管理者做决策?它固化下来的流程,是帮业务跑得更顺,还是反而成了束缚?这一层的诉求是"效能"和"可控"。它往往不直接体现在某个界面上,却决定了整套系统的成败。一个在个体层面无比顺手、却跟组织的真实业务流程对不上的系统,最终一定会被废弃。
怎么用这副眼镜?每当你接到一个需求,反过来问自己几个问题:这个需求是哪一层提出来的?它满足了这一层,会不会伤到另一层(就像前面那个培训系统,满足了组织层的数据诉求,伤了个体层的体验)?三层之间的张力在哪里?好的 ToB 设计,是在这三层之间找到平衡,而不是只盯着自己最熟悉的那一层使劲。
三、ToB 与 ToC 的四个根本差异
理解了"为组织设计"和"三层主体",我们就能更锋利地说清楚:ToB 和 ToC,到底差在哪里。
我不想罗列那种"ToB 用户少、ToC 用户多"之类的表面区别。我想讲四个真正影响设计判断的根本差异,它们每一个,都会让"把 ToC 经验直接搬过来"的设计师栽跟头。
第一,效率优先于愉悦。ToC 产品很多时候是在"争夺用户的时间",让你多刷一会儿、多停留一秒,所以它会用各种手段制造愉悦感、上瘾感。ToB 产品恰恰相反,它是在"节省用户的时间"。一个员工用报销系统,他的目标是尽快用完然后回去干正事,而不是在里面多待一分钟。这个根本差异,决定了 ToB 设计的最高准则是效率,而不是愉悦。那些在 ToC 里行之有效的"制造惊喜""增加停留"的套路,搬到 ToB 往往是帮倒忙。在 ToB,最好的体验常常是"无感":用户顺畅地完成了任务,甚至没意识到自己在用一个被精心设计过的系统。一个常见的误区,是把 ToC 的"沉浸感""趣味性"当成追求,给一个高频的录入工具加一堆华丽动效,结果天天用它的人被烦到想砸键盘。
第二,多角色,而非单用户。这一点前面已经讲透了。ToC 多数时候面对的是单一用户画像,ToB 面对的是一张由多个角色编织的网。这意味着 ToB 设计里,"用户是谁"永远不是一个简单的问题,而需要先做角色拆分。后面第三章讲用户研究时,我们会专门讲"角色—场景—任务"这套拆解方法,它是应对多角色复杂性的核心武器。一个只会做"单一用户画像"的设计师,在 ToB 面前会束手无策。
第三,决策链长,而非即时转化。ToC 的转化常常是即时的:你看到一个商品,心动,下单,几分钟内完成。ToB 的决策链可能长达数月:从最初的需求提出,到方案评估、多方比稿、预算审批、采购流程、试点、推广,中间要经过无数个人的点头。这对设计的影响是深远的,也是 ToC 设计师最容易忽略的。它意味着 ToB 设计不能只考虑"使用"这一个环节,还要考虑"被评估""被采购""被推广"。比如,产品在销售给客户演示时,好不好讲、能不能在十分钟里讲出价值?在客户试点时,新用户上手快不快、第一周会不会因为太难用就放弃?这些环节的体验,都会实实在在地影响产品的命运,而它们在 ToC 里几乎不被设计师关心。一个只为"老用户的日常使用"优化、却在"新客户的第一印象"上一塌糊涂的产品,可能根本活不到被日常使用的那天。
第四,低容错,而非可试错。ToC 产品很多时候是可以试错的:按错了再点回来,大不了重新走一遍流程,损失有限。ToB 不行。一个财务系统里点错一个金额、一个生产系统里下错一道指令、一个医疗系统里录错一个剂量,后果可能是真金白银的损失,甚至是安全事故。这种低容错的特性,让"防错"和"可恢复"在 ToB 设计里有着远超 ToC 的分量。这也是为什么,后面第六章讲交互时,我会反复强调一个判断:在 ToB,与其用弹窗逼用户确认,不如给他一条可以撤销的后路。前者打断心流却防不住惯性点击,后者既不打扰又真正兜得住底。
这四个差异,不是程度上的不同,而是方向上的不同。把它们列成一张对照表,随时提醒自己:首要目标上,ToC 追求愉悦、吸引、停留,ToB 追求效率、节省时间;用户上,ToC 是单一用户画像,ToB 是多角色关系网;转化上,ToC 是即时的个人决策,ToB 是长决策链、多人点头;容错上,ToC 可试错,ToB 低容错、需防错与可恢复。一个优秀的 ToC 设计师转做 ToB,如果不更新这张表里的底层判断,很可能会把一身好本事用错地方。重识 ToB,首先要重识这四个分野。
四、ToB 设计师的价值与挑战
说了这么多 ToB 的难,那么 ToB 设计师的价值,究竟在哪里?
我的答案是:ToB 设计师的核心价值,是深入理解业务,并把这种理解转化成让组织跑得更顺的设计方案。
请注意,我把"理解业务"放在了第一位,放在了"设计"之前。这是 ToB 和 ToC 又一个气质上的不同。一个 ToC 设计师可以不懂太多行业知识,凭着对人性的普遍洞察和对体验的敏感,就能做出好产品。但一个 ToB 设计师,如果不懂他所服务的那个行业,不懂仓储的实际作业流程、不懂财务的记账规则、不懂医院的诊疗路径,他就根本没有资格谈设计。因为他连用户在干什么、为什么这么干都不知道,他的"设计"只能是猜测和臆想,做出来的东西自然会被业务方一句"这不是我们要的"打回来。
这既是 ToB 设计师最大的挑战,也是他最深的护城河。
说它是挑战,因为每进入一个新行业,你几乎都要从头学起。ToB 的领域知识浩如烟海,且高度专业,不是看几篇文章就能速成的。你得去现场、去观察、去跟一线的人聊、去把自己泡在那个业务里,直到你能像内行一样思考。这个过程慢、笨、不性感,但绕不过去。
说它是护城河,也正因为它慢、笨、不性感。今天 AI 可以瞬间生成一个像模像样的界面,可以套用任何流行的设计模式。但 AI 替代不了你对一个具体业务的深入理解,替代不了你在现场观察到的那个"工人戴着手套点不了小按钮"的细节,替代不了你在多个角色的诉求冲突中做出的那个艰难权衡。当界面本身越来越容易生成,理解业务的能力就越来越值钱。这是 ToB 设计师在 AI 时代最该握紧的东西,我在后面第十二章、第十七章会反复回到这个判断。
除了理解业务,ToB 设计师还面临几个绕不开的挑战,它们会贯穿这本书的始终。我把它们提前点出来,请你带着这些问题往下读。
一是复杂性。ToB 系统天然复杂:业务规则多、状态空间大、角色交叉、还要跟一堆别的系统集成。如何驾驭这种复杂、而不是被它压垮,是 ToB 设计的核心命题。这本书第二篇和第三篇,很大程度上就是在回答这个问题(尤其第五章和第九章)。
二是话语权。在很多组织里,设计师在 ToB 项目中的话语权是偏弱的:需求被产品和业务主导,设计常常沦为"美化"的最后一道工序。如何用业务能听懂的语言、用数据和逻辑,去争取设计应有的话语权,是一个 ToB 设计师走向成熟必须跨过的坎(第十五章专门谈)。
三是度量。ToB 设计的价值常常难以度量,它不像 ToC 那样有清晰的转化率、留存率。一次让录入效率提升 30% 的改版,它的价值如何被看见、被认可?学会度量和表达设计的价值,是设计师从"执行者"走向"影响者"的必修课(第十四、十五章)。
一本书最好的读法,不是被动接受结论,而是带着自己的困惑,去和作者的思考碰撞。这三个挑战,我会用整本书来回答。
把视角调对,再开始
这一章我们没有讲任何具体的设计方法。我们做的,是一件更重要的事:把看 ToB 的视角调对。
我们说清了三件事。ToB 设计的对象是组织而非个人,所以你要在需求方、决策方、使用方、付费方的多方诉求里找平衡,尤其不能"只见出钱的、不见用的"。ToB 有个体、群体、组织三层主体,所以你要学会在三层之间权衡,而不是只盯着自己熟悉的那一层。ToB 和 ToC 有效率优先、多角色、长决策链、低容错四个根本差异,所以你不能把 ToC 的那套判断直接搬过来。
视角调对了,后面的路才走得正。从下一章开始,我们就要往"道"的深处走,去搞清楚 ToB 产品设计的本质,到底由哪几个关键词撑起来。