在經典的尼爾森十大啟發式當中，「系統狀態可見性」可以說是如今交互設計領域當中，最為重要的原則之一。通過向用戶展現當前的狀態，讓用戶擁有對系統的控制權，建立用戶對于產品的信任感，這也是這種設計啟發式的最重要的價值之一。
但是，想要做到可靠、易用，系統狀態展現的技巧是很講究的。這里梳理了4種最為常用的方法，結合了不少實用的案例，希望對你有所幫助。
1.1、讓用戶知道自己在哪
沒有人會喜歡迷失方向，但是無論在現實生活還是在數字領域當中，這種情況都會發生。讓用戶知道他們在哪里是創建良好導航體驗的關鍵。應用程序和網站都應該凸顯當前的導航選項，幫助用戶了解他們所在的位置。
Google 的底部導航欄設計
1.2、要經過多少步驟來完成任務
這也是一個非?；镜牟僮?，通過展現步驟數量，幫助用戶來預估完成這個過程所需要的時間。
Selecto 的調查問卷的設計
數字界面畢竟不是現實世界中的真實硬件機構，用戶更多只能借助交互過程中的即時視覺反饋來確定是否完成了操作，即時的視覺反饋因此顯得非常重要。
即時的視覺反饋讓用戶的操作得到了視覺上的「認可」，從而強化了「確信感」，這樣一來一回的確認可以避免錯誤的發生，比如可以避免用戶因為「感覺沒有點下去」而反復點擊。
這種視覺反饋的設計，最常見的范例就是點擊按鈕按下的微交互動畫，它告知用戶「系統已經捕捉到點擊交互了」。
AliAli 所設計的懸停點擊動畫
但是在某些狀況下，按鈕的視覺反饋還有很多不同的呈現形式，有更多可見的、可理解的新形態，可以在原有的基礎上探索更多可能性，比如下面的
2.1、單擊點贊按鈕
Spread love, not viruses ，作者 Charles Patterson
2.2、開關按鈕
這個開關按鈕不僅有點擊動效，而且色彩和按鈕標識也隨之改變，更為清晰地表明狀態，甚至兼顧到了視覺障礙用戶
Switcher XLIV , 作者 Oleg Frolov
2.3、書簽按鈕微交互
這個書簽按鈕通過色彩的虛實變化來呈現書簽已添加的狀態，頗為巧妙。
Bookmark interaction，作者 Oleg Frolov
2.4、添加購物車微交互
在這種情況下，視覺反饋非常明確且優雅地告知用戶已經添加到購物車里面了。
咖啡下單動效，作者 Nhat M. Tran
3.1、系統正忙于什么事情
當系統正在加載，正在執行，正在運行的過程中，通過動效來告知用戶系統并沒有停止，而是正忙于執行某件事情，是避免用戶誤解的手段。在用戶等待的過程中，通常會實用無限加載的動效（一般使用在低于10s的操作中）：
對于超過10s的更長的執行過程，無限加載的動效會顯得令人沮喪，這個時候實用進度條會更好：
這些視覺反饋很大程度上降低了系統給人的不確定感。
對于移動端應用，在初始加載階段所使用的啟動動畫界面，是否精心設計，決定了用戶對于整個產品的第一印象，優秀的初始加載動畫能夠將用戶的注意力從焦躁的等待中解放出來。
Logo 閃屏 ，作者 Gleb Kuznetsov?
3.2、內容加載
當用戶需要時間來加載內容的時候，建議使用一種特殊的的容器「界面骨架」來展現。這種臨時的內容容器不僅能夠幫助用戶快速地了解界面的整體框架，構建用戶預期，并且能夠在后臺快速地加載數據，漸進式地幫用戶獲得信息。
內容加載，作者 Ginny Wood
這種設計方式對于移動端和桌面端的設計同樣適用：
界面骨架加載動效，作者 Shane Doyle
4.1、通知和提醒
有效的通知和提醒，能幫用戶意識到有新的事情正在發生。在多數時候，我們建議設計師使用微妙的動畫來進行通知，因為動畫效果會自然地吸引用戶的注意力，人類的雙眼的動態視覺其實是非常強的。
Aleksei Kipin 設計的通知動效
4.2、提示用戶采取行動
在很多情況下，用戶界面中會有很多地方會需要用戶提交信息。比如，需要用戶提交表單，或者用戶創建了一個密碼，但是在復雜度上不足需要修正，或者填寫郵箱來訂閱信息的時候，郵箱格式出錯，等等。使用適當的視覺反饋總能夠更加有效地將問題告知用戶。
內聯郵箱驗證機制，作者 Derek Reynolds
讓用戶有掌控感，就是為用戶創造更好的體驗。在很多設計方案中，視覺反饋會因為種種原因被削弱了，甚至被忽略了。但是當用戶在和 UI 進行交互的時候，期望度和可動性其實是高度依賴于這些動效和微交互，而這正是設計師需要設計出優秀視覺反饋效果的原因所在。
文章來源：優設 作者：Nick Babich
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
隨著車內屏幕越來越多，越來越大，駕駛者在開車過程中因操作屏幕而分心機率逐漸升高。眾多汽車制造商均希望探索出一種降低或避免「駕駛員分心」的安全性技術。
手勢，是指人手、手和手臂結合產生的動作，作為解決「駕駛者分神」這個痛點的解決方案之一，正在全世界的汽車制造商中掀起「熱浪」。
你只需要隨意的揮一揮手，就能掛斷電話；將手指向順時針或者逆時針方向移動，就能調整音量大小。
汽車手勢的出現，源于對車內屏幕的操作。而這些操作均來自于移動端的設計標準，比如蘋果IOS設計規范中的標準手勢或者谷歌Mertiral Design中的標準手勢。
△ 移動端常見交互手勢
常見的手勢如上圖，分別為
為了滿足手機屏幕外觀改變，屏內顯示內容越來越多元化的需求，設計師們也在探索屏內手勢的新玩法。
△ android底部導航欄按鍵從左至右分別為：返回上一級、返回主頁、多任務
2017年iPhoneX的發布，正式開啟了全面屏時代。為了替代Home鍵及android底部導航欄，各大手機廠商相繼開始擁抱「全面屏手勢交互」。
在車機系統中，部分汽車制造商也在積極迎接變化，比如理想one采用「三指下滑」的手勢交互替代「返回主頁」的圖標按鍵。
△ 「 三指下滑」表示返回主頁
2019年的Google I/O大會上，新版本Android Q選擇與IOS采用一樣的手勢操作邏輯，即在屏幕下方提供一個指示條，用戶在左側頁面邊緣右滑代表「返回上一級」、提示條區域上滑代表「返回主頁」、提示條區域上滑并懸停代表「多任務」。
△ android系統中的三種全面屏手勢
隨著全面屏手勢在手機端的操作交互上達成一致，相信在不久的將來，也將越來越頻繁的在車機端看到全面屏手勢的「身影」。
當汽車與數字屏幕相遇，如何讓屏幕與內飾結合的更加完美，又能突顯品牌特性，似乎給內飾設計師帶來了許多挑戰與機遇，「一字屏」、「T字屏」、「7字屏」、「旋轉屏」應運而生。
△ 拜騰M-Byte 一字屏
△ 理想one的T字屏
△ 合創007的7字屏
△ 比亞迪王朝系列的旋轉屏
與此同時，因為成本及技術的限制，汽車制造商的量產車型不得不在屏幕上做出妥協。理想one的妥協方案是利用3塊屏幕組合，在視覺上形成「大長屏」的既視感。
要讓3塊屏幕「變」成一塊屏幕，僅僅在視覺上做足功夫顯然還不夠，多屏聯動手勢交互也不能「缺席」。
事實上，多屏聯動手勢交互依舊來源于IOS及android系統中的標準手勢，它將不同的手勢進行組合，并與頁面聯動顯示，形成了多屏聯動手勢。
理想one在停車模式下，用戶長按并向左滑動，即可將副駕娛樂屏上的信息「甩動」至中控屏。
天際ME7不僅有3塊屏幕組合而成的前排「一字屏」，還有2塊后排乘客娛樂屏，5屏聯動的手勢交互，天際采用「手勢+屏幕顯示」來解決。
在中控屏、副駕娛樂屏和后排娛樂屏上采用五指抓取手勢進入多屏互動頁面，比如想把中控屏上的內容分享給副駕娛樂屏，第一步是單擊選中副駕娛樂屏，第二步按住并拖動中控屏至副駕娛樂屏位置，第三步在副駕娛樂屏中點擊確認。
視頻版交互演示：https://v.qq.com/x/page/w08791lhqus.html
通過隔空手勢接聽或者掛斷電話，這似乎是科幻電影中才有的情節。但正如開篇所說，車內屏幕數量增多，尺寸加大的同時「駕駛者分心」的機率也增加了，盲操手勢與隔空手勢的出現，是解決這個痛點的一種嘗試。
目前量產的汽車中，盲操手勢主要是通過標準手勢與聲音反饋的組合來實現。
比如在理想one中，用戶在空調屏上左右滑動可以調節風量，上下滑動調節溫度，且系統通過聲音反饋告知用戶操作成功與否。
與盲操手勢相比，隔空手勢似乎科技感十足，備受汽車制造商的青睞，我們不僅可以在各種概念車上窺見它的蹤影，在君馬SEEK上，也可以實際操作一番。
君馬SEEK提供8種隔空手勢。
△ 左圖：接聽電話 右圖：掛斷電話
△ 左圖：上一曲 右圖：下一曲
△ 左圖：音量升高 右圖：音量降低
△ 左圖：音樂播放/暫停 右圖：玫瑰花
與君馬SEEK相同，寶馬提供「向左」手勢代表上一曲、「向右」手勢代表下一曲，「yeah」手勢代表播放或暫停。
但在許多其他操作上，寶馬與君馬的手勢操作則各有特色。
君馬SEEK使用手掌的正面與反面來區分不同的操作，正面表示接聽電話·/音量增加，反面表示拒聽/音量降低。
寶馬則選擇向屏幕方向點擊代表接聽電話，手掌向右揮動代表拒聽電話，手指順時針畫圈代表音量增加，手指逆時針畫圈代表音量降低。
在倒車影像中，手指向右揮動代表調整視角。
△ 圖片來源于「汽車界的扛把子」的短視頻《寶馬手勢控制詳細演示》
在手勢交互上，拜騰也交出了自己的「成績單」。
拜騰的手勢識別共五種，手掌向下激活手勢識別，手掌向上啟動主頁面，手指移動代表移動光標，ok手勢代表確定，五指捏合可拖拽內容。
△ 圖片來源于太平洋汽車網《拜騰Concept手勢感應系統操作演示》
這些高大上的技術看起來令人興奮，但在實際使用的過程中，依舊存在識別范圍有限、識別精度不靈敏、識別后的響應速度慢等等問題，而各個廠家的手勢識別沒有形成統一的標準，且沒有大規模在在用戶中進行推廣，必然會增加用戶的學習成本。
手勢識別對用戶來說是「真香」還是「雞肋」，相信時間會給出答案。
參考文獻：
汽車內手勢的交互設計，是一個有趣又好玩的課題，但如何讓這個課題在好玩但同時易用、好用，恐怕只有設計師不斷思考，并不斷采用一些用戶測試的方法進行驗證才能獲得答案。
文章來源：優設 作者：點滴DESIGN
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
這次我們不聊視覺，也不暢想未來，只說說當下 HMI 產品設計與交互體驗。
本文內容會涉及一些專業的汽車知識名詞，因為篇幅有限，如有些知識名詞不太明白可以百度一下。
說到 HMI 大多數設計師應該是既熟悉又陌生，HMI 是 Human Machine Interface 的縮寫，「人機接口」，也叫人機界面，人機界面（又稱用戶界面或使用者界面）是系統和用戶之間進行交互和信息交換的媒介， 它實現信息的內部形式與人類可以接受形式之間的轉換，凡參與人機信息交流的領域都存在著人機界面。
聽起來是不是覺得這不就是 UI 嗎？有什么區別嗎？似乎差不多，幾乎是沒有區別的，只不過是在某些場合和設備上管他叫 UI，比如移動端設備，而在另外某些場所和設備上管他就叫 HMI，比如汽車車機和數控機床。所以這個概念也不用去特別較真，HMI 就權當作是汽車上的 UI 界面吧。畢竟汽車是高科技與工業結合的完美產物，「HMI」念出這個詞時候就感覺是蠻專業的！很般配！
剛才說 HMI 最早更應用于工業上，比如常見的各種機床、制造裝備。
或者說讓時間再向前推進一點！
而這里通常意義的 HMI 則更加聚焦點，基本特指汽車車機或者車載多媒體設備。
說到這里還是要從車載儀表盤說起，從德國人卡爾·本茨發明世界第一輛汽車，距今已經 100 多年的時間了，在那些還沒有 HMI 這個名詞的年代，那么他是以什么形態出現的？那就不得不提「儀表盤」了。
當然寫這篇文章并不是去評測誰家 HMI 更優秀，而是希望通過一些假設、實驗和推斷，和大家一起來探討一下如何更有效地設計 HMI。
屏幕越大越好？車內到底需要幾塊屏幕？
我們先從屏幕開始。
說到屏幕，設計師都是比較敏感的，因為我們最終的設計交互創意都是需要都是在屏幕上顯示展示出來的，HMI 當然也不例外?，F在在車載屏幕上你能看到最大尺寸多大？
拿特斯拉為例，Model S 和 Model X 車型都是 17英寸，Model 3 為 15 英尺。
當然他肯定不是最大的，熟悉汽車朋友你應該知道我想說誰了，沒錯就是他！擁有 48 寸可多段升降屏幕的 BYTON 新能源概念車 M-Byte！48 寸的確很夸張，難道屏幕越來越大就是未來 HMI 的方向嗎？
當然這個問題肯定是否定的，為什么？那就要從車載屏幕的作用來說起。
首先我是作為一個曾經就職于汽車公司的設計師，并且是一名地道的汽車發燒友，憑借對汽車還算熟悉和熱愛做出一些產品交互分析，以下如有不妥之處還望海涵。
按照功能場景總體可分為三類：主行駛狀態信息、附設備狀態信息、多媒體 & 外設
不可缺少還需要與使用者、場景結合，我們先來做一個大概的用戶畫像。
對應這些需求，汽車需要有儀表臺（屏）控制和顯示的區域有五個。
五個區域分別是：
其中前三個是主流配置，后兩個比較少見。
關于汽車設備這塊我們不做深入展開了，畢竟這篇文章主要討論的還是設計，直接看結果！
題外音：屏幕安全性的考量
汽車是比較特殊的設備，基于安全性考慮，汽車內屏幕尺寸不宜太大與太多。
屏幕總體為玻璃材質，但與車窗擋風玻璃的材質不同，當汽車遭遇碰撞的時候，車內屏幕極易破損并形成尖銳物，極大可能會乘坐人員造成二次傷害，所以車內屏幕不易太多，更不易太大。雖然車載屏幕變大變多已不可逆轉，而且隨著屏幕技術的提升，柔性 OLED 的應用也將會在一定范圍解決安全問題。但也需要汽車相關設計者多在安全方面進行考慮，任何產品體驗應該建立在安全基礎之上的，特別是交通工具。
為什么大屏幕操控成為了當前的 HMI 主流了呢？那不得不去提一下另外一個我們熟悉的設備——手機！
同樣一個有限的區域，如果用物理按鍵那么這個區域只能是固定的功能，而屏幕就可以無限擴展。特別是在汽車中控屏上集成內容會很多，體現就更加突出。
但是在汽車上的全部使用屏幕真的是最佳選擇嗎？顯然這是有待商榷的。
不可否認屏幕的確有很強的擴展性，但是缺點也是明顯的：1.觸控反饋缺乏 2.交互效率不高
對于這樣的判斷，我們可以通過兩個實驗來進行驗證。
將類似于 Surface Dial 這種智能按鈕交互裝置引入汽車的屏幕控制中，每個按鈕可以根據情景進行自定義，并且吸附到汽車屏幕的任何位置進行交互操作，相信這一定是一種全新的使用體驗。當然這一定是需要解決比如吸附力、安全性等一系列問題。
雖然目前的屏幕還無法做到完美觸控反饋，但已經出現了一些新的硬件技術來試圖解決這些問題，比如 Tanvas Touch，其定義為 「手指與觸摸界面之間的電子壓力控制」。簡單來說他們的產品就 「皮膚的磁鐵」 一樣，能夠更加精準地感應手指的動作，最后結果就是比 Apple 的 3D Touch 更加具有壓感的觸摸操作表現。
原理是利用手指尖觸摸顯示屏時產生的靜電引力來模擬觸感，通過電磁脈沖把更的反饋發送到用戶的指尖。
Tanvas 也正在與汽車制造商們合作把這項技術嵌入到汽車或屏幕上，讓人們更容易感觸受到不同物體的表面。
也許在未來我們真的會遇到他。
文章來源：優設 作者：殘酷de樂章
醫療行業的交互設計，跟其他行業有何不同？有什么要特別考慮的點？設計師應該注意哪些方面？
產品體驗設計通道中有條簡單好記的定義： 1+X。
「X」這個字母常被定義為更多可能性，它的誕生往往是為了更好地服務行業與產品。
例如在醫療健康行業中，不再只有C端用戶，我們要面對醫院管理人--員、患者、醫護人員還有企業用戶等；環境也不單是線上場景，它可能是醫院、企業大樓、社康、疾控中心等等；合作方式同樣獨特，我們做出的任何一個設計都是需要客戶過目的，每一個字段甚至都涉及到生命健康與安全，所以會要求我更高標準地了解行業與用戶，促使我們在項目前期去不斷學習和應用一些用戶研究知識，使設計更加貼近用戶。
過往經歷中，總結了用戶研究在各階段的介入場景和方法，接下來會具體講下在醫療健康項目中的運用。
企業健康項目是從一個合作開始的，公司的行政部門想要通過我們提供的健康管理產品來提升員工整體的健康水平，并將該方案進行復制從而提供一個企業健康管理的行業解決方案。
的確，員工是一個企業的寶貴財富，健康有活力的員工群體對提升企業生命力有著非同一般的影響。通過網絡文獻調研，我發現國內企業的亞健康狀況并不樂觀。
△ 國內企業健康現狀
第一階段用研——產品定義與設計方向
為了更了解員工和企業的真實情況和痛點，我們規劃了用研計劃，列出了三個用研目標：
目標1: 員工們的主要健康問題都是什么？
通過和企業方的溝通，我們發現員工的體檢報告是挖掘健康問題的源頭，于是我們由此開始研究。
首先，我們拿到了歷年的公司員工體檢數據統計（脫敏分析），整理出體檢問題的Top10。
△ 騰訊2018年體檢數據統計
獲許可，我們也隨機向外發放問卷，了解到一些公司職工最想要改善的問題。
△ 某大廈的用研報告（僅作為分析用）
目標2：企業現在所提供的服務有哪些問題，該如何改善？
B端: 由于這是一個B to C的項目，我們優先會去采訪企業端遇到的問題，溝通發現企業都會投資提供的健康設施（體檢，食堂，健身房等），其中很多設施并沒有被充分利用，或是沒有得到合理的分配，現有的線上預約流程也存在很大的后臺計算成本。
△ 騰訊提供的健康服務與設施（非疫情期間拍攝）
C端: 通過公司內部招募和訪談了20名員工，我們總結為三個主要痛點：
△ 員工在體檢健康中遇到的痛點
以上，我們也對企業客戶與員工用戶的訴求有了初步的了解。
△ B&C兩端訴求分析
目標3：如何定義產品目標與設計目標？
通過以上分析，和其他合作團隊一同討論了體檢與健康管理行業的現狀和盈利點，我們最終確定了產品方向：通過加入AI技術，分析用戶過往體檢數據來給用戶推薦最合適的體檢套餐，幫助用戶解析體檢報告轉化為更加易懂的方式，加強與醫療服務的定制化連接；并智能定制最適合員工的管理方式和行為，充分利用起公司資源。
△ 產品形象與定義
通過對整體流程的用戶情緒地圖分析，我們得出設計的關鍵詞：專業，貼心，安全
△ 階段情緒地圖分析
知識點1: 訪談與問卷調研
不要一上來就直奔主題，可以先問一些簡單回答的問題和閑聊，讓用戶進入放松狀態時再聊重點問題。且要時刻關注受訪用戶的狀態，比如：是不是開始疲憊，回答過于發散以及表達意思模糊等等。遇到這些問題，需要隨時做調整。
訪談的時候最好不要單獨行動，要有1個主導訪談的，一個記錄的。如果訪問過程很長，有條件以及受訪者允許的情況下，可以進行錄音有助于后期的整理。
訪談結束后，最好是當場，或者至少應該是當天就完成本場次的訪談記錄和總結工作。因為根據遺忘曲線，人在20分鐘后將遺忘42%的內容，而1天后則將遺忘74%。即使有錄音筆記錄，你也會忘掉很多細節的，諸如表情，用戶的潛臺詞等等。想到的設計解決方案也可以先記錄下來但不急于放到總結當中去。
第二階段用研——產品與設計驗證
確立了目標和方向，我開始從體檢預約和檢后管理兩部分來進行設計，由于在前期建立了用研機制，我們會定期對重要版本的內容和信息設計進行測試驗證，并讓用戶基于我們定義的設計標準來打分，判斷是否達到了專業，貼心與安全。
卡片分類-測試內容與排序
在檢后的體檢報告解讀中，我們需要對解讀結果進行結構化展示，方便用戶快速獲取有用信息，提高閱讀效率，由此我們運用了卡片分類法，讓用戶對其重要性的排序，得知對用戶來說體檢異常中的單項的指標解釋>危害性>指導措施。
△ 卡片測試與分析
可用性測試-測試架構與信息形態
體檢解讀的首頁我們繪制了三個版本的方案，來突出不同的信息通過制作原型demo來進行可用性測試，讓用戶選出最喜歡的并說明原因，最終選擇出一個最優方案。
△ 體檢解讀首頁可用性測試與分析
從彈窗內容組合到內容的體檢解讀指標的可視化設計我們都做了用研測試版本
△ 體檢解讀內頁信息測試稿
最終得到更加符合用戶認知的體檢解讀設計。
△ 體檢解讀設計
灰度測試與深度訪談
由于某些需求時間緊迫，例如體檢預約，當時很快就要到體檢季，于是我們快速搭建框架和基礎功能的設計，細節疑問點列出后進行灰度版本測試，并對前期招募的種子用戶進行測試訪談，總結現存版本的問題，同時我們也訪問了企業側，把他們的優化訴求納入考慮。
△ 體檢預約訪談腳本與測試結論
比如企業要求突出安全感，福利感與智能推薦，減少后臺結算成本等，我們便通過明確隱私授權認知的全頁面彈窗以及簡化體檢預約流程，2步變1步，增強頁面福利與智能推薦的感知渲染來滿足客戶要求，也得到了滿意的贊賞。
△ 隱私授權設計
△ 體檢預約設計
以上的用研方法其實可以運用在大多數的項目中，于是我在后續的騰訊健康模塊設計中也常會去使用，例如疫苗設計中的閃屏方案測試等等。需要注意的是用研應該被列入到日常的流程中去，而不能作為臨時安插，需要在項目實施前就進行用研計劃的擬訂，才能保證我們和用研同學有條理地客觀的進行調研和驗證。
知識點2:卡片與可用性測試
就醫流程是看似并不陌生的場景，痛點也非常明顯，就是常被提到的「三長一短」問題（掛號時間長，支付時間長，問診時間短），于是在進行線上就醫服務設計時，很多人會認為沒什么好特別調研的，競品也非常多。
然而其實在設計中，最害怕的就是「我以為」。記得在做某醫院的就醫服務項目時，由于就醫環境和用戶非常復雜，所以我們在做這個項目時堅持去到了前線進行了實地考察與影子觀察法，才發現了新的洞察。
實地考察中的望聞問切
說來很巧，現場的調研方法其實和中醫中的「望聞問切」有異曲同工之妙。
△ 醫療場景用研方法
「望」：可理解為影子觀察法：選擇最能反映問題的時間和場景去觀察用戶行為，發現痛點，經過幾天的觀察我們發現早上8-10點是醫院看病的高峰期，也是排隊最嚴重，院內最擁擠的時期，所以我會在這兩個小時集中觀察和記錄患者以及醫生的狀態。
「聞」：即為傾聽，其實也是訪談法中很重要的一個原則，多讓用戶去訴說，減少自己的主觀判斷干擾用戶的完整陳述，如果記不下可以錄音。
「問」：根據我們想要了解和觀察到用戶的行為進行提問。
「切」：這里和中醫中的切診接觸不同。是指切身去體驗患者的感受，比如我會根據自己身體的某些不舒服去掛號體驗流程，情景帶入。
以上的實地考察后，我在第一時間用我們設計師的手法來記錄整理：體驗地圖分析，并通過討論提煉出設計的關鍵點：引導，連接，合并與轉化。
△ 用戶體驗地圖與關鍵點分析
知識點3:影子觀察法
用戶體驗地圖的落地應用
這四個設計關鍵點其實來源于痛點描述中的一些高頻提到的情況，拿引導和連接這兩個點來說明。
引導：通過觀察發現，用戶在嘈雜的就醫環境中本處于極度焦慮緊張的狀態，對信息閱讀和處理的速度低于平時的好幾倍，因此我們需要提供具體的，正向的引導。
△ 精準預約設計
連接：通過訪談和自己實際的體驗發現，許多線上和線下的服務之間是斷層的，一方面需要流程上連接我付了款下一步要去哪，怎么拿藥；另一方面我們也發現線下的引導設計是一個非常重要的連接機會點。
于是我們從線上和線下兩方面進行了連接，提供了一套整體的解決方案。
△ 候診與取藥簽到設計
△ 醫院物料布局與落地布置
通過用戶關系圖了解了每個相關利益人的人群要素和訴求，在設計中不僅會考慮針對他們的設計，也結合體驗地圖中的機會點引出了設計原則，作為設計的指導和驗證標準。
△ 相關利益人分析與設計原則
測試與收獲
上線后，我們穿上志愿者的衣服，去往前線進行現場解說和用戶測試，經過一個月的努力，真實感受到了現場效率的提升和滿意度的提高，院方和使用過的用戶都非常滿意，這也讓我們設計師切實感受到了欣慰和成就感。
△復旦大學附屬腫瘤醫院病理會診 整體服務上線前后對比
這得益于我們能長時間與用戶在一起，真實地聽到了他們的聲音與感受，也把想法落地去幫助他們解決了問題。這個過程中，讓我們發現類似的垂直領域需要去到前線自己去感受，而不是隔著屏幕去觀察，每個人的思考角度會不同，會發現新的問題和洞察。
知識點4:用戶體驗地圖
在醫療數據分析的場景中，我們面對的客戶是政府和醫院領導。相信在做TO B設計的小伙伴經常會遇到這樣的問題：客戶時間比較難約，給的調研時間有限；決策層客戶思考的比較廣而泛，很難深入用研。
基于這樣的問題，我們想出了一個根據客戶群體層級，區別調研的方法。
梳理角色
去年年初，我們曾走訪多家公立和私立醫院，優先通過管理層梳理出了關于數據處理上報的流程。他們對數據的關注度和處理順序往往是有一個自下而上的上報過程，基層人員進行每個月度和季度的數據匯總，分析與簡單的可視化表現，上報給部門管理和上級管理者進行審核提煉，最終給到管理決策者一些關鍵現象和趨勢和對比。
由此提醒了我們，想要提供一個完整的數據解決方案，就需要繪制角色面板，區別調研目的與手段。
△ 醫院層針對數據的處理流程
分角色的溝通用研
我們確立了針對基層人員，中層管理者以及決策管理者的用研目標并展開了差異化的溝通用研，我們會每個角色找1-2人和我們3-4個同事坐在一起，以焦點小組的方法一同腦暴某一數據場景和所需數據。
△ 醫院數據現場用研
數據研究與總結應用
根據對醫院不同角色的溝通梳理出了一些總結點，運用到了產品和設計中。
第一：我們發現了管理者們最關注的一些醫院數據的形態，并打算把基礎數據盡量以對比，警示等手段進行分析與場景描述。便于管理者直觀獲取他想要獲取的輔助決策信息。
第二：根據不同角色提供針對性的角色面板，并梳理出個角色關注的數據模塊和現象。
第三：各角色具體數據字段的梳理與總結，并進行了頻率的標注便于后續的設計面板規劃。
第四：調研中發現領導層在看數據時需要來回切換系統，且看起來沒有一個統一的路徑和條理，因此我們也和對方溝通，通過故事化的手法進行數據分析的流程體驗設計，層層深入和下鉆，從現象挖掘到問題本質。更加符合了用戶看數據的順序和認知。
△ 長沙超腦項目設計版圖
除此之外，我們后面的產品和設計的匯報也會根據角色的差異來進行內容的調整，讓聽我們說話的人可以快速理解我們想要達成共識的內容，加快溝通效率，提升了在客戶心里的印象。
這個過程中，通過用研讓用戶感覺到我們懂他們，并讓其增加了參與感，對產品和設計都是一個推進器。
知識點5：TO B/G客戶用研
說了那么多設計師在用研技能上的應用，也許有人會有這樣的疑問：如何可以不斷提升自己在各方面學到的技能呢？一年前讀到《刻意練習》這本書，給了我一些啟發，在此總結給大家，希望對你們有幫助：
1. 制定具有定義明確的特定目標
「提升專業」是個很大的詞，所以我們往往定了一個很大的目標，然后被各種事情拖著然后拋之腦后。因此拆分目標才是第一步。比如最開始做交互時我發現自己在歸納場景時總會缺失，再比如每次自己在匯報總結時，耗時過長，缺乏重點，那么這些都可以被列入要提升的小目標，總之目標不要太泛太難實現，這樣實現起來會更加容易，也更容易堅持和自我激勵。
2. 持續學習與專注練習
研讀多本相關專業書籍，并應用的項目中去。這是我的一個目標也是方法。投入項目后，我們往往會陷入事件當中，甚至會就一個點和產品爭論不休。但其實跳出來，去看些新思路不妨為一個好方法。
比如我最近在讀《感官心理學》這本書，提到人們對于「軟」和「硬」的觸感印象會延伸到女性和男性的聯想上，提到女性人們自然都會有柔軟的印象，男性則會有剛硬事物的聯想，這也就充分佐證了對于不同性別上的設計形態差異。類似的小實驗可以幫助我們的設計更有說服力。
大多時候理論知識很枯燥，也難以一時間就可以用到，但只要你讀過，在需要的時候它就會突然跑出來給你靈感。
專注是我一個單線程人的特點，我很難在一個時間里同時處理多件事，所以我會每天根據要完成的訓練目標，把時間進行劃分，個人感覺這的確產出效率也會高一些。
3. 一定要有反饋
每一次的練習必須要得到反饋，這也是評審的重要性。但其實不同的目標點可以對應方面的專家，不僅限于leader了，同事也是很好的老師，比如我會去發現身邊匯報比較厲害的同事，幫我把關。只要遇到問題，一定不會放過去問用戶研究同學的機會。
某方面沒有老師怎么辦？讓用戶告訴你！首先我會常用可用性測試的方式去檢測自己的方案中的信息傳達，交互反饋等等在進步，另外我也會在每個項目后整理一個小總結，來記錄自己的思考與進步
另外，以下是我在用戶研究學習中讀過的幾本書，推薦給大家～
面對飛速發展的現在，各行業的產品也都在積極轉型，例如開始涉足TO B行業和客戶，開始研究00后的新生代用戶，面對新事物我們設計師更要保持敏銳的眼光，利用自身的設計洞察能力去挖掘新的問題與方法，于是新的技能和方式也開始出現，所以我們一直認為產品體驗設計師沒有一個固定的能力模型，還是要根據你所從事的行業和產品來發現所需的技能點去發揮價值。學習的過程中，我們成就項目的同時也在慢慢成就自己。
文章來源：優設 作者：騰訊 April
通過一個案例解釋那些讓你們看得有大的交互專業詞匯
UI 和交互這兩個詞匯是一對孿生兄弟，有非常密切的聯系，我們在前期了解 UI 的時候“交互”這個詞總是形影不離，出現的頻次極高。
但是，從我開始學習 UI 起，就被它困擾了非常長的時間，并不是苦于如何在實戰中應用，而是在中文語境下，交互有關的詞義實在是太“玄學”了，網上對它的解釋多數也含糊不清。
比如看百度詞條里，交互本身有兩種解釋，我們分別來看一下。
1.交互：指替換；互相；彼此。語出《京氏易傳·震》：“震分陰陽，交互用事。”（陰陽……難道是我想的那個意思？）
2.交互：通過某個具有交互功能的互聯網平臺，讓用戶在上面不僅可以獲得相關資訊、信息或服務，還能使用戶與用戶之間或用戶與平臺之間相互交流與互動，從而碰撞出更多的創意、思想和需求等。（交互使人類進步？）
單就這個詞，如果詞條看不懂，多在網上搜索相關的信息，咂摸個10天半個月的，是可以對它有個大致的認識。我會用一個比較簡單詞來概括它 —— 相交互動。即人和機器有了接觸并產生操作、互動的整個合集。
好不容易把這個詞搞懂，但是，交互事件、交互操作、交互方式、交互流程、交互原型、交互設計、交互文檔、交互體驗、交互動效……又是什么意思？
當我們在網上看一些交互相關的分享，你就會感受到這種混亂，比如下文截圖的這種表述方式。
這是我非常不喜歡的風氣，通過非常生硬的專業名詞包裹自己的思路，去總結一個非常簡單易懂的道理或原則，也就是俗稱的 “不講人話”。
所以，對于這個問題的反感，我打算自己做一篇 “接地氣” 的分享，對交互的基本常識做一次掃盲。
針對這些解釋，我找了一個我自己課程學員正在處理的真實案例作為依據，并進行改版優化，來解釋所有和交互有關的名詞具體含義，以及對應的實例是什么。
先看看下面這個案例。
Protopie線上可交互稿：https://cloud.protopie.io/p/a66d68949d
圍繞這個案例開展，該頁面是公司內部人員使用的訂單管理頁面，訂單代表的是為客戶上門測量門框門扇數據和進行設計定制的服務。
再詳細點解釋，就是銷售找到定制門的客戶，要創建一個銷售訂單，填寫客戶的基礎資料信息，然后設計師會上門進行進行測量，并將測量結果和定做要求編輯進去，以及填寫具體定制參數，還有服務的價格明細。
這個頁面與公司內部的四個角色有關聯，分別是銷售客服、設計師、財務、派單員。
銷售客服：聯系到客戶以后，確定客戶的資料信息基本需求，然后創建訂單填寫基本的客戶資料。
設計師：設計師在看見訂單后需要上門進行測量溝通，并給出方案確定報價，然后將明細也記錄到資料中。
財務：財務在做賬的時候有時候需要進來訂單查看具體的明細和數據。
派單員：派單員要根據訂單內的具體數據要求，聯系倉庫進行準備和發貨（進銷存管理）。
說到這里，大家應該還已經對這個頁面是做什么的有了基本的認識了把。那么我們先不討論它的優缺點，就來講講上面的交互名詞在這個頁面中的對應實例。
人機交互：就是指上面銷售、設計、財務、派單四個角色進入這個頁面，編輯信息、查看信息的所有操作和行動的合集。
交互界面：該頁面可以進行操作和編輯，就叫做交互界面。
交互操作：交互操作就是指我們操作這個頁面的行為方式，該頁面目前只有兩種，點擊（Tap）和上下滾動（Scroll）。
滑動Scroll
點擊Tap
交互方式：這是軟件允許用戶操作的規則，比如想要選擇設計師，就要通過點擊 “設計師” 欄目，在彈出的選擇器中，通過滾動列表來選取指定人選的方法，就叫交互方式。
交互事件：交互事件是指整個人機交互中的其中一個獨立事件，比如上面案例講的，點擊設計師觸發選擇器彈出的事件，就是一個交互事件，在選擇器列表中選擇具體設計師，也是一個事件。
交互流程：交互流程是完成一個操作目標的操作流程，范圍可大可小。比如上面選擇設計師的全部操作流程，可以定義為一個交互流程。而完成整個頁面信息錄入的過程，也可以成為一個交互流程。
交互動效：比如選擇設計師的交互流程中，點擊設計師選擇器的動畫效果，就叫交互動效。交互動效是由交互操作觸發而成的，方便用戶理解界面的內容，而不是任何在UI中看到的動效都叫交互動效，比如下圖這種。
交互體驗：它和產品、用戶體驗還不太一樣，專指用戶在交互流程中得到的體驗，維度并沒有覆蓋產品服務、情感化設計。
關于交互設計、交互原型、交互文檔，我們在下一個部分討論。這里的結尾我們就來講講交互體驗，交互體驗的評判維度有很多。但拋開所有技術分析，我自己將交互體驗的結果簡化成 3 個：難用、能用、好使。
交互體驗的好壞不是產品、交互、設計師、程序員說了算的，是由用戶來評判的。所以產品和設計行業都會強調 “共情” 能力，可以站在用戶的角度來審視我們做出來的東西，而不是呆滯的上帝視角。
之所以挑這個案例，就是因為即便作為讀者的你們，應該也可以想象如果你是這個頁面的操作用戶，那么體驗一定會非常差，雖然它功能可能是完備的，但一定是 “難用” 的。
而對難用的分析上，絕對不是直接去套理論分析哪里難用，而是先找到難用的原因。
這個是多數新手會犯的錯誤，不站在業務、用戶的角度去使用應用，找出原因，而就指望著去套理論套公示來對這個界面進行 “專業分析”。
所以這里我們簡單講講，它的主要問題：
頁面菜單選項太多，操作起來感覺壓力非常大
菜單內容的分布感覺混亂，很難形成記憶點每次要設置的東西在什么位置
不同角色對這個頁面的功能訴求不同，現在的設計顯然沒有滿足
在得到上面三個問題以后，我們就可以對這個頁面做出新的優化。 而要優化交互，我們就要首先從交互原型入手，即根據我們的想法設計出可以表現交互方式、交互流程的原型圖，比如下圖案例。
Protopie線上可交互原型：https://cloud.protopie.io/p/838165bdad
交互原型和產品原型不一樣，產品原型是用來解釋產品經理自己對產品功能的規劃，不需要著重考慮交互體驗，邏輯能跑順并且能講清楚即可。
而最終的設計稿，就是基于交互原型的基礎上，遵照它的交互方式、事件、流程展開視覺內容的填充和細化。
我們再回到這個改版過后的案例，講講我們在交互原型中的流程給大家一點啟發。
首先這個頁面的所有菜單，并不是只有一個人完成填寫，最起碼要由派單員、設計師兩個人，而財務、派單員進入到這個頁面中，通常會有明確的目的要查看哪一部分數據，其它的數據信息對于他們而言都是干擾。
所以，我們將所有數據類型進行劃分，統計結果如下（大致規劃，了解意思即可）。
完成分類后，舊版中只使用上下滾動查找菜單的方式顯然是不滿足實際需要的，所以我就根據內容的劃分創建一個分頁欄的形式，將不同類目的菜單對應進行匹配。
當我們要查找某個具體元素的時候，首先選擇對應的分類以后，再在分類下方查找。并且我們還引入一個新的 “交互方式”，可以通過左右滑動的 “交互操作” 來切換分類頁面。
并且這個分頁器欄目也可以進行標識，你的賬戶對這些內容的權限如何，比如 “不可看”、“只讀”、“可編輯” 等等。
而每個分類下方，對它們再做一次邏輯分類，還有區分必填項和非必填項。如果有大量非必填項目為空，那么對于信息的查閱檢索都是干擾，選填內容是用戶需要填寫的情況下才會去填，所以我們將每個分類下面的必填和選填也作出拆分，默認將選填菜單進行折疊（也可以是默認不折疊）。
這樣，我們就可以得到一個你沒有想到的 “船新” 版本。相信大家在這個版本的交互體驗肯定比老版好出不少。
當然，這只是對交互流程的其中一個改版，并不代表我們的交互只能這么改而已，實際項目中，優秀的設計師都會提供幾種不同的版本進行評審和測試，挑出其中最優的方案。
比如，我們可以不把分類頁面做成左右滾動的，而是做成上下滑動的。
所以，在了解上面兩套交互原型的案例，我們就可以再來介紹交互設計（UE）了。交互設計就是制定用戶操作界面的流程、方式、體驗的設計，和界面視覺設計并不能劃上等號。
雖然過去行業里喜歡強調，將交互設計 (UE) 和界面視覺設計 (UI) 崗位拆分開來，但這不是一個太合理的現象，對于多數業務和團隊來說增加 UE 崗位只是平添負擔而已，未來的大趨勢是由 UI 設計師負責交互設計的內容，當然也有個洋氣的新名稱叫 UX。
最后，在完成了上面這些內容的設計和規則制定以后，事情還沒完。專業的 UE 和 UX 還會提供一份文檔叫 “交互文檔”，除了將交互原型圖置入進去以外，還要具體來介紹它的交互方式、交互事件和交互流程的說明。
基于時間原因我就沒辦法提供一份基于這個案例制作的交互文檔了，大家只要明白，如果我沒在一個地方標注可以通過左右滑動來切換頁面的方式，或者默認狀態下選填內容是展開還是關閉之類的信息，那么最后落實到開發環節中可能就會導致很多細節問題的錯誤。
以上，就是我們關于對交互有關名詞掃盲和解釋的全部內容了。學習交互，要先從這些名詞的認識開始入手，搞清楚底層的邏輯和原因，然后再通過實踐和分析來積累對這部分內容的經驗。
只有深入去了解業務，并站在用戶角度審視，勤于思考的設計師，才能在交互領域中有所建樹，理論知識只是其中嘴不重要的一環。
下面再把所有涉及的名詞羅列一遍做個總結：
人機交互：用戶和機器、軟件實現操作和互動的過程。
交互界面：可以用來進行交互和操作的UI界面。
交互操作：用戶操作軟件、界面的具體操作，比如單擊、雙擊、長按等。
交互方式：軟件允許用戶操作的規則，比如按鈕的交互方式要通過點擊才能觸發。
交互事件：沒完成一次交互操作并獲得反饋的事件。
交互流程：用戶為完成目標所做的一系列交互的合集。
交互原型：用來確定產品交互方式的原型圖。
交互設計：制定用戶操作界面的流程、方式、體驗的設計。
交互文檔：用圖文記錄交互思路、具體交互規則的文檔。
交互動效：用來協助交互操作明確交互事件的動畫效果。
交互體驗：完成交互流程后所獲得得感受。
完！
轉自：站酷-酸梅干超人
在頁面導航欄中，常會見到返回、取消與關閉三者按鈕。許多同學會弄混它們的使用邏輯，所以寫一篇小文幫助各位梳理下。
先拋開圖標，我們回到功能本身的含義上看。如果我們不在產品的語境里，就單看「返回」和「關閉」這兩個詞，你首先會想到什么呢？
當我這么去問自己的時候，腦子里出現的并不只是零碎的詞語，而是一些場景和畫面。比如我走錯路了，需要原路返回；公司復工了，我要返程回去?；蛘?，睡覺時間到了，我該關閉電腦了；飯菜燒好了，我得把油煙機關掉，等等。
如果仔細去想的話就會意識到，語義衍生出來的，都是我們日常生活中的經驗和對世界的認知。產品中使用的各種語言，不管是文字也好，或者圖標圖形也罷，一直都是以我們對它最本能的理解為基礎的。所以只要你聯想自己對「返回」和「關閉」的看法，就能知道它應該在什么樣的產品情境中出現，以及它為什么會出現。
于是，很自然的，我們會把「返回」和「路徑」聯系在一起，所以「返回」在導航設計中不可或缺。并且「返」也預示著我們會回到之前的路徑節點，整個過程是連續性的，不被切斷的。而「關閉」就完全不一樣了，它一般和我們的動作有關，是一個短暫性的操作，相比返回也顯得更為獨立。
根據我們對語義的判斷，再結合實際產品中「返回」的場景，我們可以概括出「返回」和「關閉」的特征差異。
1. 返回
連續性：按照產品的頁面層級順次跳轉。但存在特殊情況，因為有些產品定義的功能出入口是不一致的，在信息架構層級已經做了一定的優化，所以返回不一定會按原來的路徑回去，可能會按產品既定的路徑。比如網易云音樂歌曲播放頁進入直播后返回不是到播放頁。
整體性：在產品功能頁面關聯性較強的功能中，「返回」需要連接各個頁面與層級之間的架構關系，因此「返回」作為操作節點，可以幫助產品功能的各個頁面之間建立聯系，維持產品的整體性。
2. 關閉
非連續性：用于產品中的臨時內容或臨時動作，比如彈窗或活動頁，與上一級頁面沒有直接關系。
獨立性：非產品原生內容或是產品內的獨立內容。比如小程序、瀏覽器標簽等。
3. 返回和關閉的使用場景
知道了返回和關閉的特征后，我們可以從兩者的使用角度上再去梳理一下。
現在產品中關于返回和關閉有三種狀態：
1 和 2 的情況很好理解，我們只要根據前面各自的特征去看就能夠理清場景。
3 的情況會有特殊性，因為它同時具有返回和關閉這兩種看起來相矛盾的特性。其實這是由內容決定的，當內容同時具有獨立性和整體性時，就需要支持兩種操作。如小程序可以作為一個獨立功能，但其本身又可以看作是一個完整的小產品，具有自己的頁面結構和頁面層級。所以小程序對于它所屬的產品，我們有關閉的需要，小程序內的頁面導航又需要返回來實現。
除此之外，產品可能開始只有返回，后面臨時出現關閉按鈕，比如微博「疫情地圖」中使用「小區疫情查詢」和「7×24 小時疫情快訊」后會出現關閉功能（幫助用戶快速退出）。
這里我們可以從連續性和非連續性的角度看，產品針對具有復雜層級和內容的頁面設計了順次（返回）和跳頁（關閉）的導航方式，其中關閉隨實際情境出現。以此為用戶提供了更為靈活的導航路徑，來同時滿足用戶逐級深入、連續返回瀏覽和選擇性查看、臨時關閉的需求。
針對于「關閉」，它和「取消」會有重疊的含義，所以有時并不能很好地去區分這兩個功能表達的應用場景。于是，我們可以借用之前的方式，先把「取消」單獨拿出來理解。
一般來說，「取消」意味著行為過程中，還有后續行為，整個過程沒有完成，當下后悔了，因此取消了當前操作。它更傾向于表達我們主動去做了什么改變，然后中途放棄了。
比如，想煮個飯，于是下了米，倒了水，定時，確認（取消），完成（關閉）。
這時候中間如果突然不想煮飯了，在定時之后，就停止當前行為，那就是取消。但點了確認并完成煮飯之后，這個行為就結束了，只能關閉。因此，它們之間就是行為上的差異。
就好比，打開微信公眾號文章，內容已經加載出來，行為已經產生并結束，這時候左上角就一定是關閉。而發朋友圈的時候，左上角是取消，那是因為行為過程還在繼續，沒有發布，所以可以取消。而發布之后，就無法取消，想要關閉，也就只能刪除這條朋友圈了。
所以在操作行為中的頁面，左上角最好是使用「取消」。
當我們對詞的含義有了進一步思考后，就可以去看它們在產品中的表現了。
比如廣告的關閉、推薦內容的關閉。都是產品自身提供的內容，用戶不想看到就選擇關掉了，沒有試圖去改變什么。
包括內容頁面，或者活動頁面，被點開，且加載完成呈現出來之后，這個行為就結束了，沒有取消的概念，只有關閉。
再比如，選擇圖片文件時的取消，微信發朋友圈、微博發帖時的取消等等，我們能發現都是用戶主動采取了什么措施，但是又后悔了所以選擇取消。
或者如游戲設置，就不適合用關閉，會讓用戶在理解上產在歧義，比如用戶設置到一半，不想設置了，那現在關閉的話，設置是生效了么？所以用取消會更合適。
這些時候，不存在關閉的概念，因為沒有內容可以關閉，只能是取消當前行為。如果使用關閉，與該場景下的用戶行為不符，反而增加了用戶對文案的理解成本。
簡單來說，取消強調的是放棄改變，關閉強調的就只是抉擇。
不過這里也有一個特殊例子，就是，微信公眾號文章轉發給好友，左上角是關閉，而釘釘里面內容轉發給朋友，就是取消。為什么呢？
在一些特殊場景之下，「關閉」是包含「取消」的。
好比剛才煮飯的例子，現在的電飯煲很高級，如果在過程中不想繼續了，拔掉電源就是完全關閉了，但同時這個行為也包含了人不想繼續煮飯這個行為，想取消掉了，所以這時候關閉是包含取消的。它跟文章加載完成，已經呈現出來，是不一樣的。
而上面這個微信與釘釘的例子，就存在這種包含關系。比如，內容已經加載完，要分享給好友，這時候加載出來的好友列表已經出現，只是選擇發送給誰的問題，用戶可以關閉已經加載完成的好友列表頁面，或者理解為用戶打算取消當前行為。
不過這樣的設計并不建議大家將其定義為關閉，因為畢竟行為還在繼續，使用取消反而更容易理解也更符合場景定義。
譬如，PC 的彈窗經常會同時出現叉（指代關閉）和取消，雖然操作的結果都是使彈窗消失，但是用戶的操作目標是不一樣的，事實上這里提供了兩種選擇，即我不想做決定，我要關掉彈窗，以及我決定現在不這么做，我要取消這個動作，這里的關閉其實就暗含了取消的動作。
在 PC 端，我們有足夠的空間為用戶提供不同的選擇，給予用戶充分的自主控制權，以滿足他們對功能的不同期待。而在移動端，我們需要刪減或合并功能，所以當用戶同時產生重疊的訴求時，我們往往會選擇當下最符合用戶心境的功能，這是「場景細化」的結果。這也能解釋為什么現在很多 PC 產品的彈窗中也只會保留取消，而不提供叉（指代關閉）的選擇。因為用戶面對功能不知所措、不做決定的情況已經越來越少，更多的用戶已經明確地知道自己應該怎么做。
這就是「取消」和「關閉」的差異，以及移動產品對兩者的取舍的根本原因。
同樣的，有一些頁面，取消和關閉都會用叉的圖標來表示，只是在不同情境中，這個叉同樣可以理解為取消，關閉，以及取消或關閉。差異點跟上述內容相同。
返回、取消和關閉看起來簡單，深入分析后又顯得復雜，但相對復雜的分析都只是為了能簡單地去運用。在這個問題中，每個人都可以從自己日常的經驗出發，然后在產品不同的語境里去體會一個詞語、一個圖標背后隱藏著我們什么樣的認知和使用的習慣。
那由這個問題延伸的，其實還有產品的導航方式，頁面出入口的設計差異，產品中整體與獨立，連續與非連續的內容結構，原生與非原生頁面的差異等等。
小問題同樣可以見大，但我們也不需要過度思考，本來問題的解讀角度就是因人而異的，也無法面面俱到，上面的只是我的理解方式。設計還是需要回歸到用戶和產品的目標，再去結合場景和產品業務的使用模式才能得出合理有價值的方案。
文章來源：優設 作者：呆呆U理
保持好奇，巧妙融合，追求卓越，自然而然
B 端工作看起來總是沒有 C 端工作那么有趣，面臨的限制比較多，面對客戶（金主爸爸），很多時候總是左右為難。在實際工作中，面對這些情況該怎么辦？筆者根據自己的 B 端工作經驗，總結了一些交互設計的要點。
從事 B 端 SaaS 行業已經兩年有余，從最開始面對需求的茫然無措，到現在已經有了自己的一些基本方法論，這期間經歷了從有人帶到自己摸索的一個階段。
每天看看文章、看看書，大家講的都是 C 端的產品，C 端的交互和體驗；每天看同行們分析的不是如何提高用戶活躍量，就是 APP 的設計風格。這在我一個 B 端交互看來，無比羨慕啊。
C 端項目的設計師感覺每天和一線用戶打交道，忙得不亦樂乎，可以與用戶直接對接，可以添加有趣生動的文案。
而對于一個做 SaaS 的 B 端來說，Boss 常說的話就是：
你這個顏色太鮮艷了。
我們是 B 端，你這種頁面布局不合適吧。
這個文案太幼稚了，不適合我們產品的調性。
中規中矩就好，不要太跳。
整理了一堆的字段，畫了無數的線框和流程圖，卻拿不出 C 端設計師才有的豐富多彩的作品集，
盡管如此，設計的原則是通用的，無論是尼爾森十大可用性原則，還是格式塔原理，在設計方案的落實上，都有著相同的方法論。
無意在此討論 B 端和 C 端之間的差異，僅以此文章來總結下我自己的一些工作經驗，如有錯誤，敬請指出。
從業務需求的對接，到界面交互的細節，從功能的設計要點，再到產品的發展導向，我總結出了以下幾個方面，逐步展開：
C 端設計師最開心的可能就是收到用戶的反饋需求了吧，這樣表示自己的產品還有人在用，然后建個群讓用戶開開心心吐槽，完了就從里面提煉適合產品的一些需求和建議。
而對于 B 端設計師來說，如何處理需求是其成長的第一關，尤其是 SaaS 行業，不會處理需求，產品的功能更新將會遇到極大的問題。
B 端的用戶不像 C 端，雖然可以用用戶畫像來進行歸類和分析。但是由于 B 端的直接用戶是付費用戶，付了錢的就是大爺，因此大爺提的需求你敢不應？
用戶提的需求亂七八糟，有些是體驗問題，有些是功能問題，有些就是屬于比較極端的需求。那種傳說中甲方要你做一個可以根據手機屏顯示顏色而改變手機殼顏色的需求，在 B 端行業也是存在的。
那么問題來了，我們該如何處理紛繁雜亂的需求呢，我從收集需求-評估需求-需求落地挨個講起：
如果你也打算像 C 端產品體驗群那樣建立一個群，完了將自己的用戶聚集在那里，靜靜等待需求的話，我勸你三思而后行。你可以這么做，但是應該明確群的目標，可以收集需求，可以是 bug 反饋群，也可以是更新通知群；但是不要將其變成一個純粹的用戶反饋群，因為這會導致用戶的吐槽聲音過大，而讓潛在的用戶流失。
B 端的客戶一旦使用你們的系統，就要付出相應的金錢和時間代價，不是說想換一家就能換。因此他對于已經使用中的用戶反饋是極其看重的，B 端的產品很大程度是靠著同行間的口碑傳播從而取得了良好的效益。如果一個新用戶想進群了解，結果一進去就發現大家都在吐槽這個系統的不足之處，那么可想而知他的選擇是什么。
因此，最好的需求收集方式是通過運營、市場以及客服的同事們的反饋，因為他們是離客戶最近的人，他們每天都跟客戶打交道，了解這個行業從業者的一些基本情況。很多時候，客戶回訪和運營對接的時候用戶會提出一些功能的建議。
通常的一種情況是，在 SaaS 行業，你的一個客戶的流失意味著你的競爭對手多一個客戶。因此一般市場都會有競爭對手的信息，他們會知曉客戶從我們平臺流失到其他平臺的一些原因。最重要的是，他們也為你提供了絕佳的競品資料，進而可以進一步明確需求。
收集好的需求，該怎么處理呢？
工具之前我用的是 trello，很好用，你可以將需求按照類型分為不同的看板，規劃產品的進度。
之后由于團隊的原因，改用 teambition，功能要豐富點，可以寫測試案例等，對于國內用戶比較友好；可以按照 KANO 模型將需求劃分為不同的類型，用以安排產品。
KANO模型
基本（必備）型需求——Must-beQuality/ Basic Quality
一個產品應該具有的基本功能，能滿足用戶的基本需求，比如，微信的基本功能是即時通訊。
用戶不會因為該功能的出現而覺得滿意，因為這是基本的、必備的一項功能。如果連這個都沒法滿足，用戶滿意度會大幅下降。
期望（意愿）型需求——One-dimensional Quality/ Performance Quality
用戶迫切希望產品能提供的功能，當提供該需求時，用戶滿意度會大幅上升，當不提供該需求時，用戶滿意度會下降。
比如百度網盤一直為人詬病的下載限速，無法對單次下載而付費。而需要開通會員，用戶的抱怨恰好說明了其痛點；當提供單次下載付費的服務時，用戶滿意度明顯提升。
興奮（魅力）型需求—Attractive Quality/ Excitement Quality
用戶對該類型的需求并無明顯的期望，但是若產品能夠提供該類需求，用戶滿意度會極大提升，也會培養用戶的忠誠度。
比如，很多產品都有實驗室功能，即對那些不是必備需求的功能設計一個開關，用戶打開后可以進行使用。對于有的用戶來講，這些功能很大程度上會帶來驚喜。當然，每個人期望不一樣，實驗室方案也可以視為另類的灰度測試，用以驗證用戶對于功能的需求。
無差異型需求——Indifferent Quality/Neutral Quality
產品無論是否滿足該類需求，用戶的滿意度是不會變化的，正如用戶不會因為收到「瑪莎拉蒂5元代金券」而感到開心。因此在 B 端行業，開發時間有限的情況下，無需為該類需求投入資源。
比如優化一個用戶訪問量很少的網頁，也無需因為領導或者客戶的個人喜好而改變后臺頁面的顏色。無論使其鮮艷活潑還是穩重大氣，后臺滿足基本的視覺要求和規范即可。當然，這并不意味著你可以把后臺設計的簡陋和雜亂。
反向（逆向）型需求——Reverse Quality
當提供方向性需求的功能時，會招致大部分用戶滿意度的大幅下降。比如常見的在搜索中摻加廣告、強制用戶授權過多個人信息以及推送大量無用的消息等，會導致用戶的反感。
通常需求的收集不是你一個人在進行，產品經理、老板以及其他同事也會幫助你收集，匯總到你這里的需求會開會進行討論，下一步要做什么。
做之前首先要對需求進行評估，評估的原則基本是按照 KANO 模型來，但是也會有比較特殊的情況。
交互設計師需要注意的是，你除了需要關注用戶體驗的問題以外，還要與開發一起評估該需求的實現；你不懂技術沒關系，開發會告訴你該需求的落地會出現什么問題，在實現上會有什么難度。這些在評估需求的階段都要提出來，并且在交互層面解決掉，否則你畫出了原型以后，開發告訴你這個頁面必須要修改，否則開發成本過大，無法在排期內完成，這個時候你再去改交互稿將會費時費力。
評估完需求，定好下期開發的需求后就結束了么？
其實并沒有，因為需求收集不可能是一個固定的階段，它是漸進的、不確定的。因此收集需求和評估需求會不斷在實際工作中疊加和重復，比如你制定好了需求優先級，已經著手開發了；這時候老板或者領導突然又增加了一個優先級很高的需求，所以你得重新安排這些需求。如何在敏捷開發中保質保量的完成工作任務，這是一場斗智斗勇的 battle。
前面講到需求評估的時候，需要與開發人員一起評估技術難度。其實在你將需求落地為交互原型的時候，也需要持續溝通，這完全是為了避免因為技術問題而產生修改設計稿或溝通不順暢的問題。
如果你是在做的過程中，持續與開發人員保持溝通，能了解到他們是如何實現這個功能的。當然，有些基本的設計原則所不允許的事完全不用屈服于他們的「淫威」，畢竟他們得按照你的方案來。如果開發懶惰而想通過最簡單的辦法來實現，用戶體驗又是極其不友好，那么請直接對其說「NO」。
比如常見的刪除的二次確認等彈窗，一般最好的體驗是在按鈕旁邊彈出；但有些開發懶得寫彈窗，直接調用瀏覽器的彈窗，即瀏覽器頂部經常出現的那種確認彈窗，這個時候你要堅決告訴開發，這樣搞是堅決不行的。
需求的落地伴隨著競品分析，判斷一個需求是否靠譜、落地方案是否成熟的一個重要途徑就是競品分析，可以通過調查研究相關競品是如何進行設計的。這對于我們有著非常大的幫助，可以避免很多的彎路，甚至能避免犯錯，提高交互方案的可靠性。競品分析又是個比較繁雜的事項，如果是有特殊要求可以做成報告的形式，如果僅是去參考對照的話只需要去體驗競品即可。
B 端的業務比較重要，尤其是涉及到數據的增刪改查和金額的計算，一旦出錯，將會導致無法挽回的后果。因此在出錯前和出錯后，應該有相應的挽回機制。
1. 出錯前
內容編輯類的功能應該提供自動保存草稿功能，防止沒有及時保存而丟失內容；刪除、禁止等較重操作應該有二次確認，防止用戶誤刪。
對于操作流程應該建立明確的引導機制，長表單可以分開按步驟填寫。
提示信息應該明確而及時。比如一個表單需要登錄才能填寫，在未登錄的狀態下，應該先提示其登錄再填寫否則用戶在填寫大量信息后，因為一個錯誤而前功盡棄。
系統內的禁止信息、警告信息、提示信息建立一套相應的規則。
2. 出錯后
用戶的時間就是金錢，這對于 B 端商家角色中尤為重要，大量訂單的處理、表格化的導入和導出、批量管理和網站運營等方面，對于效率有著極高的要求，商家通過可視化界面來完成某項任務。
在這其中，影響最大的莫過于交互方式了，相信各位一定用過各大銀行的網站，頁面的導航關聯性弱、結構不合理、提示不明確、交互流程過長，甚至有的網站光是登錄，就得大費周章。
如何提率，我認為主要從以下幾個方面著手：
1. 提高易用性
如果你的產品，讓人看一眼就能上手，那么說明是非常友好的設計。易用性不一定意味著簡單和低智，依據復雜守恒定理（泰勒斯定理），每個應用程序都有自己內在的、無法簡化的復雜度。
所以，提高易用性意味著要設計合理的交互，易用性分為對新手（小白用戶）友好和對老用戶（專家用戶）友好，包括數量最大的中間用戶。
如果你的界面是僅僅對于新手友好，那么可能完成的任務都是簡單而輕松的。但是對于老用戶，他需要更復雜的功能來處理大量龐雜的任務；因此在設計的時候，既要提供傻瓜式的操作方式，也要對專家用戶提供提率的工具。
2. 智能化
此處的智能化既包括通過大數據或者人工智能自動將操作步驟變得簡潔，也包括諸如一些字段輸入、自動定位、圖片識別、OCR 等方式來使用戶的效率得以提升的功能。
以前的用戶要摳圖可能會在 ps 中操作好幾個步驟才能完成，但是隨著機器學習技術的發展，ps 已經可以更加智能的摳圖。當然，還包括其他功能的智能化。
在 B 端 SaaS 領域，智能化也是一個重要的趨勢，針對不同的商家所面臨的不同的行業領域，我們或許可以提供更加全面且友好的服務。
3. 場景化思維
如果你深入了解你的用戶，去觀察他們整個行業的運作模式，以及他們對于業務的處理方式，你就會明白你的產品的走向。
你需要深入每一個場景，比如，在戶外旅游領域，發布旅游產品線路的可能是在辦公室中的編輯人員，帶隊出行的是在戶外場景中的導游，現場簽到的可能是集合點的管理人員，而處理訂單的又是另一個坐在辦公室里的小伙伴。
他們需要協同工作，才能使各項工作順利展開，發布活動-用戶報名-訂單管理-報名人統計-活動成行-集合點簽到-帶隊出發-旅游結束-活動評價-領隊評價-交易成功，這一系列流程中，面臨的角色是復雜的，而意外也是常有的事。比如報名人無法參加活動而導致的退款、活動因為天氣原因而無法成行、戶外活動發生意外等。
你需要做的就是：
場景化的思維會讓你設身處地為一線操作用戶的體驗而努力。因此，交互稿完成以后，徹底回退到小白用戶的身份，假裝自己是在某個場景下要做某件事，通過你的交互方案，能否順利完成自己的目標。
此處的通用性是指，在 SaaS 軟件領域，不同客戶所面臨的行業有一定的差別，可能這個功能對于 A 用戶極其重要，但對于 B 用戶，該功能并不重要。比如有的客戶想要在前臺展示某活動的報名人的姓名以增加真實性，用以吸引用戶參加；但是有的客戶就明確反對該功能，認為這個功能侵犯了用戶的隱私。
諸如此類的需求相離、甚至相反的情況太普遍了。合適的解決方式是建立兩套開關，一套是由 SaaS 服務提供商的統一后臺來配置，用以區分比較大的行業差別，比如電商領域中，可以配置店鋪類型為：美妝、服飾、食品、電子產品等；另一套開關在客戶的站點后臺，用以控制不同的站之間的差別，比如前臺界面樣式、交易流程、相關字段或菜單的前臺顯示等。
另外比較重要的一點，也是最基本的一點，軟件設計中存在一個原則就是高內聚低耦合，模塊化設計，用以提高系統內部組件的復用。
交互設計也是同樣的道理，可以將你的商品視為一個模塊，那么這個模塊無論是添加到網站，還是小程序，我只需要創建一個商品即可，可以同步更新到不同的平臺。
另外，訂單的管理只需要添加相關的標記即可（比如來自小程序的訂單標記為小程序，淘寶訂單標記為淘寶等），一個平臺發布，多個平臺同步，有效提高了運營人員的效率。
同樣的，如果你的 pc 端產品和移動端產品沒有實質性的運營差異（即當成兩種模式來運營），那么很多數據（如文案、圖片、banner等）的獲取可以采用同一個數據源 。
最后，提高系統內的一致性，減少用戶認知成本。在同一平臺內的頁面，樣式和交互上要盡量保持一致性，不要有的地方是總金額，有的地方是總價格，這會讓用戶犯迷糊。提高通用性，也意味著你需要關注并熟悉系統內不同功能之間的關聯性，盡量做到統一處理。
在進行商業化運作和產品功能的優化時，對于正向的用戶需要激勵，對于負向的用戶需要限制。
這是我在讀完有贊的白鴉寫的關于有贊產品設計原則的文章后，影響最深的一個原則，他寫到：
我們的使命是幫助每一位重視產品和服務的商家成功?！该恳晃弧购汀干碳页晒Α故俏覀冏钪匾年P鍵詞，我們要服務的是每一位商家，然后幫助每一位商家成功，但是為了整個生態的健康，那些不重視產品和服務的商家，我們是（可以）不服務的。所以我們在產品設計原則上，在產品做一些功能的選擇上，如果這個功能做完了會導致商家不重視產品和服務，我們是不會/能做的。
舉個例子：消費者購買之后（可以）有一個評價，我們的購物評價是要么開啟要么不開啟這個功能。我們不接受商家去刪購物評價，因為商家一旦可以刪了消費者的差評，他就（很可能）不會那么重視產品和服務了。所以有贊永遠不會提供刪除商品評價的功能，商家要么就不開啟?？梢圆挥茫绻镁鸵邮苡腥苏f你不好，商家可以去跟消費者溝通，溝通完了消費者自己改，但是我們不提供讓商家刪壞評價的功能。所以，這就是最基本的有贊產品設計原則，我們只服務重視產品和服務的商家，我們所有的產品設計原則都是需要這樣。
——《白鴉內部培訓：企業服務類產品的底層邏輯和有贊產品設計原則》
更多內容請看：
曾任支付寶首席產品設計師，現任有贊創始人的白鴉是很多人心里的產品大神，這份由他在內部分享的《產品設計原則》值得設計師、產品、運營等閱讀學習。
閱讀文章 >>我將其概括為一個產品的中正原則，即中立且保持正向原則。
一方面，對于企業未來的發展而言，正向的用戶能帶給平臺無盡的潛力，平臺可以和商家一起成長，而負向的用戶，則會給平臺帶來隱患。比如，淘寶既限制商家的違規運營和欺詐客戶，也限制 C 端用戶的惡意薅羊毛，在商家和用戶之間做一個中立者和調節者的角色。
我在做需求的時候，也遇到過很多的負向需求，這在商家看來是一個必須的功能，作為平臺應該提供。但是若是提供給商家，則會對消費者的利益造成損害，刪除差評就是一個很好的例子。
看了白鴉對于有贊產品原則的闡釋，我覺得每一個平臺類的產品，都應該保持自己的中正原則：
在 B 端行業，口碑傳播是非常重要的一種被動營銷方式，很多 B 端公司都是低調的潛行者，堅持中正原則，并不會損害自己的利益，反而會獲得商家的尊重和消費者的信賴。
啰啰嗦嗦說了這么多，比較細碎，不乏邏輯凌亂的片段，但也算是對自己兩年以來對于 B 端交互的一些心得吧。
其實交互的原則基本都是通用的，無非就是根據平臺屬性做一定的調整，不同的是產品所處的行業，每一個產品都無法脫離其所處的行業而存在，這也是使用產品的具體場景。
因此做一個產品前，一定要了解行業，去熟悉行業的通用做法，了解行業的專業術語和規范，研究行業的所屬群體等，這樣你就會做出真正適合市場且能讓大多數用戶滿意的產品。
文章來源：優設
寫這篇文章的初衷，是在實際工作中遇到 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 動畫演示效果給開發人員。
文章來源：站酷
在做交互文檔之前，我們先要明白什么是交互文檔、為什么要做以及做了給誰看。
交互文檔，即交互設計說明文檔。英文 Design Requirement Document ，簡稱DRD。主要是用來承載設計思路、設計方案、信息架構、原型線框、交互說明等內容。
有些人可能對文檔這種東西比較反感，尤其是從事工作不久的朋友。其實工作得越久，越會發現文檔的重要性，它可以幫助你理清思路，并記錄下來，便于回顧。
交互文檔其實要說給誰看，其實具體情況具體分析。有的公司老板也要盯交互文檔，以及甲方爸爸、運營部門同事，都有查看的可能。
【產品經理】產品經理與交互設計師可能是溝通最多的人，產品經理主要在文檔中確認設計思路和業務流程，然后過一下頁面交互模塊。
【視覺設計】UI設計師通常最關注的是頁面交互模塊，有著產品思維和體驗思維的設計師也會仔細看一下設計思路和產品背景，以便于自己更了解產品業務邏輯和用戶心理。
【開發人員】前端的開發同事和UI設計師一樣，最關注頁面交互模塊，其他的作為提升會輔助了解。而后端開發人員關注更多的是業務邏輯、信息架構、操作流程等，這些都清晰了，他們才能輸出一份準確合格的開發文檔。
【測試人員】因為測試人員是把關產品上線的一群人，所以各個模塊、步驟都應該去了解透徹，才能提出有效的bug。
本文主要闡述以Axure軟件為撰寫工具，大家可以根據實際需求決定用什么軟件（Sketch、PPT、Word、PS、AI 等）。比如小需求可以用Sketch，快而。如果是要給甲方爸爸/大老板看的，使用PPT會讓他們更好理解。
通常，一個比較基礎、規范的交互文檔（DRD）由：文檔封面、更新日志、文檔圖例、設計背景/思路、業務流程、頁面交互、全局通用說明、廢紙簍八部分組成。當然，這不是絕對，你可以根據你的實際工作需要進行增減。
比如，如果是C端產品的話，用戶調研的結論、用戶畫像、用戶體驗地圖等等，都可以放進去給看的人一個參考。尤其是在如今這么關注用戶體驗、產品思維的一個大環境下，這些數據支撐很有力量。同時還可以幫助開發人員、界面設計人員培養產品思維、體驗思維，大家一起將產品變得更好。
其次，交互文檔的整潔與美觀也很有必要。相信在過去幾年不少人有遇到過這樣的產品經理（兼交互），他們會輸出一些有時連他們自己都看不太懂或者直接從其它競品截圖來的線框圖。當開發和界面設計的人提出質疑的時候還美其名曰線框不重要，重要的是里面的業務邏輯。。。其實用產品思維想，交互文檔就是交互設計師的產品，而看的人就是用戶，保持良好的可讀性，可謂至關重要。
交互文檔的封面如上圖，通常包括產品的名稱、Logo、版本號以及版本發布時間、所屬部門、對接負責人/對接人。
我們都知道，在產品的迭代的過程中，需求/功能是會不斷調整的。而更新日志，就是為了迭代而生。它一般由修改日期、修改內容、修改人、版本號和備注組成。如果是新增的功能或模塊，建議是要加上鏈接可直接跳轉至新增內容的，如上圖。
版本號也是同理，都應加上對應的版本鏈接，便于查看者回溯之前的內容，與當前的新版本形成對比。這一點對開發人員來說很重要，其次對于新同事深入理解產品也能起到很大的幫助。
修改日期，通常是按時間倒序排列，查看起來會比較方便。
文檔圖例，顧名思義就是關于此文檔的一些輔助說明，目的是為了讓讀者更好地理解文檔。如上圖的：操作/跳轉圖例、標簽圖例、流程圖例以及手勢操作圖例。
因為我今年對接最久的是一個B端產品的項目，所以整理了一個產品畫像，僅供參考。
業務流程圖，不是操作流程圖也不是頁面流程圖。它是產品的整體業務流程，直接和業務掛鉤，可以說是產品的核心流程。
例如淘寶APP，買家購物由始至終的流程就是它的業務流程。通常用泳道圖的形式展示，多數情況下是由產品經理繪制。
以上是我所負責產品的核心業務的流程圖。因為是B端產品，涉及角色較多，針對3個代表性角色分別進行了繪制，僅供參考。(涉及到保密協議，所有關鍵詞都去掉了)
信息架構屬于用戶體驗的結構層，是產品的骨架。一般是由產品經理或者更高層的管理人員給出大框架。除非是大的產品迭代，否則不會大改。
如果是C端產品，權限這一塊相對簡單，比較好整理的。B端產品涉及角色眾多，可能要單獨拎出來分析整理。以上僅供參考，大家具體情況具體分析。若是功能很單一的產品，交互文檔中也可省去這個模塊。
產品操作流程圖就是通過圖形化的表達形式，闡述產品在功能層面的邏輯和信息。它能夠更清晰、直觀地展示用戶在使用某個功能時，會產生的一系列操作和反饋的圖標。
上圖是登錄、注冊和找回密碼的操作流程圖。僅供參考。模板源文件下載，后臺回復“交互”即可。
頁面線框圖，是通過圖形化的表達形式，闡述產品在頁面層面的信息。包括：
【頁面標題】即每一個頁面的對應標題，一般就是導航欄標題
【頁面內容】以黑白為主，保證信息規整易讀
【交互說明】用標簽將其對應起來，包括交互邏輯、操作流程及反饋、元素狀態、字符限制、異常/特殊狀態、相關規則 等等
【主流程線】只需要畫出主流程線即可，千萬不可太多太雜，時刻考慮讀者的感受
以上是注冊/登錄的線框圖和詳細的交互說明。將重點內容用紅色標記，可以讓查看者一目了然更好理解文檔。
常用控件類似UIKit，通常將極具復用價值的控制整理在一起，方便及時調用。
文檔、軟件只是工具，最重要的還是要落地、實行起來才能對產品有所幫助。所以在撰寫文檔的每時每刻，都應該站在“讀者”的角度思考，他們看的時候感受會是怎樣的，會覺得很難理解嗎？
轉自-站酷
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務。
藍藍設計的小編 http://www.syprn.cn