使用者體驗優先

對於一個應用程式來說，最有趣的事通常發生在領域模型層裡，這裡也是你構建引擎並賦予整個系統生命與動力的地方。從領域模型層開始設計當然是可以接受的，也是常見的。但我們打算在這裡推行另一個可以節省時間和精力的方案，尤其在你對領域比較不熟悉而且用例也與使用者密切相關時。在過去的某些演講裡，Dino把這種方案稱為“軟體開發之哥白尼革命”。哥白尼並未看到過去沒人看得到的東西。相反，他只是為一些東西提供了全新的視角，為每個人都經歷過的白天和黑夜等東西提供了不同的解釋。

同樣地，我們並未聲稱有一種新的可以拯救世界的特效藥。簡單地說，我們想分享一種設計方案，把注意力集中在表現層，關注任務，以及讓你在使用者介面被使用者驗證、經過提煉和批准之後可以著手處理最有趣的東西。一切仍會改變，但大多數表現層的問題都會被解決。使用者體驗優先是使用者體驗優先的簡寫，顧名思義，這種軟體設計方案的核心是表現層和使用者系統互動。

為什麼關注互動

寫軟體的目的是讓客戶以他們喜歡的最有效的方式開展他們自己的業務。任何軟體都會產出結果，不管是通過螢幕、檔案還是資料庫更新。毫無疑問，越是瞭解預期結果，就越能有效地制定開發計劃。 當預期結果涉及與之使用者互動的某個圖形介面時，先關注那些互動就是一個很自然的決定了。關注互動會引出基於任務的設計。

基於任務的設計

有時候你所面臨的複雜性太大而無法一次處理。從模型開始處理又有點“殺雞用牛刀”的感覺。較為輕量級的做法是關注要實現的任務、每個任務需要的輸入以及每個任務產生的輸出。 那麼，不斷地從列表領取任務，繪製使用者介面的草圖及其背後的工作流。這正是統一建模語言（UML）用例圖的用途。 在UML裡，用例圖提供應用程式用例的圖形表現。用例描述系統和其中一個參與者之間的互動。具體地，用例圖展示了哪些參與者要做什麼。參與者是與當前描述的系統進行互動的使用者或者任何其他外部系統（如資料庫）。系統不能控制參與者；參與者定義在系統本身之外。

這個用例標識了兩個操作：獲取訂單和獲取產品細節。這個場景可能需要一個螢幕提出請求以及另一個螢幕顯示響應。使用者不會直接操作獲取訂單或產品細節的系統元件。使用者感興趣的是他如何指定要獲取的訂單或產品。

下一步是繪製螢幕草圖，記下請求應該如何指定以及響應應該如何展示。

重要：採用面向任務UI是行業的一個新興趨勢，與讀寫模型分離齊頭並進。由於行業認為有需 要分離領域和資料，那麼從以資料為中心的使用者介面（Access風格，基於表格）轉向面向任務介面 就是一個很自然的發展這種新的方案使需求更易轉成規範，也能改善使用者介面，使之變得更好。 最後，面向任務UI可以通過命令/查詢責任分離（CQRS）等架構模式簡化後端的結構，這個架構模 式會在第10章"CQRS導論”展開討論。

目標是找到最佳的做事方式

幾十年來，開發者沒有太多關注他們的應用程式的使用者介面。他們的注意力放在模型和資料庫，而表現層背後的模型在很大程度上被忽略了，而且還被看作一件苦差事。似乎表現層和儲存擁有不同的模型是一種不好的設計。

關注互動而不是資料，持續改善草圖才是正路。本質上，我們認為這就是使用者介面(UI)和使用者體驗(UX)之間的區別。

為每個介面建立一個檢視模型類

就軟體開發而言，螢幕經過定義並且通過批准是一件好事，也是構建系統餘下部分的絕佳起始點。一個螢幕最終就是一組輸入元素，可以輕易抽象成一個類。

這個類不需要有豐富的行為，一個簡單的資料傳輸物件（DTO)就己經足夠了。DTO是一個類，用來攜帶跨越系統的邏輯層和物理層的相關資料。有一個DTO表示來自螢幕並傳給應用程式層執行命令的資料。另一個DTO表示通過伺服器操作的響應傳遞回來填到表單上的資料。出去的DTO構成了輸入模型（InputModel），而進來的DTO構成了檢視模型(ViewModel)。

使用者介面僅僅是是使用者體驗的一部分

隨著智慧手機和平板電腦出現之前，設計良好的視覺化介面對於軟體應用程式的使用者來說己經算得上一個好的體驗了。但往後的發展似乎表明一個好的使用者介面對於交付設計良好的表現層己經不再足夠。

為了保持前瞻性，我們不得不把UI替換成UX。

使用者體驗專家的職責

使用者體驗專家(使用者體驗架構師、使用者體驗設計師) 一一是一個同時需要分析能力和創造能力的職位。使用者體驗專家分析使用者的行為，併為他們找出使用系統的最佳體驗。使用者體驗的四大要點總結如下。

• 資訊架構——瞭解資訊的層次結構，然後確定通過應用程式顯示它的理想方式。
• 互動設計——確定使用者與這些資訊互動的方式，以及為此而提供的圖形工具。
• 視覺化設計
• 可用性審查

