常見問題集 FAQ 如何協助產品團隊更成功？三大妙用與實作工具分享！
FAQ（Frequently Asked Questions、常見問答）頁面是現在每個線上產品都會有的頁面，主要目的是為了讓使用者在遇到操作上的問題、或是還在考慮使否要使用該服務時，可以自己找到多一點資訊參考。
有些產品還會有使用守則（User Guide）、使用情境分享（Use Cases）在官方網站上，希望可以不用透過客服協助，讓使用者自己可以去嘗試使用產品（Self-Service），這些頁面在功用上都是大同小異的。
在我待過的團隊中，FAQ 通常都由客服團隊、營運團隊來負責撰寫與維護，大多是有新功能、邏輯改動時才趕緊加上去，產品團隊平常其實很少去關心 FAQ 到底寫的如何、有什麼可以改善的地方。
在這邊我想要分享一些跟其他團隊討論時發現的、或是在做產品研究時受到啟發的 FAQ 使用方式，以及為何我們應該要更重視這個區塊。
【文章目錄】 ✔ FAQ 妙用一：作為使用者旅程的一部分 ✔ FAQ 妙用二：蒐集使用者研究與測試的輕量化數據 ✔ FAQ 妙用三：寫產品規劃文件時偵測漏洞的小幫手 ✔ Help Center 實作工具推薦
這篇提到的 FAQ 其實更趨近於 Help Center、Knowledge Base 的概念，不過因為我跟團隊都已經習慣稱它為 FAQ 頁面，大家就將就著看吧～～～
▍FAQ 妙用一：作為使用者旅程的一部分
1. 為新用戶設計的資訊架構
使用者：註冊/試用前，我想要先看看這個產品到底能做些什麼。
有一些使用者很討厭註冊無用帳戶、或是正在比較多個同類型的產品但還沒下決定，因此認識產品的流程並非註冊後直接試用。（當然也有很多產品無須註冊就能使用）
這些使用者認識產品的流程可能是從網路論壇的推薦與功能比較、官方網站的「功能介紹」「成功案例」頁面、或是從 FAQ 來尋找他問題的答案。因此，我們可以試圖在 FAQ 頁面中也設計一套簡單易懂的 Onboarding 流程，讓潛在使用者的體驗在最一開始的接觸點就被照顧到。
除了用「功能區塊」來分類外，也很建議提供「新手上路」「超常見問答/熱門文章」專區。
行有餘力也可以設計針對不同類型使用者、使用情境的區塊，例如 B2B 產品可能有多種功能和多種費用與計畫，就可以設計專門給個人工作室、中小企業、大型企業 … 等的區塊，將對這群人、這種使用情境下最重要的 FAQ 文章列在其中，讓使用者可以很快有個總覽，而不會被不必要的資訊干擾。
如果想知道如何設計資訊架構、啟動一個 FAQ 優化專案，我推薦這篇文章：
2. 為現有用戶提供不中斷的使用者旅程
使用者：咦？看不懂這個畫面欸，我是不是操作錯誤了？
最理想的使用者體驗當然是一整個流程順順地走完，中途沒有任何疑惑與差錯；然而事實就是產品很難設計得讓所有人都滿意並充分理解使用方式。無論是畫面的階層與架構設計不好、顏色的使用讓人困惑、文字與文案不夠清楚，都可能會讓使用者暫停一下，思考片刻。
最糟的狀況就是，畫面上完全沒有任何提示或輔助工具，導致使用者直接放棄離開；次糟的是，使用者停下原本手邊的工作，另開新頁，打開客服系統或 FAQ 頁面查詢，查完再回去原本畫面繼續操作。
好一點的作法，可以嘗試將 FAQ 內容做成 tooltip 同步串接於產品各處，當使用者困惑的時候，可以將滑鼠移到小小的 (i) 上，我們可以顯示一句話的小提示跟 FAQ 連結。當然有很大的機會使用者還是會跳出去看 FAQ 再回來操作，但是你會知道：
- 他是從哪個操作畫面跳出去的？——表示我們那個頁面可能真的做得不好，值得優化。
- 跳到我們指定的 FAQ 後，他是否還有繼續查看其他 FAQ？——表示我們該篇 FAQ 可能寫得不夠清楚，或是應該連到另外一篇才更能解決使用者當前問題。
如果是想要避免使用者跳出頁面，也可以使用 modal、slide panel、chat box 等設計方式，將 FAQ 直接嵌入產品頁面中，讓使用者可以在同個頁面一邊操作一邊觀看說明。
當然嵌入的作法也可以完全跟現有的 FAQ 架構沒有關係，而是每次設計流程、功能或頁面的時候獨立設計文字與內容。但我個人很討厭重工、要去多個地方維護差不多的內容，所以比較喜歡兩邊串接起來，這樣其他團隊想要改內容的時候也不用過 deployment 的流程，省事很多。
▍FAQ 妙用二：蒐集使用者研究的輕量化數據
1. 現有產品的優化
使用者：這有夠難用，我都要把這頁 FAQ 加入我的常用書籤了。
FAQ 畢竟也是個很多流量進出的地方，追蹤使用者行為與紀錄數據也會對產品決策很有幫助。
檢查現有 FAQ 頁面中哪些分類或問題的流量最高、低、異常，就可以拿來提出一些假設，例如：
- 流量高，因為這個功能很重要、很多人在用。
- 流量高，因為這個功能做得很爛、沒人懂那個介面，第一次使用的時候一定要看 FAQ 才懂。
- 流量高，因為操作步驟比較複雜，即使之前已經操過過同個功能，下次要用時還是想要再看一下 FAQ 確認自己沒設定錯誤。
- 流量高，因為 SEO 做得很好，很容易被使用者搜尋到。
- …
再拿著根據 FAQ 數據提出的假設去跟核心產品的數據做對比，並搭配其他研究方式來驗證，找出值得優先調整的部分。這邊的調整，可能是產品本身的優化，也有可能只是 FAQ 內容的優化。
2. 新需求的前期研究與測試：投票功能與假門測試
使用者：摁…來查查看這個產品有沒有這個功能好了！
另外我還看過的一種做法是將「現在還沒有的功能」也放在 FAQ 當中。
【文章標題】功能名稱 【文章內文】嗨，我們現在還沒有這個功能，但我們知道你們很想要！如果你也想要，請點選『投票』，或是聯繫我們的專業客服來說明你的需求唷！
依據投票數量多寡，產品團隊多了一個「使用者渴望程度」來排序優先級；原本一些被動查看功能的使用者，可能會開始主動提供使用者回饋；同時也可以避免新使用者發現產品沒有該功能就直接離開，若可以讓他們轉而去跟客服聯繫，我們就多了一個接觸使用者、說服他留下來的機會。
另外一個類似的用法是用於假門測試（Fake Door Testing），一般的作法是製作一個 Landing Page 來搜集有興趣的 beta 測試用戶名單。用 FAQ 的作法其實大同小異，只是入口處放在 FAQ 裡面以節省額外製作專門頁面的成本，同時等到功能真的上線後也可以直接繼續使用該 FAQ 頁面。
【文章標題】[新功能即將上線] 功能名稱
【文章內文】內文就是依據我們目前規劃的想法來寫一篇跟真的一樣的 FAQ 說明。最後再附上：「如果想要搶先試用，歡迎告知我們的客服人員/歡迎輸入您的 email 或使用者帳號，將會有專人為您服務/我們將會為您優先開啟功能試用！」
這個專人的服務呢，其實就可以去做使用者訪談，了解我們目前的規劃是否有滿足該使用者的需求，並且幫助我們找出第一批態度積極主動的 beta 測試用戶名單。
當然，直接邀請使用者在 FAQ 頁面提供產品回饋的也大有人在。
這個「讓使用者自行提出產品需求」的功能也可以放在 FAQ 的「搜尋結果頁」，當搜尋結果頁沒有找到任何相對應的文章，則可以讓他們自己提交想問的問題或需求。
▍FAQ 妙用三：寫產品規劃文件時偵測漏洞的小幫手
既然前面提到了用 FAQ 來做外部測試，這邊想分享的則是拿來做內部測試。
這是從我某位產品主管身上學來的招數，他在寫比較複雜、範圍比較大的產品需求文件（PRD）、產品規劃與規格書（specs）時，當跟設計師、工程師已經討論出一個初步的解法，他也會同時寫一份假想的 FAQ 出來，想像當產品正式上線後，要怎麼向使用者、利益關係人解釋與說明。目的是：
- 自問自答，檢查自己是不是能回答所有自己假想出來使用者會有的疑問、解決方案有沒有不合理的地方，同時記錄下一些產品團隊討論過的問題。
- 分享給其他 stakeholder 例如客服、業務、行銷團隊。與其叫他們幫忙看 specs 來給回饋，不如讓他們閱讀假的 FAQ 看看跟他們想像的有沒有出入、是否有漏掉任何重要的議題，同時瞭解他們認為客戶或使用者會不會有其他疑問。
- 若大家都認為沒問題，各部門其實就可以根據這份 FAQ 的內容來著手進行各自的工作，例如：行銷團隊寫功能推廣文章、業務團隊寫客戶手冊；而等到產品改動正式上線的時候，這份 FAQ 也可以直接拿去給客服或營運單位使用，他們就不用從頭開始寫了。
一般的對外文件，例如正式的 FAQ 通常都會有 proofreading 的流程，確認內容、文法、用字遣詞有沒有問題，而我認為這份假的 FAQ 其實就很類似於產品還沒開發前的輕量級 proofreading 流程，對於風險比較高或是範圍比較大的產品改動先做一次內部的健康檢查。
▍Help Center 實作工具推薦
前面介紹了滿多使用情境的，那究竟要如何實作呢？
FAQ、Help Center 當然可以由團隊內的工程師自己開發，不過我個人更喜歡用外部工具。一來是我認為開發團隊的重心應該放在產品的核心價值、而非輔助工具，二來是外部工具的功能通常都很完整，用起來很爽快！
以下推薦一些我用過、或身邊有朋友用過的工具給大家參考：
以上，希望大家都能更重視這塊有價值的璞玉！
謝謝你的閱讀！如果有任何回饋或有興趣的主題，歡迎留言給我們 📒
如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-30 個拍手；
如果想看更多實務操作的分享，請盡情長按拍手（max 50）讓我們知道 👏🏻想要持續追蹤我們的最新文章，請記得追蹤「產品三眼怪實驗室」(◉◉◉)！
我們每週末都會認真更新文章唷！千萬別錯過了～