用AI寫文章。用AI翻譯。用AI修連結。用AI統計流量。問AI「這裡是不是不太好懂？」，然後再用AI去改。
走到這一步，通常會冒出一個問題。
所有人都對這個網站太熟了。
做網站的人知道每個按鈕是什麼意思。AI讀了規格書，也能理解「這個按鈕是相關文章」。經營者看過無數遍，就算有點奇怪，腦袋也會自動幫忙補完。
但第一次來的人就不一樣了。
「這是什麼？」 「要按哪裡？」 「為什麼只有這裡是英文？」 「我回不去了耶。」 「文字看得懂，但就是覺得怪怪的。」
我想要的，就是這個「怪怪的」。
於是最後冒出來的點子，滿有意思的。
我終於要把除錯這道工序外包給真人了。
而且每提一個問題，給1日圓。每人最多1000日圓。
人類搶AI飯碗的時代來了。負責的業務是「違和感」。
1. 想外包的不是程式碼審查，而是「第一次看到時的那個卡點」
這次我要的，不是專家做的大規模稽核。
- 看不懂按鈕是什麼意思
- 不知道下一步該去哪裡
- 標題怪怪的
- 在手機上不好按
- 點進去的連結是另一種語言
- 按了一下，畫面變成一片空白
- 句子本身說得通，但人讀起來就是彆扭
- 覺得這裡如果有個什麼功能會更方便
大概就是這類東西。
美國政府的網站指南Digital.gov把可用性測試描述為：觀察真實使用者如何操作產品或服務的方法。[1] 英國政府的GOV.UK也說，看著真實使用者操作，就能找出語言、版面等具體問題。[2]
也就是說，「讓真人上手用一次」，並不是AI時代突然冒出來的什麼神祕儀式。
只是很早以前就有的可用性測試，回到了一個能用AI大量產出、大量修改的網站身上而已。
2. 有時候，經營者本人反而最沒辦法好好測試
每天認真檢查自己的網站。
說起來容易。可是文章變多、語言變多、功能變多之後，根本做不到。
而且「做的人自己來看」還有另一個問題。
他知道搜尋欄在哪裡。 他知道相關文章會出現在哪裡。 他也知道語言切換是怎麼設計的。 就算有點不對勁，也會當成「本來就是這樣」放過去。
最重要的是，看起來太麻煩了。
這一點出乎意料地關鍵。
如果靠意志力硬撐麻煩，訂下「每天檢查100個頁面」的目標，這種做法撐不了多久。那就乾脆把這道麻煩的工序獨立拆出去。
經營者不必是什麼都要看一遍的人，
而是決定該看什麼，並建好機制去修復收集上來的問題的人。
3. 一則1日圓買的不是「點子」，而是一雙新鮮的眼睛
光看「一則1日圓」這個數字，便宜得離譜。
但這裡我想買的，並不是一份像樣的顧問報告。
而是**「有一雙第一次看的眼睛，在這裡卡住了一次」這個事實**。
一個人提出1000則，就是1000日圓。 但如果只是把同一件事換個說法，就只算1則。 每人的報酬上限也是1000日圓。
這個上限相當重要。
一旦說出「希望大家多提一點」，世界立刻就會朝著「那叫AI列一萬條改善點，不就能拿一萬日圓了嗎？」的方向狂奔。
所以，在按則數給報酬的同時，還要配上這些條件：
- 真的看過這個網站
- 寫的是真實存在的位置和真實發生的現象
- 不拿同一個問題換說法來湊數
- 設定上限
另外說明一下，一則1日圓只是這次實驗的設計，並不是通用的合理報酬。如果要請人長時間工作，或做專業評估，就得換成與時間和難度相稱的條件。
4. 最大的敵人是「我用AI生成了一萬條改善建議」
沒必要禁止使用AI。
問題在於，從沒看過網站就寫出來的改善建議。
「一般來說，網站的導覽應該更清楚。」 「來改善無障礙體驗吧。」 「來最佳化響應式設計吧。」
全都沒錯。
但全都不是這次想要的。
我想要的是這樣的觀察：
「這個頁面上的這個按鈕，按了會發生什麼，我看不出來。」 「這個標題後面，話題突然跳掉了。」 「只有這個語言版本，相關文章跳到了另一種語言。」
AI可以用來把這些觀察整理得精簡一點，或是合併重複的內容。
人發現，AI整理。
別把順序弄反，這一點很重要。
5. 要是一則一則用聊天傳過來，發起人會先累死
想讓回報數量變多，提交方式也得設計好。
最要命的是這種：
「第1則。」 「第2則。」 「對了，還有第3則。」 「再補充第4則。」
聊天紀錄會沒完沒了地一直往下拉。
這樣一來，明明把除錯外包出去了，卻冒出了收回報這項新的手工活。
所以統一一次提交。
- Excel
- 線上試算表
- txt
- 有編號的清單
- 可以直接複製貼上的文字
什麼都行。
截圖原則上也不需要。圖片看起來方便，但之後要搜尋、去除重複、交給AI處理時，阻力很大。
GOV.UK的使用者研究指南也提到，打字記錄的筆記方便日後保存和分析，把一個觀察拆成一個項目，也更方便排序和分析。[3]
格式簡單就好。
位置 / 現在是什麼樣子 / 怎麼改比較好
如果是bug，就寫：
位置 / 做了什麼 / 發生了什麼
光是這些，後面的AI就能幫上不少忙了。
6. 在多語言網站上，「翻出來了」和「真人讀得懂」是兩回事
多語言網站就更有意思了。
從機器的角度看，12種語言全部生成成功。 建置成功。 HTTP 200。 連結也都存在。
可真人一看，照樣會覺得彆扭。
- 有一部分還留著原文的語言
- 只有按鈕的翻譯很怪
- 句子意思說得通，但母語人士讀起來不自然
- 文字變長，版面跑掉
- 切換語言後，只有相關文章變回了原來的語言
- 明明是同一篇文章，卻少了一部分
這個只需要看得懂那種語言的人去看就行。
看得懂英文的人看英文。 看得懂韓文的人看韓文。 中文、西班牙文、葡萄牙文、印尼文、泰文、越南文、法文、德文也一樣。
不需要讓每個人把所有語言都看一遍。
機器確認「生成出來了」，真人確認「這個正常讀得通嗎」。
分工不同。
7. 重複的回報，以報酬來說算1則，但對分析來說極其重要
同一個人如果寫了
「按鈕不好懂」 「按鈕的意思不明白」 「這個按鈕是什麼？」
三次，算1則就行。
但如果是三個不同的人，各自獨立地在同一個按鈕上卡住了，情況就不一樣了。
這就不是單純的重複，而是可以重現的摩擦。
所以統計的時候要分開處理：
- 同一個人的不同說法 → 合併
- 不同的人獨立提出的同一個問題 → 當作次數保留
「三個人在同一個地方迷路了」，比經營者的個人喜好有份量得多。
GOV.UK也把「經常向真實或預期的使用者確認可用性，並在反映使用者行為的各種裝置上測試」寫進了服務標準。[4]
增加人數的意義不是「用意見投票」，而是看同樣的摩擦會不會在別人身上也發生。
8. 最終型態是 AI → 真人 → AI，真人成為感測器
最終的流程相當漂亮。
- AI產生文章
- AI翻譯
- AI檢查連結、結構和顯示
- AI修復已知問題
- 真人實際去讀、去按、去迷路
- 真人把「怎麼怪怪的」寫成文字交上來
- AI合併重複項目
- AI依嚴重程度、可重現性和修復成本分類
- AI產生修復方案
- 修復後，再回到機器檢查和真人確認
終於，連人也成了流水線上的一道工序。
不過，留給人的不是單純的體力活。
而是察覺只有人才會感受到的摩擦。
這反而更像是一次升職。
讓機器去看「連結是不是404」，讓真人去看「不是404，但不明白為什麼被帶到這裡」。
讓機器去看「翻譯的字串有沒有」，讓真人去看「有是有，可是一般人不會這樣說」。
這樣分工才自然。
9. 測試的人一看，瀏覽量也會漲。但別把它當目的
當然，讓人看上幾十個頁面，瀏覽量就會增加。
如果是有廣告的網站，隨著正常的瀏覽，廣告也可能會被顯示出來。
不過這完全是副產品。
讓人去點廣告，或是把增加廣告曝光量訂為工作條件，那就是另一回事了。
我買的不是瀏覽量。
而是真人看過頁面之後留下的觀察。
順帶流量漲了一點的話，就當作「做使用者測試的時候，收銀機也順便響了兩聲」，這樣想正剛好。
10. 自動化的終點，並不是「零人力」
一開始用AI，總忍不住想「能把人去掉到什麼程度」。
可是真把自動化推下去，有時會得出相反的結論。
不需要把人全部去掉。
只要把人移到只有人才能創造價值的地方就行。
文章草稿。 翻譯。 整理重複項目。 檢查連結。 分類。 統計。 修復方案。
這些都交給機器。
然後到最後，
「第一次看，不知道是什麼意思」 「這裡我不喜歡」 「怎麼怪怪的」 「這個滿方便的」
只向真人買這些。
一則1日圓買的，不是一行文字。
而是我自己和AI都沒有的、另一個人一瞬間的違和感。
把自動化做到極致之後，人又回來了。
而且負責的部門是「怎麼怪怪的」。
太有人味了。
出處
參考資料（4筆）
- Digital.gov, “Usability testing digital.gov
- GOV.UK Service Manual, “Using moderated usability testing gov.uk
- GOV.UK Service Manual, “Taking notes and recording user research sessions gov.uk
- GOV.UK Service Manual, “4. Make the service simple to use gov.uk
