在 alpha 及 beta 階段的使用者中心設計 (User-centred design in alpha and beta)

在專案的每個階段進行使用者研究，且持續進行，不管是專案哪個階段都應該進行使用者研究。千萬別把使用者研究當作是專案開頭的某種儀式，更不應該在專案結尾時拿來背書。持續進行使用者研究能帶來這些好處：

• 讓你的團隊專注於真實的使用者需求
• 幫助團隊優先設計使用者較關切的需求
• 幫助團隊善用使用者的回饋並改善產品

設計師和研究員都是不可或缺的

每個團隊都需要有設計師和研究人員一起工作，同時積極關注設計和使用者洞察。兩者一起工作，並非指使用者研究員去”測試”設計師的工作結果。設計師和研究人員共同工作的意義是：

• 他們共享從使用者那裡收集回來的知識，所以每個產品的設計都被真實使用者的看法所修正。
• 研究人員定期提供的更多資訊以及回饋，幫助整個團隊快速地修正產品，決定優先順序，盡可能地創造最好的產品。
• 他們共同合作並且不斷地實驗，透過測試以證明設計方案是否能夠讓使用者輕易理解，及渴望擁有

請確保你至少有一個團隊成員主導研究，但不要讓他脫離團隊。他們還可以做其他工作（設計，撰寫內容等），但至少每2個禮拜負責進行一次使用者研究，這是所謂的「雙週測試」規則。

在設計迭代裡的研究

不要花超過2個星期的工作在設計上，卻沒有與真正的終端使用者進行測試。「雙週測試」的迭代應包括三個階段：

• 建立
• 衡量
• 學習

圖說：每兩週一次迭代過程概念草圖

建立

每一次的設計迭代過程，都應該把下次研究要用到的材料納入設計範圍之中。在 alpha 和 beta 階段可以設計不同精準度的原型，從紙本原型 (paper prototype) 到電腦中實際運行的程式原型。

使用現有的 GDS代碼 或其它開源框架的好處：

• 可以快速地建立包含設計概念的程式原型
• 程式原型通常會比紙本原型得到更明確的使用者回饋

不管做多少種原型，它們終究會被拋棄，幫助我們嘗試錯誤釐清需求是它們的使命，千萬不要覺得捨不得。能夠越快速建立大量的原型，對產品與服務的設計越有幫助。如果能抱持這種心態，將會創造出探索各種不同設計概念的自由空間，以及幫助團隊了解什麼樣的設計是對終端使用者最好的。而且，最好在專案早期階段就能夠開始投入實驗與研究。

在專案早期階段，粗糙的原型看起來不像是個完成品，設計也可能還很糟，這些都沒有關系。堅守「雙週測試」的規則，不要拖到你對設計完全滿意，或終於覺得自己做完了才開始進行使用者研究。

在進行使用者測試的 24小時之前，盡量保持原型的完整性，有助於兩件事：

• 留下一些時間微調原型
• 降低研究過程的失敗風險

衡量

使用者研究與實驗方法很多，有助於設計團隊去釐清整個使用脈絡與環節的問題，包括：使用者，設計概念，以及產品與服務本身的各種問題。

你的研究員能夠針對每個問題選擇最棒的研究方法，透過研究員的協助，一個專案最後可能會用上許多不同的研究技巧。再提醒一次，無論是哪一種專案，一定要堅守隔周就做一次使用者研究的「雙週測試」規則。

隔周使用者研究 (例如：週二測試日)

進行使用者訪談時，可以做這兩類事情：

• 讓真實使用者和設計成品或原型進行真實互動 (易用性測試 Usability Testing)
• 對你想探討的任何具體問題，進行深度訪談以收集更多息。(一對一深訪可以挖掘出使用者需求及行為的深度洞察)

每隔周的同一天舉行使用者研究，有了固定週期，團隊成員就更容易安排時間，來參與或觀看訪談或易用性測試。

通常可以這樣子安排：一天安排 5 場一對一訪談，每位受訪場次時間約為 1 小時。安排第 6 位受訪者作為備取人選，因為有些受訪者可能會臨時放你鴿子，甚至會遇到完全不適合的訪談對象。

這些地方都可以安排訪談：

• 辦公室或會議室
• 正式的研究實驗室（如果沒有現成的，試試外部場地）

