当设计团队将原本一次性的表单拆分为多步流程后，一位长期用户反馈这种改动反而打乱了他习惯的全局规划式操作节奏。这次冲突揭示了通用设计原则与熟练用户实际需求之间的错位，促使团队重新思考“最佳实践”在不同用户场景下的适用边界。

在设计行业里，有些方法几乎已经成为共识。比如：把复杂任务拆成多步，可以降低用户的心理压力。

今年下半年，某位设计师在PC招聘的功能中，也做了一次这样的改动。而最近一次客户调研，让我意识到：

有些“看起来非常合理的设计”，并不一定真的站在用户那一边。

01 一个被广泛使用的设计策略

原来的职位发布流程，是一个页面填写所有信息：

职位标题、薪资范围、福利待遇、岗位说明……页面很长，信息很密集。

从设计视角看，这个页面的问题并不难找：

• 信息密度高，容易让人产生畏难情绪
• 新用户第一次看到，很可能在未开始填写前就退出
• 所有认知负荷集中在同一时刻

于是这样的设计方法似乎是「顺势而为」：

• 把一个页面拆成多步，把更重要、也更容易填写的信息放在前面。
• 每一步更短，心理压力更小
• 用户完成一步就能获得反馈

很多大家熟悉的产品都这么做过

所以在评审阶段，这几乎是一个没有争议的决定。

02 一段让人难以反驳的用户反馈

转折出现在一次老客户访谈中。

这位客户使用产品多年，发布职位对他来说是一件非常熟练的事。他开门见山，而且情绪有些激动：

“能不能不要没事儿瞎改啊，你像以前吧，我一般会先看看这一整页都有啥，然后统一想，这一块该怎么填，那一块该怎么填。现在好了，下面的我看不到了，到第二步我觉得上一步有个地方需要改，点这个「上一步」还要担心正在填的会不会给删除了，所以就这样反复上一步下一步的，你们为什么要改成这样啊？”

我们的忠实用户，并不是在简单地表达不满，而是在清楚地描述自己的使用方式：先整体浏览、统一规划、再一次性完成。

而我们这次改动，恰恰打断了这一整套已经运转良好的节奏。

03 问题可能不在“设计对不对”，而在“我们假设了谁”

事后回头看，这次冲突并不在于多步表单是否合理，而在于一个更根本的问题：

我们解决的，可能并不是同一种用户问题。

多步表单背后的典型假设是：

• 用户对任务不熟悉
• 面对大量信息会感到焦虑
• 需要被一步步引导完成

但对这位老客户来说，发布职位并不是探索，而是一项高度熟练的执行任务。

在他的心智模型里：

• 全局感比单步轻松更重要
• 可预期性比“被引导”更重要
• 修改和回看，是规划的一部分，而不是异常操作

从他的角度看，这次改版并没有“减负”，反而增加了不确定感和反复操作的成本。

04 一些并不绝对但反复出现的原因

回想自己这些年做过的大大小小的设计，我慢慢总结出一些可能的原因。它们更像是反复出现的倾向，而不是明确的错误。

第一，「通用设计原则」被过度信任了

像“降低认知负荷”“减少一次性输入”“循序渐进完成任务”，这些原则本身并没有问题，也确实在很多场景中有效。

正因为如此，它们很容易在设计讨论中被当作一种“默认正确”。

但做得久了会发现，这些原则往往解决的是某一类用户、某一阶段的问题。一旦脱离具体的使用情境，它们就会从经验总结，变成一种不自觉的依赖。

第二，我们往往不自觉地偏向“新用户视角”

在业务目标的驱动下，新用户体验仿佛被放在更优先的位置。

这本身可以理解，但代价是：熟练用户的效率和习惯，可能被低估了。

第三，我们低估了熟练用户的“规划型思维”

对很多老用户来说，流程不是界面，而是一套已经内化的操作逻辑。

他们需要的不是被引导，而是被尊重这种既有结构。

任何改变，都会被放大为对效率的干扰。

第四，我们用数据指标替代了体验判断

多步流程可能提升了首步完成率，却不一定提升整体体验。

而那些“反复修改”“来回跳转”的不适感，往往并不会立刻反映在数据中。

05 写在最后

如果能区分探索型任务和执行型任务、或是给不同熟练度的用户保留选择权、并且主动意识到“不确定感”本身就是体验成本，体验会不会更好？其实我也没有答案，只能在以后的设计中继续探索。如果再有宝贵的用户调研的机会，可能也会更加主动关注那些“不太顺从设计方案”的声音吧。