UX設計程式的五個謬論

　　本文作者Tony Russell-Rose是致力於複合搜尋和資訊訪問App公司UXLabs的一名主管。在這裡主要是分享UX設計程式裡的幾個需要避免的謬論觀點。（以下是編譯內容）

　　自UXLabs建立以來我參與過各種各樣的設計專案：不管專案大小、簡單還是複雜、初創企業或者是大公司。在那段時間裡，我已經注意到一部分實踐看上去運作的很不錯，可是大部分的實踐結果則不盡人意。在這下面我主要是針對使用者體驗設計流程的一些謬論進行總結。

　　1. 需求分析最好是留給專家去做

　　收集和管理使用者需求的技術有很多種，只不過程式不同而已。通常這些需求都是由業務分析師在利益相關者的研討會上進行收集，隨後在一個不斷擴大的專案列表裡將其記錄為一個線下專案。這僅僅是一個開始，但是在很多時候，掌握“投入水平”（在設計和開發兩個方面）和“敏捷交付”的評估也是一項很重要的能力。雖然前者比較簡單完成，但是後者可能會涉及到資料、資源和技能等方面的可用性；還關係到企業的戰略發展；符合正在進行的專案/工作流的分配協作原則。也就是說，只要任何一個和特殊需求有關的可行性建議都是有效地，不管它是否具有優先權或者易於實現。這些評估能力是很難獲得的，但是它能和上面的專案列表產生同樣的作用，具有優先權、敏捷交付，能夠生成更讓人信得過的專案，用於後續的衝刺計劃。

　　2. 設計是一個純粹的創造性活動

　　如果在設計上給出無限的時間的話，原則上，可以找出所有解決問題的優化方案。可是在實踐中，時間是有限的，所以，應該重視在設計上的研究探索，給使用者體驗這一專案更多的優先權。分享對設計空間維度的理解也是很有必要的。在相關搜尋設計專案裡，維度通常相當於：

• 使用者：我們替什麼樣的使用者群設計，他們具有哪些相應的優先權？
• 任務：我們支援什麼型別的搜尋任務......專案類，探究類等等。
• 環境：有很多方面的環境都是很重要的，但是這裡比較適當的是資料環境....我們所關心的資訊資產，通過這些資訊怎麼對映出使用者的心理模式呢？
• 複雜度：在不同的場景下我們支援什麼樣的複雜度呢？一個簡單的、有限的互動，或者是更多的要求？許多設計專案偏重了簡單的可尋性任務，而忽視了更復雜的資訊行為型別。

　　3. 不能用數字跟蹤設計探索

　　傳統的使用者需求分析技術存在一個明顯的缺陷，那就是那些技術知識簡化論，在那種技術下的需求最終可能被表示為一個支離破碎的形式。如果缺少環境這個要素的話，他們所提供的任何將數值傳遞給使用者端的經歷也將是毫無意義的。強調這一點的方法就是通過將需求組結合到一個單一的、連貫的場景裡。方式有很多種，從一個簡單句子到一個高架構的對話，但是這樣就可以將聚合需求分享到有意義的、目標明確的故事裡。

　　一旦你從場景對映到需求，您可以把對映作為審計工具使用來評估每個需求的狀態。這種型別的審計跟蹤在一定程度上提供了透明性和追究性，這樣就確保了在分析階段所做的評論在設計探索階段具有責任性。

　　4. 專注於一個最佳的設計方案

　　以使用者為中心的設計，其核心準則就是技術原型應該與終端使用者相結合進行反覆測試，並在使用者反饋的基礎上進行升級更新。但是並不建議使用者測試建立在一套可以相互轉換的備選設計上：這使得在不同的備選設計上存在直接的定量比較，而且定性的使用者反饋通常情況下更有效用。此外，對於和搜尋相關的專案，備選方案的選項應該建立在對不同階段的資訊旅程的瞭解基礎上。

　　5. 分面和數值都屬於環境

　　人們認為一旦互動設計在完成之後並交付，例如，作為一組線框圖，設計工作基本上已經完場。但這種情況並不是搜尋專案相關的，特別是那些使用某種形式的分面搜尋技術。在這些情況下，需要有一個單獨的交付記錄形式和個人方面的內容，以及專案是如何執行的。這包括以下的一些問題：

• 轉換邏輯——例如，在遊戲開始階段使用者的選擇是如何影響中期階段的。
• 有限規則——例如，這一規則可以管理什麼時候、如何展現一個特殊的面。

　　線框圖並不是記錄這些關係和約束的合適工具，但這些細節在搜尋體驗的質量上發揮了關鍵作用，應該在設計活動裡進行定義並作為關鍵部分記錄下來。

　　原文：DZone