2019-11-26 濤濤
寫這篇文章的初衷，是在實際工作中遇到 PRD & DRD 文檔，對于一些交互設計圖，會產生不理解，或者說在實際落地畫圖的時候會發現一些前后不一致的問題，解釋過于冗余，不清晰。在接觸新的業務時，很難把新理解的內容從上至下的消化完整。所以希望通過這篇文章幫助剛接觸交互的同學更好地開展交互設計工作。
在傳統瀑布式需求分析流程中，我們設計師往往拿到的是已成型的信息架構圖&產品結構圖&關鍵業務流程圖，只是了解一下大概是什么類型的產品，很難發現企業產品中真正關鍵的流程價值點在哪里，或者說也不清楚后續發展的走向，只能卯足了勁去做圖做說明，整理完整。時間緊迫壓力大，又要照顧整個項目。往往決定產品成功與否的，是產品 20% 的主要功能（二八原則）。所以在面臨初期產品設計中，應該將主要精力放在重要功能流程中。
目前，在互聯網產品中，敏捷開發是所有產品設計者最推崇的。原因在于，能夠對業務、設計、開發更有前瞻性&敏捷性。
產品交互的成功一定是建立在業務需求提煉清晰的基礎上。業務需求的價值提煉，也是設計師需要參與完成的。業務需求是一個比較大的任務，來源可能是老板的要求，可能是產品提出的，也可能是用戶的反饋。通過業務需求，我們要分析出相關的業務目標。有個偶然的機會，了解到彩色 UML 的設計方法，在具體實踐中，感覺這個方法能夠快速適應任何業務流程，簡單方便，易懂，并能快速發現業務流程中的問題，加以修正完善。
有幸認識王海鵬老師，他推薦了早年他翻譯的彩色 UML 建模一書，作者 Peter Coad，是將彩色和企業組件集成到建模技術之中的第一本書的主要作者，是世界上經驗豐富的建模人員之一，他所創建的模型幾乎涉及到所有行業。
此書是第一本介紹用彩色來表達軟件設計的著作。作者用 4 種顏色來代表 4 種架構型，給定一種顏色，你就知道這個類可能具有哪些屬性、鏈接、方法和交互。得到的彩色構建塊能創建更好的模型，并獲得應有的認可。彩色和架構型僅僅是開始。作者更進一步將這些架構型發展為 12 個類的領域無關組件。作者在過去 10 年中創建的每個模型，都遵循這個組件所表達的基本形狀和職責。
筆者利用彩色 UML 建模的設計方法，用于業務梳理工作，達到了意想不到的效果。以下為彩色 UML 建模基本概念（截取彩色 UML 建模書中的介紹）。
△ 《彩色UML建模書》第9頁
△ 《彩色UML建模書》第10頁
△ 事例會員注冊
定義：ER 圖是用來描述現實世界中的實體關系模型，所謂實體是指客觀上或者邏輯上存在并且可以區分的人事物。
作用：促使你以最適合技術理解實現的方法，來規范的描述功能模塊的核心要素，其實就是數據庫的物理結構。而這種描述是無二義的，最清晰傳達 PM 的設計思想。
功能結構圖就是按照功能的從屬關系畫成的圖表，在該圖表中的每一個框都稱為一個功能模塊。功能模塊可以根據具體情況分得大一點或小一點，分解得最小功能模塊可以是一個程序中的每個處理過程，而較大的功能模塊則可能是完成某一個任務的一組程序。用通俗的話來說，功能結構圖就是以功能模塊為類別，介紹模塊下各功能組成的圖表。
作用
信息架構屬于用戶體驗的結構層，是產品的骨架。一般是由產品經理或者更高層的管理人員給出大框架。除非是大的產品迭代，否則不會大改。
作用
信息結構圖構成要素
定義：產品結構圖是綜合展示產品信息和功能邏輯的圖表，簡單說產品結構圖就是產品原型的簡化表達。
作用：它能夠在前期的需求評審中或其他類似場景中作為產品原型的替代，因為產品結構圖相較于產品原型，其實現成本低，能夠快速對產品功能結構進行增、刪、改操作，減少 PM 在這個過程中的實現成本。
業務流程圖，不是操作流程圖也不是頁面流程圖。它是產品的整體業務流程，直接和業務掛鉤，可以說是產品的核心流程。
作用
通過業務流程圖，鉆研關鍵事件的流程，分析為什么要這么做，探索出更深層次的問題，從而對現有不合理的業務流程進行重組優化，進而制定優化方案，改進現有流程；闡述在項目中各個角色是如何產生相關聯系的。
繪制規范/建議
任務流程圖就是通過圖形化的表達形式，闡述產品在功能層面的邏輯和信息。它能夠更清晰、直觀地展示用戶在使用某個功能時，會產生的一系列操作和反饋的圖標。
作用：基于業務流程，進行任務流程梳理，闡述角色和程序發生交互的流程，你如何進行操作，系統如何進行反饋。
任務流程與需求文檔中的業務流程并不一樣。雖然它們都是流程圖，但業務流程更偏向于業務限制、后臺邏輯等，并不過分注重用戶的操作邏輯。而任務流程則需要關注用戶如何操作、界面如何反饋等，從而引導用戶完成用戶目標。
定義：指電子產品具體所呈現的頁面跳轉流程圖。其承載了業務流程圖所包含的業務流轉信息。
作用：
定義：頁面的模塊、元素、人機交互的形式，利用線框描述的方法，將產品脫離皮膚狀態下更加具體跟生動的進行表達。
作用：用例闡釋者，用來了解用例的用戶界面；系統分析員，用來了解用戶界面如何影響系統分析；設計員，用來了解用戶界面如何施加影響及它對系統「內部」的要求；類測試人員，用來制定測試計劃活動。
構成要素
限制
包含范圍值、極限值等。
范圍值主要指數據的取值范圍。比如，當你的界面上出現了下拉菜單、篩選按鈕、滑塊等控件時，你必須標注清楚它們的選擇范圍，否則開發人員就不清楚該如何設定，如圖所示。
極限值主要指數據的顯示限制。比如，最多應該顯示多少字數，過時如何顯示，是否折行等，如圖所示。
狀態
包含默認狀態、常見狀態、特殊狀態等。
「默認狀態」主要指默認顯示的文字、數據、選項等。這些內容需要注明，否則開發人員可能難以意識到這是用戶填完的效果，還是默認就有的。
「常見狀態」主要指針對某一個模塊，經常遇到的一些狀態。這些狀態都需要在原型上表述出來。比如一個普通的積分模塊，一般會出現 3 種狀態：未登錄狀態、登錄后未簽到狀態、登錄后已簽到狀態，如圖所示。
「特殊狀態」一般指非正常情況下的樣式、文案、說明等，如圖所示：
操作
包含常見操作、特殊操作、誤操作、手勢操作等。
「常見操作」主要指正常操作時得到的反饋狀態。比如一個普通的翻頁控件，在經過不同操作后會立即出現如下的狀態。
「特殊操作」主要指一些極端情況下的操作。一般，用戶不會這么操作，但是一旦遇到極端情況，還是要想好應對措施，因為對于開發人員來說，不管是正常的還是極端的操作情況，他們都要去編寫對應的代碼。如下圖，是填寫用戶信息的例子，當不寫交互說明時，開放往往會遇到很多問題：如果已經勾選了 2 個人，再勾選第 3 個人，怎么辦？如果勾選了「張XX」，下面區塊中會相應地出現張XX的信息，那么這時候允許修改張XX的身份證信息嗎？假如允許的話，修改后「張XX」還保持勾選狀態嗎？表單提交后要新增一個被保險人信息嗎？若修改的是除身份證號碼以外的信息，「張XX」 還保持勾選狀態嗎？提交表單時是覆蓋原存儲信息嗎？若修改后出生日期、性別與身份證號碼不吻合怎么辦？等等。
面對各種復雜的情況，一方面要和開發人員積極探討，看看有沒有其他的解決方法可以簡化各種邏輯判斷；另一方面，在得出結論后，要把交互說明寫清楚，避免出現讓開發人員感到棘手的情況。
「誤操作」主要指當用戶操作錯誤時的情況。不過我們在設計時要盡量避免有用戶犯錯的機會。如圖所示，提示中已告訴用戶「庫存5件」，如果這個時候用戶在「數量」一欄中輸入「6」會怎么樣呢？系統會自動幫用戶將其改為「5」省去用戶手動修正的操作。
「手勢操作」主要指用戶使用移動產品時的操作方式。常見的有點擊雙擊、長按、捏、伸、滑動等等。
反饋
用戶操作后得到的反饋動作，包含提示、跳轉、動畫等。
「提示」主要指操作后，系統反饋給用戶的文字說明等，如圖所示。
「跳轉」主要指點擊某個鏈接后，頁面跳轉到哪里。設計師需要在原型上注明跳轉時是「原頁面刷新」還是「新頁面打開」。如果是做手機應用的話，需要注明跳轉時的轉場方式，如圖所示。
「動畫」主要指用戶操作后，系統通過動畫的方式反饋給用戶。動畫給人的感覺比較友好、趣味性較強，是非常常見的一種反饋形式。比如刪除某條信息，該信息以漸變消失的形式告訴用戶：這條信息已經被刪除了。在移動應用中，動畫反饋的形式更為常見。因此設計師一定要在原型上表述清楚動畫的形式，必要時可以制作 domo 動畫演示效果給開發人員。
文章來源：站酷