从“我应该查看评论”到 SaaS

Source: Dev.to

引言

这是我创建 SaaS AppReviews 之旅的第一部分。

问题

很长一段时间，应用评论对我来说处于一个奇怪的位置。我知道它们很重要，也很关键。经过十多年构建 Android 应用，我非常在意产品质量和用户体验，而评论是用户直接告诉你他们想法的少数渠道之一。

然而，它们从未真正成为我日常工作的组成部分。在工作中，评论是你“偶尔”检查的东西，或者在出现问题时、或者有人想起时才去看。通常这意味着打开 App Store Connect 或 Google Play Console，登录、点来点去、滚动，试图了解自上次查看以来发生了什么。大多数时候，这感觉像是一件苦差事。

触发点

AppReviews 的真正触发点来源于工作中的一个非常实际的需求：我们想在用户评论周围放置一些基础检查。没有花哨的东西——不需要仪表盘、图表或每周报告。我们只想在有新评论时得到通知，最好能和部署通知、CI 消息以及警报一起出现在 Slack 中。

当我们查看现有工具时，要么功能太多，要么价格太高。有些方案显然是为拥有专门团队处理评论和客户反馈的大公司打造的。它们功能强大，但如果你只想要一个简单的信号，就显得大材小用。对我们而言，成本和复杂度都不合理，于是只能回到手动检查。

手动检查的局限

手动检查本身就让人烦恼，更糟的是它很容易被忘记。“稍后再检查”很快就变成明天，然后是下周，结果你在阅读七天前的评论。到那时，时机已经错过。

留下差评的用户往往仍然在使用产品。如果你能快速回复，就可以澄清、提问、解释，甚至在问题演变成更大麻烦之前解决它。几天后才回复则效果大不相同——显得遥远且常常徒劳。

错过的回复不仅仅是失去评分，更是失去了解实际发生了什么的机会，失去上下文，失去本可以帮助避免同类问题再次出现的反馈。

第一个小技巧

看到这种模式不断重复后，我像往常一样对恼人的事采取行动：我写了一个脚本。第一版很丑——没有 UI，也没有配置界面。它只是抓取评论并在出现新评论时向 Slack 发送一条消息。

效果立竿见影。评论不再是需要记得去检查的东西，它们直接出现。有人看到 Slack 消息会说“哦，我看到了”或“这解释了我们昨天收到的支持工单”。有时会引发讨论，有时会促成快速回复，有时只是静静地待在那里——但至少它们是可见的。这感觉……更健康。

认识核心问题

让我惊讶的是，这个改变相对于产生的效果来说是多么微小。我们没有分析任何东西，也没有进行优化；我们只是消除了摩擦。核心问题并不是获取评论的难易——任何人都可以访问。问题在于评论存在于你必须主动前往的地方，而任何重复的手动操作最终都会被延迟。

几乎在同一时间，我注意到自己在个人项目中也在做完全相同的事。发布了某个功能，感觉不错，然后想“我应该检查评论”。有时会检查，有时不会，有时又发现反馈来得太晚，心里想“要是我早点看到就好了”。同样的模式，只是情境不同。

将脚本变成产品

于是，把脚本做成更正式产品的想法变得显而易见。起初，我并不把它当作产品，而是觉得“这应该存在”。一个简单、实惠、专注的工具——只做好一件事：让评论无需任何努力就能送到你手上。

当我开始正式构建时，新的问题出现了：

• 如果你把评论集中起来，如何避免再创建一个人们会停止查看的地方？
• 当有数十条评论时，如何在不阅读全部内容的情况下快速了解情况？

我一直更关注降低噪音，而不是堆砌功能。大多数工具之所以失败，并不是因为功能不够，而是因为功能太多。我不想让 AppReviews 变成另一个人打开一次就忘记的仪表盘。

设计原则

关注点保持极其狭窄：

• 可见性 – 评论出现在你已经在看的地方。
• 及时性 – 你在评论发布的第一时间看到它们。
• 上下文 – 提供足够信息，让你无需在控制台里翻找就能采取行动。

其他一切都是次要的。

改变与评论的关系

有趣的是，一旦评论始终可见，你与它们的关系就会改变。它们不再是你稍微回避的轻度压力源，而是产品反馈循环的一部分。你不再“检查评论”，而是对它们作出反应。这种转变虽小，却意义重大。

构建副业项目

在某个阶段，这个副业项目开始成形：夜晚、周末、小迭代、许多关于不该构建什么的决策，以及大量抵制因为“我能做到”而随意添加功能的诱惑。我并不是在打造终极评论平台，而是想解决一个非常具体、非常人性的难题——那一刻你会想，“我应该检查评论”。

下一步

在下一篇文章中，我会谈论我如何决定 AppReviews 的核心聚焦点，以及为何削减功能成为项目中最重要的环节之一。