2016 年 1 月

第 31 卷，第 1 期

本文章是由機器翻譯。

領先群倫 - 不要與 UX 相賭—改用框線

由 Dino Esposito |2016 年 1 月

Paraphrasing 蘇科學家愛因斯坦，我敢說，我不知道未來有軟體架構的存放區中，但如果即將推出的任何變更，其中一個會當然採行圖層的設計，由上而下方法。短的 UX 導向設計，UXDD 是一種方法，主要是提升軟體架構的起點使用的框線和分鏡腳本。在 UXDD，elicitation 程序的結果並非乾一般集合的需求，但改為草圖清楚地指出使用者的方式運作-和-即可馬上集合喜歡運作。而不用多說，使用者喜歡運作的方式是實際的商務程序的一般軟體表示。我看到事情，技術遺失重要的角色中有十年的軟體架構。今天花更多架構設計人員能夠結合可用技術和產品來達成一組特定的目標，同時將帳戶的現有投資特定技術、 舊版平台、 技能和預算。

聽起來很像 foregone 的想法嗎? 嗯，或許不會。此軟體的願景是什麼新的但也永遠不會成為主流軟體的願景。

定義框線

我曾使用 「 框線 」 這個字，也並用交替字 「 草擬 」。 讓我釐清並設定可以變更最初之間的差異，UXDD 的觀點而言，框線和 「 模型 」。 以下是一些定義詞彙中 UXDD:

• 輪廓是徒手畫的繪圖，主要是為了記下並擷取閃爍的概念。理想的介面，以保存草圖是文件，包括從高速公路紙張 napkins。輪廓可能代表最上層的基本架構的架構，但更有可能會擷取使用者和系統之間的互動的概念。
• 框線是草圖更精確且正確型別，因為它可提高版面配置、 巡覽邏輯和內容的組織的詳細資訊。在此同時，框線是無從驗證的任何 UI 詳細資料，例如色彩、 圖形、 陰影和字型。
• 將圖形面板擴充框線時，它會變成模型。

沒有模型和框線重要心理差異。當您顯示應用程式的使用者模型時，注意無可避免地會擷取圖形的層面，例如背景影像、 色彩和樣式。很少，使用者的注意力被組織的資訊及如何巡覽及配置相同的資訊。框線會有點來說模型完全缺乏圖形化的內容。可繪製框線，以手動方式或透過一般的繪圖工具，例如 PowerPoint Visio 或或許現有。更具特製化的工具，不過，都會顯示若要將框線連結在一起，藉此形成分鏡腳本，讓使用者有具體的最終經驗概念。

框線會符合成本效益的原因