若已經知道要進行 alpha 和 beta 測試，那麼越早進行設備場地的預約，越早招募收訪者越好。

在訪談進行之前

在準備使用者研究計畫的時候，需要留意這些項目，通常可以跟你的研究員一起討論：

• 定義研究問題 – 想從這一輪的使用者研究中了解什麼？
• 先準備好各種關於設計的假設，例如：改變按鈕字體大小會導致人們更仔細的閱讀。
• 先想過如果這些假設成立或不成立的話，代表甚麼意義。例如，因為人們花更多時間在閱讀頁面，你會知道假設是正確的。
• 確定受訪者的類型，以及人口統計基本資料：
  • 年齡
  • 居住地點
  • 適合的任務
  • 其他因素
• 至少在訪談的一星期前，開始招募受訪者（GDS 建議你透過招募機構尋找受訪者）
• 準備研究流程說明，用來介紹訪談會議如何進行，研究成果如何產出
• 請受訪者簽署授權同意書，同意你將訪談過程影像或聲音記錄下來
• 發出會議邀請給團隊成員，邀請並強烈鼓勵他們參加使用者訪談的觀察與討會
• 安排例如線上直播串流的會議(例如：GoToMeeting)，讓不能親自出席的團隊成員仍有機會可以觀看訪談研究過程

訪談研究之前，先準備好研究用的原型：

• 可以讓使用者看
• 可以讓使用者完成研究觀察的操作任務
• 確認場地現場狀況（如網路連線，防火牆限制，螢幕解析度，瀏覽器，輸入法，紀錄設備等）

訪談進行期間

在每一訪談場次上，要留意這些：：

• 確保訪談過程順利被記錄下來
• 確保現場直播可供外部瀏覽者觀看
• 在心裡不斷從頭到尾複習的訪談大綱，加強記住研究訪談的重點
• 寫下重要的觀察筆記
  • 使用 (夠黏的) 黃色便利貼寫下觀察記錄
  • 每張便利貼只記錄 1 點觀察
  • 用麥克筆/簽字筆書寫紀錄，有助於分析時的閱讀（如果以英文書寫，最好用大寫字母紀錄
  • 如果你不知道它是否重要，還是把它寫下來
• 設法完成訪談逐字稿，不管是訪談當天完成或之後

完成一天的訪談研究之後，還有很多分析工作要做。在進行設計任何重大變更之前，應該仔細分析這些訪談觀察內容。分析階段將在下面詳細說明：

游擊式研究 (Guerrilla research)

可以善用每次正式實驗間隔空擋，進行一些游擊式的測試，快速獲得設計更動的初步回饋。

游擊式的研究通常包括把原型帶到咖啡廳或其他公共場所，邀請一些自願者給予快速回饋。游擊測試的參與者並不一定需要代表你目標受眾的人，而是在進行正式實驗期間，取得一些簡單地直覺地使用者回饋。

其他研究方法

還有許多其他的研究方法可以讓你補足”個人”質性研究中的不足，並解決具體的研究問題。使用不同的研究方法可以在特定的問題中得到更好的洞察，或是驗證下一個星期訪談研究中得出的假設，是否在針對大眾使用者時也仍然正確。

這個 各種研究方法列表 ，提供了一些相關技術，以及你應該如何以及何時使用的基本介紹。

學習

現在該是時候來看看你可以從使用者測試研究中學到什麼了。藉由下列原則中，儘可能地應用你從訪談研究中得出的資料：

• 分析
• 分享
• 溝通

分析

經過了一天的使用者研究測試，收集很多使用者回饋後，適當地匯整團隊成員的看法與意見，是相當重要的。

這需要花你一些時間來詳細分析訪談內容，經過這個過程你會得到：

• 彙整所學到的訊息，形成更清晰輪廓
• 知道什麼會對設計產生影響
• 能夠確保重要的觀察結果不會遺漏

