2015 年 11 月

第 30 卷,第 12 期

本文章是由機器翻譯。

最前線 - 使用 UX 驅動設計的更佳結構

Dino Esposito | 2015 年 11 月

Dino Esposito設計與工程成就的任何軟體系統的開頭的已知的步驟: 收集來自使用者的需求。這通常牽涉到數個會議和客戶 」 和 「 網域專家的訪問。最後一個會議之後幾乎每個人都參與專案應該相信系統的所有詳細資料已被熨燙及開發可以安全地啟動。沒有人應該不能確定最終產品將會不同於已說明以及了解。客戶應該很樂意和架構設計人員應該他們深信自己懂得要做。

不過,在實務上,根據經驗同意抽象的需求並不保證成功地實作。如果客戶確實看到原型,通常它們就是不喜歡它。所有的會議和討論區,不論似乎客戶和開發人員組成的最終產品不同的想法。開發人員收到需求並建置圍繞著它們的軟體。但最終產品經常遺漏的使用者想要的標記。

我認為開發人員通常會傾向於盡快在功能完整性並不足夠在商務程序對使用者執行系統所需的焦點。因此而擷取的商務程序的功能層面整體實作是很少為外觀精美且平滑如預期般。在本文中我將會呈現可以改善架構設計人員可以建置正確的事第一次的機會的設計方法。我呼叫這個方法 UX 導向設計或 UXDD 簡稱。

在我的頭是乏人 Apple

您可能還記得 Sir 牛頓牛頓的標頭是乏人 apple 常識本文開頭他制定通用條法則的 Gravitation。最近我的頭上的 apple 是乏人和我所收到的訊息是該付款金額注意使用者的期望與實際的處理程序有時會需要建置不同的項目。也就是它會採用之外的其他功能的分析。

客戶要求來建置快速輕鬆地 — 所以他們說 — Web 應用程式以支援網球聯賽競爭力的括號。沒有一個使用者劇本。運算子會指示播放程式中繪製的相關的位置的名稱與運算子必須是系統以反映目前狀態的繪製某些 XML 摘要公開 (expose)。我的開發人員的心態立即建立資料庫資料表來保存資料的願景。接下來,我有一些快速的 HTML 表單有兩個文字方塊的願景: 一個用來表示播放程式的名稱和一個繪圖中的位置。有趣的是,當討論結束,客戶是他有更輸入玩家和位置的工具,並有一些 XML 來支援它。但是當開發人員 — 我 — 就是傳遞和客戶在即時繪製模擬環境中進行測試,就是行不通。客戶實際上想要有複雜許多。看一下 圖 1 示範開發人員與客戶之間的不同檢視方塊。 背景 畫面是客戶想要和實際的處理序; 的表示法黃色螢幕中重疊的黑色外框是低成本的現狀不當的快速解決方案。

要與目標了解之間的差異
圖 1 要與目標了解之間的差異

在一天結束時,UX 單單只是筆勢和圖形,它是使用者瀏覽互動與您的軟體的經驗。若要設計有效的 UX,為架構設計人員和開發人員的您應該更專注於工作和商務程序比資料模型和儲存體。若要了解工作,您需要進一步了解網域、 使用者以及這些使用者在該網域中的運作方式。UXDD 能夠解決此問題,但它不只是一般建議使用框線和模型。我使用了一個簡單的案例中並沒有用因為客戶 — 他記住 — 以為軟體是太簡單並不值得花費心力的完整工程實際的處理序。為架構設計人員、 沒有得到正確的訊息從客戶以告知工作的重要性。永遠不會選擇低成本的解決方案。選擇有效的解決方案。我必須承認我提出原始方案 — 低成本解決方案 — 不只是可能在真實的情況下使用。我的錯誤是要完全且盲目地信任客戶的分析並不深入了解實際的商務程序。

UXDD 是一組結構可以降至最低的遺失重要的商業點與工作和 UI 相關風險的規則。有趣的是,UXDD 可以變更某些當今開發及軟體工程設計的彙總的作法。

由上而下設計

從功能觀點來看,您可以順利建置運作系統不論是否您從頭設計工作 (例如從持續性模式中) 下方或上方 (例如,從展示層和檢視模型)。UX 的觀點而言,您才可以將成功開始從展示和檢視的模型設計和建置其他後端堆疊,從該處包括所有項目。

許多人了解專業一旦您有持續性模型的實體和關聯性,建立的使用者需求進行您已幾乎完成。該模型是整個系統用於整個堆疊並由幾個 UI 特定資料傳輸物件只是偶爾建立合作關係的模型。此內容中設計和建置的系統中進行由下而上的方式和展示層無可避免地會反映資料模型的持續性為主的願景。我們通常會呼叫此建立、 讀取、 更新、 刪除 (CRUD) 和我們通常減少任何系統 CRUD 與只是稍微更複雜的商務邏輯。如此一來,我們會鮮少注意到展示層。有時資料模型太靠近 UI 很適合使用者。有時候它不是。後面的案例提供火花其他交涉之後已傳遞第一個可運作原型。您第一次設計全新的系統上找出在某個時間點的最外層的變更以反映不同的使用者處理序。這是無法與嘗試正方形柱子融入 round 漏洞不同。因此,我將它視為許多軟體專案的最大挑戰。

