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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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