親和圖排列 (Affinity sorting #1)

要正確地做到這一點，你需要：

• 收集所有觀察過程產生的便利貼，並將它們貼到一面大牆上
• 將類似的觀察組織成主題群組
• 為每一個主題群組寫下洞察 (能總結觀察發現的扼要描述)，用便利貼寫下來，並貼到每個群組的最頂端。
• 試著去描述理論，並且判斷該理論是否有夠多證據證明其成立或是不成立
• 記下需要進一步做質性研究/量化研究的假設

在這個階段，你的目標在於建立一套完整的洞察 (這段時間觀察到，學習到的東西)，所以不要太早開始提出解決方案。整個團隊都應該保持這樣的分析過程幾個小時。

和任何觀看，參與使用者實驗的人一起合作，這將會幫助到：

• 收集各種發現
• 確認他人觀察到的東西
• 對觀察結果達成共識。

圖說：將便利貼以親和圖法 (Affinity Diagram) 整理在牆上

行動

決定你要如何處理每個發現，那些已經過證實的理論，要好好記錄下來，並且分享給專案團隊成員。

如果有任何發現是需要進一步的行動，決定在下一個迭代中需要什麼步驟，那麼就寫在橘色便利貼上，並且貼到所有便利貼的頂端。

優先順序

當你決定採取何種行動，使用優先排序的方法（如 以小紅圓點貼紙投票 ）來決定你在下一次迭代中需要花費的心力。

分享你的發現

將使用者測試與研究結果，儲存在專案團隊容易找到的地方，同時你自己也很有可能回過頭來看：

• 記住你發現了什麼
• 看看是否有一個特定的主題或功能已經涵蓋整個設計迭代過程

你可以用很多不同的方式記錄你的發現，並分享給其他人看，例如：

• 共用文件
• 網誌
• 故事牆（如Trello ）
• 研究目錄

你如果能保持記錄你測試了使用者哪些東西，也將會是很有用的，例如：當你使用程式原型時，每一輪都使用一個資料夾保存你的程式庫您可能也會希望保留著原型的螢幕截圖。

GDS 打算建立一個通用的分享格式，方便所有的政府專案彼此之間共享研究成果。當 GDS 仍在這項工作上面做出最好努力的同時，你應該要以容易取得且容易分享的檔案形式保存你的發現，以便於可以在將來分享以及學習。這些發現應盡可能的淺顯易懂，在無需更多的解釋下就能被人所理解。

將你的工作步驟添加到故事牆 (例如 Trello)上，使整個團隊可以清楚地看到你在做什麼，誰又正在處理甚麼。

影片

用影片來展示你的發現，並且存放在安全的地方（理想上專案成員可以觀看它們。）如果儲存影片在公共網站上（如 Vimeo），必須確保它們有足夠的安全保護。

溝通

你需要和其他人討論專案和其進度。你可以這麼做：

• 定期展示/簡報
• 經常發表設計
• 回顧

展示

正如同產品部門總在每個迭代結束後展示他們的成果一樣，研究和設計部門也可以定期展示。這將確保更廣泛地團隊理解以下項目：

• 正在進行的研究和設計工作
• 已經從研究中了解到了什麼
• 研究會如何造成目前服務設計的改變

這同時也是個很好的機會，幫助專案團隊中未能參加使用者研究的成員補足進度，並有機會提出問題。 你可能會根據你團隊實際的工作狀況，針對整個產品部門演講，或是僅針對研究以及設計部門進行。

考慮更遠的利害關係人

除了你目前直接的團隊成員外，很可能有其他人也關心你工作的成果，所以你可以藉由下面幾點和這些人溝通/或共同合作：

• 邀請他們參加展示
• 發佈網誌
• 維護共用文件
• 定期發送新的電子報，用原型的截圖，幫助人們看到什麼已經被測試了。

按照現況發佈設計版本

使你的團隊成員可以取得最新的設計版本，並做好相關保護，團隊成員可能會需要和其他利害關係人使用設計原型確認一些細節
。要記得在原型設計上清楚地記錄訊息，提醒看到設計的人們，這是僅是目前進展的工作而已。

回顧

每隔一段時間就定期地回顧你的進度是非常重要的。安排一個回顧會議，讓研究和設計團隊的成員都有機會能夠坦白的地討論以及建議。指派負責人和應該完成的時間確保改善被正確地執行。

譯注：
#1 親和圖法 (Affinity Diagram)，又稱 KJ 法，是整理資研究資料的一種方法，藉著Bottom-Up的過程逐漸將細碎資料形成可理解的結構，能幫助設計團隊共同合作產出創新構想，並釐清複雜的問題。親和圖法 (Affinity Diagram)是一種分析資料方法，本身與與親和性 (Accessibility) 沒有關聯。