复杂产品拼的是结构

复杂产品一乱，团队很容易先动界面。入口多了，就重新分组；页面乱了，就重排层级；用户总问同样的问题，就多加几段解释。这样做不是没用，但很多时候只是把问题往后推了一点。

《设计师的系统思维》里真正打动我的，不是“设计师也要有系统思维”这种话，而是一个更具体的现实: 真正让复杂产品难用的，常常不是界面做得粗，而是前面的结构没理顺。

界面经常背了不该它背的锅

用户说看不懂，团队第一反应通常是改文案、改层级、改按钮。可很多时候，用户不是看不懂字，而是根本不知道系统在描述什么。这个对象到底是什么，这一步为什么非得在那一步之前，这个状态和上一个状态差在哪，这个角色到底能做什么。前面这些东西没讲清楚，后面的界面再努力，也只是勉强翻译一套自己都还不稳定的语言。

所以我现在看界面问题，会下意识往前追一层。到底是表达有问题，还是结构本身有问题。两者长得很像，处理方式完全不一样。

一个产品一旦开始涉及多个对象、多个角色、多个状态，最先出问题的通常是命名和关系。用户看到几个词，以为它们差不多；团队内部讨论时，每个人心里装的其实又不是同一个东西；等功能越做越多，页面就会长出越来越多补丁。

这时候你会看到一些很熟悉的症状。帮助文档越来越厚，入口越来越绕，命名越来越抽象，很多东西只能靠“用久了就懂”。这种状态通常不是界面不够努力，而是概念边界一直没被认真处理。

很多人以为先梳理结构会拖慢设计，实际经常相反。对象清楚了，关系清楚了，哪些信息该一起出现、哪些该延后出现也会跟着清楚。很多界面决定这时候反而很好做，因为它不再是猜。

真正让设计师难受的，从来不是限制多，而是前提不稳。这个入口到底主不重要，这个对象该不该直接暴露给用户，这个步骤是主流程还是异常分支，如果这些问题没人回答，页面就只能反复返工。

我现在对系统思维的理解很朴素。它不是宏观口号，也不是为了显得想得远。它更像一个提醒: 先把系统里的东西讲明白，再谈页面怎么长。

什么是核心对象，什么是辅助对象，哪里是主路径，哪里是例外，哪些复杂度真的躲不掉，哪些只是前面偷懒带来的。把这些问完，很多设计问题会自动缩小。

所以如果只留一句话，我还是会保留这个标题。复杂产品最先乱掉的，通常不是界面，而是结构。界面只是最后把问题诚实地露出来。