有时，最有用的软件只是一个「申请发票」按钮

七月底，我们开会讨论一个正在做的平台。有好几件事想改：怎么跟进预约后的服务，哪些提醒值得发，遇到技术问题时应该去哪里反馈。说到一半，有人提出一个更小的想法：在用户的账户页面放一个「申请发票」按钮。

我喜欢它的具体。谁会在什么时候用这个按钮，为什么需要它，一句话就能讲明白：人已经付了款，现在需要发票，不该还得先打听该找谁。

那次会上，我们决定加按钮。剩下的问题不在界面上：按下去之后，事情要怎么继续？

最好画的是按钮本身

想象一下，你已经付款了。打开账户，找到那笔交易，点击「申请发票」。系统知道你指的是哪一笔吗？有没有还需要你补充的信息？它会确认收到了申请吗？团队里有没有人能看到并处理？

如果这些问题都没想清楚，最后可能只做出一个打开空白邮件的按钮。也算有点进步：至少你知道该写给谁。但你还是得解释是哪笔付款，对方也还是得去查。

我会先试着让申请直接关联那笔付款。系统既然已经知道是哪一笔，就没必要让用户抄编号或传截图。我只会请对方补充办理所缺的资料。最后确认的内容也要符合实际：如果现在只是收到了申请，就说「已收到你的申请」。

第一版只要能让用户不用到处找人就可以提交申请，同时让团队收到足够的上下文，我就觉得有用。审核和开票可以暂时人工处理，先看看实际会遇到哪些情况。

这样也能知道哪一步值得自动化。慢的可能是确认付款，也可能是补一个总是缺的字段。还有可能，重复劳动出现在这些信息齐全之后。如果还没弄明白流程就先做自动开票，时间可能花在了不该优先解决的地方。

例外也一样。有人要改资料，或者找不到那笔付款，就该有一条清楚的求助路径。第一版不用包办所有情况，但要知道处理不了的请求该交给谁。

我会挑几个申请从头跟到尾：用户找到了按钮吗？团队处理时还要再问一遍同样的资料吗？有人因为不知道申请进度，又发了一条消息吗？

这些问题能帮我区分：我们只是给页面加了一个选项，还是确实解决了一件麻烦事。它们也会告诉我接下来要做什么。有时缺一项资料，有时缺一句确认，有时流程已经够用了，可以不再改。

那次会后，我留了一个问题，用来回看其他支持任务：我们还在让用户解释哪些系统已经知道的事？ 从这里开始，往往比先画一个新页面更有用。