用戶體驗設計過程和文檔指南

文檔對於概念、設計、創建和測量產品性能很有幫助。 但不應該僅僅為了維護而這樣做。 畢竟，一堆厚厚的文書工作與您的真實產品體驗相似。

正如精益 UX 倡導者 Jeff Gothelf在 Smashing Magazine 的一篇文章中所描述的那樣，僅為了未來參考用戶體驗而創建的厚可交付成果幾乎在創建後就已經過時了。 在當今精益和敏捷的世界中，體驗應該是重點——而不是可交付成果。 無論您選擇輕量級還是更詳細的流程，關鍵是您的文檔應該有助於推動設計向前發展（而不僅僅是一個滯後指標）。

以下是產品設計和開發文檔、各個元素以及它們所屬的各個階段的概述。 產品開發和文檔可能因公司而異（例如，Spotify，如在 Spotify 構建最小可行產品中所討論的），但以下許多可交付成果在大多數組織中以某種形式常見。

我們選擇了我們認為最有效的方法，但請隨意選擇有效的方法。

它們是如何關聯的

談到產品設計文檔，理論和實踐是兩件非常不同的事情。 我們都知道以用戶為中心的設計的基本原則。 我們認識到不同的研究方法、原型設計階段以及在我們豐富的方法論環境中記錄技術的過程。 不過，您可能經常問自己的問題是“這一切在實踐中如何運作？”

圖片來源：設計過程。

簡而言之，這一切都是為了使文檔成為設計過程的補充而不是補充。 在我們詳細介紹之前，在產品設計和開發過程中快速查看文檔可能會有所幫助。 下面，我們給出了設計文檔的每一步如何联系在一起的實用解釋：

1. 在產品定義的初始階段，您正在集思廣益產品以及如何在最高級別與所有必要的利益相關者一起執行項目。 這可能會導致項目啟動計劃、精益畫布和一堆非常早期的概念圖和您想要構建的模型。
2. 進入研究階段，您的團隊會改進假設並填補空白。 這個階段因產品的複雜性、時間、資源、現有知識水平和許多其他因素而異。 然而，總的來說，建立競爭和市場分析並進行客戶調查是很好的。 如果你有一個現有的產品，查看分析、啟發式、內容、產品上下文和用戶測試也很有幫助。
3. 在分析中，迄今為止收集的產品營銷數據為角色、體驗地圖和需求文檔（如優先功能電子表格和用戶任務矩陣）提供了基礎。 至此，產品定義、產品優先級和產品計劃已經定義好，並為更正式的設計交付做好了準備。 正如 UX 設計過程和文檔指南中所討論的，草圖和圖表也可能在這段時間內不斷生成。
4. 從這個輸出中，可以創建場景、概念圖和模型，進入設計階段。 通用文檔包括草圖、線框圖、原型、任務流程圖和設計規範。 例如，在研究和分析過程中創建的競爭分析和角色會反饋到模型、概念圖和場景中。 反過來，這些部分會影響中級和高級可交付成果，例如線框、故事板和詳細模型。 一些公司將研究、分析和設計階段視為一個大型過程，如您在此概覽圖中所見。
5. 在實施過程中，將代碼和設計資產組合在一起，以創建符合產品設計規範的產品。
6. 上線產品發布後，支持票證、錯誤報告和其他分析等反饋數據繼續通過後續迭代和升級推動產品改進。 隨著產品處於生產模式，應以分析和報告的形式不斷生成和監控數據，以確保持續成功。
7. 持續的、數據驅動的產品改進是通過測量和迭代生產中的產品、使用性能儀表板和分析來實現的。

指導原則

既然您已經了解了每個階段是如何相互連接的，那麼讓我們看看一些有助於沿著每個階段移動產品的原則。 我們將解釋如何使用設計衝刺，以便流程隨著時間的推移而發展，而不是僅僅在一開始就被定義。

圖片來源：來源：以用戶為中心的設計。

與其對應的敏捷軟件類似，設計衝刺是 1-3 週的衝刺，專注於解決特定的產品和設計問題。 根據 3Pillar 的 UX 負責人 Alok Jain 的說法，設計衝刺的三個關鍵要素是協作、減少交接摩擦和團隊專注。 簡而言之，您的文檔是必須始終關注用戶本身的協作工作。 因為您在每個階段之間快速移動，所以您可以建立動力並最大限度地減少浪費。 更重要的是，你正在解決更小的問題，從而允許更多的探索和冒險。

