按钮UI设计要先确定动作，再决定外观：用户点下去会打开页面、保存内容、提交发布，还是删除记录？同一操作区域突出一个主动作，次动作降低视觉权重；标签说清结果，并补上等待、成功、失败时的反馈。只把矩形、圆角和颜色画好，用户仍可能不知道该点哪个、点完有没有生效。
本文用“周末摄影分享会”的活动编辑页串起这些决定。可以在墨刀设计中把活动表单、底部按钮和处理结果排在同一画布，先比较操作是否清楚，再把确认好的样式整理成组件。
先列出四个动作，不急着分配四种颜色
假设运营人员正在编辑一场活动：名称、时间和参加人数已经填写，页面提供“发布活动”“存为草稿”“预览”“删除草稿”。这四个动作看起来都像按钮，用户承担的后果却不同。先用下面的动作表决定它们应该出现在哪里。
| 动作 | 点击后发生什么 | 视觉安排 | 需要说明的结果 |
|---|---|---|---|
| 发布活动 | 校验必填信息，确认成功后允许参与者看到活动 | 当前编辑区域的实心主按钮 | 活动已发布，并能进入活动页面 |
| 存为草稿 | 保存当前编辑内容，暂不对外发布 | 主按钮旁的次按钮 | 草稿已保存，仍可继续修改 |
| 预览 | 查看当前内容的展示效果 | 弱化的按钮或链接样式 | 说明预览是否包含未保存修改 |
| 删除草稿 | 删除这份草稿，后果按产品规则确定 | 与发布区拉开距离 | 明确对象、可否恢复和取消出口 |
本例约定“预览”展示当前填写内容，但不会自动保存；“存为草稿”允许活动尚未填完整；“发布活动”要求名称、时间和人数符合规则。三个动作使用不同的校验条件，不能因为共用一张表单，就在每次点击时都要求所有字段填写完毕。
按钮和链接的区别主要在行为。保存、提交和打开操作面板通常是按钮；前往另一个已有页面通常使用链接。外观看起来像文字，不代表它在实现上就一定是链接。把行为写清，研发才能选择合适的控件语义，而不是根据是否有底色猜。
主次层级以一个任务区域为单位
在活动编辑页底部，“发布活动”用实心样式，“存为草稿”用描边或较弱底色，“预览”用文字样式，读者就能看到明确的行动顺序。GOV.UK按钮指南也建议区分主次操作，并避免多个主操作争夺注意。
这不等于整张复杂页面永远只能存在一个实心按钮。独立的搜索区域、弹窗和编辑表单可能各有自己的主要任务。判断时先看用户当前正在处理哪个区域；弹窗打开后，其内部操作应成为当前关注点，背景页面不应继续争抢操作。
一页里出现“提交”“立即发布”“保存并发布”三个近似入口时，应先合并行为或解释差异。换三种颜色不能解决动作定义重复。反过来，“批准”和“拒绝”是真正并列的判断，也不宜为了满足一个主按钮的形式，把其中一个藏到难找的位置。
按钮文案要能回答“会发生什么”
“确定”只有在上下文非常清楚时才够用。活动编辑页写“发布活动”，草稿确认页写“删除草稿”，比到处写“确定”更容易区分后果。动作名称、确认说明和结果反馈要保持同一对象，避免按钮说“保存”，成功提示却说“发布成功”。
- 把结果写进必要的动作中。“下一步”只表示前进；如果同时保存内容，可以写“保存并继续”。确实不会保存时，就不要给出保存承诺。
- 数量影响后果时才带数量。批量删除可写“删除所选3项”，而普通“预览”不需要添加无关信息。数量变化时，按钮也要同步变化。
- 图标不能替代难懂的动作。熟悉的关闭图标可以配可访问名称；“归档”“发布”这类容易产生歧义的操作，优先保留文字。悬停提示不能成为触屏用户理解按钮的唯一办法。
- 不要让同一词承担相反行为。“取消”应明确是取消编辑、取消发布请求还是取消活动。活动已经发布后停止报名，应使用对应的新动作名称。
如果需要帮助AI起草标签，可以提供对象、动作后果和长度约束，再由设计师核对语义。具体输入方式可参考AI辅助UI文案的写法；不能只给一句“帮我把按钮写得更高级”。
从“发布活动”走到结果，至少区分三种返回
点击发布后，先显示“发布中”，保持按钮占位稳定，并阻止同一动作被连续触发。不要把按钮突然移走，让用户误以为页面没有响应；也不要只变灰，无法区分“正在处理”和“你现在无权操作”。
| 发生的情况 | 页面应该告诉用户什么 | 后续动作 |
|---|---|---|
| 字段校验未通过 | 例如“请选择活动开始时间”，错误贴近相关字段 | 保留其余输入，修正后再次发布 |
| 已经确认发布成功 | 显示“已发布”，给出能识别的活动名称 | 提供“查看活动”，编辑状态也同步更新 |
| 已经确认没有发布成功 | 说明失败原因，以及填写内容仍在 | 原因解除后允许“重新发布” |
| 请求超时，结果暂时未知 | 说明正在确认结果，不能直接宣称发布失败 | 先查询当前发布状态，再决定查看或重试 |
最后一种很容易被漏掉：用户没有收到成功响应，不等于系统一定没有执行。若活动其实已经发布，直接恢复“发布活动”可能让用户重复提交。原型中应把“结果未知”画成独立情况，并写明由实现端查询状态和处理重复请求；按钮的视觉变化本身不能保证不产生重复数据。
本例的“存为草稿”和“发布活动”会写入同一份编辑内容，因此发布处理中暂不让用户另行保存一个冲突版本。是否允许继续修改、是否记录为下一版本，要由产品规则另定，不能由不同按钮各自决定。
禁用与危险操作，不要只靠灰色和红色
表单还没填完时，始终禁用发布按钮虽然能阻止提交，却可能让用户不知道缺什么。若用户需要点击后才能发现错误，可以保留可操作入口，点击时显示明确校验；如果业务上必须禁用，就在附近解释条件，例如“请先设置活动时间”。不要把解释只放在禁用按钮的悬停提示里。
无权限又是另一回事。运营人员只有编辑权限、没有发布权限时，可以保留不可用入口并说明“需要发布权限”，也可以按角色隐藏入口。前者便于理解能力范围，后者减少无关功能；哪种合适取决于使用场景。无论界面如何呈现，真实权限仍需由系统验证。
对于危险动作，先判断能否恢复，而不是一律弹出确认。可撤销的归档可以执行后提供撤销；本例若“删除草稿”会永久删除内容且没有恢复入口，就应额外确认。确认内容可以写：“删除‘周末摄影分享会’的草稿？删除后无法恢复。”按钮分别用“保留草稿”和“删除草稿”，让对象和后果可读，不只显示一个红色“确定”。
删除入口与发布按钮需要拉开距离，特别是在手机底部操作区。颜色能提示风险，但误触防护还依赖位置、间距、确认信息和恢复方式。
大小与排列从真实标签开始验证
先放入“发布活动”“存为草稿”“保存并通知参与者”等真实文案，再决定宽度和内边距。短标签看起来整齐，不代表换成长文案后仍可用。更完整的平台单位与热区参考见UI设计尺寸规范；这里不把某个固定像素值当作所有按钮的标准。
桌面可以并排放主次操作。空间变窄时，可以把主要操作放为一整行，再安排次要操作，或减少同区域同时展示的动作。不要直接把文字缩小，也不要让“删除草稿”因自动换行恰好跑到主按钮原来的位置。
固定在底部的按钮还要与软键盘、设备安全区域和表单错误一起看。用户正在填写活动人数时，错误说明和输入内容应能被看见；关闭键盘后，按钮的位置也要稳定。默认、键盘聚焦、按下和加载样式应可区分，重要状态不能依赖轻微颜色差别。
在墨刀里把一组按钮做成可评审的任务
- 搭出活动编辑页。放入活动名称、时间、人数三个字段与真实样本文案，按动作表安排发布、草稿、预览、删除。先检查每个入口的行为是否唯一。
- 整理按钮组件。统一文字、内边距、圆角与主次样式，用组件和颜色变量维护重复使用的部分。只改变标签长度，检查按钮是否仍有足够空间。
- 制作处理结果画面。保留编辑、发布中、已发布、校验失败和结果未知几种关键情况。在对应画面旁写清触发条件、保留的数据和下一动作。
- 串起关键路径。需要演示点击后的变化时，用墨刀原型的交互与预览表达任务顺序。重点走“先存草稿再发布”和“发布失败后修改”两条路径；成功提示应对应真实的设计约定。
- 交付到具体动作。把按钮名称、权限、校验、处理中行为、完成结果放到同一条说明里。设计稿表达预期，实际请求、权限判断和重复提交防护由研发实现并验证。
评审时让同事完成一次任务：“先保存尚未定时间的活动，补齐时间后发布，再找到已发布页面。”如果对方能清楚区分草稿与发布，等待时知道发生了什么，失败时知道怎样继续，这组按钮才真正服务了活动编辑流程。
