設計和記錄用戶體驗的具體細節。
用戶體驗設計在產品開發過程中是複雜，多變及耗時的階段。組織良好的進程通過減少團隊成員之間的誤解和提供可預測性的結果可為團隊減輕壓力。在本文中，我想集中精力將主流方法映射到現實生活中的項目中並將可交付的成果整合在一起。
階段1.想法
此階段的目標是弄清楚目標客戶的業務是如何運作的以及產品設計的目標是什麼。低保真原型是一種有助於和股東確認產品的心智模型並討論一般設計方法的工具。在這一點上，我們正在尋找“我們正在建設什麼？”此問題的答案。
旁註：我覺得“我們在建造什麼？”中的措辭比“我們在解決什麼問題？”更好。它更廣泛，因為它涵蓋了我們現有的，持續做的項目或旨在將用戶體驗從優秀提升到卓越的案例。但是，如果你要從頭開始做一個項目或對某主題感興趣，我建議你可以查看斯坦福大學的“需要尋找工具”相關學科知識並瞭解Google Ventures研究的項目。
交付
業務流程圖
在深入研究之前繪製一幅流程圖是很重要的，所以要注重流程而不僅僅是某一些特定的特性。此外，該圖將有助於開發人員之後設計軟件架構。我建議使用簡化的BPMN或類似的方法。不要過於複雜化：製作流程圖的唯一理由是讓你的團隊成員和你自己有一些時間來“閱讀”這個過程，而不是讓你的客戶或管理層看起來感覺高大上。
簡化的BPMN圖表反映了第一藝術空間的根過程
低保真原型
此可交付物的唯一目的是說明我們設計特定產品的方法。此時，我們所需要做的只是澄清中心場景的導航並定義設計模式（例如，嚮導，一組卡片，WYSIWYG編輯器等等）。
常見的陷阱
因下面三件事，通常會將此階段擠壓到最低限度或完全省略：
1.錯誤的印象，每個人都能理解，因為他們說他們會這樣做。
2.這個階段的所有元素，如小紙張和手繪按鈕，從某種角度來看可能像個笑話。
3.有人可能認為這一步將會耗費很多時間，尤其是製作業務流程圖部分，而且只需立即開始繪製場景就更有意義了。
另一個問題是設計師有時會忘記他們的想法。他們更傾向於深入挖掘細節，而不是專注於大局，所以在設計師還沒意識到陷阱之前，產品需求正逐漸消失。
通常建議的手繪風格也可能一樣令人眼花繚亂：人們可能會將逼近真實的高保真原型與實際為低保真的原型相混淆。我們可以輕鬆地使用基於UI工具包的低保真原型替換紙質原型。最初，紙質原型設計是為設計師節省了一些“工具學習時間”。當時也沒有太多的專業性原型軟件，所以用計算機進行迭代將需要花費太多的時間。如今，我們擁有好用的應用程序和UI工具包（Google和Apple提供這些資源）。 將控件從一個文檔頁面粘貼到另一個文檔頁面比使用鉛筆繪製更快。
保真度對比
至於視覺風格，我建議使用和你要用於高保真原型的相同風格。 在這種情況下，你不用花費額外的時間將線框圖從裸骨架發展為可完全交付給開發的成果。
階段2.原型
在這個階段，我們的目標是全面思考界面的各個方面，併為視覺設計和開發整理完整的文檔。
共同原則
為用戶保持清晰，明顯的導航：確保他們及時掌握當前的自己位置以及接下來會發生什麼事情。
製作移動應用程序時，根據相應平臺指南進行設計。如果你必須這樣做，請確保你有充分的理由來說服別人。並將此理由做好記錄以方便未來討論;
如果沒有必要，不要發明新的控件和模式，儘可能使用最常見的控件和模式;
使用真實或類似真實的數據，包括姓名，文本和圖片。但是，不要使用知名人士的名字，令人反感或含糊不清的內容 - 儘可能保持中立;
考慮屏幕上的內容密度和系統的不同狀態;
注意在對需要移動輸入的鍵盤進行設計時，留出足夠的空間。數字鍵盤用於數字字段。
項目文檔
關於這個問題我想說的第一件事：線框的最終用戶是你的同行，軟件工程師和產品經理。確保你的文檔對他們是友好的。
屏幕註解，訪客流程
請記住，線框圖本身並不是一個自給自足的可交付成果。它是一個可視性說明文檔，可以幫助你將個人的想法傳達給團隊。使用文本註釋，引用鏈接等。
保持結構化：有意義地進行頁面排序並確保它們反映業務流程。 避免將所有屏幕放在一個頁面上：這將迫使軟件工程師來回滾動圖片。
將標準規則放在指定的頁面上，而不是將它們隱藏在線框圖內。 例如，如果你有工具提示，請註解它的工作方式，並將文件與UI副本相連，而不是將它們繪製在任意位置。
一套適用於整個系統的制定規範工具
交互式原型對於演示非常有用，但在大多數情況下，它們不足以直接進行開發。點擊整個過程並創建產品是如何工作的心智模型需要額外的努力。不要讓工程師的工作比應有的更難。不要將你的可交付成果限制在交互式原型中。
文檔清單
每個人都會犯錯誤。最有經驗的設計師也會犯錯，但是層面不同。這裡是一個簡短的清單，旨在幫助你在進一步傳遞之前對基本級別的可交付成果進行故障排除。
這是幫助你的UX檢查清單。下載後，複選框將是可交互式的。
常見的陷阱
“人們不閱讀”
這是真的。但是，人們也喜歡自信的做自己的工作。每當工程師在沒有得到你的設計時，他們就會逼迫要求你澄清自己的想法，然後等待你的響應，記錄下來，最後對此進行構建。否則，他們可能會誤讀線框圖並構建錯誤的東西。這意味著你要讓工程師負責記錄你的解決方案。
還有一件事：如果某問題的答案可以在評論中找到，沒有人會問我這個問題。我想我們畢竟不應該低估工程師的勤奮程度。開發人員甚至糾正了一次我的拼寫錯誤。
“很明顯”和“這是默認行為”
事情就是這樣：作為設計師，由於從業績表現到個人品味的廣泛原因，我們傾向於選擇某一些解決方案而不是其他的解決方案。 沒關係：用相同的問題請教兩位傑出的專家 - 你有可能獲得不同的答案。這意味著我們認為的最佳實踐，從工程師的角度來看，是數十億的模式之一。
即使是原生的iOS和Android應用程序也是自定義設計的，因此在Android應用程序中設計日曆功能時，你不能說：“將其設置為默認設置。”猜猜為什麼 ？- 因為根本沒有默認日曆這樣的東西。你可以複製現有應用程序中的日曆（順便說一句，這是可以的），但你應該向開發人員提及，且不要期望他們從他們那裡獲取任何有價值的內容。
“我們沒時間做這個”
我們都在創造性和快節奏的環境中工作，在這種環境中，時間是稀缺資源。但事實是，無論如何，你都會花時間來評論你的設計。 在這裡，你有兩個選擇。第一：你預先安排一些時間進行註解，並在準備就緒時傳遞文檔。第二：每次開發人員需要澄清時，你口頭（在信使中）發表評論。在第二種情況下，你會在當前的任務過程中反覆分散注意力。
此外，你無法充分估計完成項目所需的時間，因為它沒有明確的結局。因此，你可能會低估完成下一個項目所需的時間，從而無法在截止日期前保質保量完成項目。此外，想在幾個月內理解未註解的項目幾乎是不可能的。
驗證
在驗證方面，你有一些可選擇的選項。
同行評審
獲得快速反饋的最簡單方法是向資深設計師詢問。第二種意見可能會派上用場，你也可以在展示你的設計時進行一些調整。雖然如此，你的同伴可能與你具有相同的認知偏差，因此他們可能很難找到概念問題。
技術可行性評估
此類審核的主要目的是確保你的設計適合開發。但是，你也可以從工程師的反饋中受益，因為他們是從不同的角度看待項目。此外，如果你錯過了一些重要的事情，他們可能會提醒你。
可用性研究
方法和目的因方法而異，這取決於感興趣的問題是什麼。你可以做到便宜且髒，或者做得慢而且徹底，但不管你有什麼樣的資源，你都會找到正確的問題。我將在下一篇文章中講述我在UX研究方面的個人經歷。
結論
牛津詞典將經驗定義為“發生在你身上的事物，將影響你的感受。”這也就是為什麼設計用戶體驗不僅僅是對屏幕進行排序和佈置控件的原因。如果你的團隊中沒有專門的UX作者-那麼你就是作家; 如果你沒有研究員-那你就是。既然你是經驗創造者，那你就是那個能讓別人感到悲慘和無能或是有資格和有能力的人。
強大的力量帶來了巨大的責任。
原文作者：Galina Kalugina
原文地址：https://uxplanet.org/ux-design-framework-402368bb6645
本文由Mockplus團隊翻譯，Mockplus做原型，更快更簡單，現在下載Mockplus，免費體驗暢快的原型設計之旅。
閱讀更多 Mockplus摹客 的文章