我們可以做什麼來改善程序? 我相信答案是將移回它從展示層會啟動並將任何進一步的決策的由上而下設計方式和衍生自簡報所需的實作詳細資料。若要有效,衝刺 (sprint) 零或瀑布預備步驟中,一種是為了確保深入了解 UX 會移到建置後端系統的之前擷取的。

UX 導向的方法

我了解 UX 專家需求計較主動產生辨識項為基礎的討論透過非被動推斷透過訪談。有時候架構設計人員和分析師還是傾向於 elicitation 期間太被動而這會導致使用者為了儘速已準備好軟體降低任何功能的優先順序。然後他們抱怨時他們最後取得系統的幾乎可使用。在此同時保持在使用 「 這是客戶所想"的藉口 elicitation 太被動無法協助有意義的 「 東西 」 我們要建置。現在我們可以撰寫軟體鏡像部分的真實世界,而不是什麼聽說客戶想要建立模型。結構化商務層面上遺漏是致命和高成本的 sin。

它是用於框線關於預期 UI 共識常見的作法。反覆執行使用者請求只限於小型的意見反應 works 框線。框線是棒、 但沒有分鏡腳本的有限值。

很少的工作完全是透過以框線可以有效地摘要的單一螢幕來完成。只想要使用螢幕的框線不可能不足以找出可能的瓶頸的程序實作。串連在腳本中的畫面是較恰當的主意。在這方面,我看到的最大挑戰尋找工具來建置分鏡腳本。這些工具是快速成長的市場。 圖 2 列出一些可以幫助您快速原型的方式可讓使用者所設計的程序的具象概念中的應用程式的展示層的工具。

圖 2 快速且有效地 UI 原型設計工具

工具 URL
Axure axure.com
Fireworks balsamiq.com
Indigo Studio infragistics.com/products/indigo-studio
JustInMind justinmind.com
UXPin uxpin.com

此外,最新版本的 Microsoft Visio 和 PowerPoint (特別是在與 Visual Studio Ultimate 一起使用) 也功能一些原型設計功能。中所列的所有工具 圖 2 提供豐富的平台建立框線和在某些情況下可讓您建立可點按的模型並將它們轉換成運作的原型。

這些工具的最進階及早提供意見並更重要、 讓牽涉到客戶稍早在設計程序並撰寫一行程式碼之前。如果您發現您遺漏重要的簡報點完成一半的後端,您將它丟棄或調整項目。

在此同時,直接外包給小組的 UX 專家展示層是不夠的。在展示層今天屬於最重要的系統和必須產生結合的解決方案架構設計人員、 UX 架構設計人員和客戶努力。這必須是第一個步驟和您移動上只有當客戶登入時簡報的理想的情況下。方法,就是可接受採取瀑布傾斜和之前程式碼撰寫完成整個簡報設計和更富彈性並加入簡報分析在衝刺中的步驟中所示 圖 3

三個步驟的 UX 驅動的架構設計
圖 3 UX 驅動的架構設計的三個步驟

設計解決方案的其餘部分

一旦完成整個方案或目前的衝刺的展示層,您有一堆螢幕 — 例如 form — 與妥善定義的資料流量 (很清楚和縮小就每個表單)。在架構上來說,這表示您知道輸入的模型的每個動作和檢視模型所需填寫表單或產生預期的回應。展示層會連接到後端透過中繼服務層所 Martin Fowler 定義在概念上符合服務層模式 (bit.ly/1JnFk8i),以及在 Domain-Driven 設計的多層式架構應用程式層。它是系統的邏輯區段您可在此實作使用案例和工作所需的任何協調流程。應用程式層屬於最上層的後端和直接與展示層的對話方塊。直接端點是由應用程式層級的每個可由呈現觸發的動作。這些端點會接收並傳回只是輸入和檢視模型所產生的框線。

是這種方法成效嗎? 還是有。框線分析相當詳盡而且正確,如果您正在實作只是客戶想的程序,而且右第一次。您縮減大幅重新交涉變更在您部署的第一次釋放或示範之後的機會。這樣可以節省時間和後續,金錢。中所示 圖 4, ,開發人員這部分指示為 emblematic 的使用者查看軟體的方式。和 UXDD 通往設計軟體運作方式。

從使用者的觀點來看軟體的本質
從使用者的觀點來看軟體的 圖 4 本質

總結

相較於如何我們今天設計軟體 — 從資料模型上 — UXDD 指派給工作和簡報比資料模型的更多的重要性。不該資料模型化和持續性都很重要,但其角色功能的工作而不是道而行。喜歡與否,這是什麼真實世界要求立即更接近。UXDD 是關於方法而非技術或模式。UXDD 不會拒絕也不強制任何技術或模式中,雖然它會很好以及 CQRS 和事件來源。如果您不滿意建置應用程式的實際程序,使用 UXDD 方法做為橫向的思考模式。


Dino Esposito的共同著作"Microsoft.NET: 構建企業應用程式"(微軟出版社,2014年) 和"程式設計ASP.NETMVC 5"(微軟出版社,2014年)。Microsoft.NET Framework 與在 JetBrains 的 Android 平台和經常在世界各地的產業活動演講的技術推廣人員 Esposito 分享他在軟體的願景 software2cents.wordpress.com 和在 Twitter 上: @despos

感謝以下技術專家對本文的審閱: 喬恩 · Arne Saeteras