摘要
昨天我优化了内容日历里的写文章入口。问题很简单：用户已经选中了日期和账号，点写文章时，系统还让他重新选择。
这说明界面没有理解当前上下文。我最后让写作入口继承当前日期和账号，并让按钮文案也跟着变化。
这篇文章讲的是为什么一个好入口应该带着用户所在场景，而不是把用户拉回空白状态。
目录
- 用户已经表达了意图
- 写作入口为什么要继承上下文
- 文案也要跟着场景变化
- 为什么要减少重复入口
- 长期收益
- FAQ
用户已经表达了意图
当用户在某一天、某个账号下面点击写文章，他其实已经表达了很多信息。
他不是抽象地想写一篇文章。他想为这一天、这个账号写一篇文章。
如果系统打开弹窗以后，把日期和账号都清空，让用户再选一遍，就等于丢掉了他的上下文。
这会让流程显得笨。
写作入口为什么要继承上下文
我让写作弹窗直接继承当前选中的日期和账号。
这样用户点开以后，不需要再确认一堆基础信息。系统已经知道他从哪里来，也知道他大概要做什么。
这类改动能减少错误。比如用户本来想给某个账号写，却因为默认值没变，最后写到了另一个账号下面。
上下文继承就是减少这种错配。
文案也要跟着场景变化
只继承数据还不够，文案也要变。
如果当前选中了某个账号，按钮或空状态就应该直接说“为这个账号写文章”。这样用户点之前就知道动作会带上哪个上下文。
这比泛泛地写“写文章”更安心。
文案不是装饰。它是对用户意图的确认。
为什么要减少重复入口
昨天我也处理了重复入口。
顶部有一个写文章，当天面板里也有一个写文章。看起来都能用，但只有当天面板里的入口更接近用户当前场景。
所以我保留更贴近上下文的入口，去掉容易让人困惑的入口。
入口少一点，决策反而更轻。
长期收益
长期看，这会让内容日历更像一个会理解现场的工具。
用户在日期里写文章，系统就继承日期。用户在账号下写文章，系统就继承账号。以后做批量推送、账号排期、自动生成选题，也都可以沿用这种上下文逻辑。
工具越懂上下文，用户越少重复填写。
FAQ
为什么不能让用户每次都重新选？
可以，但会增加错误和重复操作。系统已经知道的信息，不应该让用户再填。
文案为什么要显示账号？
它能让用户在点击前确认当前动作会作用到哪个账号。
重复入口一定要删吗？
不一定。关键看它们是否承担不同场景。如果功能相同，保留更贴近场景的那个。