可以在此處找到完整週期的極其精簡的版本，但我們將在下面詳細描述如何在您了解產品、設計產品以及發布和改進產品時應用這種思想。

1.了解產品

在構建產品之前，您需要了解其存在的背景。 為什麼利益相關者、公司和用戶應該關心推進你的想法？

圖片來源：實現共同理解。

根據 Smashing Magazine 的說法，您需要包括滿足業務需求、用戶需求和滿足兩者的最佳設計解決方案的活動。 這裡的關鍵詞是“活動”，因為雖然像商業模式畫布和精益畫布這樣的文件很重要，但你需要激勵利益相關者——否則你只會有一群昂貴的人在談論每個人都知道的東西。 這些活動是有效的，並邀請合作：

• 利益相關者訪談——使用此模板，您可以讓每個團隊成員採訪 3 個利益相關者。 產品會給客戶帶來怎樣的感受？ 他們應該怎麼做？ 通過記錄利益相關者如何看待客戶的想法、感受和行為，您可以設置一個基準來與可用性測試和用戶分析進行比較。
• 需求研討會——讓利益相關者聚在一起，討論項目計劃，並開始討論概念如何融入產品和
  技術要求。 您可以從空白的商業模型畫布或精益畫布開始，然後與團隊一起完成。
• Crazy 8s — 拿一些記號筆，讓每個人在 5 分鐘內畫出 8 個產品或特色創意。 讓每個人為每個想法打分，然後
  您將開始看到趨勢和偏好。 這實際上是 Google Ventures 重新設計過程中的第 2 步。 有關其他想法，請查看此頭腦風暴活動列表。

一旦你奠定了基礎，與大量用戶交談和測試，這樣你就有了用於研究和分析的真實現場數據。 UXPin 首席執行官 Marcin Treder在確定問題和範圍後，深入研究客戶開發和可用性測試。 當 UXPin 只是一個紙質原型工具時，Marcin 記錄了（在紙上和視頻上）與 Brandon Schauer、Luke Wroblewski、Indi Young 等 UX 超級明星的 50 多次用戶訪談和現場可用性測試。 然後，產品團隊使用這些見解來創建角色，編寫數十個用戶故事，並最終勾勒出產品需求。

在亞馬遜，使用了另一種“逆向工作”方法，其中第一步是為成品起草內部新聞稿。 這種方法有助於從客戶的角度逆向工作，而不是試圖將客戶固定在一個想法上。 通過迭代新聞稿直到聽起來很吸引人，產品團隊可以立即進行現實檢查以及快速的基准文檔，以供以後的設計和開發使用。

2. 設計產品

正如《最小可行產品指南》中所討論的，一旦您了解了
產品目的，您的主要目標是構建原型。 無論您的團隊喜歡在餐巾紙上畫畫，創建高保真或低保真線框，您最終都應該得到一些實用的東西。 這個階段的獨特之處在於，對於大多數可交付成果，文檔就是設計。

圖片來源： UXPin 。

根據 Twitter 設計經理 Cennydd Bowles 的說法，產品團隊應該提前研究兩個迭代，提前設計一個迭代，然後回顧之前的迭代。 如果你想保持敏捷，他建議直接研究低保真原型，作為優先考慮“交互優先於流程”的一種方式。 如果您想要更詳細一點但仍想保持輕量級，您可以從概念圖或草圖開始，然後迭代到低保真線框，最後創建高保真原型。 無論您採用何種方法，請確保您與利益相關者和用戶一起進行測試。

如果預算和時間允許，您還可以創建體驗地圖以突出產品滿足或失敗的用戶需求和任務模型，以深入了解用戶為實現目標而執行的活動。 雖然這些不是設計的一部分，但它們是互補的，因為您還需要了解您的產品在哪裡適合您的想法和市場。 有趣的是，Yelp 通過創建包含常見代碼行的樣式指南，使他們的設計階段更進了一步，從而允許將文檔從字面上構建到產品中。

