App交互设计：让用户少想一步

做独立开发这些年，我越来越觉得：一个 App 能不能留住人，代码质量只决定下限，交互设计决定上限。用户不会因为你用了 MVVM 就多打开一次，但会因为「这个按钮怎么点都没反应」直接卸载。交互设计不是画几张好看的界面图，而是把用户的目标拆成一条阻力最小的路径。

交互设计先解决「用户下一步做什么」

很多独立开发者习惯从功能列表出发：登录、列表、详情、设置，一个个页面做过去。但用户不是按功能模块使用产品的，他们带着一个具体目标进来。交互设计的第一件事，是把主流程写出来，而不是把页面画出来。

我通常会在动手前写一段「用户剧本」：

• 用户从哪里进入（推送、搜索、分享链接）
• 进入后第一眼要看到什么信息
• 完成核心动作需要几步
• 失败或中断时如何回到主路径

这段剧本能暴露大量问题。比如一个记账 App，如果用户打开后要先选账本、再选分类、再填金额，那核心动作被拆成了四步。更好的做法是把金额输入放在首屏，分类用最近使用的快捷项，账本默认继承上一次选择。少一步，转化率就是另一个量级。

减少认知负担的三个具体手法

1. 用默认值代替选择

选择是成本。凡是能合理推断的，就不要让用户选。时间默认当前、分类默认高频、单位默认常用、开关默认符合大多数场景。默认值不是偷懒，而是把「大多数人的选择」提前替用户做完，同时保留修改入口。

2. 用状态反馈代替猜测

用户点击后最怕的是「没反应」。哪怕请求要 800ms，也要立刻给出视觉反馈：按钮进入 loading、列表出现骨架屏、操作后出现轻提示。交互设计里有一条朴素原则：任何用户动作都必须在 100ms 内得到可见回应。没有回应的界面，用户会重复点击，然后触发重复提交。

// 按钮防重复提交的常见写法
async function submitOrder() {
  if (submitting.value) return;
  submitting.value = true;
  try {
    await api.createOrder(form);
    toast('下单成功');
  } catch (e) {
    toast(e.message || '请稍后重试');
  } finally {
    submitting.value = false;
  }
}

3. 用渐进披露代替一次性堆砌

移动端屏幕小，把所有选项摊开只会让用户无从下手。高级设置、筛选条件、扩展参数，默认收起，按需展开。首屏只保留完成主任务必需的元素，其余内容通过「更多」「高级」入口进入。渐进披露的关键是入口要显眼，别让用户找不到。

导航结构决定用户能否形成肌肉记忆

底部标签栏适合 3 到 5 个平级入口，超过 5 个就该考虑合并。层级超过三层的页面结构，用户很容易迷路。我的经验是：主功能不超过两层，深层页面用面包屑或明确的返回路径兜底。

另外要区分「返回」和「关闭」。从列表进入详情，返回是回到列表；从推送直接进入详情，返回应该回到首页而不是空白页。这类细节在真机上测一遍就能发现，但很多团队只测正常路径。

交互稿要能回答边界问题

设计稿上只有理想状态：有数据、有网络、有权限。真实环境里还有空列表、加载失败、无网络、权限被拒、内容超长、字号放大。交互设计如果只交付正常态，开发阶段就会各自发挥，最后体验割裂。

我习惯在交互说明里强制补齐四类状态：

• 空状态：告诉用户这里为什么空、下一步能做什么
• 加载状态：骨架屏或进度提示，避免白屏
• 错误状态：说明原因，给出重试入口
• 极端状态：超长文本、大字号、横屏、弱网

交互设计的完成度，不体现在主流程有多顺，而体现在异常路径有没有人管。

用数据验证，而不是用感觉争论

交互方案有分歧时，最有效的办法不是开会说服，而是埋点验证。关注几个朴素指标：核心动作完成率、页面跳出率、平均操作步数、重复点击率。重复点击率高，往往说明反馈不足；某一步流失严重，说明信息或操作成本过高。

独立开发者资源有限，不必上复杂的分析平台，关键路径埋三五个事件就够。上线两周后回看数据，比任何设计评审都直接。

交互设计说到底是一门「替用户省力」的手艺。少一次选择、少一次等待、少一次迷路，产品的可用性就往上走一格。对独立开发者而言，这可能是投入产出比最高的一块优化空间。