調查問卷，是一個低成本快速收集資料的定量分析工具。這是個看起來簡單，產出的問卷也看似很簡單，但是在整體設計的過程卻是需要很多的思考和預備。
關于調查問卷，會分成三個部分來解說，
廢話不說，直接開干！
1. 為什么做問卷
這個是問卷的目的，也直接影響后面問題的設計。
2. 如何使用問卷的研究結果
這是關于問卷解決方案的落地。不需要太過細致的落地計劃，但是至少要清楚，這份問卷的研究成果，可以獲得多少支持力度。不管問卷發現了多么偉大的問題，如果沒有落地，其實是沒有無意義。也切忌不要今年做的研究結果，明年來實施，那問卷的時效性和準確性就會大打折扣了，因為市場的瞬息萬變。
這是做所有事前，都要問的問題，「為什么做 Why」。而這個問題為什么重要呢，因為這會關系到設計問卷的核心內容是什么，會影響問卷的構成，當然最后也會產出不同的結果。
問卷的目的主要可以分為六個方面
1. 收集用戶信息
很多時候，我們或許知道理想目標用戶是誰，但是誰才是真正使用我們產品的用戶呢？了解真正使用的用戶，可以對用戶進行更針對性的分析和設計。
2. 了解用戶使用習慣
了解用戶在產品上是如何使用產品的，以及用戶的使用路徑是否按著我們期待的方式進行，這是很有必要，這也是一個驗證的過程。
2. 滿意度
了解用戶對產品的滿意程度，對于用戶不滿意的方面，可以進行歸納總結，并給出合理的解決方案
3. 建議反饋、吐槽、好評
從問卷中收集用戶的心聲，明白槽點是什么。同時也收集用戶的好評，這也是激勵團隊一個很好的方法，因為是直接來自用戶。
4. 體驗優化
對一個成功的產品來說，它要好用，它也要好看。產品有大改版前，可以用問卷來評估整體產品的體驗如何，以便在重新設計的方向上能更好聚焦。
5. 需求驗證
很多時候，需求可能沒那么明確，用戶和產品間始終存在著 gap， 所以我們有時對方案琢磨不定時，可能會試運行，后續看用戶反饋。通過合理設計問卷，我們也可以稍微窺探到用戶的想法
但是對需求的驗證，單通過問卷還是比較難的，只能窺探到比較淺的一層，最好后續可以對用戶進行訪談來做后續跟蹤，以便了解事情的全面。
這里要注意的是，問卷不適合探索用戶的新的需求，或者要驗證很精準的信息等比較復雜性的問題。
如果你問用戶，近期會推出新功能，問他會不會用。大致上，你得到的回答都是肯定。很多時候，同意比拒絕更簡單。
根據提問的方式，可以分為 「是什么」「怎么樣」「怎么辦」
1. 是什么
主要是用戶信息、使用習慣等問題。
例如，年齡層、職業、使用產品目的、知道產品的渠道、使用頻率、使用競品軟件、整體滿意度等
2. 怎么樣
主要是詢問用戶原因，比如打這個分數的原因，某功能使用如何等
3. 怎么辦
主要是詢問用戶的建議、期待產品改進的地方
問卷中并不是所有問題都適合問，有一些比較敏感的問題需要去避免，以免激起用戶的負面情緒
1. 敏感性問題
個人信息類的問題比較容易會有敏感信息存在，就像你問用戶工資區間，和在問卷最后告知用戶參與問卷都有獎品，需要填寫收貨地址。很明顯收貨地址的準確性會比工資更高。
2. 措辭嚴謹
3. 問卷的順序
先簡單后復雜，并注意整體邏輯性的表達。循序漸進，如果一開頭就是很難的問題，用戶很容易放棄答題
4. 問題長度
盡量保持所有問題在一個差不多的長度呢，保持一樣的節奏。避免時長時短
5. 避免專業詞匯
很多時候，我們會用一些所謂的“行話”來表達，但是在問卷當中，無法保證用戶同樣是理解的，而且也會讓用戶產生距離感，非必要情況下，不要使用專業詞匯
6. 選擇題枚舉要窮盡
題目數最好不多于 7 個，太多也會造成用戶選擇困難，最后記得加個其他并提供文本框輸入
7. 避免互斥、重復、相似
問題避免前后矛盾，造成用戶困擾，也不要重復或相似度極高的問題，除非這個問題是陷阱題，為了檢驗用戶是否認真答題。但是在數量有限的問題中，一般比較少使用陷阱題
8. 保持開放性
為所有選擇的選項，加入「其他——」「以上都不是」「不知道」，用戶可能會覺得問題或答案不匹配，而不知道選什么，這時需要給用戶一個出口，避免產生無效數據
9. 避免詢問引導性的問題
大部分用戶認為 XX 功能，很好用，你覺得呢？
如果看到這樣問題，大概可以從中讀出兩個信息，1. 大家都覺得好用 2. 平臺希望我說好用。
這個問題所傳達出來的隱藏含義會引導用戶做出不真實的反饋，這是沒有意義的問題
10. 避免讓用戶選擇「 是/否」「真/假」「好/壞」
強制選擇非黑即白，大部分情況下沒什么意思，因為用戶可能不確定。這個問題本身也沒有太大價值，也會錯過用戶一些比較有趣的回答。
所以如果這個問題的目的，是一定要知道的，可以更改提問的方式。
對于用戶的問題，答案要可以量化表達，來產生數據，才便于后續數據的分析
11. 避免問用戶將來的事，或回憶許久前的事
當人們將自己的行為投射到未來時，通常會過于簡單化和理想化，人們更擅于解釋當下進行的內容。
所以，如果要知道特定環境下用戶的操作，則要配合合適的場景預設，并且是用戶熟悉的場景?；蛘呖梢灾苯訂?，今天你會如何如何
所以可以通過詢問今天的行為來，確定將來會不會使用。當然這不是絕對的，畢竟未來存在太多變數。
對于許久前的用戶的操作行為，也盡量不詢問，因為會忘記，而當強迫他去思考時，他可能自己腦補，產生不準確的記憶，進而對研究結果產生偏差。
12. 其他
問卷中存在多選題，必選題，選填題，記得預覽問卷時，注意問題平臺有無自動添加文字說明。
不要用 checkbox, radio 來區別多選和單選，這是不能準確的傳達，也有可能用戶沒有注意到，或者就不清楚，而使用文字的表述會更清晰，不會產生歧義。
必選題，選填題，如果問卷平臺，也只是用*號來表達必選時，建議在文字上也加上這樣的說明
整體問卷的過程需要時間，所以也需要的具體的日程安排，以便整體問卷的進行是井然有序。
日程安排中，要包括：
調查問卷從準備到產出報告，需要一個過程，建議與其他設計師或 PD 來一起配搭工作，更高效的完成，一個人去做，總是會有一些盲點，并且會比較大的壓力。
如果你在問卷方面是新手，也建議找個有經驗的設計師或 PD 來做你顧問，減少一些不必要的坑。
文章來源：優設網 作者：箴鹽設計
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
JS學習筆記
js和java的異同點
變量聲明
函數聲明
js中的變量提升和函數提升
為什么有變量提升
總結
js和java的異同點
首先，js的語法和kottlin的語法有些相似。比如var，方法聲明用
function 方法名稱 (參數名稱...){
//方法內部邏輯
}
還有變量類型聲明 :
數據類型 : 變量名=值
區別：一：js的數據類型和java類似。只不過js中的數據類型number將java中的int，double，float整合了。
二：js中可以不用聲明變量類型。變量不聲明數據類型的話，那么他的類型取決于當前的值是什么數據類型。舉例：
var num=0;
num-"lyyyyyyyyyyyyyy";
num=[];
num={};
三：js中的類型判斷：
判斷基本類型，返回一個字符串
1
console.log(typeof '');//string
console.log(typeof []);//object
console.log(typeof {});//object
console.log(typeof 1);//number
console.log(typeof null);//object
console.log(typeof undefined);//undefined
console.log(typeof true);//boolean
console.log(typeof function(){});//function
console.log(typeof /\d/);//object
檢查某個對象屬于哪個構造函數，返回true/false
1
function A(){};
function B(){};
let a = new A();
console.log(a instanceof A);
console.log(a instanceof B);
console.log([] instanceof Array);//true
console.log({} instanceof Object);//true
console.log(/\d/ instanceof RegExp);//true
console.log(function(){} instanceof Object);//true
console.log(function(){} instanceof Function);//true
變量聲明
js的變量聲明其實大體上可以分為三種：var聲明、let與const聲明和函數聲明。
函數聲明
doSomething();
function doSomething() {
console.log('doSomething');
}
var foodoSomething= 2;
你覺得上面會輸出什么？TypeError嗎？其實輸出的結果是foo。這就引出了我們的問題了，當函數聲明與其他聲明一起出現的時候，是以誰為準呢？答案就是，函數聲明高于一切，畢竟函數是js的第一公民。
那么，下面的例子呢？
doSomething();
function doSomething() {
console.log('1');
}
function doSomething() {
console.log('2');
}
當出現多個函數聲明，那怎么辦呢？以上代碼輸出結果為2。
因為有多個函數聲明的時候，是由最后面的函數聲明來替代前面的。
domeSomething();
var domeSomething= function() {
console.log('domeSomething');
}
var domeSomething = function() {}這種格式我們叫做函數表達式。
它其實也是分為兩部分，一部分是var foo,而一部分是foo = function() {}，參照例2，我們可以知道，這道題的結果應該是報了TypeError(因為foo聲明但未賦值，因此foo是undefined)。
js中的變量提升和函數提升
在js中對變量進行操作后打印值經常會出現undefined的現象。其實原因是因為js中有一個叫做變量提升的功能。舉例：
1
var data="lyyyyy";
getData();
function getData(){
//第一次打印
console.log("data值為: ", data);
var data="yyyyyyy";
//第二次打印
console.log("data值為: ", data);
}
打印的值第一個為undefined，而第二個打印的值為yyyyy.
原因：
在執行getData()方法的時候會在函數內部首先將變量的聲明提升到第一步。
然后再聲明函數內部的函數（如果函數內部有函數的話）。
之后才會按照方法內部的邏輯先后順序執行代碼。前兩步只是聲明?。。?br />
看到這里應該就已經知道為什么會有上面那樣的結果了。
實際的方法內部代碼執行順序應該是這樣的：
function getData(){
//一。聲明變量
var data;
//二。聲明函數（如果函數內部有函數的話）
//三。按照代碼的順序執行
console.log("data值為: ", data);
data="yyyyyyy";
//第二次打印
console.log("data值為: ", data);
}
看到拆分后的代碼執行順序對結果也就不迷茫了。
為什么有變量提升
那么為什么會出現變量提升這個現象呢?
其實js和其他語言一樣，都要經歷編譯和執行階段。而js在編譯階段的時候，會搜集所有的變量聲明并且提前聲明變量，而其他的語句都不會改變他們的順序，因此，在編譯階段的時候，第一步就已經執行了，而第二步則是在執行階段執行到該語句的時候才執行。
總結
1.js會將變量的聲明提升到js頂部執行，因此對于這種語句:var a = 2;其實上js會將其分為var a;和a = 2;兩部分，并且將var a這一步提升到頂部執行。
2.變量提升的本質其實是由于js引擎在編譯的時候，就將所有的變量聲明了，因此在執行的時候，所有的變量都已經完成聲明。
3.當有多個同名變量聲明的時候，函數聲明會覆蓋其他的聲明。如果有多個函數聲明，則是由最后的一個函數聲明覆蓋之前所有的聲明。
————————————————
版權聲明：本文為CSDN博主qq_45272690的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
5分鐘帶你了解服務設計的原則、案例及常用方法！
我們常說，現在是體驗至上的時代，用戶對產品的使用不再是單純的需求滿足，更要獲得滿意的體驗。服務設計的發展為我們改善用戶的體驗提供了新的思路，從本質出發，任何產品都是在提供某種服務，服務的質量從根本上決定了用戶的體驗。
什么是服務設計
服務設計一直在我們的生活中，我們無時無刻不在體驗著各式各樣的服務。荷蘭一家專業的服務設計機構31 Volts是這樣描述服務設計的：“如果有兩家緊挨著的咖啡店，出售同樣價格的咖啡時，服務設計是讓你走進其中一家而不是另一家的原因。”這個描述很生動，同時也說明了服務設計的作用。
其實服務設計的定義還有很多，行業內不同的專家和學者都有自己的理解和解讀，不管定義如何，重要的是服務設計的思維方式，可以幫助我們從全局改善服務體驗。
服務設計的原則及案例說明
2010年在《This is Service Design Thinking》一書中，作者首次提出了5個服務設計基本原則，這些原則之后也被廣泛使用，但隨著服務設計的不斷發展，其中的一些原則也需要重新去審視和思考，因此在2017年作者將其更新修訂為6項。
a.以人為中心(Human-centered)
以人為中心的設計理念在產品設計、交互設計等領域已經得到了廣泛的應用，服務設計當然也沒有例外，以人為中心就是要站在用戶的角度上看待和思考問題，考慮所有被服務影響的人。
在日本，農產品市場存在這樣一個問題，農產品批發商無法及時從種植者處了解農產品的相關狀況、收獲量等信息，因此他們也就無法與要購買農產品的人進行談判，這樣造成的結果可能是糧食的浪費。日本的一家軟件公司NJC（Nippon Jimuki Co. Ltd.）發現了這一問題，他們希望利用自身能力（軟件方面的優勢）去解決這一問題，因此將目標設定為：創建一個可以提供有用數據而又不給農民或農產品批發商帶來負擔的系統。
最終的產出的結果是Fudoloop這個應用程序，通過Fudoloop，批發商可以提前一天從農民那里收到信息，進而協調買家的各種要求。Fudoloop的使用者分為兩種，一種是需要更新農產品信息的農民，一種是從Fudoloop上獲取農產品信息的批發商，Fudoloop分別為兩種用戶進行了設計。
圖片來源：Fudoloop
在設計Fudoloop時存在這樣一個問題，農產品市場中的相關從業人員普遍年齡較大、受教育程度低、軟件使用經驗很少，面對這樣的用戶，顯然通常的軟件設計并不符合他們的需求，因此Fudoloop的界面設計非常簡單且信息突出，從事農產品相關工作的人員可以輕松的使用Fudoloop完成農產品信息的更新，而不會因為學習產生很大的壓力。Fudoloop還在大型農業貿易展覽會邀請了一些行業內的人員和用戶參與到了產品的體驗中，并收集了他們反饋的建議，以改善產品。
圖片來源：IDEO
NJC在設計Fudoloop時充分堅持了以人為中心的原則，考慮到服務涉及的不同用戶，并根據用戶本身的特點和需求進行設計。NJC的CMO佐藤賢一是這樣評價Fudoloop的：“當簡單、以人為本的思想匯聚在一起時，創新就會發生”。
b.協作(Collaborative)
這條原則說的是，不同背景和職能的利益相關者應該參與到服務設計流程中，收集多方訴求，發現不同看待問題的角度，才會更好的解決問題。
在美國舊金山，有一所學校和Revolution Foods這家餐飲公司合作，為學校內的人員提供豐富的、營養的午餐，但是實際來餐廳就餐的人數與預期相差很大，數據顯示，有72%可以承擔起午餐費用的人并沒有來到食堂吃午餐。經過調查發現其中的原因，很多學生等校內人員并不愿意排長隊或者匆忙的吃完午餐，因此他們選擇了去校外享受午餐的時間。
為了改善這種情況，這所學校請來了全球頂尖的設計咨詢公司IDEO，他們與1300多名學生、父母、營養人員、董事會專員、校長、老師和社區團體等利益相關者一起工作，重新去設計了學校的午餐，并且制定了針對三種年齡的就餐體驗的建議，完成了飲食、就餐空間、新技術使用等多方面的優化和設計。
圖片來源：IDEO
最終，學校完美的改善了午餐服務的體驗，這其中包含了所有利益相關者的想法和工作，因此設計成果也被人們所接受，越來越多的校內人員會選擇學校的午餐，之后，這種設計模式也被舊金山的許多學校采納和推出。
所以，服務中涉及到的利益相關者有很多，多收集他們的想法與建議，甚至讓他們參與到服務設計中去，問題會得到更好的解決。
c.迭代(Iterative)
迭代是一個不斷接受反饋不斷優化的過程，如此重復執行，讓產品變得越來越好。服務設計也需要迭代，不要避免犯錯誤，而是從錯誤中學習和改變，同時也要不斷的收集各方的反饋信息，這些信息是服務進行迭代的核心所在。隨著互聯網的發展，迭代的思維早已滲透到每一個互聯網產品，此處就不再過多解釋。
d.有序(Sequential)
服務設計應該是一系列相互關聯的活動，并且是按照順序進行的，精準的把控服務每一個環節的節奏，用戶才能獲得更愉悅的體驗。
以外賣為例，用戶的使用過程包含訂外賣時的商家選擇到下單過程，下單后配送外賣，用戶收到外賣和用餐后這幾個過程，而服務的提供者主要包括商家、平臺和外賣小哥，為了保證用戶能夠獲得流暢的服務體驗，需要各個服務提供者在服務展開的不同環節推出優質的服務，如下圖。
在訂外賣時，平臺會為用戶推出“超值優惠”“限時秒殺”等優惠活動，商家推薦、訂單歷史等商家選擇渠道，以及不同的篩選條件，以上的目的都在于幫助用戶快速找到自己期望的、合適的商家。在用戶選定商家后，進入到選擇商品并下單的過程，一方面，商家會推出優惠的活動、推薦菜品等，另一方面，平臺也會給出自己的優惠。
下單后，用戶面臨的是一個配送過程中的等待時間，為了緩解用戶在等待過程中的焦慮情緒，平臺會及時更新和推送外賣小哥的狀態，如到達商家、取餐中、與用戶的距離等，同時會給出用戶預期的送達時間，若超過預期時間用戶還可進行催單，商家可以聯系用戶表達歉意，整個過程用戶對配送狀態是可視的。
用戶收到外賣時首先會與外賣小哥接觸，包括與外賣小哥提前確定取餐的時間地點，取外賣時的短暫對話等，這些都會影響用戶對服務的印象，因此外賣小哥需要保證服務態度的禮貌和友好。收到外賣后，食品包裝首先給到了用戶對商家的第一印象，然后是餐品是否符合用戶預期，讓用戶滿意。
在用戶就餐后，首先平臺要提供給用戶評價的功能，用戶可以分享自己就餐的感受，商家也可以通過平臺為用戶提供更多的優惠，引導用戶能夠再次回到商家訂餐。
從外賣的案例中我們可以看到，服務是一個過程，是需要有序展開的，每一個環節的體驗都會影響到用戶對服務的印象，在恰當的環節提供恰當的優質服務，才能確保用戶的整體體驗。
e.真實(Real)
服務本質上是無形的，應該用“物理元素”來可視化，這樣可以用戶的服務記憶，增強用戶對他們所接受服務的感知。
同樣以上述外賣為例，商家為用戶提供餐食，這部分是借助美團這個平臺和外賣小哥來完成的，用戶和商家的接觸僅僅是送達的餐食，因此無法通過像到店體驗一樣，讓用戶感知到商家提供的更多服務。
為了讓服務變得更加“有形化”，商家就需要花費更多的心思，如圖，商家為了增強用戶對服務的感知，一般會在在包裝上花費很多功夫，精致的包裝讓商家的形象更好且更加值得信任，一些有趣的包裝還可能讓用戶的心情變得愉悅。另外，商家也可以通過一張便利貼的溫馨問候或者贈送小禮品等方式讓用戶更真實的感受到服務，通過這樣的手段，即使用戶并沒有真的接觸到商家，體驗也會變得很好，商家的形象也會提升很多。
圖片來源：古田路9號
f.整體(Holistic)
整體就是要著眼于整個用戶旅程，考慮用戶與服務的每個觸點（觸點的概念后文會進行介紹），并兼顧多方利益相關者的需求。也就是所謂的全方位服務體驗，考慮服務環境的方方面面，沒有任何遺漏。這個原則實施起來并不是那么簡單，從整體角度思考問題會使問題變得復雜。不過在服務設計中，是有一些方法和工具是可以幫助我們完成整體思考的，比如服務藍圖。
服務設計的常用方法-服務藍圖
a.服務藍圖簡介
服務藍圖是一張圖表，通過列出在每個階段發生的、不同角色執行的所有活動，顯示了服務的整個過程。如圖所示是一個服務藍圖的簡單示例，垂直方向上展示服務中的利益相關者，水平方向上為用戶的歷程，也就是用戶經歷的不同階段。在服務藍圖中有兩條線，一條是可見線（line of visibility），可見線上方為用戶可與之交互的服務，也可以稱之為“前臺”，可見線下方代表的是后臺進程，用戶無法看到但需要給用戶提供支持，后臺進程還可以存在內部交互線，用來表示內部人員的聯系。用戶與前臺服務之間存在另外一條交互線（line of interaction），用來表示用戶與服務之間的接觸。
圖片來源：Service Design Tools
明確了服務藍圖的大致框架之后，還需要注意服務藍圖中一個非常重要的概念——觸點。觸點就是在服務的各階段，用戶和產品、服務、后臺產生的接觸，每個觸點也是服務可以進行展開和優化的方向。
b.Uber服務藍圖繪制
為了明確服務藍圖的繪制和分析過程，下面將結合下圖所示的Uber服務藍圖進行說明。
圖片來源：Medium
(1) 明確用戶歷程
用戶使用Uber打車服務主要可以簡單分為以下三個階段：注冊（下載APP - 新用戶注冊），乘車階段（下單 - 等待車輛到達 - 乘車 - 到達目的地）、乘車后（付款 - 評價）。
(2) 明確利益相關者
用戶與之產生互動的前臺服務人員為司機，而設計師、開發人員、項目經理等負責后臺的服務支持，以保證Uber按照預期的目標運作。
(3) 明確前后臺活動
一方面，需要明確和用戶接觸的前臺活動有哪些，Uber打車服務中和用戶產生接觸的主要為司機及車輛，因此需要確保司機是合格的、車輛內部的環境是干凈舒適的，同時司機在與用戶接觸的過程中需要提供禮貌的問候和交流，滿足用戶在乘車過程中的要求，完成乘車費用的收取，提醒用戶離開前帶好隨身物品，以及評價乘客等。
另一方面，用戶對后臺的流程可能并不了解，但需要明確哪些后臺活動和支持會對用戶產生影響。比如在用戶下單時能夠自動獲取用戶定位，告知用戶預期的時間和價格，以及發送給用戶司機的狀態等。
在明確前后臺活動時，我們可以以用戶歷程為線，分步驟進行分析，確保每個環節中涉及到的前后臺活動沒有被遺漏。
(4)明確關鍵觸點
在服務藍圖中我們可以標注用戶與服務的主要接觸點，針對觸點進行設計是提升服務體驗的一個重要和有效的手段。
在Uber打車服務中還有一些需要注意的觸點，一是等待時間，這包括用戶發起乘車請求后、付款時以及評價司機時，等待時間是造成用戶體驗較差的一個原因，因此需要注意標注出這些觸點，并想辦法優化，在服務設計中需要注意相關環節的應盡量簡單，減少用戶的等待。另外需要注意的是會對體驗影響較大的觸點，如司機態度不友好、乘客下車時忘記帶隨身物品等，可能造成失敗的服務體驗的觸點應該精心地去設計，避免這樣的情況發生。
通過以上過程我們完成了Uber服務藍圖的繪制，從中可以獲取到Uber打車服務的整體概貌及其相互關系。
///
結語
服務設計的思維能夠幫助我們從全局的角度去審視和思考，發現更多改善服務的可能性，從而為用戶提供更好的體驗。因此對于產品和設計等相關人員來說，不能僅僅把目光放在產品本身，而是要從服務的角度去正確看待產品和用戶的關系，以用戶為中心，找到用戶與產品的每一個接觸點來進行服務設計，這樣才能保證用戶在整個流程中都能得到好的體驗。
文章來源：站酷 作者：百度MEUX
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
用戶體驗設計就像是一場直面自我的修行，無論是從認知提升、工作能力等維度，都在時間和實踐中不斷去促進自我對事物的探索，在過程中不斷獲取對世界的感知和成就感。在學校里所接觸的關于交互設計的認知，大部分局限于產品領域與基礎交互，而后逐漸過渡到交互體驗與設計的結合并且作用于商業，成長過程中也會不斷思考，這次想聊聊設計價值，大概分為三點：價值思維、價值判斷、價值體現。
我的設計能夠給用戶/產品產生什么價值？如何體現設計的價值？可能很多朋友也會和我一樣有這樣的疑惑，假如能夠在接觸需求后便思考該需求背后的價值，那對應的行動也會有很大差異性。
可能對于大部分的設計師而言，作為主要的執行力，需要肩負起項目的責任，所以會把大部分時間都投身在項目需求和日常溝通來提升自身能力，很少有剩余時間去沉淀已做完的設計，只有在產品體驗會或者其他渠道的反饋中獲取最后的問題，久而久之就像是打補丁，既無法體現設計價值，自身能力也無法得到完整的提高。然而促使設計師進步的往往不是技能的熟練，而是對業務需求思考的廣度和深度。因此需要樹立起價值的概念，價值可以驅使行動產生改變。
價值觀因人而異，而價值觀會影響一個人的行為引導其做出選擇，對價值的思考取決于思維上升空間有多大。因此需要有一個思維模型能夠幫助我們更好的建立起價值思維，可以幫到我們更加有邏輯的思考。相信許多朋友都聽過「Why-How-What」即黃金圈法則，個人認為可以從日常需求中幫助設計師建立起一套價值思維。黃金圈解析：
△ 圖片來自網上
了解黃金法則后，我們看看如何把黃金圈的思維模型運用到工作中。
假設我們接到一個「商城系統」的設計需求，可以嘗試這樣拆分：
WHY：我為什么做
關注點：站在產品角度，對產品真正的幫助和提升
HOW：我要怎么做：
關注點：需求做的更好，超出玩家預期
WHAT：需要做什么
關注點：讓玩家使用更加高效，滿足多種場景
綜上所述，設計師處于不同的階段，所關注的價值層面對應的行動也會不同，不僅要求設計師在需求之外還需要全局思維的思考延伸，了解當前產品階段最需要的是什么，更多需要設計師自我審視，建立價值思維的思考模型，不僅僅停留在行動層的思考。
（我為什么要做）價值觀——（我要怎么做）能力——（我要做什么）行動
「黃金圈」法則可以幫助我們建立起價值思維，然而每個設計師有各自的價值衡量，以下是我認為的一些價值維度：
1. 層次與目標
日常我們總會接受到大大小小的需求，簡單和復雜會摻雜混合，從工作角度而言需求是都要做的，但是從設計價值的角度而言，需求是有輕重緩急之分。那如何進行價值判斷呢，一般的設計需求從目標上可分為三個層次：
2. 二八法則分配
當有了一個基礎劃分后，就可以對需求進行合理評估，考慮到現實情況下通常會面臨這些情況：
時間緊迫：日常需要大量的時間進行協作溝通和跟進
精力有限：任務重加班多，無法長時間保持高效的工作狀態
所以可嘗試根據二八法則對時間精力進行分配，對于一些價值較低的需求，可以和需求方充分溝通，過濾無效信息后快速處理；對于價值較高的需求，投入大量時間與精力設計與打磨。對于初中級的設計師來說，滿足「可用性」和「易用性」是仍需要多加錘煉的基礎能力，對于高級以上的設計師來說，有了一定的經驗下達成前兩者較為容易，可以把更多的時間精力投入在「愉悅感」的設計上。
前面講了價值與判斷，但設計無論是賦能或者是驅動，還是需要明確最終目標是什么，我的理解是最終服務于產品解決問題。那如何體現設計價值就顯得尤為重要，以下簡單拋出兩點：
1. 提升體驗和口碑
雖然不能直接為產品帶來實際收益，但是帶來體驗提升，而口碑的增長相當于為長線運營打下基礎，也為后續進入的產品矩陣留下增長空間，例如最近大火的《天地劫》，相信后續的出品也會讓玩家更加期待。
像這類的例子有許多，例如《王者榮耀》的公眾號還有專門的 UI 迭代日記，即便是運營多年的產品仍然在不斷的打磨和提升體驗，為產品帶來正面影響。
△ 圖片來自王者榮耀公眾號
2. 帶來商業利潤，促進社交、消費增長
這類體現通常是商業化/社交相關，《陰陽師》眾所周知的抽卡系統和「畫符咒」的交互方式也帶來了大量的社交互動和用戶增長，還有《Pokémon GO》捕捉寶可夢和「投擲精靈球」，促進了玩家大量的線下的互動場景，我認為這些都是設計價值的體現。
這些設計相對于大部分玩家是一種「隱形」的存在，不像角色、場景設計等容易被感知，對于設計的價值體現一定不只是給產品錦上添花，是能夠通過對用戶/玩家群體的理解去塑造和滿足需求。
文章來源：優設 作者：阿澤與設計
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
先看目錄！
1.什么是流量分發
2.為什么要做流量分發
3.首頁中流量分發的類型
4.流量轉化模型
5.流量如何分配的
6.設計案例與流量分發
7.如何衡量流量的效果
相信大家對流量并不陌生，我們在運營的口中經常會聽到這個詞：流量。運營通過各種手段和策略吸引用戶來接觸、使用我們的產品，從而吸引到了許多的流量，流量越多機會也就越多，比如一家奶茶店門店選址要考慮的最關鍵因素就是人流量。
流量分發的本質其實就是用戶需求分發，我們設計師的價值就在于如何讓這些流量發揮出更大的價值，讓流量價值和用戶價值相匹配。流量就像是一片海，海水通過不同的分支流入大陸形成了江、河，如果沒有這些分支，那么這些水永遠無法被利用，發揮出它們的價值。流量分發我們最常見的方式有：搜索分發、算法分發、社交分發、人工分發、付費分發
舉一個比較典型的例子：海底撈在進行流量轉化之前，并不是單純的在店門口給用戶一排座位讓用戶去等待，因為這部分用戶就像沒有被分流的海水是死的，這時候的用戶其實也有自己的目標，就是消磨時間，那么海底撈就提供了一系列服務讓這部分用戶活動起來，比如給零食、玩具、做指甲等等，于是這部分用戶其實就相當于進入了就餐流程的分支，提前享受服務和餐廳提供的福利，除了提升用戶體驗以外，也消化了大部分的流量。試想一下如果一下來了許多客戶，但你只有十幾張椅子讓用戶等待，勢必造成更多的損失。
流量是無序混亂的，只有到它應該去的地方，它才會有價值。產品與用戶雙方都需要有清晰的目標，產品提供解決方案和導流不同的場景，用戶負責完成目標給業務帶來價值。
流量分發最典型的就是電商產品，因為業務目標非常明確，就是實現gmv的提升，但同時其用戶的需求場景也是相對來說很復雜的。那么一個好的流量分發策略，可以大大的減少用戶完成目標的時間和精力，也讓產品可以準確的掌握用戶的需求流向。
流量不分發或者錯誤分發就會造成更多的消耗，什么意思呢？我們舉個例子，譬如下方的?？觓pp首頁，首頁中雖然提供了搜索、分類和標簽欄不同模塊，但是核心的內容顯示區域則只有一張預售產品的大圖。我們知道用戶類型非常多，這樣的布局對于小白和第一次用此款產品的小白來說會十分迷茫，因為最顯眼的內容中并沒有他們想要獲取的信息。我們不求滿足所有用戶，但至少需要覆蓋大部分用戶和核心用戶，此外，這樣的形式就像一個漏斗，只靠一個出口漏水，效率自然不高。
同時為了達到最大化，流量的分發并不是單向的，而是并行、串聯的。比如你可以在通過搜索找到某件商品，參與活動、運營板塊、商品分類、網紅直播等等區域都可以發現這個商品，同理，你想要購買視頻app的會員，不僅僅可以去個人中心，你還可以去詳情。所以流量就像一個大網格，單純的給漏斗戳幾個洞還不夠，甚至要把這些洞用很多根管子串起來。
流量分發可以幫助盤活新業務以及尋找新的價值，例如我們之前的電商產品在前期是以時間軸為核心的消化方式，商品以單品列表平鋪的形式展示，在產品發展過程中形態會發生變化，單純以這樣的形態承載用戶需求肯定是不夠的，所以更多運營板塊和推薦可以分擔這部分“舊”流量。
我們在移動端的首頁可以常看見的類型有：搜索、宮格型板塊、信息流、banner、fab等。
搜索給有明確需求的用戶提供了入口，同時在搜索這個顯性場景中我們也可以細化出更多的場景給流量提供更有效的支持
例如搜索場景下除了熱門搜索、搜素歷史以外還可以提供不同的分類內容推薦。
逐漸走下神壇的banner，曾經可是在UI界叱咤風云，在當時由于他是首頁占比一哥，很多產品在首頁規劃中都認為banner會承載大部分的流量，尤其是像淘寶等電商產品，banner不僅僅可以靠圖片吸引用戶，在做一些大促活動時候還可以變成氛圍擔當，和導航欄上下呼應。我們說首頁是寸土寸金的，但是大家發現沒有，banner的流量和他本身的價值可能不相匹配。也就是說雖然他面積很大，但是用戶點擊率相比于其他板塊并沒有什么優勢，甚至還低。所以淘寶目前的首頁已經看不到banner了，這個區域可以放下更多的運營區塊和流量入口，當需要它的時候再配置起來就可以了。
這個板塊除了業務分類的“金剛區”以外還有運營活動的配置區域，我們先來說以業務劃來劃分的流量入口，以這樣的形式來分配流量是常規的手段，當然他也是有利弊的，有利的地方在于幾乎每個業務板塊雨露均沾，至少是在同一屏幕中呈現，還可以左右滑動切換更多。弊端的話就是層級深，并且用戶瀏覽效率低不聚焦，對于那些泛瀏覽型的用戶并不友好，因為你進入一個業務板塊后發現內容自己 不感興趣需要就需要再返回。所以這樣的分流更適合深度使用產品的用戶
那有沒有另外一種形式可以分配流量給不同業務板塊呢？當然是有的，比如tab標簽，有了tab標簽，泛瀏覽的型的用戶會更喜歡，他們能更快的找到自己喜歡的內容，比如bilibili、騰訊視頻的首頁，這個當然也和產品目標有關，他們希望讓用戶看到更多的內容，讓產品更扁平化。
那么你即想扁平又想讓用戶直觀的看到業務板塊分類怎么辦呢，你可以這么做，就像大眾點評一樣上邊是宮格，下面是tab標簽
Fab和cta可以說是比較另類的存在了，幾乎就是你想讓用戶去點，那你就放，所以這樣的入口流量路徑就比較單一，無法沉淀和升級流量，是短期目標的形態。fab的這樣的懸浮入口會一直在首頁顯示，通常產品為了吸引用戶會將其設計的比較吸引人，比如添加動效等，但是fab也會干擾用戶正常瀏覽界面，所以一般可以用透明、伸縮的方式解決，不過伸縮要考慮用戶實際操作，避免頻繁的伸縮造成的更多干擾。
大部分產品對于泛瀏覽用戶的匹配場景都是提供信息流，但是單純的給信息流依然無法讓用戶深入沉淀，所以需要在信息流中穿插一些分流入口，譬如品牌、話題、活動、排行等，讓用戶有更深入的瀏覽，這樣才能促成轉化。
流量獲取很容易，但是我們的目標并不是讓用戶進來逛一圈就走，所以流量的轉化我把他以這樣的模型展示，也就是說流量從獲取到沉淀再到最后的進化過程。
獲取新流量的方式很多，例如社交分發、線下活動引流等等，內部流量也可以通過打通多個板塊進行流量互換。但是這些流量是表面的，不做進一步整合也就沒有實際價值，所以我們需要將其沉淀下來。
流量就像過江之鯽，如果你想讓這條江里有更多魚，你首先需要有個兜來留住這些用戶，為了不讓這些魚繼續游走，你可以給更多豐富的食物、創造更好的環境。如何讓魚更好的在這里生存呢，要讓他們熟悉你的一切，要讓這些魚在其中發展、繁衍，所以當我們用內容吸引住用戶后，要讓用戶留下來成為深度用戶，這個前提就是讓用戶更長時間的使用產品，如何提升產品使用時長呢？譬如通過智能算法在很多斷流的板塊提供偏好推薦、幫助用戶預判場景、社交互動、讓用戶有成就感、積分體系、個人成長系統、個人品牌塑造等。
之前兩步依然是在存量市場里盤流量，這是對的，從十四五國家發展規劃來看，我們能看到一個關鍵的變化，就是從“速度”到“質量”的變化，如果你的流量已經完成沉淀，那么可以不著急找增量，而是找進化的方法。當然以下是我個人的一些思考，僅供參考。從淺層到深入，從深入到高效，從高效到創造，所以當你的流量已經比較成熟的時候，可能更多需要讓這些用戶再創造新的內容，他們可以利用你提供的產品創造自己的玩法，即便你不提供任何的幫助也可以形成生態，甚至還可以幫你引入增量市場。
譬如玩社群的都知道，引流簡單，但是要維持社群的熱度和培養超級粉絲是很難的，但是一旦你做到了，那么這些人就是幫你創造更多的價值，所以你需要一個龐大且智能的基建，還有更好的服務。
判斷流量分配是否合理的標準不在于多和廣，而在于核心價值與目標是否達成。譬如內容型電商（抖音、快手）和傳統型電商（淘寶、京東），內容型電商的流量是依靠內容帶動電商去轉化，更多的是依靠內容的質量，而傳統型電商依靠的是商品，那么在這兩個產品中，前者的流量更多還是要流向內容而非商品。
再舉個例子，在首頁的板塊中，我們默認流量從大到小是板塊越靠上的越多，越靠下的越少是嗎？也不是，板塊的分配是需要結合用戶需求的，比如你規劃的板塊視覺上很明顯但是從數據上看流量很低，那么這個板塊就是有問題的，或者板塊不明顯但流量很高，這些都不是正常表現。
所以流量分發之前就要確定好，分發的目的和希望達成的目標。是能夠讓新用戶更快了解產品，還是讓成熟用戶在使用時更高效，或者大力宣傳新業務等等，不是一股腦兒隨大流的把蛋糕切成幾塊。
不知道有沒有在做抖音的小伙伴，抖音的流量分發讓很多人搞不明白，其實抖音屬于一個強運營平臺，當用戶制作一個視頻發布后，他的流量并不是全部來自于已經關注你的粉絲，一部分是通過判斷你的視頻內容和質量分發給相應標簽、可能會喜歡的用戶。但是快手和抖音不同，快手的社交分發策略更重，用戶發布的視頻，已經關注的粉絲分發到的比例會更高，這樣用戶的互動也會更強。
通過一些設計案例我們來看看設計在流量分發中起到的作用。
流量與曝光是有關系的，為了爭取更多的曝光我們可以采用這樣的方式進行設計，通常我們可以看到橫向滾動結束后進入下一級界面需要點擊更多，但點擊的成本就高于滑動，所以在這里可以讓用戶直接通過滑動進入下一級界面，增加曝光。同時滑動是承接上一步手勢操作，很連貫，相比點擊的效率也會越高。
我們經常在用產品的時候能看到同一個界面可以從多個不同的入口進來，比如像小鹿茶app點擊下單跳轉到商品列表，也可以直接點擊底部第二個tab切換過來。比如你可以在夜宵板塊和品牌板塊都能找到kfc，讓一個區域的流量不僅僅從單獨的方向流入，這樣可以滿足更多用戶的場景需求。像淘寶的商品流量來自多個不同的層級
還有我們可以將更深層級的業務板塊提到上一層級，提高子業務板塊的點擊率和曝光，譬如貝殼在下方的tab板塊中除了信息流內容外還嵌入了精選、人氣、熱門三個分類。還有類似像德邦app這樣的工具型首頁其實版面利用率太低，本身產品功能不多其實不需要劃分出這么多板塊，讓每個板塊流量這么分散，可以直接在首頁中加入查單號的功能，并且將寄件收件歷史平鋪在首頁。
淘寶商品詳情中會有店鋪和店鋪推薦內容，方便用戶查看更多偏好商品，提高客單價。具有電商屬性的社交產品在用戶圖文中可以添加商品鏈接、標簽、話題等等。還有淘寶在首頁的feed流中點擊商品會進入另一個feed流，這里的商品又進行了算法權重的加持，會更加準確與多樣，由于本身處于逛場景的用戶，在這一步再次幫助用戶進行準確選擇，可以提高轉化，當然了，這樣中心化的分流方式對于商家而言不太友好。
衡量流量分發的效果，我們可以查看板塊的點擊率（UV/PV）和預期。比如在某個周期中，有100個人進入這個界面，而這個界面中的banner最終點擊量為1000次，那么這個banner的點擊率為1000/100=10，平均每人點擊了10次。點擊率越高，該入口的流量自然更大。
每個產品對于活躍的標準不同，比如一個商場衡量活躍用戶數會算那些進來蹭空調的大伯大媽嗎？還是衡量那些有消費行為的顧客，同理一個產品計算活躍不是單純看每天有多少人登錄瀏覽就算活躍的。
那么觀察活躍度有什么用呢？比如我們之前做一個大促活動，每個板塊都有活動，但是大促結束后，只有童裝類板塊的日活流量在持續下降，于是我們通過相關調研，發現是因為童裝類的品類太少，用戶沒有逛和再次購買的興趣。
一波流量進入后，我們不僅要看他們去了哪里，還要查看這波流量在這里做了什么，于是我們通過查看頁面停留時長可以判斷一些問題，比如
1. 如果用戶在本該停留時長長的頁面反而停留時間短可能是當前內容不感興趣、看不懂、閃退、臨時有事等等
2.反之，在本該停留時間短但是用戶停留時間長，說明可能文案排版或者解釋的不清楚、用戶可能在思考、臨時有事等等
一波流量進入后，可能進入更深級界面也可能停留原地，那么還有一部分可能就直接離開了，查看流量的流失可以幫助我們判斷以下問題
1.如果用戶在進行某個多步驟任務，當我們發現其在即將完成時退出了，或者在中間步驟退出了，那說明可能出現了某些問題讓用戶進行不下去
2.用戶可能對當前流程沒有預期，也可能覺得有風險也可能是對某個地方產生不滿
流量就像是一群被標記過的小白鼠，從哪里來到哪里去，中間做了什么，都被我們記錄了下來，那么頁面訪問路徑也是我們查看這些流量去向的關鍵指標，例如cctalk在冷啟動后默認打開發現頁面，我們進行了一些用戶的調研，發現90%以上的同學在進入后都會切換到上課這個界面，這里可以思考的是作為產品我們發現用戶有這樣的行為，需不需要對產品進行優化，產品這樣的設計是否考慮到的是新用戶和培養用戶習慣讓更多課程有曝光。其實這里可以做一些判斷，如果用戶近期有購課、上課的記錄和行為，默認打開上課板塊。若新用戶或者長期沒有上課行為的用戶則默認打開發現界面。這樣就可以起到更精準的分流。
8.總結
流量誠可貴，流失就白費。
今天分享就到這里，你學廢了嗎？
文章來源：站酷 作者：應駿
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
文章目錄
原文鏈接：https://blog.csdn.net/zy1281539626/article/details/114934551
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
SpringBoot與Web開發（超詳細）
一、簡介
二、SpringBoot對靜態資源的映射規則
1、所有 /webjars/ ，都去 classpath:/META-INF/resources/webjars/ 找資源
2、"/" 訪問當前項目的任何資源，都去靜態資源的文件夾找映射
3、歡迎頁： 靜態資源文件夾下的所有index.html頁面，被"/"映射
三、模板引擎
1、引入Thymeleaf
2、Thymeleaf的使用
1、導入thymeleaf的名稱空間
2、使用thymeleaf語法
3、Thymeleaf的語法規則
四、SpringMVC自動配置
1、Spring MVC auto-configuration
2、擴展SpringMVC
原理
3、全面接管SpringMVC
原理
五、如何修改SpringBoot的默認配置
一、簡介
使用SpringBoot的步驟：
1、創建SpringBoot應用，選中我們需要的模塊。
2、SpringBoot已經默認將這些場景配置好了，只需要在配置文件中指定少量配置就可以運行起來。
3、自己編寫業務代碼。
自動配置原理：
xxxxAutoConfiguration：幫我們給容器中自動配置組件
xxxxProperties:配置類來封裝配置文件的內容
1
2
二、SpringBoot對靜態資源的映射規則
@ConfigurationProperties(prefix = "spring.resources", ignoreUnknownFields = false)
public class ResourceProperties implements ResourceLoaderAware {
//可以設置和靜態資源有關的參數，緩存時間等
1
2
3
WebMvcAuotConfiguration：
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
if (!this.resourceProperties.isAddMappings()) {
logger.debug("Default resource handling disabled");
return;
}
Integer cachePeriod = this.resourceProperties.getCachePeriod();
if (!registry.hasMappingForPattern("/webjars/")) {
customizeResourceHandlerRegistration(
registry.addResourceHandler("/webjars/**")
.addResourceLocations(
"classpath:/META-INF/resources/webjars/")
.setCachePeriod(cachePeriod));
}
String staticPathPattern = this.mvcProperties.getStaticPathPattern();
//靜態資源文件夾映射
if (!registry.hasMappingForPattern(staticPathPattern)) {
customizeResourceHandlerRegistration(
registry.addResourceHandler(staticPathPattern)
.addResourceLocations(
this.resourceProperties.getStaticLocations())
.setCachePeriod(cachePeriod));
}
}
//配置歡迎頁映射
@Bean
public WelcomePageHandlerMapping welcomePageHandlerMapping(
ResourceProperties resourceProperties) {
return new WelcomePageHandlerMapping(resourceProperties.getWelcomePage(),
this.mvcProperties.getStaticPathPattern());
}
//配置喜歡的圖標
@Configuration
@ConditionalOnProperty(value = "spring.mvc.favicon.enabled", matchIfMissing = true)
public static class FaviconConfiguration {
private final ResourceProperties resourceProperties;
public FaviconConfiguration(ResourceProperties resourceProperties) {
this.resourceProperties = resourceProperties;
}
@Bean
public SimpleUrlHandlerMapping faviconHandlerMapping() {
SimpleUrlHandlerMapping mapping = new SimpleUrlHandlerMapping();
mapping.setOrder(Ordered.HIGHEST_PRECEDENCE + 1);
//所有 /favicon.ico
mapping.setUrlMap(Collections.singletonMap("/favicon.ico",
faviconRequestHandler()));
return mapping;
}
@Bean
public ResourceHttpRequestHandler faviconRequestHandler() {
ResourceHttpRequestHandler requestHandler = new ResourceHttpRequestHandler();
requestHandler
.setLocations(this.resourceProperties.getFaviconLocations());
return requestHandler;
}
}
1、所有 /webjars/ ，都去 classpath:/META-INF/resources/webjars/ 找資源
webjars：以jar包的方式引入靜態資源。WebJars
訪問localhost:8080/webjars/jquery/3.3.1/jquery.js的結果：
2、"/" 訪問當前項目的任何資源，都去靜態資源的文件夾找映射
"classpath:/META-INF/resources/",
"classpath:/resources/",
"classpath:/static/",
"classpath:/public/"
"/"：當前項目的根路徑
例子：訪問localhost:8080/abc 就是去靜態資源文件夾里面找abc
例如我們訪問js文件夾下的Chart.min.js：
訪問結果：
3、歡迎頁： 靜態資源文件夾下的所有index.html頁面，被"/"映射
編寫index.html文件。
訪問結果：
三、模板引擎
常見的模板引擎：JSP、Velocity、Freemarker、Thymeleaf（springboot推薦，語法更簡單，功能更強大）
1、引入Thymeleaf
Thymeleaf官網
在pom.xml中添加以下依賴：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>
2、Thymeleaf的使用
@ConfigurationProperties(prefix = "spring.thymeleaf")
public class ThymeleafProperties {
private static final Charset DEFAULT_ENCODING = Charset.forName("UTF-8");
private static final MimeType DEFAULT_CONTENT_TYPE = MimeType.valueOf("text/html");
public static final String DEFAULT_PREFIX = "classpath:/templates/";
public static final String DEFAULT_SUFFIX = ".html";
1
只要我們把HTML頁面放在classpath:/templates/，thymeleaf就能自動渲染。
success.html：
HelloController：
package com.keafmd.springboot.controller;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
/
Keafmd
@ClassName: HelloController
@Description:
@author: 牛哄哄的柯南
@date: 2021-03-04 19:54
*/
@Controller
public class HelloController {
@ResponseBody
@RequestMapping("/hello")
public String hello(){
return "Hello World";
}
@RequestMapping("/success")
public String success() {
return "success";
}
}
訪問success的結果：
1、導入thymeleaf的名稱空間
<html lang="en" xmlns:th=";
1
2、使用thymeleaf語法
HelloController：
package com.keafmd.springboot.controller;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import java.util.Map;
/*
Keafmd
@ClassName: HelloController
@Description:
@author: 牛哄哄的柯南
@date: 2021-03-04 19:54
/
@Controller
public class HelloController {
@ResponseBody
@RequestMapping("/hello")
public String hello(){
return "Hello World";
}
/*
查出一些數據在頁面顯示
@param map
@return
*/
@RequestMapping("/success")
public String success(Map<String,Object> map) {
map.put("hello","你好");
return "success";
}
}
success.html：
<!DOCTYPE html>
<html lang="en" xmlns:th=";
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<h1>成功</h1>
<!--th:text 將div里面的文本內容設置為-->
<div th:text="${hello}"></div>
</body>
</html>
運行結果：
3、Thymeleaf的語法規則
1、th：任意html屬性，來替換原生屬性的值
th:text — 改變當前元素里面的文本內容
更多參考下圖：
2、表達式
Simple expressions:（表達式語法）
Variable Expressions: ${...}：獲取變量值；OGNL；
1）、獲取對象的屬性、調用方法
2）、使用內置的基本對象：
#ctx : the context object.
#vars: the context variables.
#locale : the context locale.
#request : (only in Web Contexts) the HttpServletRequest object.
#response : (only in Web Contexts) the HttpServletResponse object.
#session : (only in Web Contexts) the HttpSession object.
#servletContext : (only in Web Contexts) the ServletContext object.
${session.foo}
3）、內置的一些工具對象：
Selection Variable Expressions: {...}：選擇表達式：和${}在功能上是一樣；
補充：配合 th:object="${session.user}：
<div th:object="${session.user}">
<p>Name: <span th:text="{firstName}">Sebastian</span>.</p>
<p>Surname: <span th:text="{lastName}">Pepper</span>.</p>
<p>Nationality: <span th:text="{nationality}">Saturn</span>.</p>
</div>
Message Expressions: #{...}：獲取國際化內容
Link URL Expressions: @{...}：定義URL；
@{/order/process(execId=${execId},execType='FAST')}
Fragment Expressions: ~{...}：片段引用表達式
<div th:insert="~{commons :: main}">...</div>
Literals（字面量）
Text literals: 'one text' , 'Another one!' ,…
Number literals: 0 , 34 , 3.0 , 12.3 ,…
Boolean literals: true , false
Null literal: null
Literal tokens: one , sometext , main ,…
Text operations:（文本操作）
String concatenation: +
Literal substitutions: |The name is ${name}|
Arithmetic operations:（數學運算）
Binary operators: + , - , * , / , %
Minus sign (unary operator): -
Boolean operations:（布爾運算）
Binary operators: and , or
Boolean negation (unary operator): ! , not
Comparisons and equality:（比較運算）
Comparators: > , < , >= , <= ( gt , lt , ge , le )
Equality operators: == , != ( eq , ne )
Conditional operators:條件運算（三元運算符）
If-then: (if) ? (then)
If-then-else: (if) ? (then) : (else)
Default: (value) ?: (defaultvalue)
Special tokens:
No-Operation: _
注意：內容過多，詳細內容參考官方文檔。
示例：↓
HelloController：
package com.keafmd.springboot.controller;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import java.util.Arrays;
import java.util.Map;
/*
Keafmd
@ClassName: HelloController
@Description:
@author: 牛哄哄的柯南
@date: 2021-03-04 19:54
/
@Controller
public class HelloController {
@ResponseBody
@RequestMapping("/hello")
public String hello(){
return "Hello World";
}
/*
查出一些數據在頁面顯示
@param map
@return
*/
@RequestMapping("/success")
public String success(Map<String,Object> map) {
map.put("hello","你好");
map.put("hello1","<h1>你好</h1>");
map.put("users", Arrays.asList("柯南","小蘭","基德"));
return "success";
}
}
success.html：
<!DOCTYPE html>
<html lang="en" xmlns:th=";
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<h1>成功</h1>
<!--th:text 將div里面的文本內容設置為-->
<div id="div01" class="myDiv" th:id="${hello}" th:class="${hello}" th:text="${hello}">這里的內容被覆蓋</div>
<hr/>
<div th:text="${hello1}"></div>
<div th:utext="${hello1}"></div>
<hr/>
<!--th:each 每次遍歷都會生成當前這個標簽-->
<h4 th:text="${user}" th:each="user:${users}"></h4>
<hr/>
<h4>
<span th:each="user:${users}"> [[${user}]] </span>
</h4>
</body>
</html>
效果：
四、SpringMVC自動配置
1、Spring MVC auto-configuration
參考官方文檔：點這里
Spring Boot 自動配置好了SpringMVC
以下是SpringBoot對SpringMVC的默認配置：（WebMvcAutoConfiguration）
Inclusion of ContentNegotiatingViewResolver and BeanNameViewResolver beans.
自動配置了ViewResolver（視圖解析器：根據方法的返回值得到視圖對象（View），視圖對象決定如何渲染（轉發？重定向？））
ContentNegotiatingViewResolver：組合所有的視圖解析器的。
如何定制：我們可以自己給容器中添加一個視圖解析器；自動的將其組合進來。
Support for serving static resources, including support for WebJars (see below).靜態資源文件夾路徑,webjars
Static index.html support. 靜態首頁訪問
Custom Favicon support (see below). favicon.ico
自動注冊了 of Converter, GenericConverter, Formatter beans.
Converter：轉換器； public String hello(User user)：類型轉換使用Converter
Formatter ：格式化器； 2017.12.17===Date
@Bean
@ConditionalOnProperty(prefix = "spring.mvc", name = "date-format")//在文件中配置日期格式化的規則
public Formatter<Date> dateFormatter() {
return new DateFormatter(this.mvcProperties.getDateFormat());//日期格式化組件
}
1
2
3
4
5
自己添加的格式化器轉換器，我們只需要放在容器中即可
Support for HttpMessageConverters (see below).
HttpMessageConverter：SpringMVC用來轉換Http請求和響應的；User—Json
HttpMessageConverters 是從容器中確定；獲取所有的HttpMessageConverter
自己給容器中添加HttpMessageConverter，只需要將自己的組件注冊容器中（@Bean,@Component）
Automatic registration of MessageCodesResolver (see below)：定義錯誤代碼生成規則
Automatic use of a ConfigurableWebBindingInitializer bean (see below).
我們可以配置一個ConfigurableWebBindingInitializer來替換默認的（添加到容器）
初始化WebDataBinder
請求數據=====JavaBean
1
2
org.springframework.boot.autoconfigure.web：web的所有自動場景
If you want to keep Spring Boot MVC features, and you just want to add additional MVC configuration (interceptors, formatters, view controllers etc.) you can add your own @Configuration class of type WebMvcConfigurerAdapter, but without @EnableWebMvc. If you wish to provide custom instances of RequestMappingHandlerMapping, RequestMappingHandlerAdapter or ExceptionHandlerExceptionResolver you can declare a WebMvcRegistrationsAdapter instance providing such components.
如果你想保持Spring Boot MVC 功能,你只是想添加額外的(MVC配置)(https://docs.spring.io/spring/docs/4.3.14.RELEASE/spring-framework-reference/htmlsingle MVC)(攔截器,格式器,視圖控制器等)您可以添加自己的@ configuration類WebMvcConfigurerAdapter類型,但沒有@EnableWebMvc。如果你想提供RequestMappingHandlerMapping, RequestMappingHandlerAdapter或ExceptionHandlerExceptionResolver的自定義實例，你可以聲明一個WebMvcRegistrationsAdapter實例來提供這樣的組件。
If you want to take complete control of Spring MVC, you can add your own @Configuration annotated with @EnableWebMvc.
如果你想完全控制Spring MVC，你可以添加你自己的@Configuration注解@EnableWebMvc。
2、擴展SpringMVC
實現如下功能：
<mvc:view-controller path="/hello" view-name="success"></mvc:view-controller>
<mvc:interceptors>
<mvc:interceptor>
<mvc:mapping path="/hello"/>
<bean></bean>
</mvc:interceptor>
</mvc:interceptors>
做法：編寫一個配置類（@Configuration），是WebMvcConfigurerAdapter類型；不能標注@EnableWebMvc
特點：既保留了所有的自動配置，也能用我們擴展的配置。
在config包下創建個MyMvcConfig。
代碼實現：
package com.keafmd.springboot.config;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.ViewControllerRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
/*
Keafmd
@ClassName: MyMvcConfig
@Description:
@author: 牛哄哄的柯南
@date: 2021-03-17 20:26
/
@Configuration
public class MyMvcConfig implements WebMvcConfigurer {
@Override
public void addViewControllers(ViewControllerRegistry registry) {
//瀏覽器發送 /keafmd 請求 來到success頁面
registry.addViewController("/keafmd").setViewName("success");
}
}
原理
1、WebMvcAutoConfiguration是SpringMVC的自動配置類。
2、在做其他自動配置時會導入，@Import(EnableWebMvcConfiguration.class)。
@Configuration
public static class EnableWebMvcConfiguration extends DelegatingWebMvcConfiguration {
private final WebMvcConfigurerComposite configurers = new WebMvcConfigurerComposite();
//從容器中獲取所有的WebMvcConfigurer
@Autowired(required = false)
public void setConfigurers(List<WebMvcConfigurer> configurers) {
if (!CollectionUtils.isEmpty(configurers)) {
this.configurers.addWebMvcConfigurers(configurers);
//一個參考實現；將所有的WebMvcConfigurer相關配置都來一起調用；
@Override
// public void addViewControllers(ViewControllerRegistry registry) {
// for (WebMvcConfigurer delegate : this.delegates) {
// delegate.addViewControllers(registry);
// }
}
}
}
3、容器中所有的WebMvcConfigurer都會一起起作用。
4、我們的配置類也會被調用。
效果：SpringMVC的自動配置和我們的擴展配置都會起作用。
3、全面接管SpringMVC
SpringBoot對SpringMVC的自動配置不需要了，所有都是我們自己配置，所有的SpringMVC的自動配置都失效了。
做法：我們需要在配置類中添加@EnableWebMvc即可。
@EnableWebMvc
@Configuration
public class MyMvcConfig implements WebMvcConfigurer {
@Override
public void addViewControllers(ViewControllerRegistry registry) {
//瀏覽器發送 /keafmd 請求 來到success頁面
registry.addViewController("/keafmd").setViewName("success");
}
}
全面接管后，靜態資源失效。
不推薦這樣全面接管。
原理
加了@EnableWebMvc自動配置就失效了。
1、@EnableWebMvc的核心：
@Import({DelegatingWebMvcConfiguration.class})
public @interface EnableWebMvc {
2、DelegatingWebMvcConfiguration
@Configuration(
proxyBeanMethods = false
)
public class DelegatingWebMvcConfiguration extends WebMvcConfigurationSupport {
3、WebMvcAutoConfiguration
@Configuration(
proxyBeanMethods = false
)
@ConditionalOnWebApplication(
type = Type.SERVLET
)
@ConditionalOnClass({Servlet.class, DispatcherServlet.class, WebMvcConfigurer.class})
//容器中沒有這個組件的時候，這個自動配置類才生效
@ConditionalOnMissingBean({WebMvcConfigurationSupport.class})
@AutoConfigureOrder(-2147483638)
@AutoConfigureAfter({DispatcherServletAutoConfiguration.class, TaskExecutionAutoConfiguration.class, ValidationAutoConfiguration.class})
public class WebMvcAutoConfiguration {
4、@EnableWebMvc將WebMvcConfigurationSupport組件導入進來，自動配置類失效了。
5、導入的WebMvcConfigurationSupport只是SpringMVC最基本的功能。
五、如何修改SpringBoot的默認配置
1、SpringBoot在自動配置很多組件的時候，先看容器中有沒有用戶自己配置的（@Bean、@Component）如果有就用用戶配置的，如果沒有，才自動配置；如果有些組件可以有多個（ViewResolver）將用戶配置的和自己默認的組合起來。
2、在SpringBoot中會有非常多的xxxConfigurer幫助我們進行擴展配置。
3、在SpringBoot中會有很多的xxxCustomizer幫助我們進行定制配置。
以上就是SpringBoot與Web開發（超詳細）篇一的全部內容。
————————————————
版權聲明：本文為CSDN博主「牛哄哄的柯南」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/weixin_43883917/article/details/114375472
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
越來越多的產品引入會員系統，如何做好一個會員系統，是當下設計師需要解答的一個命題。
會員的本質是建立用戶分層，便于形成用戶的差異化營銷，通過這種差異化的營銷達到以下四種目的：
提高用戶留存率（增加用戶粘性）；
提升用戶價值；
得到會費收益；
建立流量橋梁；
目的：篩選出高價值用戶（高留存+消費力強），精細化運營
手段：收會員費，建立用戶層之間的壁壘
結果：用戶自發分層，愿意掏錢的那批人成為會員用戶
原則：給會員用戶提供卓越的服務，給普通用戶提供好用的服務（反例：某網盤限速機制，約等于強賣會員，嚴重傷害普通用戶的使用體驗）
價格優勢：會員專享低價（電商產品有會員專享價、外賣產品有會員紅包）
資源優勢：增值內容（影視、音樂版權）
體驗優勢：更好的服務（更快響應、專屬客服、無廣告等）
心理優勢：身份認同（尊貴感標識，與普通用戶形成差異。對社交、游戲尤其關鍵）
短期價值：通過收取會員費，提高營收
長期價值：增加用戶粘性、鞏固并提升市場占比
體驗角度：更好的服務、專屬福利
心理層面：身份認同、沉沒成本（已經花了會員費，越多使用越合算，不然就虧了）
UI界面設計環節，一般的會員體系會涉及到的界面、視覺元素有：
會員觸點/前置曝光
會員中心
會員身份等級
所有將用戶引導至會員中心頁面的入口都可以算作會員觸點，觸點越多，用戶被引入會員中心的可能性越大。但觸點也不是越多越好，過多觸點會引起用戶反感，將觸點置于合適位置，能更自然高效地提高轉化率。
2.1.1 個人中心：露出會員板塊，通常是視覺強調中心。
個人中心是曝光率較高的頁面，其中整合了許多重要和必要功能入口。利用個人中心頁面，可以很好增加會員信息的曝光。該方式也是最常見且最通用的觸點形式，不局限于產品類型。
2.1.2 內容卡點：體驗完免費部分之后，會員內容收費，觸點卡于兩者之間。
增加用戶沉沒成本：用戶已經在早期投入大量時間和精力閱讀免費內容；
利用用戶好奇心：有前文做鋪墊，用戶行至卡點處，對剩余內容的好奇遠超過一般內容；
需求明確（制造問題）：用戶開會員就是為了解決剩余內容無法觀看這一具體問題，用戶總是傾向于解決問題而不是在原有基礎上提高要求。
2.1.3 會員專區：建立專享感，將會員內容與普通內容進行區隔。
將付費內容集中在一個區塊內，制造差異化，不論是內容質量或者商品價位，本質都是讓用戶形成會員價值很高的感覺。
2.1.4 會員頻道
常見于電商產品，同樣是起到區分內容，建立壁壘的作用。
2.1.5 底部提示
使用較為輕量的底部提示，引導用戶關注會員信息。該視覺樣式還常被用作登錄提醒。
2.1.6 小banner
見縫插針式的視覺提示，占用流量最大的首頁空間，此時文案的利益刺激尤其重要。
2.1.7 會員專頁
使用一個底部tab的權重來承載會員相關信息，可見會員體系的重要性。
會員中心是展示會員權益，以吸引用戶開通會員的頁面。是用戶全面了解會員相關信息的窗口，氛圍營造、權益展示、行動點突出，是設計會員中心需要考慮的要點。
2.2.1 會員中心的常見頁面結構
不同產品有不同的會員中心布局，有差異性也有共性。
氛圍感、套餐選擇（多套餐情況）、行動點、會員權益，是多數會員中心頁面共有的模塊，模塊之間位置并不固定。
本質上越重要的模塊，應該被分配越醒目的視覺表達方式。通過調整位置、面積、視覺對比度等，都可以調整不同模塊之間的權重，達到產品想要呈現的優先級效果。
2.2.2 會員中心_氛圍感
打造氛圍感的方式多樣，常見的有以下幾種方式：
2.2.3 會員中心_套餐選擇
部分產品不存在套餐選擇，只有一種套餐，如盒馬。在用戶體系中，將用戶分為兩層，用戶會員與非用戶會員。部分產品在會員中又進一步分類，推出了多種會員套餐。
常見套餐以時間區分，如包月會員、季度會員、包年會員、連續包年會員等。除此之外，也有以權限范圍為區分，如百度網盤的會員VIP和超級會員SVIP，超級會員享受更多特權。還有垂類會員，如視頻產品中單獨開辟出體育分類，對應設立專門的體育VIP卡。
上方案例中的套餐選擇均以卡片的樣式展示，除了該種方式，還有可以以列表形式展示。
列表形式的好處在于，套餐在垂直方向鋪開，延展性強，當套餐數量改變時，不會影響展示效率，而卡片式的展示形式會造成部分套餐被擠出屏幕，用戶需要左右滑動才能瀏覽全部，交互成本略高。同時，卡片式套餐需要點擊選中套餐，再點擊行動點，才能觸發支付，而列表式模型，直接點擊對應套餐項上的按鈕即可呼出支付，交互更加簡潔。
多套餐模型下，產品往往會重點突出一到兩項套餐，從商業層面講，通常希望用戶選擇價格更高的套餐，從體驗層面講，將附加值最高的套餐用角標突出，輔助用戶決策。
2.2.4 會員中心_行動點
行動點是一個頁面中最醒目的元素，往往是由按鈕充當。按鈕的點擊數據也可以直接反映頁面的設計是否合理。對于會員中心頁面來說，提升關鍵性按鈕點擊，往往是改版的目標和方向。
最常見的行動點布局方式有4種：
購買按鈕常駐于底部工具欄
購買按鈕緊鄰套餐選擇模塊，位于頁面中部
頁面同時有多個購買按鈕
界面始終存在一個購買按鈕
符合一般操作習慣，關鍵行動點常駐于頁面底部，已經被普遍接受。
購買按鈕緊鄰套餐選擇模塊，從操作的角度上來說，更加合理，套餐選擇完畢之后，購買按鈕含義類似“確定”，兩個步驟緊密相關，符合格式塔的遠近親疏原則。同時，頁面中心相比于頁面底部更加容易視覺聚焦，用戶能更加容易注意到。這也解釋了，為什么居中的對話框常用于警示，需要引起用戶高度關注，而底部半彈窗往往承載不那么關鍵的內容，一般承載無破壞性的操作。
購買按鈕意味著支付入口，頭部卡片上增加支付入口，不妨通過數據觀察，測試不同位置的點擊效果如何。
隨著頁面上劃，界面中第一個行動點（頁面中部）被推出視圖，此時底部工具欄浮出，保證頁面不管在何位置，始終可見至少一個行動點，讓用戶隨時可以進行支付。
2.2.5 會員中心_權益
會員權益是決定用戶是否購買會員的重要因素。有些權益相當實在，如會員折扣、專屬紅包等，而有些權益的誘惑力相對較弱，不同的權益強度決定了不同的視覺呈現方式。
會員權益細節介紹
會員權益從交互上，可分為兩類，可點擊和不可點擊。不可點擊的權益往往在會員中心頁面是以宮格圖標的形式呈現。而可點擊的權益，往往內容詳實，需要更多的空間來解釋和說明權益的具體內容。
從視覺形式上，也可以分為兩類：
彈窗呈現
子頁面呈現
除了購買會員之外，部分產品引入了“身份等級”的概念來將用戶進行分層。劃分的維度可以是用戶的活躍度、裂變能力等，可以依此，設計一系列的會員任務。會員身份等級機制利用了用戶的攀比、自我實現等心理，進一步增加用戶與產品之間的粘性。
會員身份等級一般集中在4-7個之間，其中梯度理論上呈遞增趨勢。作為設計師，需要將低等級到高等級這種“越來越高端”的氛圍烘托出來。不同類型的產品有自己的特色和局限，金融類產品在整體視覺屬性上趨于穩定內斂，而娛樂性強的產品則在視覺上限制較少。
隨著梯度的增加，設計難度也在增加，如何在不同等級之間拉開合適的視覺感知差距，是一個難點。如上圖中的“黑金會員”和“黑金PLUS會員”在視覺上比較雷同，差異較小。當靜態視覺發揮空間有限時，可以考慮加入動態元素，增加區分。
徽章系統
與會員等級的本質一樣，徽章系統將用戶分層，制造不同的用戶群，擁有更多、更高級徽章的用戶對于產品來說，自然是價值更高的用戶，這類用戶是產品需要重點關注的對象。他們是產品的深度體驗者，他們的意見反饋相比于普通用戶更加準確和反映問題。
隨著產品本身的日漸成熟，越來越多的產品選擇加入會員體系。會員體系無論對產品的短期或者長期利益都至關重要，從短期來講，直接增加營收，從長期規劃來講，對于增加用戶粘性、提高市場份額也有著重要意義。作為設計師，如何把用戶對于會員期待的“價值感”、“尊享感”用體驗的形式呈現出來，至關重要。
會員體系涉及到的相關設計細節很多，小到一個會員標簽，大到一級頁面，其中的設計細節更是不勝枚舉。將龐大的概念不斷拆解為一個個細小的可控的模塊，加以分析和總結，始終是沉淀設計經驗的方法之一。高大上的觀念理論，需要一個個見微知著的細節支撐。
文章來源：站酷 作者：doo_W
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
藍藍設計的小編 http://www.syprn.cn
