本文分享國際化司機端首頁改版完整思考過程，化繁為簡提升司機使用效率，提升產品用戶體驗。
隨著滴滴國際化業務腳步不斷加快，司機端始終是作為承載全球化業務運力的基礎保障。
同時，在移動通信技術高速發展的背景下，不同國家間的傳輸速度與硬件設備差距正在不斷縮小，用戶對應用產品的期望由基礎的可接受、可使用、功能齊全，向更易用、簡約、更為專注的產品使用體驗上轉變。
在新階段下，「為全球司機用戶提供一個「克制」「可依賴」的產品使用體驗」、「為業務拓展提供有力的體驗支撐」是體驗設計團隊在新的階段下提出的目標。
2018 年 9 月我們與產品同學深入拉美當地對司機側進行為期 2 周的產品體驗調研。雖然在當地的時間較為短暫，但是我們依舊感受到了拉美國家的習俗文化和人文特點。
相比中國人的含蓄內斂，巴西與墨西哥人顯然更加熱情隨和。
在巴西，這個世界上假期最多的國家，處處體現著人們對生活的享受才是自始至終的追求。無論是世界杯一個月狂歡長假，還是周末下午兩點開門的商區，總會讓人羨慕的同時刷新你對享受生活的認知。
而娛樂至上的墨西哥人，熱情友好，能歌善舞，我們常說的放飛自我在這里幾乎成為墨西哥人每天的生活常態。他們喜歡享受當下，后天下之憂而憂。他們覺得工作賺錢就是為了更好的休息，大多數人每天都是開朗樂觀的處世態度。
同樣，落后的基礎建設、糟糕的交通狀況、教育水平低下、價格昂貴的電子產品以及相對不太穩定的社會環境，也是它們共同存在的問題。
在當地，我們通過實地調研與用戶訪談等方式，針對產品體驗的問題與司機進行面對面溝通。收集了很多寶貴的用研資料與司機訴求，如司機希望平臺為他們推薦訂單引導，司機希望獲得更多的實時動態訊息和司機每天都可以查看自己的收入狀況等，集中體現在效率、感知、體驗這三大方面。
其次，伴隨著業務的不斷增長，越來越多的功能使得我們的產品變的更加復雜，舊版的框架布局早已是不堪重負，無論是現存的體驗優化問題，還是未來業務功能的拓展問題，舊的框架體系都是難以為繼，無法再通過簡單的修補來滿足用戶和業務未來的訴求。
改版升級對產品本身來說是一件非常重要的事情，需要對多方因素進行慎重考慮。經過多次的溝通討論，權衡改版對產品可能產生的利弊關系，采用小步快跑，快速試錯，分階段分模塊的方式進行。
首頁既作為承載核心功能（發車）的載體又是其他重要板塊的分發的入口，在內容呈現與用戶感知上都存在很大的體驗提升空間；我們通過拆解業務中長遠需求規劃得知，大多數重點需求依賴于首頁框架布局，而現存首頁框架無法滿足業務訴求；在競品的改版中首頁的變化最大，并在司機群體中取得比較正向的反饋；通過上述分析，決定率先對首頁進行優化改造。
首先我們與產品、運營側進行深入討論，結合用戶訪談整理的用戶訴求，對此次首頁改版的目標達成一致。
在舊版的框架體系中，大量信息在首頁呈現，功能層級復雜，重點功能難以突破和查找，關聯較弱的信息架構嚴重影響和分散了司機的關注點。隨著業務模式不斷擴展，首頁新需求類型逐漸增多，一套更加具備靈活的拓展能力和管理能力的首頁框架尤為重要。
首先我們將舊版的首頁布局打破重建，對現有模塊進行整理。功能相似、定義模糊、司機操作相對低頻的模塊進行合并、刪減。
對司機高頻操作模板進行場景劃分，將相關信息進行聚合處理，通過對入口的強化，來明確司機對不同模塊的認知。
出車管理
將與出車相關信息進行組織聚合，結合司機不同的使用場景，將功能與模塊進行結合，加強認知，減少司機多余的思考與判斷，快速響應，提升工作效率，同樣也為業務在有關出車功能方面提供靈活可拓展的組件框架。
收入管理
通過顯示司機最關注的今日收入信息，為司機提供方便快捷的查看功能，使司機更專注于工作本身。同時對收入管理入口起到了強化認知作用。
信息管理
對關于個人相關的信息通知及功能操作進行聚合，方便司機對個人信息進行快速查看，提高查看效率。
通過對框架模塊的標準化定義，后續的業務需求便可以進行歸類管理，根據不同需求的不同屬性，結合功能使用場景，選擇合適的模塊進行展示，提高司機使用效率同時增加首頁的業務框架擴展能力。
通過對框架的重構，有效的解決了首頁信息承載壓力過大，功能層級復雜的問題，同時地圖的面積相比舊版首頁也大幅增加，信息呈現更加簡潔、輕量。
出車操作作為首頁的核心功能，通過調研得知，司機普遍反映在舊版首頁中存在出車操作感知弱、收出車狀態區分不明顯的問題，對司機的操作體驗和感知體驗造成了比較大困惑。
在首頁改版過程中我們著重對出車操作進行了設計分析，基于對業務的了解和競品的分析，得出以下三個結論：
通過「兩強一弱」，減少司機困惑提升發單效率的同時，間接的延長司機的在線時長。
完成頁面設計后我們發現，操作按鈕通過靜態視覺角度去表達收出車空間位置關系是十分困難的，僅通過 Toast 提示會造成用戶理解的斷層，于是提出使用動效去進行「搭線」串聯，搭線發車前按鈕的點擊和收納后的位置提醒進行視覺體驗上的串聯，從而達成感知增強，解決視覺體驗層面不容易解決的問題。
豐富的訂單獎勵活動是我們與競品相比重要的競爭優勢，司機在完成定量訂單的同時提供了更多的額外收入。查看每日獎勵活動，已成大多數司機每日上線必做的事情。
與舊版相比，在新版首頁中通過提升獎勵入口層級，縮短了查看獎勵活動操作路徑，從而方便司機快速查看。
通過首頁透傳的獎勵卡片，司機在首頁即可獲取到推送的獎勵相關信息，及時獲取到獎勵預告和進度，提升了司機工作效率的同時加強了司機對獎勵活動的感知。
在經歷了快速奔跑的粗放階段，我們也在思考司機端產品究竟以怎樣的品牌氣質傳遞給海外的司機群體。
在當地，我們在司機心目中更像是合作伙伴，憑借真誠互利的態度贏得了當地司機的用戶。
真誠、熱情與融合我想這就是我們想要傳達的核心品牌情感，而克制、可依賴將作為產品體驗的設計原則貫穿始終。
顏色系統
司機端顏色系統在基于現有品牌色基礎上，結合不同國家顏色文化的理解，新增加符合本地化的輔助色系，以提升產品的親和力，傳遞品牌情感。
文字系統
針對司機用戶的操作使用場景，對文字字號梯度進行提升，通過文字粗細、顏色、大小加強信息對比度，使司機在更多復雜場景下可快速獲取重要信息，提升閱讀體驗。
在此次改版中新引入 Barlow 與 DIN Alternate 字族作為模式數字展示字體，兩款字體分別為 Android 及 iOS 系統下默認包含字體，相比 Roboto 與 SF Pro text 兩款字族，在數字展示上更為明確、識別性更強，同時因為自身「纖瘦」的特性，在屏幕橫向面積上節省更多空間。
業務在不同的階段有不同的側重方向及打法，設計側根據業務所處階段應及時的調整自身的目標定位，快速響應，積極探索設計的機會和突破點，在不同的階段發揮自身價值，助力業務達成共同目標，為用戶創造更便捷的產品使用體驗。
首頁改版從立項到設計再到研發，多部門同學緊密配合，在有限的時間內最大化的完成預期上線效果。
全量上線后，通過問卷對首頁改版進行滿意度收集，司機對新版首頁的滿意度平均值高達 93%。取得的成績離不開每一位參與改版的同學支持，也得益于國際化團隊自始至終對產品體驗的重視與認同。
作為司機端體驗升級的第一步，首頁改版只是一個開始，希望通過不斷的打磨優化，秉持初心，為全球司機提供更克制、可依賴的出行平臺。
文章來源：優設
一、建立一個庫
1、git clone [url] // 克隆代碼
2、設置貢獻者
git config --global user.name "" // 設置當前本地庫username
git config --global user.email "" // 設置當前本地庫useremail
git config --global user.email // 查看當前本地庫useremail
git config --list // 查看所以配置項
二、git的三個區
1、工作區：本地編寫代碼的地方叫工作區
2、暫存區：工作區改好的代碼先提交到暫存區，然后由暫存區將代碼提交到版本庫
- 作為過渡層
- 避免誤操作
- 保護工作區和版本區
- 分支處理
TypeScript是什么
Type+EcmaScript6
TypeScript是JavaScript的強類型版本。然后在編譯期去掉類型和特有語法，生成純粹的JavaScript代碼。由于最終
在瀏覽器中運行的仍然是JavaScript, 所以TypeScript并不依賴于瀏覽器的支持，也并不會帶來兼容性問題。
TypeScript是JavaScript的超集，這意味著他支持所有的JavaScript語法。并在此之上對JavaScript添加了- -些擴
展，如class / interface / module等。這樣會大大提升代碼的可閱讀性。
和JavaScript若類型不同，TypeScript這種強類型語言最大的優勢在于靜態類型檢查,可以在代碼開發階段就預知一
些低級錯誤的發生。
●-種類似于JavaScript的語言，在JavaScript的基礎之上增加了類型，同時增強了JavaScript部分語法功能
●遵循EcmaScript 6標準規范
●由微軟開發
●Angular2框架采用TypeScript編寫
●背后有微軟和谷歌兩大公司支持
●TypeScript可以編譯成Javascript從而在支持Javascript的環境中運行
●TypeScript和javascript的關心就好比less和css的關系
javascript 是動態的
可以在執行階段重新賦值不同的類型數據
.ts 后綴表示一個TypeScript文件
Typescript兼容es6
TypeScript為javascript增加了類型的概念
Typescript是強類型 一旦定義數據的類型 不能動態修改這 樣幫我們在開發階段避免很多低級錯誤
1.全局綁定滾輪事件，獲得dataZoom的位置：
myChart.on('dataZoom',function(event){
if(event.batch){
start=event.batch[0].start;
end=event.batch[0].end;
}else{
start=event.start;
end=event.end;
};
});
2.把的start和end賦值給要更新的option
window.setInterval(function () {
num=Math.random()*num+100;
data0.splice(0,1);
data0.push(num);
option.dataZoom[0].start=start;
option.dataZoom[0].end=end;
myChart.setOption(option);
},3000);
首先來解釋一下什么是動態布局：
所謂動態布局就是可以通過修改內容實現關聯內容自動改變的布局方式。
在 sketch 45 之后的版本，我們可以通過 resizing 對元素的上下左右邊距進行固定，來實現頁面布局的動態響應。這種響應是被動的，需要我們拖拽著它，它才能給出反饋。雖然不是多么的聰明，但是這種被動的方式解放了很大一部分生產力，足以讓你鄙視一下 Photoshop 的 UI 設計了。
有了被動響應，自然也想要有主動響應，通過改變元素內容去改變布局。之前在 sketch 里面一直有一個功能：文字尾部跟隨（間距在 20px 以內，后面可跟文字或圖標）。如圖：
功能雖單一，但在工作效率上帶來了極大的提升。當然我們想要的更多
比如：
一個標簽，我希望可以跟隨文字長度而自動適應。
△ 不是這樣
△ 而是這樣
在 Sketch 58 之前，我們可以通過 kitchen 或者 Anima 等外部插件實現這類效果。但是這類插件在創建為組件以后會出現一些莫名的抽搐，可用性不高。在 Sketch 58 之后 Sketch 自身就攜帶了這些技能，可以實現一些動態布局，不過目前來看它還是存在一定的局限性，它的動態布局是基于 symbol 的。但我們不會為了布局而刻意去做 symbol，這會加重組件庫的維護負擔，在整體的收益率及效率上不見得能帶來多大的提升。組件庫應盡可能的保證干凈、靈活以及它的實用性。
我們取長補短。所以，這里要講的不是某一個插件或某一個功能，而是結合插件與自身的布局來達到足夠的穩定與，解放雙手，釋放大腦。
這里主要通過介紹 Kitchen、Anima 和 sketch 的布局部分，整合它們各自的優勢來做一系列的動態布局。
對比一下各個插件之間的差異
Kitchen
輸入按鈕的上下左右邊距，讓文字與按鈕背景的邊距固定。改變文字寬度，按鈕寬度隨之改變。
Anima Padding
Anima 不需要手動輸入邊距，插件會自動保留文字周圍的邊距并生成 padding。
Sketch 布局
sketch 也不需要手動輸入邊距，但是需要將想要實現動態布局的內容創建為組件，在創建組件的過程中可以對它的動態方向進行限定。這里一共七種模式（無、水平「從左往右、居中、從右往左」、垂直「從上往下、居中、從下往上」）。文字的對齊方式最好和布局的動態方向保持一致。
可以看出 Anima 和 Sketch 會更一點
我們可以讓按鈕再可以復雜一點。
比如加個 icon：
或者換個行：
在一個維度上的動態改變，大家應用得都挺好。但 Sketch 組件在文字換行時并沒有在縱向上去改變高度。
解釋一下：
按鈕、標簽等這類元素，我們通常都會創建為組件，方便我們管理及調用。接下來我們把剛才做好的動態按鈕組件化，再來看看它們是否能實現動態響應。
Kitchen
Anima
Sketch
在組件化之后，Anima 出現了未知錯誤，按鈕并沒有任何變化。在實際使用中，sketch58 之前的版本可以正常變化。58 及其之后的版本暫時會出現問題，把 Anima 更新到 3.2.2 之后，官方更新說修改了 symbol 之后的 padding bug，但是在實際使用中并沒有帶來改善。
所以在這里不建議用任何第三方插件去做 symbol，即使 Kitchen 在這里沒有出現什么大的問題，但在實際操作中的響應速度及穩定性都比較差。此外 sketch 的更新速度很快，大多插件很難即時跟上它的更新速度，從而導致一些不可預知的問題。為了組件的可維護性、自身安全，請盡量用 sketch 的自帶技能去搭建組件。
按鈕或標簽這類組件通常會多個同時出現，比如這樣：
這樣：
我們可以通過以下幾種方式快速實現布局：
Kitchen
Anima
Sketch
其中 Kitchen 和 Anima 可以實現全自動的動態響應，包括復制、刪除等操作。而 Sketch 需要手動去維護或者創建為組件后才能實現全自動的動態響應。
這里傾向于直接利用 Kitchen 或 Anima，不會產生不必要的 symbol，但同時也能提升我們的設計效率。對比 Kitchen 和 Anima，Anima 的響應速度更快，功能更豐富，在實現固定間距的同時可以保證對齊方式。具體的應用場景，我們后面會講到。
動態的組件，結合固定間距可以實現一系列便捷的操作。接下來我們講一些具體的實現效果。
基于上面的結論，我們在這里的動態組件都會用 sketch 的布局功能來搭建。
label 在之前的版本中不需要特殊處理，因為有尾隨功能。59 版本之后這個功能被移除，新的布局可以完全取代它了。這里我們手動配置一下水平方向的布局。
注意文本的對齊方式與布局方向要保持一致。
再利用 「Anima-Padding」/「Kitchen-自動排版」 實現動態布局。
Anima 需要合理編組來實現
圖標解釋
△ Padding（內邊距）
△ Stack（堆載）
導航欄也是常用的組件之一。
首先創建「選中」與「未選中」兩種狀態組件。也可以用一種狀態（選中狀態）通過控制元素隱藏/顯示、修改文字樣式等來實現狀態改變。不過操作比較繁瑣，這里就不推薦了。
這里的選中狀態需要用到 sketch 的水平布局，短橫線才可以跟隨文字動態改變。
置入建立的組件，確定好間距，再次建立組件，保持水平布局。就可以得到一個動態的導航欄了
也可以用 Anima/Kitchen 的布局去實現這個效果。
再次強調：Anima/Kitchen 的最好不要作為組件使用。
通用性強，復用率高的組件建議用 sketch 的布局去建立組件。
如何把大象放進冰箱
這里要實現的效果是「改變文字寬度，保持文字與右側的線條間距不變」
方法：
序號、文字、白色背景成組，并水平「從左向右」布局
這樣文字可以推動白色背景變寬，與右側線條始終維持相同間距。
結合 sketch 的調整尺寸（resizing）還可以手動改變步驟條的寬度。
表單也可以通過 anima 或者 kitchen 來布局，實現數據的快速增刪。
PS: Anima 的 stack 會默認選一種對齊方式，出現下列這幾種布局效果（下方左對齊異常的原因和我組件的搭建方式有關）。
左對齊
居中對齊
兩端對齊
右對齊
6. switch / radioButton
同樣的，利用 sketch 的布局，還可以創建動態的 switch 和 radiobutton。
方法和之前建立動態按鈕類似，不過需要注意的是：這類 tooltip 會存在一個最大寬度，在超出這個寬度后需要換行處理。但是sketch 的動態維度只有一個象限（x或y）。這個時候當超出最大寬度后就需要手動去換行并調節高度（動態高度，手動調節寬度，可以依據文字是否換行來判斷邊距是否正確）。
建議：這里我們可以建立兩個組件，一個動態高度，一個動態寬度，根據文本量的多少去選擇合適的動態方向。上面換行的按鈕也可以這樣處理。
再多說一句：Anima 可以通過拖動寬度來改變文字的對齊方式（自動寬度、自動高度），結合自身的 padding 可以實現兩個象限的動態改變。但是出于穩定性的考慮，我們不推薦用它來做 symbol。
模塊相對于簡單的組件結合了多種布局方法。
以這個留言版為例展開說明：
這個留言版由頭像、name、like、dislike、留言內容等 5 個元素組成。從布局上看可以把頭像、name、like、dislike四個元素作為一個部分，留言作為一個部分。在整體上形成一個上下動態布局的組件。
頭像和 name 固定于左側；頭像鎖定寬高，name 文本自動寬度，布局方式從左向右。
like、dislike編組固定于右側，文本自動寬度，布局方式從右向左。
留言部分固定左右間距，文本自動高度。這樣我們可以通過拖動該區域的寬度去實現高度的動態改變。
利用 Anima 的 stack，實現每個留言版之間的固定間距。此外，在 stack 里面我們可以選中兩邊對齊的方式。
讓組內留言版的寬度保持一致。
分別建立「左上、上、右上、左、中、右、左下、下、右下」等 9 個單元格組件。通過（左、上邊框+th+td）的方式也可以，這里不細說。
每一列單元格分別打組，用 Anima（stack 左右對齊）或 Kitchen 固定垂直間距（間距為 0），組名 tr。無論是單元格的增減，還是單元格高度的變化，都可以在縱向上動態改變。
對 tr 打組，固定左右間距（間距為 0），實現表格在水平方向上的動態變化。
利用上面的知識我們來做一個相對復雜的卡片
要點
具體步驟
從上圖可以看出卡片主要分為三個部分
對圖片+標題編組，命名「banner」，確定標題的文本區域及動態方向，這里的標題我希望它在換行時往上走。這樣可以把文字定為下方固定。如圖：
對頭像、名字、標簽編組，命名「人物簡介」。固定頭像大小，固定名字位置。對標簽編組，這里標簽應該是動態的，從左往右布局。
標簽高度固定；人物簡介寬高固定；
固定人物介紹文本與卡片左右間距以及上邊距
對「海報」「人物簡介」「人物介紹」再次編組，確定組內各元素間距。編組和背景確定邊距。
這個過程剛開始可能是一個漫長的調試過程，在熟悉后，會讓調試有一個明確的方向，從而縮短時間。
不對，工作還沒交付給開發就不算完成。工作中我會使用藍湖把設計資源交付給開發。
結果
Anima 的布局在上傳藍湖后，藍湖上顯示正常，但是 sketch 本地布局統統崩潰了。我不禁長嘆一聲，??！
藍湖官方解釋「兩個插件在 Sketch 提供的方法調用是有沖突的，建議在上傳前關掉 Anima 插件」。
關掉 Anima 需要在插件中關掉后并重啟 sketch 才能生效，不然編組的內容依舊會保留 Anima 特性。
接下來重新總結一下：
結合以上內容為開發同事做的一個上線海報，他們可以只關注內容了。
文章來源：優設
一款產品從0到1的設計流程，在進入開發前的所有工作。這篇文章以去年做的一個小項目為例。
1.了解客戶需求，根據競品產生需求
工具：Axure、Mindmanager、Visio、OmniGraffle、PPT
1.1產品初期模型
1.1.1 競品收集（應用市場、專業網站、行業調查報告、搜索引擎、）
在應用市場、專業網站、行業調查報告、搜索引擎中尋找競品
輸出：
在產品的潛在目標用戶尋找競品
對產品的潛在用戶進行挖掘，分析核心功能的其他實現方法，將功能延展擴大可獲得不同層面的競品。
輸出：
將過程、操作的碎片化處理來尋找競品
將產品的結構、使用過程、操作等一步一步的拆開，根據每一個碎片信息來尋找競品。
輸出：
1.2競品選擇
競品選擇中最關鍵的一步，就是對競品進行分類。
1. 功能完全相同的競品：找出當下產品的核心價值，評估與我們設計目的與市場上成型產品的一致性；更快更好地借鑒對方取得成功的地方；有針對性地尋找差異化競品的方向。
2. 核心功能相似的競品：通過以點帶面地挖掘價值點或者創新點，將我們自己的產品做到。功能完全相同是一個點進行縱向思考，然后尋找競品；核心功能相似則是多個點，排列組合式地進行縱向思考，找到的競品更加全面，我們能夠借鑒到的價值點更多。
3. 功能本質相同的競品：加深對待設計產品的需求本質的理解，通過本質相同挖掘需求的核心所在，借此來找到相對應的參照物。該類競品，往往需要我們進行橫向思考，試圖從別的方面，方向入手，其思維廣度大大增加，有可能從其他領域中得到解決問題的啟示。這類競品是最容易發現亮點和突破的。
輸出：1.功能完全相同的競品
壁紙制作：可以將喜歡的圖片制作成精美的壁紙，定制專屬于你的高清壁紙。
2.核心功能相似的競品
座右銘壁紙：可選擇背景、輸入文字形成自己的鎖屏壁紙。
3.功能本質相同的競品
livefun:將視頻轉換為壁紙，將多張照片合稱為一個live photo。
1.3 競品拆解
競品拆解就是用碎片化方法對競品功能進行拆解，并最終形成競品的功能列表的過程。
形成功能列表后，對功能進行備注，尋找到競品使用過程中的不足，從而超越競品。
輸出：
接下來還需要和所有必要的相關人員就產品以及項目的開展方式進行多次頭腦風暴。
頭腦風暴(Brainstorming)是由美國奧斯提出的，一種激發集體智慧產生和提出創新設想的思維方法。頭腦風暴(Brainstorming)指一群人（或小組）圍繞一個特定的興趣或領域，進行創新或改善，產生新點子，提出新辦法。
頭腦風暴可能帶來一套啟動計劃、一個精簡的框架和一系列比較早期的概念圖以及模型。
頭腦風暴如下圖所示：
2.確定需求
2.1產品定位及如何正確描述需求
前面我們已經講述了怎樣搭建初步產品模型，通過梳理產品模型，可以清楚地了解應該如何定位一個產品。產品定位是需求收集的方向。
用戶需求主要包含三個要素：目標用戶、使用場景、用戶目標。
經過對產品定位的梳理，就明確了產品的目標用戶群體，接下來就可以進行需求的收集、分析活動了，總體流程包括需求收集、需求分析和篩選，需求優先級排序幾部分。
輸出：
產品定位：以用戶產出內容為主的可個性化推送壁紙應用。
用戶場景描述：
陶娟平時喜歡根據心情更換不同風格的壁紙，但是每次找壁紙都讓她十分頭疼，很難找到有個性又好看的壁紙（都是用戶制作上傳的壁紙作品）。
陶娟打開8樓壁紙app，登陸后填寫了她的個性偏好，系統根據她的喜好個性化推送壁紙。陶娟選了一款壁紙，還可以看到同時和她使用同一款壁紙的網友。
2.2需求收集的途徑
1.用戶場景畫像：根據之前的產品定位和使用場景用戶畫像文檔分析產出需求
2.競品分析：找到同類競爭產品，深入體驗競品功能
3.頭腦風暴：可以集結產品經理、設計師、運營、市場、開發、進行頭腦風暴，圍繞一個特定的話題進行討論
4.用戶反饋
5.數據分析
輸出：
2.3需求分析和篩選
在需求收集過后，已經有很多的被選需求了。
如何分析和篩選需求呢？
1.篩掉明顯不合理的需求
哪些是明顯不合理的需求？比如當下技術不可能實現的或明顯意義不大的，投入產出比低的、無匹配的產品使用場景、明顯不合理的需求等
2.做需求分析
把明顯不合理的需求排除后，就需要一個一個對剩下的需求進行分析。首先要了解需求的三個分類：用戶描述的需求、用戶實際想要的需求、用戶的潛在需求，這是三件不同的事情，卻有著千絲萬縷的聯系。我們需要通過用戶描述的需求，找到用戶實際的需求，再挖掘用戶潛在的需求。
3.需求做減法
有時候決定不做什么比決定做什么要更重要，產品的需求是無上限的，大量的堆積需求，會使產品非常臃腫，毫無特色，還會導致工期過長，拖慢了產品推出市場的進度，對產品百害而無一益。因此，應該傾向于做“輕產品”，學會做需求的減法。
這就涉及接下來需要討論的問題，如何判斷需求的優先級。
輸出：篩選后的需求列表
2.4需求的優先級
需要對所有的需求定義一下優先級，優先級高的需求優先開發，優先級低的需求延遲開發。
輸出：
2.5 輸出產品功能圖和功能需求列表
用戶需求列表確定之后，先以產品功能的形式展現出來，產品功能圖可以直觀的看出產品的初步功能架構。
輸出：產品功能圖
功能需求列表的價值，一是在于幫助產品經理理清思路，二是在于幫助項目團隊的其他成員了解產品功能需求，讓他們提前做好相關準備。
輸出：功能需求列表
3.產品架構
3.1 產品功能架構
結合之前的市場調研及產品路徑規劃，梳理了一下產品架構的大模塊
輸出：產品功能架構
3.2 流程圖的規范
流程圖有時也稱作輸入-輸出圖，某種程度上來說，流程圖是一種溝通性質的圖形化語言。一般會使用一些標準符號代表某些類型的動作，如判斷用菱形框表示，具體的操作行為、活動用方框表示，開始和結束用圓角矩形框表示。
3.3 確定核心功能流程圖
首先我們要設計的是產品的核心功能流程，例如登陸的流程就需要前期設計好，綁定手機號登陸還是直接微信登陸。登陸的流程會對后期的功能產生影響。
輸出：功能流程圖
做好了核心功能的流程圖后，我們需要對app主干做一個流程圖。保證每一個功能都可以形成閉環。
3.4 評審與確認
評審主要是讓業務部門和開發部門參與，好的流程圖具備清晰易懂、簡單明了、完整準確的特點
4. 原型設計
4.1 什么是產品原型
產品原型是設計方案的表達，是產品經理、交互設計師的重要產出物之一，也是項目團隊的其它成員（尤其是設計師、開發人員）的重要參考和評估的依據。
4.2 低保真產品原型
首先我們要根據產品架構畫出初步的頁面，也就是低保真產品原型。
這樣的原型圖有幾個好處：
可以快速產出：有時候一個需求的開發周期很短，低保真原型可以快速滿足同事的時間要求。
修改成本低：一個產品策劃很可能會被修改很多次，低保真的原型修改起來很方便。
輸出：低保真原型圖
4.3 高保真產品交互原型
工具：axure、ai、ps
高保真產品原型，則是高功能性、高互動性的原型設計，是忠實展示產品功能、界面元素、功能流程的一種表現手段。
高保真的好處：
便于梳理產品細節：制作高保真原型的過程中可以讓產品經理提前發現產品潛藏的各種問題，提前處理風險。
更容易讓其他成員了解產品設計：有時候簡單的線框圖無法讓別人想象出你要做的事情，也不清楚你要放的是哪幾個字段，而高保真原型就可以。
相對而言，劣勢就是制作周期比較漫長，涉及到產品流程的修改，那基本原型就得回爐重造一遍。所以高保真原型可以做一些核心頁面，不重要的頁面可以后期慢慢完善。
輸出：動態交互稿
5. 視覺設計
工具：Sketch、Ai
在產品0到1時候視覺評審，會花大量時間去討論產品的設計風格和主配色，在確定視覺稿沒有交互問題后，然后就是討論視覺設計稿的細節。在產品功能迭代的時候，評審的都是整體視覺風格的繼承性和視覺稿的細節。例如對交互設計的理解是否到位，邏輯是否正確，視覺層次是否正確等。
5.1 設計組件規范
5.1.1 為什么做組件規范
1.保證產品風格統一
每個設計師都有自己的審美和風格，產品迭代可能是不同的設計師來負責項目，但是產品的風格必須保證是統一的，所以就需要一個規范性的文件來作為設計標準。
2.提升團隊效率
在sketch里，有一個好的組件庫，設計師就不用重復去改每一個頁面上的圖標。只需要改動一個就能同步頁面上所有的圖標。
3.打磨細節體驗
在產品長期迭代的過程中，對每一個元素都需要對其場景、狀態考慮清楚。所以在整理過程中，經常會發現以前沒有注意到的問題并優化。
5.1.2 組件規范內容和分類
不同的項目的規范內容都是不同的，我們需要明確規范內容的分類有哪些?？梢韵却_定大體的規范內容，在頁面完善的過程中也不斷的完善規范。
iOS的設計尺寸建議使用一倍圖375*667的尺寸進行設計。因為這和安卓的常用尺寸360*640的誤差很小。安卓和iOS可以共用字體、圖標和間距?？梢愿臃奖憷镒龊媒y一的設計規范。
輸出：
文章來源：站酷
運營類活動是在某一段時間內進行的，有明確業務目標（業務轉化、品牌傳播）及營銷群體，依賴游戲化手段帶來優秀用戶體驗，從而獲得成功的一類活動。
1. 生命周期短
運營類活動生命周期較短，常在某一段時間（可能是周期性的），一般跟隨時節熱點或者運營節奏來進行。較短的生命周期給設計、開發、數據等帶來較大挑戰，設計程式化提供基本設計思路，組件化降低設計成本。
2. 業務目標明確
運營類活動一般以產品營銷、品牌運營為目標，發放各類優惠券大眾目標用戶，從而帶來業務轉化，或者營銷企業品牌，比如常見的年底 h5。
3. 有一定故事場景及氛圍
運營類活動需要較強的故事場景。良好的場景設計、氛圍營造可以帶來沉浸式的用戶體驗，與用戶建立情感共鳴。從而提升用戶參與度、帶來好的業務轉化。
故事場景結合時節熱點，同時考慮活動需要營造的體感氛圍。
4. 人群細分
運營類活動的特征在發起之初就有特殊的運營目的和特定特征的用戶群體。為實現最優的業務轉化，需要在設計之初明確活動覆蓋的用戶人群。同時在各個環節都能考慮到特定用戶群體的不同需求，尤其是在業務轉化的過程中，好的人群細分往往帶來事半功倍的效果。
5. 游戲化
引入游戲機制及游戲元素。
運營類活動結合時節熱點，通過富有故事性的視覺傳達（插圖、動效、聲音等設計元素）帶給用戶沉浸式的體驗，與用戶建立情感共鳴，從而有效的鼓勵用戶行為。
沉浸體驗的營造對設計師提出了更高要求，可以從活動設計的故事感、用戶代入感、產品互動感、主體差異感幾個方面來思考入手。
運營類活動中廣泛應用了游戲化機制和元素，它們是活動成功的有效保障。設計時綜合考慮業務及用戶需求，從用戶動機激勵、行為引導的角度出發，將運營活動游戲化?？梢栽诨顒訁⑴c深度的各個階段引導用戶操作，從而達成活動目標。以下列舉了運營活動中常見的用戶動機，后續我會從用戶參與路徑出發，盡可能詳細的描述在用戶參與的每一個階段起作用的為動機，以及實現的手段。
大獎帶來的誘因效應
動輒百萬的大獎獎勵幾乎已經成為運營活動的標配，在動機理論中，用戶行為的產生來源于需要，需要導致內驅力，引發行為，從而推動用戶實現特定的目標。當目標的誘惑力很大時，即使沒有內部驅動也能激發行為。這也是眾多運營類活動大獎存在的理由。
占便宜的心理
愛占便宜是人的本性，從心理學角度講，占便宜就像是額外得到的驚喜和獎賞，可以讓人產生滿足感！用戶在這種心理作用下，會為了小利益去做出設計預設的行為，將業務需求設置在‘占便宜’的路徑中可有效提高參與、轉化率。比如在設計中用中獎動態彈幕來強化用戶參與的動機，提高參與率。
有趣和好奇心
人天生具有好奇心，它幫助我們適應不斷變化的環境、發現新的資源，是一種「無法抗拒」的行為動機。在運營活動中，用戶會被有趣的活動頁面，未知的規則設計所吸引，從而開始主動「探索」。這也是用戶參與的動機之一，設計中精致的 UI、有效的頁面信息傳達保證了用戶好奇的有效性。
即時反饋及階段性成就
「即時反饋」是沉迷現象發生的原因。學習之所以痛苦正是因為其反饋鏈路太長，你只有在考試或者應用到所學知識時才能獲得反饋，還有可能是負面的。在活動設計中，每一次用戶操作都會有及時、細膩的反應，可以給用戶帶來精神愉悅，同時設計的階段性成就又給用戶帶來成就感，用戶會不知不覺中在活動中越走越遠。
隨機獎勵的多巴胺效應
人類的本能熱衷于冒險，隨機的、不確定的獎勵能夠刺激大腦分泌多巴胺，帶來愉悅感，從而刺激用戶行為的重復。在活動設計中，常用到這一理論，比如抽獎機制。
所有權與擁有感
當用戶感到他們擁有或控制某樣東西時，會自然而然的強化它的屬性、發揮其價值。尤其是通過適當的付出和自身努力，用戶還可能不合理的高估其價值。在活動設計中，常使用戶通過易實現的行為獲得權益，通過「幸苦操作」強化了擁有感，提升其心理價值，從而促進用戶對權益的使用。
稀缺性與用戶渴望
稀缺性的心理學原理在于人們想要獲得某樣東西的原因僅僅是它太罕見，或者無法立刻獲得。它破滅了人們對情況的控制感，人們會為了重獲控制而采取行動。設計時，可以利用這種心理鼓勵用戶做出期望的行為。常見的有時間限制、權利限制等。
使命感/社交影響/損失規避……
運營類活動中數據和策略思維是保證活動效果最大化的有效手段?；顒有枨筇岢鰰r，即考慮可能的參與用戶細分；活動開始時，考慮引流途徑和引流方式、物料的差異化；活動進行時，根據用戶細分策略化任務推送，根據埋點數據監測積極調整相關設計元素。事無巨細才能確保活動成功。
文章來源：優設
JavaScript基礎知識——JS預解析
js代碼是由瀏覽器中的JavaScript解析器來執行的。JavaScript解析器在運行JavaScript代碼時分為兩步：1預解析、2代碼執行。
預解析
預解析是指js引擎會把js里面所有的var與function提升到當前作用域的最前面。（這里的當前作用域包括：全局作用域與局部作用域）。
預解析可分為：變量預解析和函數預解析
變量預解析：就是把所有的變量聲明提升到當前的作用域的最前面但是不提升賦值操作。如下例所示：
<script>
console.log(num); //結果為undefined
var num = 10;
</script>
//其實際執行過程為
var num;
console.log(num);
num=10;
函數預解析：就是把所有的函數聲明提升到當期作用域的最前面 但是不包括調用函數。如下例所示：
var num = 10
fun();
function fun() { //結果是undefined
console.log(num);
var num = 20;
}
//其實際執行過程為
var num;
funtion fun() {
var num;
console.log(num);
num=20;
}
num = 10;
fun();
在idea中使用jdbc往數據庫里儲存中文亂碼問題
這里使用的數據庫是mysql。
ide為idea.
有時做一些web項目時需要往數據庫里面儲存中文，就是需要用到jdbc往數據庫里面儲存數據時，參數改為中文?？墒莾Υ嫱曛?，打開sqlyog查詢又是???這樣子的亂碼
上網找了很多方法，數據庫的編碼問題都改了，而且統一成utf-8了，但還是儲存時為亂碼。
后面檢查時在sqlyog里改中文又可以正常顯示。
這就說明數據庫上是沒有問題的，應該是連接這塊，于是在連接的url上加入了參數就可以正常顯示了characterEncoding=UTF-8
這里使用的是c3p0的連接池，不同的連接池可以去對應的配置文件中加上參數
在Vue中，用watch來響應數據的變化，示例代碼如下，
第一種方式
<input type="text" v-model="userName"/>
//監聽當userName值發生變化時觸發
watch: {
userName (newName, oldName) {
console.log(newName)
}
}
第一種方式有一個缺點： 就是當值第一次綁定的時候 不會執行監聽函數，只有當值改變的時候才會執行。
如果我們想在第一次綁定的時候執行此監聽函數，則需要設置immediate為true。比如當父組件向子組件動態傳值時，子組件props首次獲取到父組件傳來的默認值時，也需要執行函數，此時就需要將immediate設為true。
第二種方式
watch: {
userName: {
handler (newName, oldName) {
console.log(newName)
},
immediate: true
}
}
immediate表示在watch中首次綁定的時候，是否執行handler，值為true則表示在watch中聲明的時候，就立即執行handler方法，值為false，則和一般使用watch一樣，在數據發生變化的時候才執行handler。
當需要監聽一個對象的改變時，普通的watch方法無法監聽到對象內部屬性的改變，只有data中的數據才能夠監聽到變化，此時就需要deep屬性對對象進行深度監聽。
第三種方式
<input type="text" v-model="cityName.name" />
data (){
return {
cityName:
{
name:'北京',
location: '中國'
}
}
},
watch: {
cityName: {
handler(newName, oldName) {
console.log(newName)
},
immediate: true,
deep: true
}
}
注：監測為對象的時候，newVal == oldVal
此時會給cityName的所有屬性都加上監聽函數，如果屬性較多時，每個屬性值的變化都會執行handler。如果只需要監聽對象中的一個屬性值，則可以做以下優化：使用字符串的形式監聽對象屬性：
watch: {
'cityName.name': {
handler(newName, oldName) {
console.log(newName)
},
immediate: true,
deep: true
}
}
數組的變化不需要深度監聽;
在watch中不要使用箭頭函數，因為箭頭函數中的this是指向當前作用域.
藍藍設計的小編 http://www.syprn.cn