解决自己的痛点

在需求调研里一直存在一种方法，就是从自身的痛点出发去挖掘项目。

因为这种痛点需求你碰到了，别人自然很大概率也能碰到，那你在解决这种痛点的过程中，自然会形成一套有效的解决方案，而这种有效的方案能顺利发展成一个还不错的产品。

比如我之前分享过一个小语种翻译的案例，也就是将 AI 的翻译能力引入到 TranslatePress 插件，去做 WordPress 网站的小语种版本翻译。

同样的道理，Shopify 网站也需要这样的功能，其他的 SAAS 平台也大概率适用这套逻辑。

另外像我们现在熟知的一些产品，很多在刚开始的时候也都是从解决自身痛点开始的。比如脸书最初是为了方便同学之间相互联系与分享信息的，推特最初也只是让员工通过短信分享简短状态更新，等等。

那这篇文章再分享一个一直困扰着我的翻译通点，我猜很多人应该也有碰到。

比如上图是我与一位土耳其客户在 WhatsApp 上沟通需求，他不懂英语，我也不懂土耳其语，于是就这么利用翻译软件在沟通。

因为我使用的是 Mac 版本的软件，因为没办法使用浏览器插件之类的方式去实现沟通信息的高效翻译，导致我现在只能是一句一句将文案拷贝并粘贴到 DeepL 中翻译。

如果只是单纯的复制粘贴其实也能忍受，主要是复制完收到的信息，了解了大概的意思之后，我还得回复客户的信息。

就又得切换一下 DeepL 的翻译方向，我在其中输入中文，然后复制其翻译完成的土耳其语回复给客户。

如此这样一个沟通过程，因为过程中的翻译软件加入变得非常复杂。且 DeepL 这样的翻译软件在保存对话上下文方面做得非常糟糕，其使用体验一直不好。

有时候客户发一条类似“昨天的配置数据我需要修改一下”的信息，那我自己的工作量就大了去了，需要往回翻记录并一条一条再去翻译试图去找到那条数据，整个链条非常冗长。

起初我也试图去找过一些解决方案，比如 DeepL 的客户端产品、谷歌翻译的客户端产品，甚至 Tranworld 翻译助手这样的产品，发现都不好用。

因为这些产品基本是为了通用需求设计的，根本没有考虑这种双语对话的翻译场景。

我想要的点其实很简单，一是文本的翻译，二是翻译记录保留。

那解决这个痛点最方便的做法，便是在 WA 的每一条消息下显示出对应的翻译文案（类似于网页版）。但是我自己也调研了下，好像 WA 桌面端并不允许这么做，我自己也没发现在类似这样的桌面软件。

有段时间我甚至使用 Raycast 里的一个自动选择脚本去做了自动翻译，但实际体验下来还是不好使，不仅出错的概率高且脚本总是反应不及时。

以上，仅仅是一个从自身痛点发现需求的案例吧。其实类似这样的案例，如果只要在工作过程中多留心一点总是能发现不少的。