把一个小项目做完整，比把它做复杂更难

一个小项目最令人兴奋的时刻，通常是核心功能第一次跑通：按钮有响应，内容能够保存，页面终于显示出了预期的结果。

但从“能够运行”到“愿意每天使用”，中间还有一段不太显眼的工作。

从真实的使用顺序出发

开发时，我们知道所有按钮的位置，也知道系统里已经有哪些数据。第一次使用的人没有这些背景。

拿一个写作工具来说，最自然的顺序可能是：

1. 看清楚自己有哪些文章。
2. 打开一篇草稿，开始写正文。
3. 确认修改是否已经保存。
4. 预览读者最终会看到的样子。
5. 检查标题和文章设置，再发布。

如果文章地址、日期和标签先占满了屏幕，写作本身就被推到了后面。功能没有少，顺序却不符合人的习惯。

完整体验藏在边缘状态里

除了理想情况，还可以主动检查这些时刻：

使用时刻	应该回答的问题
还没有文章	接下来从哪里开始？
刚刚修改正文	保存了吗，还是正在保存？
保存失败	修改是否保留，如何重试？
没有搜索结果	是没有内容，还是关键词不合适？
准备发布	哪些内容会被读者看到？

这些提示不需要写得很长。准确的几句话，比一个始终显示“操作成功”的通知更有帮助。

把高频操作放在手边

写作、保存和预览会反复发生，可以放在容易看见的位置。删除和撤回使用得少，也会改变已有内容，适合放在较低的位置，并说明操作后的结果。

一个简单的判断是：现在这个页面，最希望使用者完成哪一件事？ 如果答案是写作，就让标题和正文成为视觉中心。

用一次完整流程验收

检查清单可以很短，但要走完：

• 创建一篇草稿。
• 修改正文并重新打开。
• 预览、发布，再从前台阅读。
• 修改已发布文章，确认更新前的展示。
• 用自己的真实内容连续使用几天。

最后一项尤其重要。示例数据能发现排版问题，真实使用才能发现那些一天里反复让人停顿的小地方。