序章 · 源泉：为什么「好」如此稀缺

一个让人不安的悖论

我们生活在一个能力空前过剩的时代。

人类从未像今天这样,掌握如此多的知识、工具和技能。一个普通的开发团队,今天可以在一个周末里搭起一套系统,而这套系统在二十年前需要一整个部门、半年时间才能交付。云计算让算力像自来水一样按需取用,开源社区把曾经价值连城的基础设施免费摊在每个人面前,设计工具把过去需要专门美术训练的工作变成了拖拽和套用模板。我们建造的速度、积累的知识、可调用的资源,都到了文明史上的顶点。

可是,当你真正坐下来,去用那些每天不得不用的企业软件,你会发现一件奇怪的事:这些东西大多并不好用。公司的报销系统、项目管理后台、CRM、内部的审批流,它们功能齐全,却笨重;信息密集,却混乱。

我想请你做一个小实验。回想一下你上一次用公司某个内部系统办事的经历。

也许是提一张报销单。你要在七个折叠的面板里来回翻找,搞不清"事由"和"备注"到底有什么区别,上传发票时被告知"格式不支持",却没说支持什么格式;填到一半电话来了,回过头来发现填的全没了。也许是查一笔订单卡在哪。系统给你一个叫"S-3"的状态,没人告诉你 S-3 是什么意思,你只能去问同事,同事说"哦那个啊,就是在等仓库确认"。也许是你点错了一个按钮,屏幕上只剩一句冷冰冰的"操作不可逆,请谨慎",而你已经无法回头。

这些场景,你大概率都不陌生。它们如此普遍,以至于我们渐渐习以为常,觉得"企业软件本来就这样"。

但请停下来想一想:这有多奇怪?在一个能在周末搭起复杂系统的时代,在一个 AI 能瞬间生成精美界面的时代,这些每天被成千上万人使用的核心系统,怎么会笨重、混乱、冷漠到这个地步?

这就是那个让人不安的悖论:我们建造的能力达到了顶峰,高质量的产物却依然如此稀缺。

许多东西给人的感觉,是尚未完成、残破不堪,或者干脆是被人遗忘在角落里、没人愿意为之负责的半成品。我们能造,但我们造得不够好。这一点在 ToB 的世界里尤其刺眼。在那些服务于组织运转的软件里,"能用就行"长期以来被当成默认的及格线,而"好用"被当成一种奢侈,一种锦上添花、可有可无的东西。

这本书想要挑战的,正是这条默认的及格线。

稀缺的不是技术,是判断

为什么会这样?为什么在一个技术如此发达的时代,好的 ToB 产品反而成了稀缺品?

一个流行的解释是"ToB 产品不需要好的体验"。持这种观点的人会说:企业软件是买来干活的,不是用来取悦人的;采购的是老板,用的是员工,员工没得选;只要功能跑得通、流程走得完,体验好不好无所谓。这套逻辑听上去很现实,也确实主导了行业几十年。

但它经不起推敲。

我们来看一组对照。同样是企业内部沟通工具,为什么 Slack 能从一堆功能更全、卖得更久的传统企业 IM 里杀出来,成为一代人心目中"工作沟通"的代名词?同样是文档和协作,为什么 Notion、Figma 这些一打开就会用的工具,能在巨头林立、看似格局已定的市场里,硬生生撕开一道口子,甚至反过来定义了人们对工作软件的期待?

它们靠的不是功能更多。很多被它们取代的老产品,功能清单比它们长得多。它们靠的,恰恰是那个被断言"无所谓"的东西:体验。

答案于是很清楚:当用户终于有了选择,他们会用脚投票。体验从来都重要,只是在过去,用户没有选择,被锁死在公司采购的那套系统里,这份重要性才被掩盖了。一旦市场上出现了好用的替代品,"体验无所谓"的神话立刻就破产了。

所以,稀缺的真正原因,不在技术,而在判断。

造一个 ToB 系统需要的技术,今天已经唾手可得。真正稀缺的,是有人愿意去搞清楚:这个系统到底服务于谁、谁在什么场景下用它、他真正要完成的任务是什么、什么会挡他的路、什么能帮他一把。这些问题没有标准答案,也没有现成的库可以 import。它们需要的是一种判断力,一种既懂业务的冷静、又懂人的体察的判断力。

而这种判断力,恰恰落在两种常被认为互不相干、甚至彼此对立的东西之间:科学,和艺术。

理性之美:科学与艺术不是两端

人们习惯把科学和艺术放在一条直线的两端。科学是理性的、可度量的、追求正确的;艺术是感性的、主观的、追求动人的。在这种二分法里,做 ToB 软件天然被归到"科学"那一端,它讲究架构、性能、数据、工程,跟"美"似乎扯不上关系。

这本书的核心主张是:这种二分法是错的,至少在 ToB 设计的语境里是错的。

优秀的企业级信息系统,从来都是科学与艺术共同作用的产物。它的科学性,体现在稳定可靠的架构、经得起推敲的技术选型、用数据驱动的持续优化、对复杂业务逻辑的精确建模。它的艺术性,体现在对用户真实处境的同理、对认知负担的体察、对信息层级的拿捏、对一个动作该弹窗确认还是该允许撤销的分寸感。