開發人員通常同意使用表單的框線展示層，即使規劃的後端之前了解是大幅很有幫助。許多年，此產業裡 cultivated 架構軟體是與架構建築物大致相同的概念。靈活移動然後出現來對抗我們撰寫程式碼之前，需要大事先中和已關閉的設計概念。Not Agile 其實是表示沒有設計和任何分析 — 相當則相反地，我想 — 但 Agile 可能無法解決核心問題的軟體開發。什麼是軟體的最終目標? 我們只需撰寫軟體只以儲存及處理資料嗎? 相反地，不是我們撰寫軟體主要是為了讓使用者在更有效率且更快速地執行商業工作嗎? 在第二個案例中，現在變得相關性的展示層是最重要的。在此情況下靈活度表示逐一查看和使用者定義一組可接受的框線與共同作業，和 [分鏡腳本而不是資訊不足，無法建立良好的持續性模型。

但並不罕見軟體管理員，以查看無用的成本，以便將任何交付項目，也沒有直接的錢的上框線所花費的時間。這麼一來，您可以避免在實際軟體成品上具有小組的焦點。軟體與土木工程比喻是老道的比喻，它說下列恢復它現在相當有用: 當您想要建置車庫 (不是以更別提建築物的更複雜的型別)，您會解釋您想要或只是必須是放在一起的基礎構件，然後抱怨當他們將內容傳遞 bricklayers 您從未想或要求嗎?

建立及驗證框線是額外的工作來管理和額外的成本。不過，也會調整的線框檔案 jots visual 的畫面。是另一個則是調整數千行程式碼所組成的多層式的系統。採用框線和 UXDD，您肯定會花更多的時間才能撰寫任何一行程式碼，但您節省更多的時間之後傳送第一次衝刺 (sprint)。並儲存更多時間系統為偶數其效果和優點可以是更好發生和評估。UXDD，要更接近比以往立即傳遞專案的夢想。儲存在後續的衝刺 (sprint) 和 remakes 是遠超過您事先花使用框線。

如何產生框線

在 UXDD 和框線的基礎在於軟體不應建立模型的商務網域的概念。相反地，它應該寫入至鏡像商務領域。這項轉變的觀點來看我們使用系統的設計模式中有相關的 spin-offs。特別是，它提供進行初步分析強以工作為導向的焦點，並模糊了模型的相關資訊。此層面 scares 大部分經理人聽起來怪怪的做法，因為沒有人未數十年。訪談，與客戶獲得預期的結果一直以來都建立全能的資料模型來讀取和更新系統的狀態資訊。網域和應用程式的複雜度增加時，這個方法是越來越不有效率且容易管理。

個別群組訪談是仍在可接受，但是更為理想如果目標是了解系統與工作，會使他們的環境中處理相關的事件。事件重傷是新興的方法來擷取框線，並迅速有效地配置展示層。您可以找到簡短介紹的作法重傷事件，在撰寫自己的作者和 master， bit.ly/1N25MJl。簡單的說，這是方法，以瀏覽複雜的商務領域既快速又直接的點的方式。它具有強式工作導向的類別，並讓您深入了解網域，特別是，若要實作的工作。更棒的是，它可讓您聆聽使用者真的需要做些什麼以及實際的流程動作、 觸發程序，以及您要反映和反映透過軟體的事件。

如何驗證框線

這是一個關鍵點: 沒有明確簽核和框線建立客戶接受度，任何工作，則遺失它並不保證最終的理想 ux。UXDD，您必須核准框線之前在您開始撰寫程式碼中任何嚴重的數量。

看看框線的客戶是只有第一個步驟，不過。框線的有效驗證通常會需要投入更多心力。您必須對使用者顯示執行工作，以及完成指定的工作結果的序列的步驟和畫面的意義。腳本是用來撰寫商務工作的多個框線串連參考詞彙。如果不夠精確框線的內容，播放腳本真的會接近測試軟體所做的原型，只不過腳本的成本是軟體原型的成本，而且幾乎可以立即解決。在進階案例中，甚至可能相當合理的影片的使用者使用影片播放腳本時。許多，因為每個作業所需的平均時間，可能會顯示其身體語言。正確的驗證程序也可能含有認知分析，例如測試-操作-測試-結束 (切合實際) 的項目。中所示 [圖 1, 、 切合實際基本上反覆試驗錯誤工作階段的目標是逐漸提升使用者滿意度，以及達成共用的目標。

[圖 1 認知分析適用於 UX 分析切合實際流程圖

沒有不難，切合實際 — 它是一般常識，但為 foregone，其實不然，它可以有效地運作。適用於認知分析越和越您花事先，越您稍後將儲存。對於使用者執行這項操作，取得平衡是主要是正數。整體來說，它不能在啟動時撰寫程式碼以假設模型為基礎，然後找出錯誤的成品遞送較差。

其中的故事

有本文所示。永無止盡的一系列的會議之後, 小組與客戶已確定，來建置網站的所有層面必須已正確討論及分析。系統每一方面既然釐清，撰寫不便。沒有出現意外的錯誤狀況的順序。蜜月旅行持續幾天，直到程式開發人員登入頁面上引發的第一個例外狀況。登入要發生的情況只能透過成員資格? 會有任何的社交驗證? 答案是 「 否，客戶未提及。 「 resounding 登入，所以傳遞未經驗證的 Facebook 和 Twitter。您猜怎麼著？ 社交登入是客戶嚴格的要求。很嚴格因此明顯它不沒說。社交登入的額外工作，並了解，事先就有可能導向成員資格系統的實作方式不同。在此同時，很明顯，如果任何人都已顯示使用者的登入頁面社交按鈕缺乏輪廓就已記下並報告，在小組內的每個人都中所示 [圖 2。

圖 2 框線的社交登入建立該 Nobody

從原型的框線

您覺得 elicitation 程序中使用認知分析的概念所投入越多，越您可能會尋找特定的工具，可協助建立框線和分鏡腳本。框線是相當容易、 快速建立，但也如此的分鏡腳本。請注意，少數框線簡單串連就夠特定使用者和特定商務案例。某些情況下，必須撰寫一些程式碼，證明概念。一些術語也適用於此處有助於釐清。概念證實通常是小型的練習，以確認假設或播放使用給定的內容中的新技術。我要呼叫的概念為網域特定"hello world"。 原型是假的系統嘗試模擬完整的系統，為了測試可行性或甚至是系統的可用性。這是您需要將分鏡腳本證明不太夠。最後，術語經常交換使用同時也有其本身嚴格定義的另一種說法是 「 駕駛員 」。 試驗是只根據一般的適用對象或資料集的子集測試完整的生產系統。

總結

若要有效，框線應該只在不同的抽象層級比網域磁碟機設計無所不在語言專案關係人之間交換的貨幣。無所不在的語言和框線的目標是簡化交談，並降低風險的曲解，詐欺的資料，以及錯誤假設因為缺乏資訊和指引。

無所不在的語言和框線不可以神奇地將構想轉化成執行程式碼的方法。遠低於 ambitiously，兩者的重點是要找出您可以降低成本的撰寫接近預期的預算及期限的軟體的具體步驟的順序。

下個月我將這進一步，討論使用框線 (深度) 架構的改變。

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

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