醫療行業的交互設計，跟其他行業有何不同？有什么要特別考慮的點？設計師應該注意哪些方面？
產品體驗設計通道中有條簡單好記的定義： 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.交互：指替換；互相；彼此。語出《京氏易傳·震》：“震分陰陽，交互用事?！保庩枴y道是我想的那個意思？）
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界面。
交互操作：用戶操作軟件、界面的具體操作，比如單擊、雙擊、長按等。
交互方式：軟件允許用戶操作的規則，比如按鈕的交互方式要通過點擊才能觸發。
交互事件：沒完成一次交互操作并獲得反饋的事件。
交互流程：用戶為完成目標所做的一系列交互的合集。
交互原型：用來確定產品交互方式的原型圖。
交互設計：制定用戶操作界面的流程、方式、體驗的設計。
交互文檔：用圖文記錄交互思路、具體交互規則的文檔。
交互動效：用來協助交互操作明確交互事件的動畫效果。
交互體驗：完成交互流程后所獲得得感受。
完！
轉自：站酷-酸梅干超人
在頁面導航欄中，常會見到返回、取消與關閉三者按鈕。許多同學會弄混它們的使用邏輯，所以寫一篇小文幫助各位梳理下。
先拋開圖標，我們回到功能本身的含義上看。如果我們不在產品的語境里，就單看「返回」和「關閉」這兩個詞，你首先會想到什么呢？
當我這么去問自己的時候，腦子里出現的并不只是零碎的詞語，而是一些場景和畫面。比如我走錯路了，需要原路返回；公司復工了，我要返程回去?；蛘撸X時間到了，我該關閉電腦了；飯菜燒好了，我得把油煙機關掉，等等。
如果仔細去想的話就會意識到，語義衍生出來的，都是我們日常生活中的經驗和對世界的認知。產品中使用的各種語言，不管是文字也好，或者圖標圖形也罷，一直都是以我們對它最本能的理解為基礎的。所以只要你聯想自己對「返回」和「關閉」的看法，就能知道它應該在什么樣的產品情境中出現，以及它為什么會出現。
于是，很自然的，我們會把「返回」和「路徑」聯系在一起，所以「返回」在導航設計中不可或缺。并且「返」也預示著我們會回到之前的路徑節點，整個過程是連續性的，不被切斷的。而「關閉」就完全不一樣了，它一般和我們的動作有關，是一個短暫性的操作，相比返回也顯得更為獨立。
根據我們對語義的判斷，再結合實際產品中「返回」的場景，我們可以概括出「返回」和「關閉」的特征差異。
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鍵詞，我們要服務的是每一位商家，然后幫助每一位商家成功，但是為了整個生態的健康，那些不重視產品和服務的商家，我們是（可以）不服務的。所以我們在產品設計原則上，在產品做一些功能的選擇上，如果這個功能做完了會導致商家不重視產品和服務，我們是不會/能做的。
舉個例子：消費者購買之后（可以）有一個評價，我們的購物評價是要么開啟要么不開啟這個功能。我們不接受商家去刪購物評價，因為商家一旦可以刪了消費者的差評，他就（很可能）不會那么重視產品和服務了。所以有贊永遠不會提供刪除商品評價的功能，商家要么就不開啟?？梢圆挥?，如果要用就要接受有人說你不好，商家可以去跟消費者溝通，溝通完了消費者自己改，但是我們不提供讓商家刪壞評價的功能。所以，這就是最基本的有贊產品設計原則，我們只服務重視產品和服務的商家，我們所有的產品設計原則都是需要這樣。
——《白鴉內部培訓：企業服務類產品的底層邏輯和有贊產品設計原則》
更多內容請看：
曾任支付寶首席產品設計師，現任有贊創始人的白鴉是很多人心里的產品大神，這份由他在內部分享的《產品設計原則》值得設計師、產品、運營等閱讀學習。
閱讀文章 >>我將其概括為一個產品的中正原則，即中立且保持正向原則。
一方面，對于企業未來的發展而言，正向的用戶能帶給平臺無盡的潛力，平臺可以和商家一起成長，而負向的用戶，則會給平臺帶來隱患。比如，淘寶既限制商家的違規運營和欺詐客戶，也限制 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界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務。
大部分交互設計師接到需求后，就開始分析下競品、然后結合自己產品和自己的想法，就著手交互原型制作了，在這樣一個設計流程中，交互設計師很難有體系化的思考。
有沒有一套體系化的設計思路，讓交互設計師做出的方案又專業、又全面、又經得起挑戰和用戶檢驗的設計方案呢？
本文是我梳理的一套體系化設計流程與思路，希望可以幫到大家。體系化設計思路大綱如下：
作為一個交互設計師。在我們接到需求之后，首先需要弄清楚的是產生需求的業務背景是什么。其次是基于業務背景了解產品的目標是什么。最后弄清楚產品的用戶人群有哪些，用戶目標是哪些。
交互設計師通過從產品經理或者其他需求發起方那里了解需求生產的業務背景，了解為什么要做這個需求。在了解清楚之后，追溯需求最原始本質。
在我們實際工作的大部分情況下，大部分產品經理不會在需求文檔中將業務背景寫清晰，這時候我們交互設計師就可以將業務背景在交互文檔中輸出，并清晰的展示出來。
1. 業務背景是什么？
業務背景通常是我們為什么要做這個功能。通過做這個功能，對業務有什么幫助。通過業務背景，我們可以推演出業務訴求，并得到對應的產品目標。
2. 產品目標是什么？
產品目標是產品能得到什么樣的結果，對產品來說可以獲得什么樣的好處。所以在交互文檔的設計中要重點體現出產品目標。通過明確產品目標，可以清晰的指導我們做交互方案。
3. 用戶人群是哪些？
用戶人群主要是通過我們對現有產品的用戶畫像得到，并推算出使用這個需求的用戶人群是哪一類人，通過明確的用戶人群，這樣我們在做設計過程中，可以很清晰知道這個需求為誰而做。
4. 用戶目標是什么？
用戶希望通過使用這個功能達到什么樣的好處或目的。
5. 設計目標是什么？
通過業務背景、用戶人群、用戶目標和產品目標拆解出對應的設計目標。
以登錄注冊為例。業務背景是目前產品的登錄和注冊的效果不理想。對應的用戶人群分為兩類，分別為新用戶的注冊流程和老用戶的登錄流程。用戶目標是方便快速的完成登錄注冊流程，越簡單越快越好。產品目標是提升登錄注冊的完成率。
設計目標是拆解，如何能提高登錄注冊的完成率。那么設計師可以拿到登錄注冊的完成流程，看看登錄注冊過程中，哪些步驟轉化率低，那么對轉化率低的地方進行設計優化。
目標拆解就是對頁面進行數據提升具體優化方案，例如文案問題、視覺布局問題、交互路徑問題等。
對于設計師來說設計方法有很多種。例如常見的有：目標導向、數據分析、用戶調研、設計走查、場景化設計、用戶體驗地圖、競品分析等。
在做設計方案過程中，一般不會將上述的方法全部用到，更多的是使用其中的一種或者幾種混合使用。
根據具體的需求選擇適合的方法。例如在做登錄注冊這個優化流程方案過程中，可以通過數據分析找到轉化率低和設計走查思考如何提升數據，就可以完成設計目標。
1. 不同場景梳理
我們需要以場景的思維做場景分析，通過場景分析就可以清晰地描述這些場景，從而確定用戶的需求，并在這基礎上用交互方案滿足需求。
舉個栗子，產品提出一個需求：應用添加「商品列表按照價格從低到高排序」的功能，這還是老思維，是在「定義我們的應用」；
而如果從場景的角度來思考，用戶搜索某種商品，在列表頁會列出一長串商品，而用戶此時只想快速找到符合他的要求的那一個；而有些用戶在挑選的時候，會需要買價格便宜的，此時排序功能就是用戶的需求。
這樣從場景來理解，會更清楚地理解需求發生的環境，便于做出好設計。
比如，順著排序的場景，可以進一步想：有這樣需求的用戶在我們的應用里多嗎？如果多，那么意味著用戶經常需要進行排序的操作，所以在設計的時候，可以把排序的入口放的明顯一點，好操作一點，方便用戶輕松地進行排序。
對于使用滴滴快車的用戶，整個流程包含三個階段，分別為上車前，坐車中和下車后。每個階段都存在多種用戶使用場景。
2. 不同角色用戶
有時候需要考慮不同角色的用戶，例如后臺系統，需要同時考慮普通用戶、管理員角色和超級管理員。
三個不同角色的使用權限也是完全不同的。權限：普通用戶 < 管理員角色 <超級管理員。三種角色的主操作流程也是不一樣的，在設計過程中需要差異化設計。
3. 設計不同流程
明確設計目標、設計方法確定、弄清楚不同場景。接下來就是設計不同的流程。
一般先設計功能入口流程，接下來就是主流程和支線流程。最后才設計異常流程。
4. 方案細化和走查
在涉及到異常場景，且可以全局性復用的情況，則只需要全局性組件說明即可，不用每個流程都展示其異常場景組件或者頁面。
全局組件指的是整個產品通用的組件，例如全局斷網，操作成功、操作失敗、加載、空數據界面，404 等
全局斷網：一般是在首頁使用 tips 提示。用戶在其他界面點擊操作時，也會出現 toast 反饋提示用戶。也有一些 app 在用戶進入后出現對話框提示用戶網絡異常。相對于對話框，使用 tips 對用戶的干擾度更小。
操作成功：一般操作成功都是根據具體的使用場景出現對應的提示。
操作失?。寒惓Ｇ闆r導致操作失敗，這時需要統一的提示，通常使用 toast，也有一些使用對話框強提示用戶。
加載：涉及到全局加載和局部加載，全局加載在設計中要統一說明，例如上一個界面點擊進入下一個界面，使用的全局加載就需要說明。如果是一些小場景的加載，那么需要特殊說明。例如上拉加載，下拉加載，局部小區域加載等。
空數據類型一共有三類：
通過核心指標判斷設計方案是否符合預期，以此驗證設計方案是否成功，并為后續產品的迭代優化做依據。
1. 關注設計的核心指標
設計過程中，要關注設計的核心指標，針對于核心指標，進行針對性的設計。
如果改版的最重要（核心）的指標是任務流程完成率，先查看用戶操作流失率，然后分析找出流失原因，給出對應的優化方案。等到優化方案的產品版本上線后，對比完成率數據變化。
如果改版的最重要（核心）指標是人均觀看次數，則要思考可通過哪些設計策略可提升產品的人均播放次數。
舉個例子，新浪微博，以前版本用戶看完視頻后，視頻會有重播按鈕和推薦視頻，用戶只有進行下一步點擊才能播放下一個視頻。
改版后看完視頻會自動切換到下一個視頻。這樣的設計策略雖然綁架了用戶的行為，用戶從一個主動接收者，變成了一個被動接收者，但是這種策略能有效的提升人均播放次數。
2. 核心指標帶來的價值/收益
當驗證了核心指標往好的方向發展，這時候，就需要總結核心指標帶來的價值和收益，這樣的話設計價值才可以直接被量化。
舉個例子：一個 banner 的點擊率達到 3% 的時候，每天 GMV 約 200 萬，當重新設計了這個 banner，同時其他條件保持不變，點擊率提升到了 6%，這時候通過數據查看每天的 GMV 是多少，如果達到了 400 萬，那么這增加的 200 萬的 GMV 則是通過設計優化所帶來的。
設計師在交付稿件后，容易松懈，以為項目告一段落，就疏于后續的跟進工作。其實后續的跟進也很重要。產品測試版上線后，交互設計師應該跟進后續的走查和設計問題的反饋。
通過數據分析，確定上線的方案有哪些問題需要優化，建立需求池方便后續跟進優化，不斷完善產品設計。
文章來源：優設
如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里
當別人問你什么是交互設計時，你又一臉懵逼了。本篇文章就來好好聊聊什么是交互設計
工作了很多年，卻依然說不出何為交互設計。一說道理，大家都懂，但是當別人問你什么是交互設計時，你又一臉懵逼了。為什么會這樣呢？因為我們沒有自己去總結，沒有形成自己的知識庫。
交互設計，它由IDEO的一位創始人比爾?莫格里奇在1984年一次設計會議上提出，他一開始給它命名為“軟面（Soft Face）”，由于這個名字容易讓人想起和當時流行的玩具“椰菜娃娃（Cabbage Patch doll）”，他后來把它更名為“Interaction Design”――交互設計。
首先，我們來看看權威方對交互設計的定義：
交互設計協會(The Interaction Design Association (IxDA))解釋如下：
交互設計師以創造有用且實用的產品及服務為宗旨。以用戶為中心作為設計的基本原理，交互設計的實際操作必須建立在對實際用戶的了解之上：包括他們的目標、任務、體驗、需求等等。以用戶為中心的角度出發，同時努力平衡用戶需求、商業發展目標和科技發展水平之間的關系，交互設計師為復雜的設計挑戰提供解決方法，同時定義和發展新的交互產品和服務。
百度定義如下：
交互設計（英文Interaction Design, 縮寫IXD)，是定義、設計人造系統的行為的設計領域，它定義了兩個或多個互動的個體之間交流的內容和結構，使之互相配合，共同達成某種目的。交互設計努力去創造和建立的是人與產品及服務之間有意義的關系，以“在充滿社會復雜性的物質世界中嵌入信息技術”為中心。交互系統設計的目標可以從“可用性”和”用戶體驗“兩個層面上進行分析，關注以人為本的用戶需求。
唐納德諾曼給出的定義：
重點關注人與技術的互動。目標是增強人們理解可以做什么，正在發生什么，以及已經發生了什么。交互設計借鑒了心理學、設計、藝術和情感等基本原則來保證用戶得到積極的、愉悅的體驗。
首先要知道什么是交互
交互，及溝通交流，發生互動關系。比如人和人之間的交互就比較好理解，最經典的一幕可以用孫悟空智斗金角大王、銀角大王。金角大王說：孫行者，我叫你一聲你敢答應嗎？然后，金角大王就叫：孫行者。孫悟空回答：爺爺在此。就這樣，孫悟空就被收進去了。這就是一個簡單的交互。
再比如，我們每天上班，到公司和同事打招呼。你說：“早上好呀”，同事回答“早”。這也是一個常見的交流互動。
人和人之間的交互比較好理解，那人和機器呢？其實也是非常好理解的。我們都忘不了微信推出的搖一搖功能，打開搖一搖，搖動手機，就會出現“咔咔”的聲音，然后加載，搜尋出一個和你同時在搖的人。其實，我們和任何機器之間的發生互動關系，都是屬于交互。往更廣的意義上說，如果失去了交互，地球將不再運轉，將毫無生機?，F在，智能時代已經到來，我們除了研究人和人、機器、產品、環境、服務、系統等之間的關系，還要研究機
器和人、機器、產品、環境、服務、系統之間的關系。
總之，當人（或機器）和事物（無論是人、機器、產品、服務、系統、環境等等）發生雙向的信息交流和互動，就是一種交互行為。
其次，我們來聊聊設計
聊設計之前，我們要先說說藝術，原研哉老師對設計和藝術的描述非常精辟，下面就引用他的話。
藝術說到底是個人意愿對社會的一種表達，其起源帶有非常個人化的性質，所以只有藝術家自己才知道其作品的來源。這種玄虛性使得藝術“很酷”。當然，解讀藝術家生成的表達有多種方式。非藝術家通過對藝術的有趣闡釋與藝術互動，欣賞之，評論之，在展覽中對藝術進行再創作，或把藝術當做一種知識資源使用。
而設計，則基本上不是一種自我表達，它源于社會。設計的實質在于發現一個很多人都遇到的問題，然后試著去解決的過程。由于問題的根源在社會內部，除了能從設計師的視角看問題外，每個人都能理解解決問題的方案和過程。設計就是感染，因為其過程所創造的啟發，是基于人類在普遍價值和精神上的共鳴。（來源，原研哉，設計中的設計）
通過上述的描述，我們不難發現，設計主要表現在發現問題–解決問題。而交互設計就是發現和解決人（或機器）和事物（包括人、機器、產品、服務、系統、環境等等）之間的互動關系問題。
所以說，交互設計的范圍是非常廣的，和各個學科都有涉及，我們可以通過下面的圖來看看交互設計和各個領域之間的關系。
那交互設計主要是做什么工作呢？
作為交互設計師，也應該好好問問自己這個問題。通常，外界的人就認為我們就是畫畫原型，或者有時候畫畫UI，而我們通常就是這么做的，所以也不得不讓人們這么想。而現在大多數交互設計就是指移動端、網頁端的交互設計。
那么交互設計的核心競爭力是什么呢？對于很多公司來說，其實是沒有交互設計這個崗位的，交互的工作就由產品經理和UI設計師各自分擔了。現在產品經理基本都掌握了原型技能，而且產品經理通常在做需求移交的時候已經把交互表達的很清楚了。而且很多UI設計師能力較強一點的，在做設計的時候都會考慮到交互。如果交互設計師在公司就只做做原型，那么，你就會被取代。
那么交互設計的工作內容到底包含哪些呢？《用戶體驗要素》這本書很好的說明了這些內容。本書把用戶體驗要素分五個層級：戰略層、范圍層、結構層、框架層、表現層。不同層級，表示著你的不同能力，引用一下大眾點評高級交互設計經理范怡的一張圖，比較形象的描繪了交互設計的能力范疇和價值。
怎么樣，看到這些是不是有一點點覺悟了呢。如果想做好一名交互設計師，就應該擴大自己的能力范圍，提升自身價值。怎樣做好交互設計呢？如何運用設計原理來做交互設計呢，我們下篇來聊聊唐納德羅曼老師書里的交互設計6要素：示能、意符、約束、映射、反饋、概念模型。
原文地址：站酷
作者：Luyeelin
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計
如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里
第一段：工具
設計師學習的第一階段其實都是從工具開始的。這分為兩種：
第一種是有形工具，比如PS、AI、Axure之類的軟件；
另一種是無形工具，就是設計時用到的思維方式。
1、有形工具
先說第一種有形工具。
很多人在學習UI時很容易陷到工具的學習里去，覺得工具學的越多能力就越強。其實根本不是這么一回事，軟件對交互來說是非?；A的一部分。
從UI視覺方面來考慮，PS就足夠了，AI都顯得略有多余，不需要其他軟件。PS其實是一款非常強大的視覺軟件，切圖也比較方便，BAT等公司也是用的PS。
還有輸出交互文檔的工具，一種是PPT，一種是Axure，這兩款軟件就足夠覆蓋絕大多數交互文檔了。當然還有其他軟件，如果是快速迭代的原型直接在紙上畫也可以。
交互需要快速溝通，你要拿著設計反復和其他人對接。要是搞了個很生僻的軟件給別人，結果別人打不開，老板就會罵你。要記住自己是設計的一環，能快速傳遞自己的設計思路才是最重要的，不要搞一些生僻的軟件、格式和字體，這都是門外漢干的事。
像AE、Flash面試時可能會給你加分，因為公司可能有一些高保真的動畫展示要做，其實在真實工作中用到的機會非常少。
2、無形工具
第二種是無形的思考工具。設計思維其實最不好培養，說的殘酷點，你可能看五年的書都出不來思維，最好能有人指點一下。
第二段：新產品、新思路
前沿的設計意識，是很多設計師容易忽略的。
這個怎么練呢？
每天一定要抽出三十分鐘的時間看新產品和新思路，這是今天的互聯網設計師必須要干的一件事。很多一線團隊每天都會分享各種各樣的新聞，百度有自己的分享機制，三星喜歡每個月讓設計師找的交互、用研、技術信息，收集起來專門搞一個月報。
設計師有很多渠道可以看前沿信息，比如互聯網一些事，愛范，36kr，癮科技之類的網站。這種前沿意識非常重要，它決定了你能在二流公司還是一流公司，這是排在第二位的。
這個堅持三個月以后，自然而然就會飛躍，不需要怎么特意去學，這可不是培訓可以得到的，養成一個好的習慣，每天看半小時其實就是最好的學習。
第三段：人——對人和需求的研究
工具和思維的問題比較好解決，最難解決的問題其實是“人”的問題?？赡芎芏嘣O計師一輩子都解決不了“人”的問題，而它對企業的影響又是最大的，交互設計最重要的就是解決“人”的問題。這一點甚至能決定一款千萬級甚至上億級產品的生死。要知道你的一切設計行為都是為商業負責的，所以前期對交互不甚了解，可以先從PS開始，后期就是“思維”和“人”，這兩個東西是比較難的。
看看前輩是怎么說的：
交互設計目前發展得怎樣，前景如何？
答：現在我們接觸到的交互設計可能只局限在網頁或者APP這種，交互設計是個很廣泛的概念，前景肯定是有的。互聯網是人和服務的對接，很多嶄新的設計和商業模式一旦出來，那就是新的商機。
新手自學UI應該從何處入手？
答：視覺基礎不好的就學PS去臨摹，現在很多開源的信息，比如學UI網。如果臨摹到一定程度，可以看一看dribbble，其實視覺非常好解決，思維的提升才困難。
學習交互設計需要掌握什么軟件？
答：PPT和axure足夠了，這兩個東西都不需要學。隨便來個人學兩三天都能拿著軟件畫出漂亮的線框圖，關鍵是你的線框圖從哪里來、為什么要這么畫。
交互設計師需要學習代碼嗎？
答：交互設計師不需要學代碼。知道為什么企業招聘要求你們懂代碼嗎？因為很多企業希望你做了設計做前端，節省人力成本，正式公司都不會有這個要求。就算你覺得設計師應該學代碼，建議你還是先把本行的設計能力學好。當兩件事你都要做的時候意味著哪件事你都做不好，這是自我管理的問題。
交互需要手繪功底嗎？
答：手繪功底？有或者沒有都可以，交互不需要你造型能力多強，你只要能把邏輯關系畫出來就行了，不需要搞什么素描陰影。你不是要做畫家，朋友們，畫家和設計師是有區別的。
（內容來源網絡，如有侵權請聯系，承諾必定刪除）
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計
藍藍設計的小編 http://www.syprn.cn