開發者 Terence Eden 為了改善其開源專案 ActivityBot 的安裝體驗，申請了 NLnet 補助，並承諾測試真實使用者的安裝流程。他透過 Mastodon 招募志願者，每人支付 25 歐元作為一小時的時間補償，並透過視訊會議進行測試。測試格式要求參與者共享螢幕並「邊做邊說」（think aloud），詳細描述他們的操作、困惑、挫折或滿意之處。Eden 手動記錄筆記，並在每次測試後根據反饋更新 README，再讓下一位參與者測試，形成迭代改進過程。總共支付了約 150 歐元。
透過這些測試，Eden 發現了多項具體的文件問題，包括： 1. 示範工具的連結錯誤。 2. 部分使用者會在終端機中閱讀 README。 3. 使用者不清楚「重新命名檔案」的具體含義，特別是隱藏檔案的重命名方式。 4. 對於示範工具應該僅在本地機器可用還是也應提供網頁版感到困惑。 5. 不清楚為何某些文字需要加引號而某些不需要。 6. 作者認為幽默的玩笑實際上令人困惑。 7. 部分技術術語需要額外解釋。 8. 章節順序令人困惑。 9. 文件中實際上沒有解釋軟體的功能。 10. 一個對作者來說技術上有趣的章節，對其他人來說完全令人困惑。 11. 並非所有 Web 伺服器都以相同方式使用權限。
Eden 強調，雖然他承認 ActivityBot 的 README 並非完美，但經過這些測試後已明顯更易於遵循。他反對僅使用大型語言模型（LLM）來模擬使用者，因為他認為與真人對話能帶來獨特的視角、情感反饋（如語氣中的挫折感）以及不可預測的價值（如看到對方的貓）。他建議開發者即使無法付費，也應尋找願意邊操作邊口述的人來測試文件，因為這能顯著提升文件品質。
事件背景
ActivityBot 是一個申請 NLnet 補助的專案。Eden 過去曾為 GOV.UK 進行技術寫作，當時他的文稿會經過另一位人類編輯的審閱，這些編輯能發現拼寫檢查器無法捕捉的錯誤，並透過對話中的語氣挫折感來指出需要修正的地方。
社群觀察
社群討論中，多位評論者共鳴於文件經常未能說明軟體實際功能的問題。用戶 andai 指出，許多專案頁面（如 Gleam）僅使用模糊的行銷用語，缺乏對軟體功能的清晰說明。用戶 extralongdivisi 也表示，許多 README 僅堆砌流行詞（buzzwords），使用者必須透過示範才能理解軟體用途。用戶 bryanhogan 指出，這種方法論在 UX 設計領域被稱為「可用性測試」（usability testing），並引用了 Nielsen Norman Group 的相關指南。用戶 bambax 則分享了自己撰寫個人筆記時，發現即使是自己寫的步驟，過幾週後也會變得難以理解，因為當時所有邏輯都在腦中是自明的。