可用性審查詳情 使用者體驗專家可以與客戶面談很多次，實際上也應該這樣做，但這隻能理解客戶的基本要求。這會產生一些可以討論和調整的草圖。僅當介面和互動構成流暢的執行機制，既沒有可用性瓶頸，也沒有帶來流程障礙，才能得到非常令人滿意的使用者體驗。 對於使用者體驗專家來說，與使用者交談是非常基本的，但實地驗證使用者介面、觀察使用者操作、聆聽使用者反饋以及在可能的時候錄製他們的操作可能更加重要。 可用性審查是一個迭代流程，它產生的模型可以轉成允許使用的技術所支援的使用者介面形式。從程式設計的角度來說就是建立CSS、HTML或者XAML模板等東西。

使用者體驗開發的順序，使用的工具

使用者體驗開發的階段

• 草圖(sketch)
• 線框(wireframe)
• 模型(mockup)
• 原型

前3個階段需要專門的工具，第4個階段只需一些常規的編碼工具。

4個使用者體驗工具：Axure、Balsamiq、UXPin、Wirify；微軟SketchFlow介於線框和原型之間，但只適用於XAML應用程式。

為什麼你需要在互動上花時間

就使用者體驗而言，即使簡單到只有兩頁的CRUDweb應用程式，也可能暗藏出人預料的陷阱。只有通過觀察使用者使用這個應用程式，你才可以肯定地判斷你提供的使用者體驗是好還是壞。

如何實現殺手級使用者體驗

• 第一，你以迭代的方式描述你的想法，從草圖到線框最後到完備的模型。
• 第二，你使用預存資料、不用後端或者使用偽造的僅用於測試的後端把檢視轉成可工作的原型。
• 第三，完成這個原型之後，就要應對最棘手的部分了：告訴客戶他剛批准的只是一個原型而不是最終應用！

注意：需要澄清一下草圖、線框和模型等常見使用者體驗行話的確切含義。草圖是徒手繪圖，主要用來記錄想法。線框是更高階的草圖，它關注功能、布鬲、導航和資訊。線框並不關注使用者介面細節。最後，模型關注實際的外觀和感受，可以看作加上樣板使用者介面的線框。

把互動變成檢視

毫無疑問，HTML和CSS，甚至XAML，可以讓你在幾分鐘內建立一個可工作的原型檢視。但是，這裡的重點是為客戶描述互動模型。如果首先你展示草圖而不是彩色截圖，客戶可能會感到更加放鬆，思想也會更加開放。不要太早牽涉太多無關重要的細節。

所以你最好使用低保真草圖，不要牽涉到技術。當草圖足夠清楚，你就可以建立線框，新增更多關於功能、佈局和導航的細節。Balsamiq等工具在快速建立線框方面提供很大幫助。線框設定螢幕的結構；模型只是在線框之上開發的一些圖形想法。

但是，到目前為止你所得到的都是純靜態內容，不會動，也不能操作。根據你為建立線框選擇的工具，你可能想建立真實的故事板演示UI螢幕的流動。

把檢視變成原型

即使是最好和最廣為接受的使用者介面也可能在大量使用之後暴露問題。步驟：

• 自我確信——不要在得到首次批准就停下腳步；嘗試使自己確信你所建立的互動設計的質量。
• 建立原型（可選）——如果仍然心存疑慮，可以建立一個原型，甚至錄製使用者使用這個原型的情景，以便獲得他們感覺的真實反饋。

原型只包含表現層，僅僅使用預存資料或者一個偽造的後端來模擬一些行為，可以是HTML頁面或者XAML程式。 根據你想提供的保真度，為一組認可的草圖建立線框和原型只是短短几天的事情。

現在告訴客戶它只是一個原型

客戶喜歡這個原型，讓你繼續構建這個應用程式。理想狀態下，每個介面應該綁到一個檢視模型類（ViewModel），它描述了用來填充檢視的資料。此外，每個介面應該綁到一個輸入模型類（InputModel），它描述了觸發操作時將會離開介面的資料。

重要，在第5章“發現領域架構”裡，我們強調了標識鬆散耦合的業務上下文的重要性。大多數情況下，這會產生一張由一些塊和少數關係構成的圖表。每個塊都可能使用最合適的架構、設計和技術單獨實現。

MVC、MVP、MVVM以及其他模式

MVC MVC是Model-View-Controller的簡稱，MVC的主要目標是把應用程式分成不同的部分——模型、檢視和控制器。模型表示應用程式的狀態。它包含了應用程式的功能，在狀態改變是發出通知。視圖表示顯示給使用者的任何圖形元素。它獲取並處理任何使用者操作。控制器把使用者操作轉換成模型上的操作，然後切換到下一個檢視。 MVP MVC模式演化成Model-View-Presenter（MVP），其中，表示器元素取代了控制器，也承擔了更多的責任。這包括從編排任務到渲染檢視的一切東西。在MVP裡，檢視和模型是嚴格分離的，表示器則在它們之間進行協調。 MVVM Model-View-VlewModeI（MVVM）是原來的Presentation Model模式的更受歡迎的名字。在MVVM裡，你有一個類整合了使用者介面的命令和檢視模型。一個單獨的類一一一檢視模型物件一一暴露了綁到使用者介面視覺化元件的屬性以及綁到使用者介面事件的方法。MVVM尤其適合具有強大雙向資料繫結機制的應用程式場景。這對於基於XAML的應用程式以及Universal Windows應用程式來說尤其適合。 不要混淆：就分層應用程式而言，MVC、MVP和MVVM都是表現層的模式。