在需求調研里一直存在一種方法，就是從自身的痛點出發去挖掘項目。

因為這種痛點需求你碰到了，別人自然很大概率也能碰到，那你在解決這種痛點的過程中，自然會形成一套有效的解決方案，而這種有效的方案能順利發展成一個還不錯的產品。

比如我之前分享過一個小語種翻譯的案例，也就是將 AI 的翻譯能力引入到 TranslatePress 插件，去做 WordPress 網站的小語種版本翻譯。

同樣的道理，Shopify 網站也需要這樣的功能，其他的 SAAS 平臺也大概率適用這套邏輯。

另外像我們現在熟知的一些產品，很多在剛開始的時候也都是從解決自身痛點開始的。比如臉書最初是為了方便同學之間相互聯系與分享信息的，推特最初也只是讓員工通過短信分享簡短狀態更新，等等。

那這篇文章再分享一個一直困擾著我的翻譯通點，我猜很多人應該也有碰到。

比如上圖是我與一位土耳其客戶在 WhatsApp 上溝通需求，他不懂英語，我也不懂土耳其語，于是就這么利用翻譯軟件在溝通。

因為我使用的是 Mac 版本的軟件，因為沒辦法使用瀏覽器插件之類的方式去實現溝通信息的高效翻譯，導致我現在只能是一句一句將文案拷貝并粘貼到 DeepL 中翻譯。

如果只是單純的復制粘貼其實也能忍受，主要是復制完收到的信息，了解了大概的意思之后，我還得回復客戶的信息。

就又得切換一下 DeepL 的翻譯方向，我在其中輸入中文，然后復制其翻譯完成的土耳其語回復給客戶。

如此這樣一個溝通過程，因為過程中的翻譯軟件加入變得非常復雜。且 DeepL 這樣的翻譯軟件在保存對話上下文方面做得非常糟糕，其使用體驗一直不好。

有時候客戶發一條類似“昨天的配置數據我需要修改一下”的信息，那我自己的工作量就大了去了，需要往回翻記錄并一條一條再去翻譯試圖去找到那條數據，整個鏈條非常冗長。

起初我也試圖去找過一些解決方案，比如 DeepL 的客戶端產品、谷歌翻譯的客戶端產品，甚至 Tranworld 翻譯助手這樣的產品，發現都不好用。

因為這些產品基本是為了通用需求設計的，根本沒有考慮這種雙語對話的翻譯場景。

我想要的點其實很簡單，一是文本的翻譯，二是翻譯記錄保留。

那解決這個痛點最方便的做法，便是在 WA 的每一條消息下顯示出對應的翻譯文案（類似于網頁版）。但是我自己也調研了下，好像 WA 桌面端并不允許這么做，我自己也沒發現在類似這樣的桌面軟件。

有段時間我甚至使用 Raycast 里的一個自動選擇腳本去做了自動翻譯，但實際體驗下來還是不好使，不僅出錯的概率高且腳本總是反應不及時。

以上，僅僅是一個從自身痛點發現需求的案例吧。其實類似這樣的案例，如果只要在工作過程中多留心一點總是能發現不少的。