sprint
"羅馬不是一天建成的。"
"千里之行，始于足下。"
將一個大問題，拆解成很多小問題，一點一點實現并驗證可行性，一個版本一個版本改善，用迭代的思想輸出成果。越早交付價值，就越早獲得回報。市場瞬息萬變，如果一定要把所有問題全都解決才能上線，結果就是遲遲無法上線，胎死腹中。
就像開發會交付一些帶有BUG的程序一樣，設計也會產出一些帶有BUG的設計。評估一個設計結果是不是可以帶著BUG交付，有兩個參考因素：設計是否解決了需求，BUG的嚴重程度。
當然，無論是開發還是設計，在前期應該盡可能多方面考慮周全，盡量減少BUG的出現。
ratio
常見、不常見，就是比例。在一些書上的叫法是“關鍵路徑”和“邊緣場景”。
工作重心應該放到“關鍵路徑”。不能因為處理邊緣場景，而降低關鍵路徑的使用體驗。比如不能因為有一些用戶不看活動細則就報名參加活動導致一些問題，就讓所有用戶首次進入時就先收到一個大大的彈框描述活動細則，首屏一個不友好的彈窗會極大降低活動的轉化率。
同時，不常見的場景在設計中應該是要避免出現的。以登記出生日期為例，如果采用文本框，用戶可能會輸入無效的日期，而如果采用下拉框，就能夠避免這種邊緣場景的發生。
大部分用戶和小部分用戶，也是比例。想獲得最大的收益，就要把重心放在大部分用戶中。這在企業產品的設計中也適用，一個高凈值客戶的需求，不如一個典型用戶的需求重要。因為$100 x 1 = $100，$10 x 50 = $500，該選哪個一目了然。
priority
所有的task都可以分出輕、重、緩、急。接到一個task不是馬上去做，而是要先規劃一下什么時候去做。這跟GTD的理念有點接近，新任務是要先放到待辦事項中的。接到一個任務就立馬放下手頭的事情去處理，只會讓自己的時間碎片化，什么都做不好，還越做越多。
不同的ratio也會產生不同的priority。你的目標用戶群中很小一部分用戶才有的需求，就是低優先級的。
system
一個系統，各個組成部分是相互關聯的，牽一發而動全身。交互設計就是在構建用戶的使用環境，是一個完整的系統。首先要考慮的，是“結構層”，之后才是“框架層”（具體頁面）。在一個頁面增加了一個按鈕，隨之就會產生一個新的頁面或者新的狀態，同時要確認按鈕可用的前置條件，點擊后的效果，對后續流程的影響，一切都是相關聯的。
這跟建筑設計很相似，都是系統性工程。一個辦公樓三層樓高的LED廣告屏的位置下移了一點，廣告屏的檢修通道就會隨之移動，盡而影響三層樓的平面布局，家具布置、采光、交通、消防、管道都可能會受到影響。
clarity
less is more.
你想表達的東西越多，別人就越聽不明白你要表達的核心概念，因為傳遞了太多干擾信息。初階設計師很容易犯的錯誤就是炫技，采用各種各樣酷炫的效果，導致最重要的信息被干擾而無法傳遞給用戶。
data
收集數據，分析數據，評估設計，優化設計，這才是一個良性的循環。沒有數據，大家都是睜眼瞎。
用戶體驗的提升一定會帶來某些數據的提升，這些提升可能是轉化率的提升，也可能是凈推薦值的提升。
在團隊有分歧時，最容易解決分歧的工具也是數據。
code
設計要考慮開發可行性，了解一點代碼可以讓你高效率地利用已有工具，很多交互細節已經被現有的程序框架規定好了，不需要再特別注明讓開發同事幫忙實現。
比如在網頁中，表單是在標簽中，當你在這個表單的任意一個輸入框中按下回車時，會自動調用這個中的submit按鈕。
再比如，iPhone中一個網頁的輸入框的type被設定為tel，當其獲得焦點時，iPhone會自動調起只能輸入電話號碼的數字九宮格鍵盤。同樣的還有email、number等。
其實這就是采用了一更大范圍的“組件庫”。
另外，交互細節有時也會體現在算法層面。比如Google Instant，一堆結果以什么樣的規則呈現在面前，讓用戶滿意的結果怎么出現在最前面，背后是靠程序算法計算出來的。
---
> 微信公眾號：三角規（ID：coding-designer）