这两者不是此消彼长,而是相互依存。

举个具体的例子。一个订单管理系统,后端工程师可能为它设计了一套优雅的架构,数据模型严谨,性能出色,这是科学的胜利。但如果一线运营在这个系统上,每处理一个订单要点七次、在三个页面之间反复横跳,那么这套优雅的架构,在业务上依然是失败的,它没能转化成使用者的效率。反过来,一个界面做得赏心悦目、动效流畅的系统,如果背后的状态机漏洞百出,"已取消"的订单居然还能点"发货"、两个人同时操作会把数据改乱,那它就是个随时会崩的花瓶,再好看也没人敢托付。

在 ToB 的世界里,科学保证了系统"立得住",艺术保证了系统"用得动",缺一不可。把这两者割裂,无论偏向哪一端,都做不出真正好的 ToB 产品。

"理性之美"这个书名,说的就是这件事。它不是"理性"加"美"的简单并列。它想说的是:真正的美,本身就是高度理性的;真正的理性,最终会呈现为一种美。一个把复杂业务梳理得清清楚楚、让用户毫不费力就能完成任务的系统,那种顺畅与克制本身就是一种美,一种属于工程师和设计师的、冷静的美。这种美不靠装饰,而靠秩序;不靠炫技,而靠对问题的彻底理解。

这也是为什么,我想把这本书写给设计师,但又不只写界面和视觉。我越来越确信,一个 ToB 设计师如果不懂业务、不懂系统、不懂一点工程的思维方式,他的"设计"就只是给一个自己并不理解的东西涂脂抹粉。反过来,如果他只懂技术而失去了对人的体察,他造出来的就又是一个"能用就行"的半成品,继续给这个世界增添稀缺。

这本书写给谁,以及怎么读

这本书的目标读者,是已经入行、有了一定经验、想要往更深处走的 ToB 设计师,大致是中级以上的水平。

如果你已经能独立完成从需求到界面的设计,却常常感到力不从心:面对盘根错节的业务,说不清自己的设计为什么对;在跟产品和研发的拉扯中,拿不出有分量的依据;看着自己做的东西,"好像也没什么问题但就是不够好",却找不到病根——那么这本书就是为你写的。

它不是一本教你怎么用 Figma、怎么画线框图的入门手册。那样的书已经够多了。这本书想给你的,是一套更底层的东西:一种把科学的严谨和设计的体察结合起来的思维方式,以及一系列可以反复调用的方法和判断框架。

全书循着一条线索展开,我把它概括为"道、法、术、势"四个阶段。

理解(道),是认知的地基。重新看清 ToB 到底是什么、它为谁而设计、业务和信息系统如何运转、用户的真实需求藏在哪里。不打好这个底,后面的一切都是空中楼阁。

建造(法),是科学的方法。从需求分析、建模,到信息架构、交互、视觉,再到设计系统。这是全书最厚重的部分,也是一个设计师赖以安身立命的核心手艺。

进阶(术),是高阶的能力。复杂系统的拆解、数据驱动的设计、数据可视化,以及在智能体时代如何为 AI 而设计。这些把一个合格的设计师和一个出色的设计师区分开来。

升维(势),是格局的打开。设计团队与领导力、设计与商业战略的协同、设计伦理,以及对未来的展望。当你不再只关心一个界面,而开始关心设计如何在一个组织里创造价值,你就走到了这一层。

你不一定要从头读到尾。如果你正被某个具体问题困住,比如设计系统怎么治理才不会腐化、复杂表单怎么拆才不让人崩溃、AI 功能到底该怎么设计才让人信任,你完全可以直接翻到对应的章节。每一章我都尽量让它能独立成篇,并在末尾附上可以直接拿去用的实操清单。但如果你愿意从头读,那条"道、法、术、势"的线索,会让你对 ToB 设计这件事有一个更完整、也更扎实的认识。

回到源泉

这本书属于一个更大的、我私下称之为"源泉"的命题。

"源泉"这个词,我借自安·兰德的同名小说。那本书里的主角,是一个拒绝随大流、坚持按事物本来应有的样子去建造的建筑师。打动我的不是他的偏执,而是他对"好"的那种近乎固执的信念:在一个普遍将就的世界里,依然有人相信,东西本可以、也本应该被造得更好。

ToB 软件,就是今天这个时代里被将就得最厉害的角落之一。

让我们算一笔账。假设一个一万人的公司,每个员工每天因为糟糕的内部系统,平均多花十五分钟,多找一次、多填一遍、多等一会儿、出错返工一次。十五分钟看起来微不足道。但一万人,一天就是十五万分钟,合两千五百小时;一年下来,是六十多万小时的工作时间,被白白消耗在系统的笨拙里。这还只是时间,没算上那些被磨掉的耐心、被败坏的心情、被扼杀的创造力。

改善这些系统,不是一件浪漫的事,但它值得做。因为当一个系统真正变得好用,它节省的不只是几次点击,而是无数人每一天的精力、耐心和创造力,而这些东西本可以被用在更值得的地方。

让"好"不再稀缺,这就是这本书的源泉,也是它想抵达的地方。

接下来,我们从重新认识 ToB 本身开始。