# 最前沿的技術 - 利用用戶體驗驅動設計改善體系結構 作者?[Dino Esposito](https://msdn.microsoft.com/zh-cn/magazine/mt149362?author=Dino+Esposito)?| 2015 年 11 月  任何軟件系統的設計和工程都始于眾所周知的一步，即收集客戶需求。這通常需要與客戶和域專家進行多次會議和面談。在最后一次會議結束后，參與項目的幾乎所有人都應該認為系統的全部詳細信息均已落實，可以安全地啟動項目開發了。任何人都不應當懷疑最終產品會與所解釋和理解的有差異。客戶應該感到滿意，架構師應該認為自己完全知曉該怎么做。 不過，實踐經驗表明，在抽象的需求方面達成共識并不能保證成功實現。當客戶真正看到原型時，他們并不喜歡，這種情況屢見不鮮。無論開展多少次會議和討論，客戶和開發者對最終產品的想法似乎都不同。開發者在收到需求后構建滿足這些需求的軟件。不過，最終產品經常會不符合用戶的需求。 我認為，開發者往往會力求實現功能完整性，而不夠關注讓系統出色執行最終用戶所需的業務流程。所以，雖然業務流程的功能方面有所覆蓋，但總體實現很少與預期的一樣完善和順暢。在本文中，我將介紹一種設計方法，這種方法可以增加架構師首次就能構建正確的軟件的可能性。我將這種方法稱為用戶體驗驅動設計（或簡稱為 UXDD）。 ## 靈感來源 您可能還記得這樣一段逸聞：蘋果砸在 Isaac Newton 爵士的頭上，讓他想到了萬有引力定律。最近，我的頭也被蘋果砸了一下，生出了以下想法：要充分注意用戶的預期和實際流程，有時需要構建不同的內容。也就是說，要做的不僅僅是功能分析而已。 客戶曾要求構建一個簡便快捷（他們是這么說的）的 Web 應用程序，以支持網球公開賽的競爭對陣圖。這只是一個用戶情景。操作員指出了選手姓名和相關抽簽排位，并希望系統能夠公開部分 XML 源來反映當前抽簽狀態。我的開發者根據自己的思維模式立即想到了創建數據表來保存數據。接下來，我想到了創建包含兩個文本框的某種快捷 HTML 窗體：一個文本框用來顯示選手姓名，另一個用來顯示選手的抽簽排位。有趣的是，當討論結束時，客戶確信有工具可以輸入選手姓名和排位了，并且還有提供支持的部分 XML。但當開發者（就是我）交付了這樣的工具后，客戶通過實際抽簽模擬進行了測試，卻發現這行不通。客戶想要的工具實際上更復雜。請參見圖 1，它展示了開發者和客戶的不同視角。背景屏幕是客戶需要的解決方案，展示了實際流程；疊加層內有黑色邊框的黃色屏幕是低成本的解決方案，雖然快捷但并不適合。 ? 圖 1：客戶預期和開發者理解之間的差異 總而言之，用戶體驗不僅僅涉及手勢和圖形，還涉及用戶在與軟件交互時獲得的體驗。為了設計有效的用戶體驗，作為架構師和開發者，您應該更加關注任務和業務流程，而不是數據模型和存儲空間。您必須詳細了解域、用戶和用戶在相應的域中執行哪些操作，才能理解任務。UXDD 能夠解決此難題，但它不只是通常推薦使用線框和模型而已。我在一個簡單方案中使用過這種方法，但并不行得通，因為客戶（在他看來）認為軟件過于簡單，與完整設計實際流程的工作并不相當。作為架構師，我沒有從客戶那里獲得有關任務重要性的正確信息。絕不要選擇低成本的解決方案；請選擇有效的解決方案。我不得不承認，我建議的原始解決方案（低成本的解決方案）在實際情況下根本無法使用。我所犯的錯誤是，盲目地完全相信客戶的分析，而并沒有詳細了解實際的業務流程。 UXDD 是一組結構方案，能最大限度地降低遺漏與任務和 UI 相關的重要業務點的風險。有趣的是，UXDD 能夠改變目前部分的開發和軟件工程綜合實踐。 ## 自上而下的設計 從功能角度來看，無論您是從底部（即從暫留模型）還是從頂部（即從表示層和視圖模型）開始設計，您都能成功地構建有效系統。從用戶體驗的角度來看，只有當您從表示層和視圖模型開始設計，并由此構建其他所有內容（包括后端堆疊）時，您才能夠成功。 我們中很多人學習過的專業知識都是，在根據客戶需求構建由實體和關系組成的暫留模型后，您差不多就快完成了。此模型將是整個系統的模型，用于整個堆疊，只會偶爾與一些 UI 特定的數據傳輸對象合作。在這種情況下，系統的設計和構建都是按照自下而上的方式進行，而且表示層也必然會反映數據模型以暫留為中心的理念。我們通常將此稱為創建、讀取、更新和刪除 (CRUD)，并且我們也經常會將任意系統簡化為 CRUD，只含略復雜的業務邏輯。這樣一來，我們就不太注意表示層。UI 太靠近數據模型有時對用戶來說很好；有時卻不是。在您交付首個有效原型后，后一個方案會促使開展更多協商。您在首次從頭開始設計系統后發現，在某些情況下，必須更改最外層才能反映不同的用戶流程。這無異于嘗試將方形釘子釘入圓孔內。因此，我將這認為是許多軟件項目的最大挑戰。 我們可以如何改善流程呢？ 我認為答案是，回到自上而下的設計方法，從表示層開始設計，并根據表示需求制定任何進一步的決策和實現詳細信息。為了使其有效，必須有一種沖刺 (sprint) 0 或瀑布式初步步驟，才能確保在構建系統后端之前，對用戶體驗有深入的了解。 ## 用戶體驗驅動方法 我從用戶體驗專家那里了解到，與通過面談被動推導相比，最好是通過循證討論來主動捕獲需求。有時，架構師和分析員往往會在推導過程中過于被動，這就導致用戶降低任意功能的優先級，以使軟件盡快交付。然后，用戶會在最終獲得軟件時抱怨系統幾乎無法使用。同時，在推導過程中過于被動，以“這就是客戶所需”為借口，對我們將要構建的“產品”沒有任何幫助作用。如今，我們編寫軟件是為了反映實際應用，而不是為了針對所了解到的客戶需求建模。遺漏業務結構方面是代價巨大的致命過失。 常見做法是，使用線框就預期 UI 達成共識。由用戶反復運行線框以征集反饋意見只在一定程度上有用。線框雖然很不錯，但若沒有情節提要，就價值有限了。 只有很少的任務是完全通過一個您可以有效匯總到線框中的屏幕完成的。只觀察屏幕的線框可能還不足以發現流程實現的可能瓶頸。最好是在情節提要中連接屏幕。在這一方面，我認為最大的挑戰是尋找情節提要的構建工具。此類工具構成了快速發展的應用商店。圖 2?列出了一些能夠幫助您快速制作應用程序表示層的原型的工具，讓用戶可以具體地了解正在設計的流程。 圖 2：可快速有效地制作 UI 原型的工具 | 工具 | URL | |---|---| | Axure | [axure.com](http://axure.com/) | | Balsamiq | [balsamiq.com](http://balsamiq.com/) | | Indigo Studio | [infragistics.com/products/indigo-studio](http://infragistics.com/products/indigo-studio) | | JustInMind | [justinmind.com](http://justinmind.com/) | | UXPin | [uxpin.com](http://uxpin.com/) | 另外，最新版 Microsoft Visio 和 PowerPoint（尤其是與 Visual Studio Ultimate 結合使用時）也具備一些原型制作功能。圖 2?中列出的所有工具都提供了豐富的平臺，可便于您創建線框，以及在某些情況下創建可單擊的模型，并將其轉化為功能性原型。 這些工具中最先進的可以提供早期反饋，更重要的是，您能夠在設計過程的早期以及在編寫任何一行代碼之前就讓客戶參與進來。如果您在后端完成一半時發現遺漏了重要的表示點，要么放棄，要么進行調整。 同時，簡單地將表示層外包給用戶體驗專家團隊還不夠。如今，表示層是系統最重要的一個部分，必須由解決方案架構師、用戶體驗架構師和客戶共同生成。這必須是第一步，理想情況下，只有當客戶贊同表示層時，您才能繼續。在方法方面，可以接受的做法是，執行瀑布式傾斜，并在編碼前完成整個表示設計，同時提高敏捷性，并將表示分析添加為沖刺 (sprint) 中的一個步驟，如圖 3?所示。 ? 圖 3：用戶體驗驅動結構設計的三個步驟 ## 設計解決方案的其余部分 當您完成整個解決方案的表示層或僅當前沖刺 (sprint) 后，您便有一系列屏幕（例如，窗體）和定義明確的數據流（明確了流入和流出每個窗體的數據）。從體系結構上來說，這就意味著您了解每次操作的輸入模型，以及填充窗體或生成預期響應所必需的視圖模型。表示層通過從概念上匹配服務層模式（如 Martin Fowler ([bit.ly/1JnFk8i](http://bit.ly/1JnFk8i)) 所定義）的中間服務層，以及域驅動設計的分層體系結構中的應用程序層與后端相連。您實現用例及其所需任務的任何業務流程的位置正是系統的邏輯段。應用程序層是后端的頂層部分，并與表示層直接對話。應用程序層由每個操作的直接終結點構成，這些操作可由表示層觸發。這些終結點接收并僅返回線框生成的輸入模型和視圖模型。 這種方法真的有效嗎？ 那當然。如果線框分析不僅徹底還正確無誤，則您實現的流程就是客戶想要的，并且第一次就是對的。這樣大大減少了在部署第一個版本或演示后重新協商更改的可能性。不僅節省了時間，而且隨后還能縮減開支。如圖 4?所示，開發者將這指明為用戶對軟件的典型看法。使用 UXDD，就可以這樣設計軟件。 ? 圖 4：用戶視角的軟件本質 ## 總結 與我們當前采用的軟件設計方法（從數據模型往上）相比，UXDD 更加重視的是任務和表示，而不是數據模型。數據模型和暫留并不是不重要，只是它們的角色對任務具有功能性，而不是任務對它們的角色具有功能性。無論您是否樂意，這都更接近于當前的實際應用需求。UXDD 關乎于方法，而不是技術或模式。UXDD 既不拒絕也不授權任何技術或模式，盡管它可以與 CQRS 和 Event Sourcing 完美結合使用。如果您不滿意應用程序的實際構建流程，請將 UXDD 方法看做一種橫向思維方式。 * * * Dino Esposito?*是《Microsoft .NET: Architecting Applications for the Enterprise》（Microsoft Press，2014 年）和《Programming ASP.NET MVC 5》（Microsoft Press，2014 年）的合著者。作為 JetBrains 內的 Microsoft .NET Framework 和 Android 平臺技術傳播者，Esposito 經常在全球行業活動中發表演講，并在?[software2cents.wordpress.com](http://software2cents.wordpress.com/)?和 Twitter?[@despos](https://twitter.com/@despos)?上分享自己對軟件的看法。*