在 UXPin，我們的流程是在網格紙上使用銳利筆進行小組素描會議，然後將其裁剪為幾個線框，然後添加細節，直到我們擁有一個高保真模型。 如果涉及用戶測試，我們會將模型構建成高保真原型。 對於大型功能發布，我們進行了廣泛的用戶測試，因此比例約為 70/30，有利於原型。

3. 構建和發布產品

當您開始進行繁重的技術工作時，創建有助於您了解整體願景的文檔非常重要。 隨著您對產品的改進，具體要求可能會發生變化，但您的文檔應該可以幫助您了解產品投入使用時的優先級。

圖片來源： MVP 活動。

RedStamp 的用戶體驗經理 Kristofer Layon認為，您可以將產品需求和技術規範文檔可視化為路線圖。 產品路線圖顯示了用戶故事，並幫助您確定為滿足他們而構建的功能的優先級。 有時，可能會將特定日期添加到路線圖中，以便它也可以用作時間線。 路線圖的優雅之處在於，它可以幫助您優先考慮您正在構建的內容，使其與您的產品需求和技術規範定義的“方式”相輔相成。 在決定特徵時，您可以使用卡諾模型將它們分為 3 類進行評估：

• 基本屬性——這些是產品正常工作所必需的。 例如，筆記本電腦的基本屬性是鍵盤或屏幕。
• 性能屬性——這些可以作為 KPI 在不同產品之間進行比較。 例如，筆記本電腦是根據 CPU 速度和硬盤空間來判斷的，因為人們往往更喜歡可以存儲大量數據的快速計算機。
• 令人愉快的屬性——這些是主觀的，取決於客戶的喜好。 例如，Macbook Air 非常輕薄，觸感非常順滑。 合適的客戶會發現它是一個很好的賣點，而其他人則不為所動。

通過基於此模型以 1-5 的等級對功能進行評分，您可以將它們繪製在優先級矩陣上，以幫助您開始設想您的產品路線圖的外觀。 在 Apple， “道路規則”和“Apple 新產品流程”通過定義職責、創建階段以及從開始到發布的重要里程碑作為產品路線圖。 事實上，道路規則被如此認真地對待，以至於丟失它可能會導致立即終止（甚至在文件中都有說明）。

4. 改進產品

在構建（並最終發布）產品時，文檔還需要關注定義和跟踪銷售和其他 KPI。 畢竟，如果您不知道要優化哪些指標，就無法改進產品。

圖片來源：數字產品管理。

LaunchClinic 的創始人 Dave Daniels建議您寫下發布目標（例如 30 天內 30,000 次下載），並確認您擁有正確的工具來記錄進度。 使用指標工具和錯誤報告軟件，您可以設置定期報告，以便在發布的前幾週及以後密切關注。 在客戶方面，您還可以對用戶進行細分並向他們發送自定義調查，以評估您可能想要迭代的地方。

在 Spotify，迭代階段是產品開發中最長的階段。 產品團隊使用當前指標和優先級矩陣（可能在設計階段創建）來權衡收益與改進某些產品超出其“局部最大值”的努力。 如果他們確定付出的努力是值得的，他們將返回到定義階段以“全局最大值”來改進產品。

主觀環境中的客觀過程

在產品設計文檔方面，沒有單一的靈丹妙藥。 幾乎所有使用我們產品的公司都採用了我們上面描述的策略。 雖然產品開發和用戶體驗設計是高度主觀的空間，但您的流程和文檔並不需要如此。 畢竟，產品的最終目標是收入，這沒有什麼主觀的。

圖片來源：設計過程說明。

無論您是輕量級還是更喜歡更詳細的文檔，目標都是一樣的——把它從你的腦海中拿出來，放到紙上（或屏幕）上，這樣你的團隊就可以互動和做出反應。 文檔應該是產品的指南針，而不是一成不變的規則。 我們討論的某些階段可能會以稍微不同的順序甚至平行發生，但它們的存在都是為了為瘋狂提供方法。 使用有效的，放棄其餘的，並隨著產品的發展而發展您的文檔。

如需更多將文檔納入設計流程的方法，請下載用戶體驗設計和流程文檔指南。 Aarron Walter、Laura Klein、Ian McAllister 和其他數十人提供專家建議。 Vurb、MailChimp、Apple、Google 等公司也展示了視覺示例。