金剛區是什么，想必大家都有所了解。
沒有的話看這張圖就懂了：
圖片來源：淘寶首頁
我在微信上搜了一下，發現大部分討論金剛區設計的文章，都是在講怎么畫圖標。
但是我自己在使用各大 APP 的過程中，發現很多金剛區并不是那么好用，而且這跟圖標好不好看無關。
金剛區設計不好，會對我的使用造成直接影響：
我今天就來總結一下，對于金剛區設計的交互/體驗思考：
金剛區里有多少項比較合適？
這其實是米勒法則（Miller’s Role）的典型運用了。
如果你還不太了解米勒法則，看看下面這張圖里的詞語：
現在，半分鐘回憶一下，你記住了多少個？
……
大部分人能記住 5~9 個。
米勒的研究發現，普通人的工作記憶（Working Memory）只有 7±2 個信息塊。
如果給的信息超出了這個數字，大部分人也只能記住這么多。
所以說，金剛區里的圖標數量，最好也維持在這個數，否則就是對用戶的記憶能力要求過高了。
通常來，4 個圖標很輕松，說 6 個圖標是比較理想的，8~9 個就有點吃力了，10 個就超綱了。
例如支付寶這個就過分了，好在這只是工具類產品，復雜一點也沒辦法：
人們在看閱讀文字時，視線軌跡是之字形：
人們在閱讀表格時，視線軌跡是除草機形：
上圖來源：這樣設計表格，看著真難受！
雖然金剛區的眼動圖我沒有，但第一步肯定是從左上角開始往右掃。
所以，用戶最有可能使用的圖標，應該從左到右排在最上面一行，最不常用的可以排在右下角。
例如美團外賣這個設計，看著就挺合理。不但把重要內容放在第一行，而且還做了很大的視覺區分：
不過一些不愁流量的 APP 會選擇把黃金位置用做商業宣傳，難免損失點易用性。
1. 仿真圖標
如果追求質感，多半會使用物品本身的顏色，例如每日優鮮這個：
這種圖標就沒什么顏色好討論了，注意一下整體和諧就好。
2. 數量較少
如果圖標數量不多可以使用一個顏色，那么顏色上，同樣沒什么好討論的。
例如 QQ 音樂：
3. 數量適中
如果圖標數量在 7 個左右或以內，那么可以每種顏色的圖標都來一個，這樣用戶也能記住大概什么顏色代表什么。
例如京東這樣：
4. 數量很多
圖標數量遠超過 7 時，就不可能每種顏色來一個了，否則顏色都不夠用了。
如果還是想要劃分顏色，可以將類型作為依據，這樣用戶在尋找圖標時會比較有方向。
當然，其實也可以簡單點，干脆都一個顏色，例如聯通手機營業廳：
1. 底框
一些產品為了統一感，會用圓圈或者圓角矩形，把所有圖標都框起來。
這樣視覺上是好處理了，但交互上很不推薦，因為會大大降低圖標的識別度，乍眼一看都長一樣。
這種底框在主流產品里已經很少見了，不過這么做的設計師還是不少：
這種圖標數量少，有顏色區分還好，如果數量多又一個顏色，那就很難辨認了。
縱觀常見的金剛區圖標，通常不外乎四種樣式：線條、形狀、2D、3D、仿真。
聯通手機營業廳
QQ 音樂
京東
美團外賣
每日優鮮
任何樣式都能讓用戶識別和記憶，但是不同的樣式給人的感官不同。
真實性越高的視覺樣式，就越容易給人高級的感覺；相反真實性越低的視覺樣式，越容易給人簡單邊界的感覺。
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼ben_lanlan，報下信息，會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
相信身為設計師的我們，在工作中肯定遇到過自己加班加點，絞盡腦汁設計出的方案被質疑、挑戰，在宣講自己設計方案時，總會出現以下聲音：
起初的無言以對到有理有據的辨析設計方案都體現出對設計方案更加全面的思考。
想要讓自己的設計方案更合理，獲得大家認同，可以分為 4 個步驟：
1、 樹立自己用戶思維
2、充分辨析用戶需求
3、嚴謹打磨設計方案
4、精準有趣的文案
我們常說吃飯不積極，思想有問題。看似玩笑話，但是蘊含的是對于吃飯是本能，是刻在腦子記憶中的。而設計師在做設計時，也需要有這種“本能思維”。
用戶思維最基本就是 圍繞用戶 幫助他們 解決實際問題。如果用三個字來概括的話：人、場、事。
人：目標用戶
場：在什么情況下？
事：要干嘛？
例：筆者 因為在家寫文章沒時間出去吃飯 ，所以需要點外賣 讓別人將飯送到家里。
一個合理的設計方案，必然是將人、場、事很順暢的串聯下得出的結果。
用戶之所以有需求一定是遇到了問題（需求源于問題），只要找準問題所在就能明確用戶需求，那我們的設計便成功大半。辨析用戶需求可以從兩反面：
2.1、確定問題
2.2、清晰表述問題
2.1、確定問題
除了常見訪談、問卷、測試等調研手段，設計師可以采用【同理心圖譜】的方式推導用戶需求
從 說了什么、做了什么、想了什么、感覺到什么 四個維度去勾勒用戶真實的想法感受。
例：日常支付場景
想要將問題表述清楚，還是回到第一部分我們講的：人、場、事上，通過陳述句將用戶面臨問題和期望狀態（目標）的差距描述出來。
如：小明在QQ群里搶發紅包中，由于當前支付流程冗余導致他支付效率較低，影響了大家氛圍。
用戶與他們的需求是問題陳述的核心，避免：我們應該怎么做、產品應該...作為開頭。
保持陳述的寬泛性，不要過早拋出細致的解決方案、技術限制等內容，避免團隊發散受限。
專注一點不要試圖在一個問題陳述中解決太多用戶需求，一次解決一個就很好了。
在打磨解決方案上，設計師需要考慮 易用性、易理解性、及著力提升用戶任務效率，給用戶一個更好的體驗。在打磨設計方案時，我們不必在一個方案上求多表現，一個方案能能夠將你所要表達的設計要點表達清楚即可，主要注意：
健康碼主要是為了讓工作人員快速辨別人員是否安全，但在眾多人中需 快速判斷，這個轉化到設計上解決方式：通過大面積的 色塊直觀反饋；通過實時的 滾動時間+滾動背景反饋真實性；在結合下方核酸與疫苗輔助判斷，整體非常貼合實際訴求，重點突出，有節奏感。
通過體驗核心信息，將內容合理布局，重點突出，操作劃分明確，有助于信息獲取與確定。
人的認知資源有限，天生不善于處理復雜信息，在面對復雜信息時需將內容以一定秩序邏輯管理，分而治之，減少用戶的選擇，讓正確的行為變得自然和明顯。
在58二手車頁面的改版中，頂部按鈕直接 分流 不同目的用戶；中間模塊展示用戶 最關心的維度：價格、品牌、車類型；下方 透出推薦內容 吸引用戶往下逛。
如上圖百度網盤的分層設計（圖片來源：大牙的設計筆記）中，設計師根據不同的會員周期，改變以往的“多人一面”，打造出“多人多面”靈活分層頁面布局，將復雜狀態很好的根據不同時期進行拆解。
多考慮用戶使用場景，挖掘一些場景是可以通過我們的設計 幫助用戶多走一步，幫他們排除障礙，減少負擔。
打車軟件在特定時間點自動浮出目的地，微信聊天窗自動出現截圖、驗證碼直接在鍵盤上方等都是通過用戶的行為預判了用戶下一步的行為，極大的提高了效率。
情感化不一定都是很精美的插畫、動效等表現層面上的，有時候 貼心的記錄、舒緩的內容、小游戲...... 也可以起到 情緒調節 的作用，提高用戶看到復雜信息的 忍耐度。
----------------------------------------------------------------------------------
所以在具體設計方案上，需要不斷的去思考打磨設計方案，讓自己的設計：
①、顯而易見的，讓用戶體驗后覺得「沒錯，就應該是這樣」；
②、有價值的，它為用戶解決實際的問題；
③、與用戶的心理模型相符，它不意味著更多的設計。
文案這塊本應該屬于上一個模塊額范疇，之所以單獨講是因為文案對于體驗而言太重要了，優秀的文案不僅可以減低用戶理解成本，還可以讓用戶感到興奮、溫暖、愉悅，并感嘆：臥槽，牛脾。
身為交互設計師，不需要做到像杜蕾斯那樣上熱搜的文案、solgan，但設計稿中的文案必須要做到：表達精準無歧義、適當趣味化。
我們是通過屏幕與人交流的人，屏幕上的文案觸點之一，因此簡潔精準的表達出我們要說的內容很重要。這設計中，首先應該避免一些專業術語、“高大上”的詞語，應該簡單直白，用最簡單的詞語，去掉那些不需要出現的詞。
①、直接告知行動：在微信發語音按鈕文案（按住 說話，松開 發送），非常直白的告知用戶需要做什么，且文案中的空格這個細節也將先后順序表達的十分清晰；而QQ在長按時沒有進行文案的提示著點體驗上就不如微信了。
②、文案盡量簡短：成年人 1s 可閱讀 7 個字左右，豆瓣的評論引導就非常簡短，直接三個字：寫評論，明確引導用戶點擊；而知乎為了營造良好的社區氛圍，引導用戶言行友善，但文案較長，相比寫評論而言顯得不夠簡明扼要，如果改成：友善評論... 是否會更好？
③、避免使用雙重否定的句式：在微信撤回的反饋文案中采用了雙重否定的句式（是否撤回該條消息）這樣的句式容易增加認知負荷；而淘寶刪除記錄反饋文章中，則直接詢問：確認刪除？這樣的句式更直接，更好理解。這里我嘗試將微信撤回反饋改成：撤回該條消息？下方操作文案也直接使用撤回，這樣看起來是否更明確了呢？
結合自身產品定位：上述兩個案例續費文案都是展示了自身產品的定位進行設計的，相較于冷冷的會員到期提示，這樣的方式更顯趣味性。
文案適當擬人化：擬人化的文案可以拉近用戶距離，會顯得產品更有溫度而不是冷彬彬的機器，有時還顯得有些小可愛~(#^.^#)
----------------------------------------------------------------------------------
所以在具體交互方案上，設計師對于文案的把控記住以下幾條原則：
①、字詞簡單，用用戶看得懂的字；
②、表意準確無歧義；
③、字數簡短，陳述語句，避免使用雙重否定類句式；
④、必要時可適當擬人化、趣味化。
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼ben_lanlan，報下信息，會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
你是否在面試有中被問到，你設計的頁面需求是如何獲取的? 需求是如何聚焦篩選的？需求是如何做優先級排期的？在互聯網產品的全生命周期里都會涉及到很多的需求。企業的CEO、甲方客戶，用戶調研各方得到的需求時常扎堆，就算是一個小功能也會有很多問題，呈分散式、零星式。
哪個需求對用戶來說最重要？用戶對我們的新功能是否滿意？我們究竟要先做哪些需求？在企業里，大多數時候項目排期內，我們都面臨著開發、設計、測試等人力資源有限的境地。用戶什么都想要，但是不可能所有功能都一起開發、上線。作為用戶體驗設計師或者高級UI設計師，我們有充分地理由掌握一個科學系統的方法可視化需求排期。到底有沒有一個科學的方法論把需求劃分優先級，去說服你的老板、甲方、產品、技術和你自己？
廢話不多說 ，我們直接上干貨！
維基百科對KANO模型的定義如下：
The Kano model is a theory for product development and customer satisfaction developed in the 1980s by Professor Noriaki Kano, which classifies customer preferences into five categories.
KANO 模型是東京理工大學教授狩野紀昭(Noriaki Kano)發明的對用戶需求分類和優先排序的有用工具，以分析用戶需求對用戶滿意的影響為基礎，體現了產品性能和用戶滿意之間的非線性關系。
“用戶滿意度”是用來衡量需求實現后，用戶的滿意程度。具體可以分為以下幾個等級。
“功能完善程度”是用來衡量某個功能被實現的程度。具體可以分為以下幾個等級。
通過“用戶滿意度”以及“功能完善程度”兩個維度，我們可以劃分五種不同類型的需求：
（M）基本型質量 —— Must-be Quality
（P）期望型質量 —— Performance Quality
（A）興奮型質量 —— Attractive Quality
（I）無差異型質量 —— Indifferent Quality
（R）反向型質量 —— Reverse Quality
（1）必要型：產品必須要有的功能，屬于用戶的基本需求，即用戶的痛點。需求滿足時，用戶不會感到滿意；需求不滿足時，用戶會很不滿意；當投入達到一定程度時，不需要再過多的投入。
比如：我們生活中常見的必需品。手機要可以打電話，汽車需要能加速和剎車；微信的聊天功能、抖音的短視頻功能、百度的搜索功能等等一系列產品必須的功能。
（2）期望型：（線性增長）用戶希望有的功能，用戶在其他產品上使用過并養成了一定的用戶習慣后，作為期望的標準也希望產品能具備此功能。需求滿足時，用戶會感到很滿意；需求不滿足時，用戶會很不滿意；這類需求與用戶的期望契合度極高，需求實現程度越高，用戶的滿意度也越高。我們要集中投入。
比如：手機的儲存容量、續航能力越高，用戶的滿意度越高。當地服務類生鮮外賣產品，騎手的實時定位以及距離送達時間就屬于期望型需求。但也隨著整體功能不斷完善也在慢慢從期望型需求轉化為基本需求。
（3）興奮型：超出用戶預期的的功能。是產品差異化的亮點，如果沒有該功能，用戶的滿意度不會降低，但是如果有了該功能用戶的滿意度則會大大提升。能極大的提高用戶的滿意度，但是同時也要付出大量的研發成本。興奮型需求一般是目前市面上沒有的功能，用戶沒有接觸過，也沒有養成用戶習慣。
比如最近網易云音樂、QQ音樂等推出的一起聽功能，bilibili推出的一起看功能就屬于興奮型需求。早年間里第一次使用微信便捷的語音交流，第一次使用抖音等，會讓我們在初次使用時出乎我們的意料。
（4）無差別型：用戶不在意的功能，這類需求的有無對用戶來說無關痛癢，用戶并不關注。
在APP中一般為特定目的而產生的多余設計，如提醒你續費會員頁面，屬于引導消費。這類需求要避免投入過多，將精力轉移到其它類型的需求上面去。
（5）反向型：會引起用戶反感的功能，是指用戶不希望出現在產品或服務上的功能。出現時，用戶的滿意度不增反降。比如在進入一款APP時有四五個彈窗活動入口引導充值和誘導消費，需要逐個點擊關閉才能進入頁面，這類設計越多用戶的負面體驗就越強。
Tips：比如我們做一款手機，打電話功能是基本型需求。我們需要花費大量的時間去夯實這個功能，把它做的穩定準確。如果一款手機打電話交流都有問題，而去花費大量精力去優化它的拍照，視頻等功能。就是失去了一款手機最基本的使用。這與產品設計初期優先考慮產品的可用性與易用性，是否能打中用戶痛點同理，先把精力集中做好基本型需求，而不是過度關注在產品設計細節等期望型、興奮性需求上。
根據前面“用戶滿意度”作為縱坐標，“功能完善程度”作為橫坐標得到這張Kano品質要素圖
Tips：在圖像中可以看到，魅力屬性和期望屬性是會慢慢發生變化的。魅力屬性會隨著時間推移、用戶習慣的養成、競品的影響等，慢慢轉化為期望屬性。一部分的期望屬性會隨著時間推移、用戶習慣的養成、操作流程的影響等，慢慢的轉化為基本型屬性。
首先我們選擇要進行排序的需求。
在實際的工作場景中，我們往往在一個工作周期內可能同時會接到很多的需求。我們面臨項目時間緊，開發、設計人手資源有限的境況。我們首先就需要篩選出適合Kano模型的需求類型，才能更好的進行下面的評估過程。
我們的需求池中往往有著不同類別的需求，有的是需求是關系到最終用戶，有的需求是運營、管理層、甲方客戶。按照常規的需求類型大致可以分為這幾類：
（1）軟件問題（技術類）：這類問題多為軟件BUG，這類問題通常涉及到我們的產品是否為用戶提供了良好的可用性（產品功能初期一般優先考慮的是可用性和易用性）體驗，一般屬于基本型需求，因此屬于需要緊急處理的問題。
（2）用戶問題 （交互體驗類）：這類問題多為交互體驗問題，例如用戶使用產品過程中出現的不知道如何使用某功能（沒有做功能引導、不符合用戶心智、學習成本高），或者某功能找不到在哪（功能個入口不清晰、信息入口層級過深）等類似問題。
（3）產品建議：這類問題基本上屬于期望型需求，例如用戶希望增加某某功能或在某個操作流程感到缺少什么功能。
（4）其他問題：Kano模型適合與最終用戶可以直接操作、感知、相關的需求。而不是針對于產品的運營人員、管理層、甲方客戶等的需求。
Tips：因為KANO模型只從用戶滿意度及功能完善程度這兩個維度出發去分析需求價值，所以并不適用于當價值衡量需考慮其他維度因素，如需要將戰略、商業收益納入考慮等等。
選擇我們產品的目標用戶。
可以在問卷題目中增加條件篩選，在后續問卷收集后進行數據清洗。比如產品的目標用戶為18-36歲女性用戶，就可以在問卷中增加詢問年齡問題，在收集上來的數據結果中篩選掉這一部分非目標用戶數據。為我們下一步的問卷設計投放做準備。
針對第一步梳理后的需求集，進行正反向的發散。KANO問卷每一個功能或需求問題是由正向和負向兩個子問題構成，分別是用戶在具備或不具備某項功能做出的反應。問題選項按照：非常喜歡、理所當然、無所謂、勉強接受、很不喜歡，進行評定。
對此我們問用戶3個問題：
（1）正向問題：
如果我們增加【功能1】，你的感受是?
（2）反向問題
如果我們不增加【功能1】，你的感受是?
（3）重要程度
【功能1】對你來說有多重要？
Tips：在實際調研中，產品具有某個功能，大部分人不會表示“不喜歡”或“無可奈何”?！盁o所謂”一般是態度的下線，即很少會有人會覺得“很不喜歡”或“勉強接受”。所以在問卷設計階段為了提高用戶填表的效率，在選項設定中正反向只設定3個選項。
可以采用定量調研的方式，使用“問卷星”設置好問題發在產品用戶交流群中或私域流量群中。
Tips：
如何向用戶提問，如何收集用戶的回答將直接影響到需求排序的結果。這一步非常重要。
提醒用戶正反問題之間的區別，注意強調“增加”還是“不增加”，防止用戶看錯題意。
在實際題目設置中，當功能數量比較多（大于5個時），有比較接近類似的，建議對用戶進行分組，每個用戶最多回答5個功能點，且盡量是區分度大的功能點。
有時需要對功能進行解釋，確保用戶能夠理解。
調研后需要對數據進行清洗，處理掉一些用戶亂填或錯誤的數據。比如所有題目都選一樣和一些可疑結果的數據。
基于收集的問卷量化的結果，進行需求分類分析。每組正反向問題的排列組合一共是25種，得到需求類型參照表。這張表格中，將重點關注正向的回答（即 > 0 的部分），這樣我們可以幫把注意力放在最重要的正向需求上面。（避免關注到“具備功能時”用戶覺得“勉強接受”和“很不喜歡”的需求上）
Tips：Q：代表可疑結果。對于一個功能的提供與否，用戶都表現出了很喜歡或者很不喜歡這種自相矛盾的情況。所以，這樣的結果在最終統計時，一般都需要排除掉。
需求優先級排序為：基本型 ＞ 期望型 ＞ 興奮型 ＞ 無差別型 ＞ 反向型
在需求數量不是很多只需確認需求分類時，到這里就可以結束了。只需要基于以上結果進行統計，根據少數服從大多數的邏輯，最多比例的屬性作為統計后的結果，即該需求分類。
比如：【功能1】最后收集數據為，基本型42、期望型28、興奮型0、無差異型7，【功能1】為基本型需求。再根據需求排序確定優先級。
如果涉及到較多需求，或者同類型需求有多個需要優先級排序時，你還需進行下一步。
我們引入better-worse系數的概念，表示某功能可以增加滿意或者消除不喜歡的影響程度。
Better系數=（期望數+興奮數）/（期望數+興奮數+基本數+無差異數）
= （P+A）/(P+A+M+I)
Worse系數= -1 *（期望數+必備數）/（期望數+興奮數+基本數+無差異數）
= -1 *（P+M）/(P+A+M+I)
Bette系數，可以簡單理解為滿意系數，代表如果產品提供某種功能，用戶滿意度會提升。Better值越大/越接近1，則表示用戶滿意度提升的效果會越強。
Worse系數，可以簡單理解為不滿意系數，Worse的數值通常為負，代表產品如果不提供某種功能或服務，用戶滿意度會降低。其絕對值越接近1，則表示對用戶不滿意度的影響最大。
1. 橫坐標為Better系數，縱坐標為Worse系數絕對值。根據實際得到結果將最大值均分依次放入兩個坐標軸上。
2. 分別計算Better系數平均值、Worser系數絕對值平均值，將其作為參考警戒線加入圖表中。
3. 將各個需求的對應的Better系數值、Worser系數絕對值放入圖像內。
4. 我們將根據需求的重要性，來調整上圖中點的大小。這時我們引入功能重要程度概念（在前文問卷問題中有提到），這里可以量化功能需求的重要程度，從“不重要”到“非常重要”，1到9分依次可對應需求點的直徑大小，比如“非常重要”點為90px直徑的圓，可根據具體情況靈活運用。
5. 根據需求優先級排序為：基本型 ＞ 期望型 ＞ 興奮型 ＞ 無差別型 ＞ 反向型 。同一需求類型再根據重要程度二次排序。
6. 至此各個功能需求優先級排序一目了然。
最后，我以“呱呱生鮮”產品為例子回顧整個Kano模型可視化需求的流程。
這次我們有10個需求需要做需求可視化。分別為：
Q1：在點擊訂單結算后提供優惠換購功能；
Q2：詢問上次購買訂單是否滿意反饋彈窗；
Q3：會員每日可領取免費菜功能；
Q4：進入APP提醒不在常用定位地址功能；
Q5：商品詳情頁面菜品推薦做法功能；
Q6：有辣味的商品圖片提醒辣度指數；
Q7：商品詳情頁面菜品直播功能；
Q8：商品列表顯示菜品榜單排名參數；
Q9：購物車結算提示可以免費領取小蔥；
Q10：猜你喜歡你的常購清單功能；
因為KANO模型只從用戶滿意度及功能完善程度這兩個維度出發去分析需求價值，以上10個需求功能均為用戶可直接感知。符合Kano模型條件。
選擇產品的目標用戶進行問卷投放。
對此我們問用戶3個問題：
（1）正向問題：
如果我們增加【功能1】，你的感受是?
（2）反向問題
如果我們不增加【功能1】，你的感受是?
（3）重要程度
【功能1】對你來說有多重要？
使用“問卷星”設置好問卷問題投放在產品用戶交流群中或私域流量中。
對調研后收集上來的數據進行數據清洗，處理掉一些用戶亂填或錯誤的數據。比如所有題目都選一樣和一些可疑結果的數據。
（1）基于收集的問卷量化結果，對照需求類型參照表,進行需求分類分析。
（2）結合需求優先級排序：基本型 ＞ 期望型 ＞ 興奮型 ＞ 無差別型 ＞ 反向型 。
（3）計算better-worse系數，計算Better系數平均值、Worser系數絕對值平均值，將其作為參考警戒線加入圖表中。
（4）將各個需求的對應的Better系數值、Worser系數絕對值放入圖像內。
（5）我們將根據需求的重要性，來調整上圖中點的大小。
（6）得到最終的需求可視化排期圖，至此各個功能需求優先級排序一目了然。
我們設計師需要在自我能力范圍內，不斷提升為企業團隊服務，增加自己對內話語權以及對外影響力。成為自我驅動高級體驗設計師。在工作中也需要對需求做一個設計價值和優先級的排序，搭建需求可視化體系。對不同的需求進行品質類型劃分，列出屬于自己排出的需求列表，在更有價值的需求上花費更多的時間精益求精。
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼ben_lanlan，報下信息，會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
當下互聯網進入以內容運營為核心的時代，市場競爭激烈，需要對于市場的熱點進行快速反應，持續迭代。不管是大廠還是小廠的UI設計師多多少少需要支援運營需求。U1S1 做簡單運營圖對于體驗設計方向的設計師來說，性價比確實有點低，一般難度較高的運營設計需求都由專業的視覺設計師來做，體驗設計師一般接到的都是比較簡單或者緊急的需求，這對于設計的能力提升來說是比較有限的，大量的時間被占用在運營設計上，持續被榨干，有些本末倒置，但人生就是這么操蛋，總得想辦法解決。
就目前大部分互聯產品的Banner而言。
其構成一般由標題文案、主體元素（人物、物品等）、背景（場景、底色等）元素構成。
面向設計師：模板化運營設計 + 素材資源同步盤
第一種方法是本文的核心方法，原理很簡單，其實就是利用Sketch和或者Figma的組件化（為了統一語義本文統一稱為組件，其子集為用例）進行設計。
我們將這些元素分別打包成組件.
把組件的用例調整后放置在預覽區所有不同尺寸的畫板中。
當出現需要特殊調整的時候可以解綁微調。如果希望給畫面添加一些細節的話，再另外添加即可～
這么一波操作，大概1個多鐘就可以輸出一整套7個圖，足以應付一周22套運營圖的需求了（悲傷的故事）
當然要達到這種速度還需要一個通用素材庫的加持?？臻e時間把一些KV的圖素拆出來放到Eagle共享盤，這樣你和你的小伙伴們就可以高效愉快地拉圖了...
面向運營同學：創客貼等第三方設計平臺
在創客貼搞個團隊模式，然后設計師把常用的一些模板上傳上去，運營同學只要自己改改文案，換換人就可以啦
雖然有了模板化的設計工具，但如果缺少了設計規范的引導，就會宛如脫韁野馬，設計出各種偏離業務需求或風格不一致的Banner出來。
設計規范需要與運營同學共同協商制定，比如標題最長長度、排版構圖、圖素尺寸等等。具體規范需要根據不同的業務需求進行定制化。
下面就以我們團隊的制定方式作為范例說明一下。
排版構圖
常規的排版構圖模式有居中式構圖、左右構圖。
居中式構圖：居中式構圖是將主體放置畫面的中心進行構圖。這種構圖方式這種構圖方式的最大優點就在于主體突出、明確而且畫面容易取得左右平衡的效果
左右式構圖：左右構圖將文字標題元素和主體物按照比例分割進行位置安排。符合用戶閱讀習慣：閱讀視線要符合用戶從左到右或從上到下的瀏覽習慣。
尺寸
Banner的尺寸需要根據UI界面的需求進行制定。
例如針對我司的產品，一個活動最多有7個運營位的樣式，分別在首頁、搜索位、文章封面、活動中心、閃屏等。
標題長度限制
由于運營同學有時候對于標題的長度沒有經過精簡優化，標題特別長長長長長長長長，加上Banner本身就小，在手機屏幕上基本看不清，也就沒有意義了。因此需要共同制定好主標題副標題長度限制，超過就直接打回重改。
出血設置
制定出血位的原因是某些尺寸的圖素可能出現在多個不同的入口，以及不同尺寸的手機屏幕可能會出現裁剪的現象。
不論是設計師也好，運營同學也好，完成設計之后最好建立一個視覺自查表進行對照，目的是盡量減少一些原則性錯誤，減少來回改稿的情況。
為了更完美的提升整個流程效率，不僅需要升級中部流程，前后端的流程都需要進行優化。
首先是最好在需求的前端建立需求排期表進行需求的篩選。
分門別類地將需求的詳細信息進行可視化展示，對應的需求文檔接入。這里不得不吹一波飛書文檔，太**好用了。
針對需求的后端即設計交付環節，最好是在設計稿導出的時候使用工具進行壓縮，更小的體積意味著更快的加載速度，這對于提升產品的用戶體驗是毋庸置疑的。這里推薦2個工具：
1.imageOptim
2.Picdiet https://www.picdiet.com/zh-cn (個人推薦JPG使用這個網站，壓縮的質量最高)
最后，如果實在人力不足的情況下，就把項目外包出去吧，畢竟占用UI設計師太多時間產出如果沒什么價值的話，其實roi也是很低的，設計師的人力成本也是錢！
“能用錢解決的問題，就用錢解決！”—— 魯迅
如果運營經常提出很多無理的需求，比如量很大，沒有什么依據都是拍腦袋想的，那可以考慮把項目外包出去，一旦外包出去，花的就是真金白銀，讓運營也知道，這是設計師嘔心瀝血畫的，市場的價格就擺在那，整天搞些有的沒的是否真的能對項目帶來價值。
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼ben_lanlan，報下信息，會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
我們在設計中經常會遇到新版本或改版的設計，從創意想法到設計初稿的過程可能會花費比較長的時間。而作為設計師除了自己思考設計之外，還需要與產品、設計老大溝通我們的一些設計想法。因此，我們需要在不同的階段輸出不同的內容反饋進度并達成一些共識。
首先我們要明確什么是情緒版？我的理解是：情緒版既不是初稿也不是最終的風格方向，而是設計師在了解了相關的產品背景后，基于自己對于產品的理解給出的一個較為初始的設計建議，并且希望可以通過這個初始的建議與產品側達成一些相關的設計共識。
情緒版的設計流程大概分為前中后三個階段，前期：分析-收集，中期：篩選-組合，后期：打磨-呈現。
主要是分析產品相關背景或需求本身的方向，結合產品背景及需求本身再進一步分析大概的設計方向并收集相關素材內容。
當我們收集完成后需要對現有素材進行二次篩選并組合，基于現有素材組合大概的設計方案結構。
基礎方案組合完成后需要進行二次打磨，細化方案的內容表現，檢查整體的一致性及完整度，最后呈現給產品方。
可能很多設計師會疑惑為什么要做情緒版，直接設計初稿不就好了嗎？如果有這個疑問，可能還沒實際了解到情緒版到作用。但我們可以試著從我們在設計過程中遇到的痛點來了解情緒版的作用或者意義。
在設計的過程中你是否會存在下面幾個問題：
從這幾個問題中，我們可以得到一個比較統一的結論就是：前期設計呈現內容不夠，導致溝通不足而產生方向不統一。因此基于這個關鍵點，我們再來看情緒版的作用。
在前期，世界觀、背景方面的內容大多是以文字的方式呈現，因此設計師可以通過情緒版的方式，來輸出對應的世界觀設計表現，這樣可以更加直觀的表現出對應的視覺語言。
在初期與產品側溝通時，單純靠語言表達的方式很難讓對方達到一種腦補的狀態。因此借助情緒版的方式更加直觀的呈現設計想法，通過具象的圖形或者圖形，大大降低雙方的溝通成本。
基于第二點的溝通，我們可以明確的了解到產品側的一些喜好。為后續設計初稿時起到一個清晰的方向作用。
從零到一設計一套完整的方案往往需要耗費較長的時間，借助情緒版設計的方式來快速響應一些想法及創意，這樣可以大大提高前期的輸出效率。
從多次的嘗試中，我總結梳理了幾個基本原則，了解這些原則可以讓我們在做的時候更加嚴謹，輸出更加準確的設計方案。
情緒版的設計與我們日常設計一樣，需要給出不同的方向建議，單一的方案往往難以抉擇。多方案輸出除了提升抉擇空間之外，還可以增加方案碰撞的情況，往往可能是方案A的某部分內容疊加方案B的某部分內容才能產生最初的方向。
此階段的所有輸出皆屬于嘗試與探索，因此不必過于考究設計細節，重點在于表達出需要相關的設計概念及思考想法，把更多的時間留作設計思考及方案嘗試。
情緒版的輸出重點在于前期溝通而達到一個比較好的共識，因此在保證質量的情況下，避免花費過多的時間而影響輸出的效率性。盡量做到快與準。在過往中項目組，基本上是以半天（4個小時左右）為一個單位來完成一套方案。
情緒版是一種非常有效試探產品側想要往那種方向去推動的方式，因為我們在實際的設計過程中，產品側可能也對整體的設計大調并不少特別有明確的腦補，因此設計師可以借助情緒版的設計來挖掘產品側想要往哪個方向進行發力。
這里總結情緒版的設計方法大概有這幾種：1.借助圖像/插圖、2.結合實際場景引申、3.借鑒摘取同類型設計、4.繪制草稿。
在我們設計一些專題活動或者繪制插圖相關的一些設計時，可以考慮使用這種方法來輸出你的情緒版設計，可以通過借鑒一些設計網站或插圖網站上的現有素材來拼接，并表達自己在這方法的一些設計意圖及想法。
從更概念化的角度出發，通過引用一些實際場景、物品、圖像，來拓展相關的圖形、質感、色彩方面的設計，并且輸出相關的設計雛形。例如我們在設計LOGO或者圖形類的一些設計，使用這種方法就可以幫助我們突破一些現有的認知壁壘。
在設計之初，我們通常會有一個大概的思考雛形，但如果直接開始設計往往效率上并不高。因此可以借助一些設計網站上的設計，通過摘取組合的方式呈現自己的初步想法。我通常會在UI新版或者改版的時候使用這種方式，但只能表達大概的想法且不能代表最終的初稿設計。
當我們想要表達一些溝通或者框架的設計時，我們可以使用草稿繪制的方式來表現，這個方式簡單快捷，可以很有效率的對齊大部分的設計共識。
基于原則及方法，我們可以來簡單了解下情緒版設計中需要注意的一些事項，通過這些內容讓你在實際操作過程中少踩一些坑。
設計方案控制在2-3個左右即可，前期大多是屬于試探性方案呈現及找方向，太多則容易導致選擇困難。
篇幅過長往往容易降低別人閱讀的耐心，對于情緒版的輸出也是如此。結合過往的經驗，建議以16:9的畫面為一頁來呈現一個方案。
在一頁內呈現的方案避免過于平均，可以適當突出某些想要重點表達的內容，例如在這個方案中想要重點突出圖標、顏色等，那么這里需要突出這部分在畫面中的比例，適當縮小其他模塊的尺寸。
在輸出情緒版設計方案時還可以適當考慮結合產品的世界觀，通過一些具象化的圖形或者插圖來表現相關的內容。例如我們之前在游戲中心改版的嘗試中，就發散了幾個相關的世界觀，因此我們在輸出方案時，則只需要把對應的世界觀作為方案，通過情緒版的方式表現出來即可。
一致性是表現一個設計師是否具有系統化、全局觀的思考思維，因此我們在表現情緒版時也需要關注這方面的內容，避免整體的調性不匹配。
在呈現方案時，盡量多維度的進行對比，呈現一個完整性、系統性的設計。例如我們在設計UI相關的內容，從圖標、顏色、字體等等一系列的內容需要細致的闡述清楚，讓人更加能夠了解你的意圖。
由于我日常以設計UI為主，因此可以給大家重點分享我在UI情緒版設計的經驗。希望可以幫助到大家快速上手。
當你在做UI設計情緒版時，需要明確了解UI設計中的結構，更系統性的去思考整體的內容。我們在UI設計中往往需要包含以下這些內容：圖形系統（圖標+輔助圖形）、顏色系統、字體字形系統、質感形態、界面形態、插圖風格、動效系統、影像系統，等等這些部分的內容。
案例一：整體風格比較偏個性一些，頁面嘗試用深色的背景設計
優點：整體風格比較酷，配色比較未來感符合年輕的人的審美，深色的背景讓內容更加聚焦。
案例二：整體風格3D化的設計，包括頁面的一些體驗上都可以增加視察的效果來設計
優點：整體設計風格比較新穎，符合現在的設計趨勢，整體感覺也比較年輕多彩
缺點：3D的制作成本相對較大
案例三：整體風格比較清爽，白色融入漸變的設計也會顯得比較年輕
優點：整體頁面清爽，可以滿足任何內容的透出，漸變色的圖標和按鈕的設計補充了細節
很多時候我們會覺得情緒版設計可有可無，或者因為時間的關系不允許我們經過這一步。但，如我一開始提到的點，情緒版可以在前期幫助我們去打通很多思考的壁壘，輔助設計師在前期直觀的與產品側進行方向上的探討，從而找到大方向上的共識。
以上都是屬于我個人總結的一些經驗，因此建議大家在日常項目中多去嘗試，并在嘗試中找到適合自己的方法。
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼ben_lanlan，報下信息，會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
信息架構這篇是本人在現階段覺得較難學習與闡述的知識點，網上關于信息架構的知識內容也是參差不齊。在學習與探究的過程中查閱了很多資料，反復修改多次，盡量用直白的語言結合實例來闡述信息架構。目錄如下：
大家可以根據上述目錄來進行選擇性閱讀，當然全文閱讀也是極好的～
這篇文章的起源，來源于最近看到的話題“B端設計師會被組件庫取代嗎？”。從表面上看，在組件庫越來越完善的時代，很多頁面設計依靠組件庫就能夠快速搭建。
那么在這種情況下，B端設計師存在的意義和價值到底體現在哪里呢？其實B端設計的重點并不在頁面的視覺上，視覺只是作為設計師最終輸出成果的一小部分。個人認為B端設計師工作重心體現在做「正確的設計」，比如以下幾個方面：
1.這個設計能否完成對應的商業目標和產品目標；
2.我們的信息呈現是否合理以及能否解決當前需求；
3.用戶能否在頁面上快速找到想要的信息；
而想要弄清楚并解決上述這些問題，在眾多的話題闡述之下，我發現其論述本質上都逃離不了「信息架構」這個概念。因此我認為設計師都需要對這個概念有充分的認知，這能夠幫助我們做出正確且出色的設計。
關于信息架構的概念，在百科上面的定義大部分都比較晦澀難懂，比如維基百科和百度百科的解釋：
相信大部分人都很難明白其中描述的意思。在這里換種思路，將信息架構拆分為信息與架構去理解。
信息指的是內容的載體，常見的文字、圖像等都是信息；架構的含義則形容對應的組織和結構。那么信息架構就是將信息通過一定的形式組織起來，然后呈現出來。其本質就是研究信息的表達與傳遞。
通俗點講，信息架構就是讓用戶可以更容易的理解我們的產品，讓用戶在使用我們的產品時可以更順利、更自然。因此信息架構沒有一個具體的呈現形式，它更多的是體現在產品設計的各方面。具體主要表現為組織系統、標簽系統、導航系統和搜索系統。
為什么需要信息架構？我們都知道B端產品設計的核心是「降本提效」，在設計這一側的可以將其理解為降低認知成本，提升使用效率。
降低認知成本需要我們更好的表達信息，讓用戶能看明白我們的產品能夠做什么，如何用；提升使用效率需要提升信息的傳遞效率，讓用戶能夠很容易的找到需要的功能；
而信息架構從本質上來講也正是研究信息的表達和傳遞。因此我們需要通過它來幫助我們更好的完成B端產品設計。如果沒有信息架構來作底層支撐，那么我們在頁面上看到的可能就只有功能的堆疊，讓產品陷入難以上手或者不知道怎么用的尷尬境地。
一個強大信息架構是產品質量的保證，是作為設計支撐點的骨架，它會減少可用性問題，提升整體導航行，創造對用戶友好的體驗。比如舉一個工具層面的例子：
PS的工具欄堆疊在界面各個部分，而Figma的工具欄則集中在右側且只出現當前需要的功能。很明顯Figma在信息架構中的信息組織部分做得更為友好，PS則會顯得遜色一些。這也是我們在學習PS的時候會顯得比較吃力的原因之一。
可以說良好的信息架構是高效用戶體驗的基礎。視覺元素，功能，交互和導航都是在信息架構的基礎上構建的。因此想要做出體驗好且合理的頁面設計，我們就需要參與到信息架構這個過程中來，和產品一起完成對應架構的梳理。而不是只完成從原型到頁面這個部分。
如果想要搭建一個好的建筑，我們需要知道其建造的目的，是按照什么樣的結構搭建，內部有哪些系統，以及最后呈現的模樣。
那么信息架構也同理，我們首先需要知道信息是為了什么目標服務，然后我們通過怎樣的結構來組織這些信息，以及過程中會用到的信息元素，最后如何呈現它們。這都是我們在搭建信息架構中需要進行的必要步驟。如果某些環節沒有做好或者沒有了解透徹，那么在輸出信息架構時往往會出現方向或者策略上的問題。接下來我們看看這些步驟是如何具體呈現的。
B端行業對于業務理解的要求是比較高的，只有在理解業務的基礎上，將業務需求轉化為對應的設計目標，我們才能夠輸出合理的信息架構方案。
個人認為理解業務的基礎，就是能夠用一句話講清楚當前設計的產品。這句話可以描述為：誰在什么地方想要完成什么目標。比如「用戶想要不出門就能夠吃到東西」，這就是外賣軟件提供的產品服務。
雖然看上去這句話很簡單，但其中包括了三個要素：用戶、場景和目標。因此我們在分析和梳理業務的過程中首先要弄清楚的就是這三個要素。
用戶永遠是排在第一位的，也是我們首先需要弄清楚的。在B端設計中，本質上可以分為兩類角色：客戶和用戶。比如我們常用的釘釘或企業微信，購買客戶是企業，實際用戶是員工。
對于企業：「我想要有一款軟件可以更好的管理員工」
對于員工：「我想要這款軟件能夠更好地提高工作效率」
客戶決定了我們產品的購買（部分情況下也兼顧使用），而用戶則決定了后續產品的復購率。因此在業務理解中，我們需要弄清楚當前產品所處的服務階段，比如初期為了打開市場肯定更傾向于客戶，而中后期為了提高產品的使用體驗又會偏向于用戶。
因此我們首先需要弄清楚的就是當前產品是為哪些「目標用戶」服務，這也就決定了我們在設計信息架構時對應的不同側重點。
場景是指需求產生的某種條件，這個條件包括但不限于環境、時間、地點、空間等，只有上述條件滿足，這個需求才能成立。這里可以把場景理解為產生該問題的原因。
比如當用戶提出「她需要一件衣服」，那么我們就需要弄清楚用戶為什么需要添加衣服，是她感冒了自身覺得冷還是因為外界環境冷。這兩種場景涉及到的解決方案是完全不一樣的。
在平日的工作中我們可以通過以下兩種方式來更好的了解業務場景：
1.通過業務方文檔進行業務背景的初步理解。業務文檔中一般都會包括需求背景，我們可以通過文檔進行初步了解。
2.通過業務溝通進一步加深業務背景的理解。由于很多B端業務離設計師本身的生活比較遠。因此對于需求背景中不理解或者比較模糊的部分，我們可以通過與業務方或產品多次溝通來挖掘最底層的背景。
畢竟需求背景是理解業務的重要步驟，我們只有知道需求產生的原因，才能夠針對性的給出解決方案。
目標決定了我們的產品最終的方向。我們首先接觸到的一般都是業務目標，而我們要做的就是將業務目標轉化為我們此次的設計目標。
A.業務目標
業務目標就是此次業務想要解決的實際問題，它通常是一個宏觀上的描述。比如打車軟件的業務目標簡單概括來講就是讓用戶能夠更快速地打到車，減少等待焦慮。我們一般通過文檔或者溝通來了解該目標。
B.設計目標
設計目標是我們基于業務目標而給出的設計策略，是一種更具體的實現方式。比如我們要讓用戶快速的打到車，那么這個時候我們的設計目標就是通過將用戶位置和司機位置進行快速匹配，并通過超時補貼紅包的方案來降低用戶焦慮。從而實現業務目標。而這一過程涉及到的信息點就有：司機位置、乘客位置、等車時間、補貼金額等元素，并需要思考它們之間的關系和呈現方式。
可以發現從業務目標轉化到設計目標這個過程，實際上就是在確定功能和信息點的過程。這樣才能讓我們更好地設計信息架構。
從前文可以看出我們會在整體設計過程中出現很多的信息元素。如果不經過對應的組織和處理，直接堆疊在一起，那么信息含義會比較亂且難以調用。比如下方：
而右側圖片信息的組織過程可以理解為通過將零散的數據信息進行分類，再以某種結構化的形式將它們重新組合排布的過程，直白一點就是先分類，再結構化呈現。我用一張圖來表明這個過程：
那么這個過程中「信息組織」和「結構呈現」到底應該怎么做，也就是接下來要講的組織方式和結構類型。
組織方式可以分為精確分類和模糊分類。精確分類就是我們會利用物體本身物理屬性來進行分類，比如位置、字母表、時間、類別、層級等方式進行組織。一些工具類應用例如滴答清單內容信息都是按照時間來進行組織的：
而模糊分類則是按照更為主觀的邏輯對信息進行分類, 如主題、任務、用戶、隱喻等來進行歸類，比如我們常用的APP商城是按照不同的主題類別來進行區分的。
但在很多時候，產品傾向于將兩種組織方式結合起來形成復合型組織方式，從而能夠使我們的整體組織形式更符合用戶的使用習慣。比如藍湖的信息組織，其中既包含了模糊分類（按使用類型等分類），也包含了精確分類（按上傳文件時間等）。
其實在大部分B端產品中，大都按照模糊分類來進行處理，比如按照任務、流程等方式。而精確分類更多用于在頁面內的局部信息模塊，比如創建時間和文件大小等。
歸根結底，我們分類方式的選擇需要結合我們前面提到的用戶、場景和目標，這樣才能讓我們的分類更具說服力。
當信息按照分類維度組織后，我們接下來就是把整體信息進行結構化，這樣才可以將信息整體連接起來并呈現出來。一般分為以下四種組織方式：
A.層級結構（最重要的結構）
這是信息架構中最為常見的結構，也是比較符合用戶認知的結構。有時也稱為「樹狀結構」。以子父節點的形式一層一層延展。
層級結構的優勢就在于可以承載復雜的多層級內容，通過層級遞進的方式將復雜的多層級拆解得更簡潔。
但我們需要把控好內容的廣度和深度，廣度指的是在層級結構中每一層的數目，最好控制在7個以內。如果廣度太寬意味著每個頁面會給用戶展示太多的信息，增加尋找內容的負擔。深度為縱向結構，建議一般3層，最多不超過5層。過深的層級會讓用戶點擊很多次，且不容易被用戶發現。比如飛書的基本信息架構也是主要以層級結構來進行的。
B.矩陣結構（多維度結構）
矩陣結構是各個節點都相互連接的一種信息架構方式，通俗來講就是用戶既可以通過多個維度去觸達同一信息，也可以從單個維度連接多種信息。
這種結構其實就更類似于我們在做相關功能時：比如當你進入電影全屏時想要退出時，既可以通過點擊按鈕退出，還可以通過鍵盤的Esc返回到，通過多點觸達同一操作。
又比如我們的聯系人功能，我們既可以通過輸入數字撥打電話，也可以查找聯系人進行撥打，還可以查詢電話記錄進行回撥。
矩陣結構最重要的意義在于給用戶提供多種路徑，使用戶能夠在不同路徑中尋找各自想要的東西。
C.自然結構（隨機性）
自然結構不遵循任何一致的模式，節點都是被逐一連接起來的。
自然結構一般都具有隨機性和不確定性。這種更傾向于泛娛樂化的C端應用。比如我們常見視頻網站的在推薦流都是應用的自然結構。比如打開B站等視頻平臺，你很難猜到剛進入看到的是什么。
但一般自然結構不會單獨存在，比如B站在自然結構中也綁定了層級結構來進行層級上的劃分。
D.線性結構（單一性）
線性結構是非常單一的一個結構，整體是一層一層向下遞進。比較強調先后順序的一種結構。
這種結構通常用于我們常見的軟件安裝程序等，也可以用于部分功能結構，比如網站的視頻發布，一般都是經過上傳-編輯-發布這三個步驟來依次進行。
大家可以發現在進行信息架構時，我們在很多情況下可能會運用多種組織結構方式，我們需要根據對應的用戶決策場景來考慮讓最適合的幾種方式相結合。但最終目的都是為了讓用戶能夠更快速的獲取信息。
在信息的組織過程中，我們需要注意用戶的心智模型。比如當我們看到紅點就知道有新信息通知，看到下拉箭頭就知道可以展開。這是互聯網產品在無形中給用戶建立的底層習慣認知。用戶目前對于普遍產品的一些基礎布局、功能名稱和交互邏輯都形成了一定的習慣，這都屬于用戶的心智模型的內容。
因此我們在組織信息時盡可能不要去打破用戶常見的心智模型，否則必然會導致用戶的不習慣。我們常見的「掃一掃」功能，微信、支付寶和QQ會隱藏在「+」號里面。而微博和抖音卻分別放置在了「我的」和「搜索」里面。
這樣會導致用戶難以發現該功能。因為用戶接觸新的信息時，會以最初接觸的局部信息為依據展開并形成初步認知，而用戶認知中的信息組織邏輯和實際信息的吻合度越高, 他在進一步查看或尋找信息的過程中體驗會更順暢, 反之, 若一開始形成的認知與實際信息的差異過大, 在后期的信息搜尋過程中則容易遇到困難。而這個吻合程度其實就是用戶心智模型。
雖然建議在一定程度上遵循用戶心智，但并不是說絕對遵循。對于用戶不熟知的場景或者某些專業術語，我們需要通過靈活有效的提示（比如標記注釋等）來引導用戶就可以了。比如我們剛才提出的抖音掃一掃，它的應用場景其實是用于抖音官網后臺登錄，且在后臺登錄時已經給出了對應提示，那么這樣的設計也是合理的。
當經過上面的信息組織，其實我們已經能夠歸納出一個大體的信息架構框架。但在信息組織之外，我們還需要關注以下三點：標簽、導航和搜索。這對于信息架構的完整性也有非常重要的意義。
標簽系統，通俗來講就是要我們對當前整個系統信息節點的命名，從而讓信息的呈現更容易識別。拿個最簡單的例子來進行說明：
可以看到左側和右側關于衛生間的信息標示，可能左邊你能一眼區分，右邊可能就需要反應半天才能猜出到底代表什么含義了。
這其實就是關于我們的信息命名是否能夠被大多數用戶所接受的場景，也就是我們標簽作用所起的作用。標簽可以分為圖片和文字標簽，都需要考慮用戶對該信息命名的認知程度，也就是前面提到的心智模型。那么如何能夠更好的去定義標簽名稱呢，這里需要注意2個方面：
A.優先選用被行業廣泛接受的詞或圖標
在進行標簽定義的時候，盡量選擇已經被用戶所熟知的詞語，比如「工作臺」「通訊錄」等已經被運用得非常熟練，對于類似功能就直接以該形式命名，比如我們的設計軟件中，很多圖標和功能名稱都是通用的：
這樣做能夠很大程度減少用戶的學習成本。因此在B端設計中我們也需要注意到我們所在的行業，哪些名詞已經達成了共識，就無需再造新名詞。
B.不確定的詞語可以參考競品或調研來決策
當某類功能或場景的標簽難以確定時，我們就可以嘗試去找一下競品是否有類似功能，或者找該行業的領頭羊（比如聊天工具的巨頭微信），那么在進行標簽定義的時候，可以參考它的命名體系。因為它已經替我們教育了一部分用戶，會間接降低學習成本。
如果某些標簽在上述過程中還是無法確定，那么我們結合自己經驗或者與咨詢業務相關人員來進行討論，在必要時候可以在標簽旁邊添加注釋來進一步說明。
導航系統其實應該是大家比較熟知的一個系統了。就像使用導航系統來規劃行程一樣，導航系統都會存在于每個網站中。比如我們常見的側邊導航、頂部導航等。
因為網上關于導航系統已經有很多資料的講解了，在這里闡述下四類導航的含義：
1.全局導航：位于頁面最上層的導航，用戶幾乎在頁面的每個地方都可以看見，是最高層級的導航系統；
2.局部導航：位于最高導航的下級子類導航，子類導航并不是必須的導航，根據場景進行取舍；
3.情景式導航：通過點擊文字鏈接進行跳轉的導航，比如在個人資料里面植入其它網站的鏈接地址；
4.輔助導航：這里包括網站地圖，網站索引，網站指南等輔助類型的導航。
輔助導航的網站指南包括新手引導和演示教程等?，F階段更巧妙的功能引導，是當用戶在進行某些功能的操作時及時進行提示，這樣不僅達到了為用戶引導的效果，還減少了一連串的新手引導對于用戶的打擾。比如figma在進行組件更新后，只有當你調用組件功能時，才會及時進行提醒。
搜索，是我們平日最常用的查找信息的功能，它能夠幫助我們快速進行信息的檢索。雖然搜索功能非常重要，但并不是每個系統每個頁面都需要搜索。我們決策是否添加搜索時需要考慮下列三點：
1:內容復雜度：當前頁面承載的內容復雜度如果較少，對于簡單內容頁面往往不需要搜索；
2:內容性質：當前頁面的性質是偏向于用戶瀏覽還是查找，根據用戶行為來決定是否需要搜索；
3.搜索場景：如果搜索場景很簡單，考慮是否只用篩選或分類就能夠解決問題；反之如果搜索內容很復雜，我們還可以搜索結合篩選來更好的查找信息；
上述3點決定了我們是否需要考慮搜索功能。而關于搜索的其他細節點，比如搜索規則和搜索結果等，在這里不做進一步的闡述。在這篇文章中更重要的是弄清楚我們何時需要搜索功能。
我們通過上述方法已經知道如何梳理信息架構了，那么我們應該如何呈現它呢。這部分其實也是很多資料中比較模糊的點。
在學習的過程中，發現部分資料認為信息架構就是單純的指思維導圖，但實際上信息架構并不能單純只用思維導圖就能夠完全表示。
因為信息架構包含了很多部分的內容。只能說思維導圖可以是信息架構的一種表現形式，其可以幫助我們在思考階段梳理整體產品的信息構成。
這里拋出一個很有意思的觀點，那就是「功能結構圖」和「信息架構圖」到底什么關系，這里用兩張圖示例：
可以看到，功能結構圖更多體現的形式是功能闡述，一般形式為名詞+動詞，比如頭像設置；而信息架構圖重點呈現的應該都為信息元素，一般為名詞，比如頭像圖片。
但在大多數時候我們看到的產品架構圖，其實更偏向于功能結構圖和信息架構圖的結合。因為在很多時候闡述信息構成時需要依賴功能進行輔助說明。
因此這篇文章講述的信息架構更偏向于基于產品的整體架構。其實信息架構對于呈現形式并沒有特別的限制，只要能夠幫助你清晰表達產品整體結構就行?！缎畔⒓軜嫞撼絯eb設計》第4版中其實也并沒有對表現形式這一塊進行嚴苛的定義，其用「顯示信息元素間的關系——站點地圖」的說法概括了信息架構的呈現形式，其表達如下：
可以看到其表達形式包括思維導圖和流程圖等形式：思維導圖的優勢是能夠總覽全局信息，查看信息的深度和廣度，而流程圖的優勢則更能夠表達整體的邏輯關系。
因此信息架構的呈現需要根據你的產品場景選擇合適的視覺框架表達。不必讓形式限制了我們的發揮，而是應該形式追隨于我們的架構表達。其只是一個信息梳理結構的說明結果（類似于中間態），我們需要借助它來更好的闡述思路與溝通想法。
在輸出信息架構之后，其實這里想聊一聊頁面的呈現。因為當梳理好大的框架后，剩余的頁面細節其實都需要通過原型圖來進行體現。這個過程是從框架到頁面的階段，其實對于設計師來說也是很重要的部分。在這里根據自己的理解列出了以下幾方面的注意點：
A.頁面能夠讓用戶看懂
這其實就是涉及到我們的信息組織和標簽系統。如果當我們的某個頁面不能讓用戶第一時間獲取到該頁面表達的信息，反思一下是在哪個方面做得不好。是標簽系統含義模糊呢，還是信息的組織分類方式不對。從頁面呈現倒推信息架構。
綜合來說就是設計時的排列要考慮用戶的心智模型（比如網頁的常規排版和通用名詞定義等），對于某些難以理解的地方給予用戶幫助和解釋。雖然B端產品想要完全避免學習成本是不可能的，但我們可以盡量減少其學習成本。
B.考慮用戶的視覺動線
當我們在進行信息排列時，這時需要思考的就是用戶的視覺動線，也就是我們常說的視覺瀏覽「F模型」和「Z模型」。對于不同的信息流來說，采用不同的動線模型能夠讓用戶更好地查找信息。
F模型和Z模型的使用區分其實就是在使用場景上，對于內容頁面來說F模型會更為合適（比如文章或者搜索結果），適合文本類的內容。但對于非文本的頁面，則更適合用Z模型，Z型模式的設計跟蹤了人眼掃描頁面時的路線——從左到右，從上到下，能夠更好引導用戶的視線。
C.掌控好適度的信息層級
B端由于在視覺的發揮空間不多，那么相對來說保持良好的信息層級能夠讓整體的體驗變得更為良好。
不管是原型圖還是視覺，整體的視覺層級要體現得更為清晰。按理說最好的視覺層級控制在三級左右。如果發現視覺層級過多，需要考慮是不是因為信息架構設計時縱向層級過深，通過調整架構的形式來更好的呈現信息。以及對同頁面的信息進行重要程度分級。
當我們做完或者聽別人闡述對應的信息架構時，該如何評判呢，到底怎樣的信息架構才算優秀呢。個人認為可以從3方面去進行判斷：
業務層：
1.設計目標合理：能平衡商業目標和用戶的目標，保證客戶和用戶都有較為良好的體驗；
2.核心任務目標：能夠讓用戶順利完成產品的核心任務，需要通過用戶測試來進行驗證
結構層：
1.平衡廣度和深度：在進行功能使用時不會隱藏的太深而找不到，是否有冗余步驟
2.保證拓展性：當前信息架構在面對未來新增或者刪減信息時能夠穩定拓展
體驗層：
1.保證易讀性：用戶不經過介紹，通過頁面信息呈現能夠看懂該產品是用來做什么的
2.保證易查找性：用戶在需要某個功能時能否快捷的找到，是否有多種查找方法（比如搜索或篩選）
合理的信息架構需要具備以上條件，我們需要在做設計呈現時也盡量保證以上條件。但在很多情況下其實并不能完全滿足，這個時候我們需要根據業務目標的重要性來選擇某些點進行滿足。
梳理一下整體文章的架構，其實是按照「是什么-為什么-怎么做」的形式來進行拆分的：
這篇文章想要表達的觀點，不是讓設計師獨立去梳理整體信息架構，而是讓設計師擁有信息架構意識，了解其是如何進行并產生的。這樣你在看到整體架構時，有足夠的理論支撐去判斷它的好壞，并通過自己的理論認知去理解和改進不好的地方。
當我們對信息架構有足夠的認知時，我們在設計頁面時才能有合理的思考方向，做出「正確的設計」，避免成為無情的作圖機器。信息架構作為產品交互視覺最底層的支撐，只有骨架搭好，對于用戶的使用體驗才能夠有本質上的提升。
注：文章中不可避免會存在不足之處，如果對文章中內容有更好建議，歡迎隨時交流。
參考資料：
《web信息架構》第四版
《信息焦慮》
《用戶體驗要素》
《信息架構設計》
「從設計前/設計中階段，了解信息架構知識點」
「互聯網產品如何搭建信息架構」
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼ben_lanlan，報下信息，會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
文章來源：站酷 作者：進擊的M
關鍵詞：搜索框，UI，UX交互，用戶體驗，響應式設計，網頁
題外話Tips: 在寫Amazon案例時，看到了歪果仁對國貨馬應龍的評論，簡直太歡樂（以前看過人家翻譯的帖子，但自己看一遍還是太搞笑了）。于是就寫跑偏了，翻譯了下貼了上來。隨便樂樂~ （CTRL+F頁內搜索可直達）
目錄：（CTRL+F頁內搜索可直達）
第一章 搜索框-默認狀態
一、 位置
二、 寬度（包含響應式設計）
三、 按鈕樣式
四、 展開 or 隱藏？
五、 默認要有提示文字??！
六、 推薦詞
七、 有很多分類怎么辦？
八、 一個頁面里有2個搜索框怎么處理？
第二章 搜索框-光標觸發的狀態
一、下拉框中，歷史記錄+熱搜詞是標配
二、下拉框中，標配+額外內容
三、下拉框中，純個性化內容
第三章 搜索框-搜索中的狀態
一、 默認交互
二、 個性化交互
三、 搜索下拉框中的多選功能
四、 回車 or 不回車？
正文：
以下都是從Web端角度寫的總結，Web的空間比APP大，相對來說，交互可發揮的余地更大。APP端如果有時間，就另外再寫吧。
搜索框簡單吧，也就輸入框+按鈕。但是就那么點小元素，里面也是注滿了無數的小心思，死光了無數產品經理/交互設計師的腦細胞，只是為了讓交互更流暢，產品體驗更好。
搜索框的默認UI/UX樣式，取決于網站的業務性質，取決于搜索功能的重要性，取決于頁面布局。
一、位置
搜索框的位置放在哪里，取決于搜索功能對于網站的重要性。
N年前，就有很多小伙伴引用過如下研究報告了，我重復下吧。
Dawn Shikh 與 Keisi Lenz 的研究：展示了在142個參與者的調查中，網站搜索框的期望位置。研究發現，對用戶來說最方便使用的地方是網站的左上角與右上角位置。用戶可以使用常見的F形掃描模式輕松找到它。
如圖，搜索框要放置在網站的右上角或者中間位置，這是用戶所期望的位置。
目前大部分網站在UI布局搜索框時，也是大致遵循這個規則的。但總體來說，搜索框的位置，還是可以分為如下幾種：
1. 頁面-居中
2. 頁面-頂部居中
3. 頁面-頂部右邊
4. 其他
那么，分別討論：
1. 頁面-居中
為啥居中？當然因為對于網站，搜索是核心功能。如果沒有搜索功能的話，業務幾乎無法開展。它最最最重要啦！
1）絕對居中
這種一般適用于搜索引擎的首頁。頁面基本就是一屏，搜索是最主要功能，其他內容不重要。
比如Google, 百度。
Google的界面就相當干凈清爽。嘿，我就是純搜索的，趕緊搜唄！
百度，可以只顯示一個搜索框。
如圖所示的搜索框下的大塊資訊，是可以在設置中隱藏的，不想看，關掉就好。
2）相對居中，垂直略靠上部。
適用于數據庫網站的首頁。
因為數據庫的數據量動不動就是千萬、上億的，搜索是極其重要的功能，99%的用戶都是帶著目的來的，直接通過搜索找數據的。搜索框需要極其醒目，需要占據首屏大部分的位置。
但考慮到數據庫網站的首頁也需要展示其他信息，來增加用戶粘性，一般會有好幾屏，比如最新信息，熱點信息之類的。這些就放在搜索框大區塊的下方了。
比如 官方司法權威網站-中國裁判文書網，全國的1億多個案件都在這個數據庫里，供免費查閱。搜索數據是核心功能，因此搜索框最醒目，占首屏大部分位置。其他信息依次往下布局展示。
2. 頁面-頂部居中
為啥頂部居中？因為網站業務中，搜索是重要功能，但不是全部。不用夸大顯示，但頂部的居中好位置要留給它。
一般適用于電商平臺，資訊平臺。
這些網站中，展示商品、廣告、信息才是重點，是為了促成交易，增加流量的。搜索是工具，比較重要，但不是重點，只是為了達成目的的一個手段。因此可以放在頁面頂部且居中的顯眼好位置，重要，但是不過分夸張。
用戶場景：
如果用戶是漫無目的的瞎逛，可以隨便瀏覽頁面中提供的大量信息。
如果用戶是有目的的找某個商品或信息，也能很容易的在頁面頂部找到搜索框，定位目標。
比如，電商平臺-京東
比如，視頻平臺-Youtube
看到了嗎？頂部中間，不太顯眼的那個灰色搜索框。
3. 頁面-頂部右邊
為啥頂部右邊？因為網站業務中，搜索只是輔助功能，居中這么好個位置沒必要，放右邊看得見就行了。
比如， Dribbble
Dribbble，設計師都知道。一般大家都是去隨便看看找靈感的，瀏覽信息是重點，搜索功能不太重要，放邊上就行了。
比如，小米
提問：有同學會問，嗯哼，這是電商網站呀，要賣產品呀。為什么不像淘寶京東一樣放頂部居中呀？
回答：因為，這是品牌自己的平臺呀，就那么幾個品類，在頂部導航條內，側邊導航條內都已經展示得清清楚楚了，鼠標點點就行了。搜索是次要的功能。
根據設計原則——奧卡姆剃刀原理（簡單有效原理）
* 只放置必要的東西
* 給予更少的選項
頂部的品類導航條本身就能幫用戶找到產品了，可以直達分類頁面，是非常重要的入口，也是重要的產品宣傳，需要放在頂部首行的位置。
搜索是輔助功能（此處相信小米的PM是分析過search usage的），放在次要位置就可以了。
不需要同時突出搜索框+品類導航條，來增加用戶的選擇成本。
另外，要是搜索框居中了，那展示品類的重要導航條就得布局在第二行。Web/APP的第一屏都是黃金位置，能省一行是一行。
4. 其他
1）可以放logo的右邊。
比如google的搜索結果頁
從設計理念上說，google的搜索框和logo放在一起，也能組成品牌和搜索引擎之間的強關系。即google=search. 用戶們不也早就說，“你google一下”，而不是“你搜索一下了”嘛!
從UI上說，搜索引擎的內頁一般只有列表，這樣搜索框也能和列表左對齊，布局清晰。
2）其他位置，根據情況判斷。
比如Figma界面，文章最后有圖。此處不贅述。
二、寬度
搜索框的寬度（包括input box + search button），同樣取決于搜索功能的重要性。其中，大概率取決于上文所述的搜索框的位置。
其次，也需要考慮輸入的關鍵字的字符數。
另外，根據整體布局決定。
一般情況下，220px<寬度<650px。 請注意, 這是建議的相對值，不是絕對值。只表示搜索框在大部分Web中的情況，具體需根據自己的頁面情況調整。實際應用中，也有搜索框最長到1000px的情況。也有比220px更短的。
根據搜索框在頁面中的不同位置，搜索框寬度分別如下：
1. 如果搜索框位置在頁面居中，那搜索功能也極其重要，那當然寬一點。
比如上文提到的google，百度。搜索框寬度通常固定在650px以內，保證在所有分辨率中都能顯示全。也保證了可顯示的關鍵字字符數大于60個（即60個字母，30個中文字），大大的足夠了。
2. 如果搜索框位置在頂部居右，那搜索就是輔助功能，那當然短一點。
具體寬度，需要考慮頂部UI布局情況。但一般不小于220px（大概數值，自己平衡）. 不然就不太方便輸入關鍵字了，或者關鍵字就顯示不了幾個了。
3. 那如果搜索框位置在在頂部居中呢？則可長可短，根據業務情況和頁面布局判斷。
如果為了用戶體驗好的話，搜索框寬度也需要考慮「響應式設計Responsive Design」。
既然都說到 「響應式設計」了，那么就提一下吧。
概念：
響應式設計（Responsive Design）是頁面布局可以「響應」不同尺寸屏幕的設計方法。通常我們說起響應式設計都是針對網頁設計的。同一個頁面，隨著屏幕尺寸的改變，自適應地改變頁面布局。
通俗來說，這個網頁就可以自動適應手機，平板，和電腦的各個分辨率。用戶在各個設備上瀏覽這個web頁時，頁面布局和交互都是自動調節的，相當舒適。
以頁面中的單個功能區為例：
* 比如，內容區塊的在一定程度上能夠自動調整，以確保填滿整個頁面。
* 比如，網格排布，能夠減少/增加排布的列數。如圖片布局在“1行1列” 到“1行N列” 之間，自動調整列數。
* 比如，能夠適應比例變化的圖片。圖片自動調整大小。
* 比如，篩選功能在網頁里是在頁面左側一列，全部展開顯示的，在手機里就可以隱藏顯示，通過按鈕點擊，有滑出菜單之類的。
Tips: 做響應式設計，需要公司舍得投入資源，因為涉及到很多額外的工作量。最起碼有以下：
* Designer | 設計——做3套設計。
* Frontend Engineer | 前端——寫響應式設計的代碼，可寫1套，可寫3套（方便維護）。
* QA Engineer | 測試——測不同的分辨率，最起碼測3套。這還沒算fix bug后的retest.
為啥3套？因為針對分辨率需要做2個節點。我司一般是792px<X<1440px
好了，響應式設計就大概講一下吧。不然又能寫好幾頁。收~
以Youtube為例，大家可以感受下搜索框的響應式設計。
搜索框的寬度是會自動調節的。最小的時候就一個放大鏡圖標（此時為適應手機分辨率），但最寬也就是固定到640px，不然太寬了，輸入關鍵詞時，搜索按鈕離得太遠，點擊也會很不方便。
三、 按鈕樣式
搜索框的按鈕樣式，同樣取決于搜索功能的重要性。也需要平衡整體頁面布局。
按鈕樣式大致情況，如下圖所示：
* 色塊帶圖標的
* 只有一個圖標的
* 沒有按鈕的
* 色塊帶圖標+文字的。
* 其他（比如就一個放大鏡圖標等。圖片中沒做展示）
具體怎么應用，詳見后文：
四、 正常顯示 or 簡化顯示？
九、 一個頁面里有2個搜索框怎么處理？
四、正常顯示 or 簡化顯示？
有些Web中的搜索框，因為各種原因，可能就會做簡化。而不是整個顯示，這個需要根據情況決定，就是——隨機應變~
比如，Apple官網，只顯示一個放大鏡圖標。
此處跟上文提到的小米官網的情況類似。商品品類就這些，導航條突出品類，搜索功能弱化。
但蘋果在此處更弱化了搜索，只放一個放大鏡圖標。（從UI上看，目測是由于導航條中品類太多，放不下搜索框了。） 等用戶點擊了放大鏡圖標后，才使用CSS / JS特效，滑動顯示完整的搜索框，且居中顯示。
再比如，Airbnb 愛彼迎，全球民宿短租公寓預訂平臺。
網站中，搜索功能很重要，是用戶預定，增加銷售的入口。因此需要突出搜索框。
* 首頁，默認顯示完整的搜索框。
* 當頁面滾動時，搜索框置頂顯示，方便用戶查詢和預定，增加潛在銷售可能。但是這個搜索框的內容太多，硬要在置頂層中全部顯示的話，這個始終置頂的層的高度就會很高，會影響用戶瀏覽頁面內容。
那么就把搜索框略微簡化，相應的高度也就小了。（不建議只放一個放大鏡按鈕，太弱化搜索功能了。會流失潛在客戶，流失潛在銷售可能）
* 搜索框在置頂層中居中顯示，點擊簡化版搜索框后，才動效顯示完整的搜索框。
五、默認要顯示提示文字啊！
在輸入框中可以提示搜索示例，告知網站支持哪些內容的搜索，以及如何使用功能。防止用戶一臉懵，優化用戶體驗。
通常適用于數據庫，資訊類這些內容類型較多的網站。
比如，天眼查。（垂直頂部居中的搜索框）
比如，網易云音樂。 （右上角搜索框）
六、推薦詞
基于業務需要，搜索框內經常會有推薦詞，方便用戶不用輸入關鍵詞就可以直達結果。同時，也是一種對商品的促銷，對資訊的推廣。根據不同需要，可以有不同的顯示方式。
Tips: 推薦詞，熱搜詞，促銷，廣告都可以這么處理。
1. 框內
1）單個推薦詞交替顯示
比如，小米官網
截圖為動態圖哦，大概5秒換一個推薦詞。個人覺得間隔時間有點長了。
2）多個推薦詞同時顯示
比如，LexisNexis 全球頂級法律數據庫 中國站
沒有和小米一樣，做1個推薦詞的動態交替顯示，是因為用戶場景不同。
考慮到LexisNexis的用戶都是律師群體，工作中時間寶貴。使用網站不是閑逛，而是為了快速查詢數據，沒有時間等待。因此一次性顯示2-3個推薦詞，方便用戶直接看到，直接點擊。
提示：推薦詞可能會大于3個的，比如有8個。那就在用戶每次回到首頁后，顯示一批新的推薦詞。
或者，直接顯示在框外，如下文所述。
2. 框外
比如，淘寶
七、有很多分類怎么辦？
如果要針對很多內容類型分別搜索怎么辦呢？搜索框怎么處理呢？有很多方法。
按復雜程度，依次進階如下：
1. 下拉框型
一般用下拉框了，那通常分類對于搜索不是太重要，不用突出顯示。
2.Tab型
如果用tab來展示分類了，那目的通常是：
* 推廣產品或內容
* 引導用戶，優化用戶體驗
1）橫版顯示。比如 某房產網站
2）豎版顯示。比如 知網
搜索框的左側的3個Tab為內容類型分類。
搜索框中展開的下拉框中是字段，此處一并展示。
3）豎版+橫板顯示。比如 某房產網站
如上圖，是豎版分類+橫版的兩個搜索按鈕。
如上圖，是豎版的分類+橫版的分類。橫版的分類還做了2級分類。分類太多，相信設計師們在處理時也挺頭大。
八、 一個頁面里有2個搜索框怎么處理？
回答：哪個重要，就突出顯示哪個唄！
以Amazon為例，
該頁為商品評論頁面。
* 頂部搜索框為全站搜索，非常重要。因此寬度較長，按鈕為亞馬遜的主色調黃色，醒目。
* 頁面內的搜索框，為針對評論內容的搜索，則相對弱化。
搜索框的默認狀態講完了。那么當鼠標點擊搜索框，此時還沒有輸入任何內容，那么光標觸發的狀態是怎樣的呢？通常，根據業務情況，大多數搜索框都會自動彈出下拉框。
我們此處只討論下拉框中的顯示情況。
一、下拉框中，歷史記錄+熱搜詞是大部分網站的標配。
比如，B站。
二、 下拉框中，在歷史記錄+熱搜詞的基礎上，再添加些網站自己想推廣的內容。
比如，Zcool本酷。
三、下拉框中，根據網站自身業務情況，顯示個性化內容。
1. 比如 Zillow, 美國知名房產估價網
網站業務就是估房價。下拉框中，第一行就是“當前位置”，點擊后跳轉到結果頁，顯示定位地址的相關結果。優化用戶體驗。
2. 比如，攜程。
攜程的業務結構相對復雜，搜索也就相對復雜。搜索項同時也涉及到很多字段/參數，其實也類似表單了。后面有機會可以講下表單的交互，此處不延伸討論了。大家有興趣可以去逛逛攜程。
在搜索框中，一旦開始輸入字符，那新一輪的交互又開始了。
一、 默認交互
目前通用的規則——搜索聯想功能，Google已經定義好了。我就不重復寫了，如下摘自UXPlanet：
Google自2008年以來掌握并實施了“搜索聯想”。
“搜索聯想”（自動建議）可以幫助用戶通過已輸入的文本來預測可以找到的查詢結果，為用戶節省了時間并創造了更加便捷的體驗。
交互細節如下：
* 確保搜索聯想是有效的，設計不完善的搜索聯想會混淆和分散用戶的注意力，所以使用拼寫自動更正、詞根識別、語義識別和預測，可以改進搜索體驗。
（Lu傾傾 注：中文搜索還要識別拼音）
* 盡可能快速的提供搜索聯想，例如輸入到第三個字的時候，就給用戶提供相匹配的聯想詞匯，以此減少用戶數據錄入的工作。
（Lu傾傾 注：現在其實輸入第1個字就可以提供聯想了。）
* 只提供少于10個項目的聯想詞句（不建議使用滾動條），否則信息將會變得難以承受。
* 允許用戶通過鍵盤的上下鍵控制選擇列表。
（Lu傾傾 注：
百度在使用“鍵盤”（鼠標不行）上下選擇列表時，如果高亮在某個聯想詞上停頓2秒以上，則等同于“回車鍵”，整個頁面的搜索結果刷新。 Google不支持此功能。
這是用戶體驗的差異）
* UI上，已輸入文本和建議文本視覺上保持差異（例如，通常情況下建議的詞匯通過加粗表示）
二、 個性化交互
1. 比如，Google
（Google作為搜索引擎的燈塔，搜索交互亮點的地方太多太多了，這里只舉個小例子。）
如上圖，不只在下拉框中展示搜索聯想的關鍵詞。
還把關鍵詞作為一個詞條顯示給客戶，比如電影，比如品牌。還同時顯示各自的參數，比如 圖片，字段。
可以幫助用戶了解信息，精準定位。
2. 比如，維基百科。
由于網站的定位不同。維基百科是一個百科全書，其中都是各類詞條相關的知識/信息。因此下拉框中的聯想，都是以詞條形式顯示的。包含了圖片，詞條名， 參數/字段。
3. Amazon 亞馬遜
亞馬遜的用戶體驗也是做到極致了。搜索下拉框除了提供搜索聯想的關鍵詞，還按照不同的特殊關鍵詞，提供不同的參數選項，方便用戶一步到位，不用再到搜索結果頁里做一次篩選了。優化用戶體驗。
比如，想搜索“chair”, 輸入了關鍵詞“chai”(注意，還沒打全 chair)，下拉框中除了顯示chair相關的商品。還直接把chair的價格區間顯示出來，方便用戶點擊后，直接顯示相關搜索結果。
相信此處亞馬遜的PM們是做過usage分析的，chair列表頁中，應該是 “價格”篩選的usage是最高的，并且極有可能用戶進入chair列表頁的第一個用戶行為就是對價格做篩選。PM們就干脆把篩選項放到了搜索下拉框中了。
針對關鍵詞”ipad”, 也是同樣的交互處理方式，此處是顯示“尺寸”區間。
針對關鍵詞“alarm”,下拉框中按照鬧鐘的不同“功能”，顯示“圖片+分類“，方便用戶直接點擊。
【亞馬遜篇 番外】
在收集亞馬遜案例的時候，好玩就去搜了搜國貨之光“馬應龍“，歪果仁們的評論簡直是太歡樂了，看著看著我都笑出了鵝叫聲。
于是就跑偏了，翻譯了2個評論，貼了上來。大家看文章看久了，休息下~
以上，討論的都是輸入單個關鍵詞搜索的情況。
那么輸入多個關鍵詞的交互該怎么處理呢？
N年前，我在《交互設計稿-純實例》之前我寫過，此處不再贅述了。
如有興趣，請戳，https://www.zcool.com.cn/work/ZMjY4Nzg3MDA=.html
大部分的網站的搜索功能，都是需要在輸入關鍵詞后，點擊“搜索按鈕“ or “回車”，才展示新的搜索結果頁的。（此處不討論百度中，鍵盤移動到聯想上就刷新結果頁等特殊情況）
即一定要有個確認的命令，才觸發搜索。這里面有很多考慮。比如：
* 數據量大，如果是實時響應+即時加載搜索結果頁，對服務器和代碼質量的要求都太高。
* 用戶體驗不太好。因為用戶還沒輸入完，或者還沒確定。頁面就在不停的刷新，會干擾用戶。
但，也有個別工具軟件中，不用按回車，就實時刷新搜索結果。比如，Figma.
在軟件中，都是自己的存檔文件，數據量本身就不大。此時邊輸入關鍵字，邊實時響應，刷新搜索結果頁，讓用戶隨時看到自己的文檔。這種情況下，不用按回車，用戶體驗還更好。
以上，終于寫完了。
暫時寫到這吧，總結太累，但是值得！
最后，附上Amazon貝索斯的原話：
翻譯如下：（沒有太直譯，不然有點拗口）
“以用戶為中心”有很多優點，但最大的一個就是：用戶是美麗的、棒棒的、不會滿意的，即使他們說我們的商業很贊，他們表示很開心很滿意。但他們其實想要更好的東西，不過他們自己并不知道。那么你的讓用戶愉悅的渴望，會驅使你代替他們去發明創造。
——杰夫*貝索斯，2016年給股東的信
額，還是拗口。簡單來說，就是：
筒子們，為了讓用戶高興，發揮你們做產品/交互的主觀能動性吧，自己研究創造去，做個好產品出來。不用指望用戶告訴你做什么/怎么做，他們也不知道。
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請掃碼ben_lanlan，報下信息，會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作，也請與我們聯系。
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
1、鼠標事件：
onclick 左鍵單擊 ondblclick 左鍵雙擊 onmouseover onmouseenter 鼠標移入 onmouseout onmouseleave鼠標移出 onmousedown 鼠標按下 onmousmove 鼠標移動（鼠標滑動） onmouseup 鼠標抬起 oncontextmenu 右鍵單擊(右鍵菜單)
2、鍵盤事件：
onkeydown onkeypress 鍵按下 onkeyup 鍵抬起 鍵盤事件必須放在整個文檔（document）里面去操作，不能放在節點里面去操作
3、系統事件：
onload 加載完成后 onerror 加載出錯后 onresize 窗口調整大小時 onscroll 滾動時
-
//onload 加載完成后 onerror 加載出錯后 onresize 窗口調整大小時 都是放在window的身上
-
window.onload = function(){};
-
-
//onscroll 滾動時 可以放在document和window身上
-
document.onscroll = function(){};
4、表單事件：
onfocus 獲取焦點后 onblur 失去焦點后 onchange 改變內容后 onreset 重置后 onselect 選擇后 onsubmit 提交后
5、監聽事件(綁定事件)寫法：
節點.事件 = 函數。
document.getElementById("main").onclick = function(){alert(1)};
document.getElementById("main").addEventListener("click",function(){},false);
行內綁定<button οnclick="alert('hello world')">Click</button>
<button οnclick="func()">Click</button>
<script type="text/javascript">
var func = () => {
alert('hello world')
};
</script>
6、事件函數this指向：在事件函數中，關鍵詞 this 就表示觸發事件的這個節點對象。
7、修改this指向：
call() 第一個參數為 函數this將要修改指向的對象 函數有參數時 后面, 一一跟上即可 可以主動執行函數
apply() 第一個參數為 函數this將要修改指向的對象 函數有參數時 數組包一下 可以主動執行函數
bind() 第一個參數為 函數this將要修改指向的對象 函數有參數時 后面, 一一跟上即可 不不不會主動執行函數 但會return函數本體 再加一個括號即可執行
-
window.a = 0 //在window對象下創建一個屬性，屬性值為0
-
-
let obj1 = {
-
a: 1
-
}
-
let obj2 = {
-
a: 2
-
}
-
-
function fn(num1, num2, num3) {
-
console.log(this.a);
-
console.log(num1, num2, num3);
-
}
-
-
//修改函數里面this的指向
-
fn.call(obj1,4,5,6)
-
fn.apply(obj2,[4,5,6])
-
fn.bind(obj1,4,5,6)()
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
轉自：csdn
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
vue.js 是采用數據劫持結合發布者-訂閱者模式的方式，通過 Object.de?neProperty()來劫持各個屬性的 setter，getter，在數據變動時發布消息給訂閱者，觸發相應的監聽回調。 具體步驟： 第一步：需要
observe 的數據對象進行遞歸遍歷，包括子屬性對象的屬性，都加上 setter 和 getter，這樣的 話，給這個對象的某個值賦值，就會觸發 setter，那么就能監聽到了數據變化。 第二步：compile 解析模板指令，將模板中的變量替換成數據，然后初始化渲染頁面視圖，并將每個指令對 應的節點綁定更新函數， 添加監聽數據的訂閱者，一旦數據有變動，收到通知，更新視圖。 第三步：Watcher 訂閱者是
Observer 和 Compile 之間通信的橋梁，主要做的事情是:
1、在自身實例化時往屬 性訂閱器(dep)里面添加自己
2、自身必須有一個 update()方法
3、待屬性變動 dep.notice()通知時，能調用自身的update()方法，并觸發 Compile 中綁定的回調，則功成身退。 第四步：MVVM 作為數據綁定的入口， 整合 Observer、Compile 和 Watcher 三者，通過 Observer 來監聽自己 的 model 數據變化，通過Compile 來解析編譯模板指令，最終利用 Watcher 搭起 Observer 和 Compile 之間的通信 橋梁，達到數據變化 -> 視圖更新；視圖交互變化(input)-> 數據 model 變更的雙向綁定效果。
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
轉自：csdn
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
Hello，你好呀，我是灰小猿，一個超會寫bug的程序猿！
最近在利用springboot+vue整合開發一個前后端分離的個人博客網站，所以這一篇總結一下在開發中遇到的一個問題，關于解決在使用vue和springboot在開發前后端分離的項目時，如何解決跨域問題。在這里分別分享兩種方法，分別在前端vue中解決和在后臺springboot中解決。
為什么會出現跨域問題？ 首先一個定義一定要了解，就是瀏覽器的同源策略，
什么是瀏覽器的同源策略， 簡單來說就是瀏覽器發送請求的協議、域名和端口要和服務器接收請求的協議、域名以及端口一致。這樣才能完成交互，但是很顯然這樣是不可能的，尤其在對于在同一臺電腦上開發前后端分離的項目的時候，一定是會使用兩個端口的。那么這樣就形成了跨域問題。
在這里分享一下我解決跨域問題用到的兩個方法，
先說一下我是怎么發現出現跨域問題的吧，最開始我在從前端瀏覽器向后臺發送請求的時候是沒有攜帶瀏覽器的cookie的，但是這樣就導致了無法對瀏覽器的請求進行驗證，所以在后來我用了一個方法讓瀏覽器在每次發送請求的時候在http請求頭中攜帶上cookie，方法如下：
在vue的main.js方法中寫入如下代碼：
//引入axios依賴 import axios from 'axios' //讓請求攜帶上瀏覽器的cookie axios.defaults.withCredentials=true Vue.prototype.$axios = axios
以上表示引入axios請求，也就是ajax請求，同時開啟寫入憑證，只有withCredentials等于true的時候，才會攜帶cookie。
在vue中解決跨域問題其實也比較簡單，因為我們每次瀏覽器發送的請求中，URL的前半部分一定是相同的，比如http://localhost:8080/blogs與http://localhost:8080/login，我們就可以將他們相同的URL提取出來，封裝到axios.defaults.baseURL中，這樣我們在每次請求的時候，就可以將請求地址簡寫成“/blogs”這樣，也相當于是將URL頭部進行了一個簡單的封裝。
注意：設置統一請求路徑的axios.defaults.baseURL =
"http://localhost:8080"應該寫在axios.js中
但是在解決跨域問題的時候，我們應該將axios.defaults.baseURL = "http://localhost:8080"寫成axios.defaults.baseURL = “/api”。
這樣我們每次請求的路徑前面都會是“/api”的形式。
這也是第一步：
在axios.js中設置axios.defaults.baseURL = "http://localhost:8080"寫成axios.defaults.baseURL = "/api"
在babel.config.js的同級目錄下新建一個js文件vue.config.js
在其中寫入如下代碼：這段代碼是解決跨域問題而配置的一個代理。我這里后臺服務器的請求連接是http://localhost:8081，所以如果你的不是的話需要修改一下。
/**
* 解決跨域問題
* @type {{devServer: {proxy: {"/api": {changeOrigin: boolean, pathRewrite: {"^/api": string}, target: string}}, host: string, open: boolean}}}
*/ module.exports = { devServer: { host: 'localhost', open: true, // 自動打開瀏覽器 // 代理配置表，在這里可以配置特定的請求代理到對應的API接口 // 例如將'localhost:8080/api/xxx'代理到'www.example.com/api/xxx' proxy: { '/api': { // 匹配所有以 '/api'開頭的請求路徑 target: 'http://localhost:8081', // 代理目標的基礎路徑 // secure: false, // 如果是https接口，需要配置這個參數 changeOrigin: true, // 支持跨域 pathRewrite: { // 重寫路徑: 去掉路徑中開頭的'/api' '^/api': '' } } } } }
如我們現在要發送login登錄請求，那么請求應該是這樣寫的：
this.$axios.post("/login")
在springboot框架的后端想要解決跨域問題，只需要添加一個類CorsConfig，并且讓它實現WebMvcConfigurer接口， 其中代碼如下，一般在開發的時候直接將代碼復制過去就可以了。
import org.springframework.context.annotation.Configuration; import org.springframework.web.servlet.config.annotation.CorsRegistry; import org.springframework.web.servlet.config.annotation.WebMvcConfigurer; /**
* 解決跨域問題
*/ @Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "HEAD", "POST", "PUT", "DELETE", "OPTIONS") .allowCredentials(true) .maxAge(3600) .allowedHeaders("*"); } }
以上我解決跨域的兩種方法，在網上也查找了很多解決跨域的方法，但是錯綜復雜，經過嘗試和自己研究，以上兩種方法是我親測成功的，當時前后端都配置了。
所以小伙伴們有不同的見解或者更好的方法，歡迎提出指正！
我是灰小猿，我們下期見！
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
轉自：csdn
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
藍藍設計的小編 http://www.syprn.cn