這本書到目前為止我看了一半了，但是其實覺得有點空虛。
至少在這看完的一半裡面，有2/3幾乎是沒有任何啟發性的內容。
怎麼說呢，也許該用比喻的方式，假如有一段文字是這樣的，不知道你們看完以後做何感想。
=== 這是比喻的分隔線===
標題:
如何成功在家準備好一場小趴踢
內文某段:
一個好的主人，絕對都知道成功的水煮蛋，是趴踢的關鍵。"
然後沒有教你怎樣做出成功的水煮蛋，連什麼樣的水煮蛋叫做成功，都不說清楚...
=== 這是比喻的分隔線===
我想我這個比喻有點離題太超過，不過反正我看完以後的感覺就是有看等於沒看。書裏告訴你從事UX工作有哪些方方面面(這裡好像應該有"該注意"三個字對吧? 但是我覺得我不該把這三個字寫上去，因為作者只說有哪些方方面面，沒跟你說該怎樣注意)。
(後記: 上面這整段文字是在看完前半本的時候，難忍心中的不耐，所以寫上發洩一下。耐著性子把後半段整本書看完以後，發現後半段條列的各種方式，雖然我們有很多都耳熟能詳，但是作者將它們的使用時機和方式進行歸類以後，的確覺得讓人很有收穫，所以筆記越寫越開心。)
不過看著看著，很高興我終於看到條列式的東西，覺得多少有些用途，所以就開始做筆記。做著做著，想想乾脆寫篇blog吧? 於是這篇就這樣來了: 是的，我在辦公室寫blog。
Chapter 5: 進行UX初期，規劃探索的幾種方法
- UX Questionnaire
- Team - 列出整個執行team的組成。負責人員、管理階層、開發人員、DevOps人員等。可以的話，列出每個人(或小組)負責的內容有哪些
- Goals - 簡要列出這個專案的目標，最佳的結果是只有三到五個目標。如果這裡出現太多目標，那表示大家對這個專案的期望過高(多)、野心太大，最好做一下調整。
- Users - 目標使用者，可以有一類以上的目標使用者，最好說明為何那些使用者會怎樣使用，說明針對那類的使用者，我們期望達到哪個目標。這個目標使用者不應該是寫上"所有人"這樣廣泛的東西。
- Strategy - 產品的優勢為何? 為何使用者不使用別人的東西卻要使用你的產品? 產品的利基是什麼? 遠景是什麼?
- Tasks and scenarios - 例如，列出主要功能的大流程方塊。像是 "查看建議清單" - "加入到我的
- 清單" - "做完了以後勾選掉"。
- Success measures: 這裡望文生義，不說明。但是要說明"用什麼樣的方法來驗證是否達成" 或是 "到什麼樣的數字表示達成"。
- Key dates and milestones - 望文生義。
- Risks - 在這個階段你有看到什麼明顯的風險了嗎?
- 以上項目，可以在經過整理之後，成為"Project Brief"的一部份。
- UX Project Plan - 這個是針對整個專案執行過程中，UX所要介入的時機的計畫。
- 首先確定你自己了解專案的目標 - (照理說做了Project Brief的話，那裡面已經包含有了這個了。
- 腦力激盪出各種相關的方法 - 針對專案的目標，盡可能思考出各種可以朝向這個目標前進的方法。每種方法可以大致列出其中的流程和必要步驟。
- 預估所需時間 - 針對上面腦力激盪出來的每個方法，預估每種方法所需耗費的時間。
- 設定里程碑 - 針對專案的時程(如果原本有被要求)，設定一些中間的里程碑，必且依照預估的時間檢查里程碑有沒有可能達成。
- 建立出一份簡單的文件 - 以 ["所需時間(例如兩週)", "內容(做什麼)", "產出結果", "參與人員"] 這些欄位為橫軸，產出一份表單，或是做成甘特圖，當然，直接畫在有日曆大白版上也可以。
- 以上五個步驟執行完畢之後，最好再額外產出一個查核清單，以 ["內容", "預估時間", "複雜度", "最差所需時間", "風險"] 這些欄位為軸。
- Listening Tour - 適用於你是空降參與某個專案。列出你要了解的事情(每個人的特長、工作狀況、對UX的看法、對專案的期望、他們認為專案該如何執行)，然後先把這些問題發給所有受訪者。平均每個受訪人員約半小時。
- Opportunity Workshop - 望文生義。通常使用這個的原因是你自己一個人想不出來目標、方法等，期望眾志成城。執行步驟如同常見的腦力激盪模式。這份結論可以拿去在進行前述的"訪談法"裡面使用。
- Project Brief - 適用於專案最開始時，或者你被丟到某個原本早已緊密合作的團隊之中擔任UX角色時。主要是製作一份文件，包含 "商業分析","使用者需求", "目標", “主要期望(針對專案或公司成員對你的期望，期望你來解決什麼事情"。然後做成文件以後發給每個相關人員看，並且不時追蹤這份文件是否需要更新/有沒有事情脫節了。這份文件可以的話，儘可能緊單、只要一頁就好。例如針對專案列出一份 "Vision(Why)", "Requirements(What)", "Design Principles(How)" 這樣的文件即可。
- Strategy Workshop - 這種方式，主要是要激發參與人員對產品的未來創造想像，透過這個未來的想像來思考專案應該專注在哪個方向。所以可以使用常見的各種腦力激盪會議模式進行。(2x2 Kano Model, Mood Board, Story Board,...等)
如果你的時間不太多，那麼建議執行Listening Tour。
Chapter 7: 設計的方法 (Design Methods)
- Design Brief - 最適合做來讓全部內部人員明確知道產品的現在以及將來、產品注重的是什麼、目標是什麼。盡可能做在一頁圖文並茂的頁面中即可(最好是長得像常見的那種圖文很多的多欄式DM，可以印出來發送更好)。內容應該(最好)包括
- 關注點(Focus)
- 受眾
- 特色與功能
- 使用者所獲得的感受
- 限制與期望
- Design Principles - 設定一些設計準則(我覺得比較像是中心思想的概念)，當作產品的方向。可以是條列式。準則設定好之後，後續的所有設計開發，都應該依照這些準則為出發點。在這些準則之下所衍生出來的、後續添加的，由於有了準則規範，因此可以確保你的產品的使用者體驗有前後一致性。建立準則時可以用以下步驟參考:
- 想想看是什麼部分，讓你所做出來的東西獨一無二。
- 把想出來的東西條列出來。注意，不要寫得太通用。像是"使用者友善"、"簡單易用"...這類的，這種準則沒太多幫助。可能有用的準則像是: "用起來跟普通電視一樣"。
- 縮減這個清單到五條以下。如果有太難割捨的，想想看有沒有可能把其中的幾條用不同的表達方式濃縮成一條。
- 為這些條文找一張或多張相關的圖片(有點像是勵志圖片的味道)。然後為每個條文做一些簡短的說明，就像製作PPT一樣。
- 把這個準則分享給團隊成員，進行必要的討論，收取建議。
- 經常三不五時回頭看看新的狀況是否符合準則，或者是準則需要修正。
- Sketching - 我的天啊，這本書竟然詳細說明準備什麼樣的筆、哪一種紙來做簡單的產品規劃塗鴉...
- 進行提塗鴉時，當完成某一個版本，然後你看著這個版本的塗鴉，你也許發現這個版本有太多文字。那麼你可以再做一個版本是盡可能用圖案表達的。然後到後面再來從各種版本之間擷取適當的元素混合。
- Sketchboard - 把你的sketching拿來全部貼到特大號的紙上或白板上，進行思考和討論。
- Task Flow - 使用wireframe的圖形，描繪出執行某件事情的整個流程。
- Top-down方式
- 使用者最先碰到的應該是什麼?
- 起點在哪裡?
- 這個產品的主要部分是什麼?
- 最先出現什麼，接著使用者逐步深入產品時會發生什麼事情?
- Bottom-up方式
- "Moments of Truth" - 使用者在整個產品裡面接觸到的產品關鍵點: 也就是產品存在的目的。
- 思索到達moments of thurth的之前與之後有哪些流程。
- Scenario-based sketching: 前兩者的混合。思考使用者如何從起點(top-down)到達關鍵點(bottom-up)。
- 完成上面的分析之後，可以多想想是否還有其他的路徑，並且額外考慮一下若使用者在中途放棄時，產品該如何回應。使用者再次回來時(同一個裝置或不同裝置都有可能)，該如何處理。
- 提醒:
- 可以用便利貼來在白板上組合。
- 最好不要把整套系統全部完整畫在一張圖裡面，而是分開多張圖較好。
- 有時候會在不同的功能之間跳來跳去，此時可以使用"Service Blueprint"的圖形來額外輔助。
- Top-down方式
- Wireframe - (懶得筆記)
如果你的時間不太多，建議執行Sketchboards方法。
Chapter 8 - 測試與驗證的方法
- Paper And Interactive Prototypes - 也不一定真的就是紙筆，用繪圖軟體、PPT等都行。就是一般的互動模擬驗證。並非要整個產品全部驗證，主要要驗證的是一些關鍵部分。
- 如何選擇哪些項目需要做這個驗證? 可以使用Critical/Complex graph，在畫面右上區(Critical+Complex)的部分就是需要驗證的部分。
- Black Hat Session - 這個方法很有趣。關於Black Hat，要參照"Six Thinking Hats"的論述。Black Hat主要是從"懷疑產品"、"負面思考"、"給予評價"的方向來思考產品。例如，假裝你是有決定權的主管，然後跳進來任意判斷這個產品哪裡出問題。實施方式如下:
- 把prototype的各種圖，放在白板上。
- 找一些人，包含熟悉產品的以及對產品陌生的人。
- 給每個人一堆便利貼。
- (約15分鐘)請他們對每個prototype的想法寫在便利貼上，貼在prototype旁邊。想法可以包括:
- 你看著某個畫面時，是否了解到這個畫面到底在幹麻?
- 這個畫面帶給你什麼印象? 這個印象是否是"本就應該有的"? (我的假設是: 比如說，你要傳達一個節省的概念，結果給人的印象卻是貧窮...這就是不該有的)
- 你是否知道你要做什麼以便進行下一步?
- 你所見到的資訊和功能有沒有什麼問題?
- 你是否滿意於所需步驟數 (要花多少步驟完成某件事) ?
- 有沒有什麼東西你覺得太複雜、太累贅?
- 畫面上有哪些指引、按鈕等不合理?
- 完畢以後，對大家進行同步與討論。就像整理腦力激盪的結論一樣的處理方式。
- Black Hat Session的方法，其實可以在任何時候使用，而不只是限於最後驗證階段。其實在設計的會議過程中，如果大家發現卡卡的，也可以暫停一下會議，然後立刻進行小規模的黑帽會議，把事情理清了以後再繼續原本的會議。
- Quick-And-Dirty Usability Test - 望文生義，也就是"隨便抓一個人(你睜開眼睛看到的第一個不熟悉這個產品的人)“，然後問他你這樣的設計有沒有問題(他們看到了什麼、他們認為你的產品是怎樣運作的)。這件事情可以在任何時候做，並且盡可能多做。注意: 盡可能找的對象是潛在的用戶群，而不是知曉你產品的人。
- Five-Second Test - 給用戶看你的產品(畫面)五秒鐘，然後讓使用者不要再看(或關掉螢幕)。接著問他記得看到什麼、他覺得這個畫面的用途是做什麼。這種測試是的起因，是因為目前大部分人會同時在多個產品(軟體、App)之間進行切換，很容易分心，因此這個測試可以讓你知道你的產品在使用者的手上，使用者到底真實體驗到什麼。同樣的，這個測試也可以在任何時候做、並且盡可能多做。
- UX Health Check - 能協助你了解你的小組成員對於產品的整體看法，當然，也讓你了解。實施方式如下 (大約控制在一小時最佳):
- 準備好你的team，對，就是日常為這個產品工作的team。
- 把產品的功能分開列出。例如，註冊、帳號維護、首頁等等。也可以是以設計的角度來分類，例如內容、商標、互動性等)。
- 為每個功能分類，設定一個比較對象。比如說，你覺得Amazon的某個功能很好，或是Apple的某個設計很好，就把它們當比較對象。
- 為每個比較設定目標。例如，你覺得你的產品在這個功能上面，只要有Amazon的50%就夠了，那就設定50%。
- 接著大家就開始評分。小組必須討論出來，到底我們做到了多少分，並且達成一致。注意: 討論的過程與產出才是最重要的部分。
- 找出差異最大的點(分數落差最大的項目)，然後大家討論怎樣可以提高產品的分數，減少落差。
- 經常性地重複，比如說每週一次。每次就是改進落差最大的部分。
- 附註: 這個方法其實沒有什麼科學分析，因為分數是很主觀的。但是這個過程能讓小組成員思考如何讓產品變得更好。此外，這也能用來協助小組找出工作的優先順序。
如果你的時間不太多，那麼上面的這些驗證方法，建議執行Black Hat Session。
(後記: 想不到光是這些筆記就有五千字。在Chapter 9之後又回到那種沒什麼建設性的文字去，所以就沒做筆記了。)