網頁制作poluoluo文章簡介：有感用戶體驗規劃與系統實現.
有感用戶體驗規劃與系統實現
最近一直在“深山老林”中修煉“支付寶新版收銀台”,經歷了白板設計，視覺設計，前端開發，前後端聯調各個階段。點點滴滴……
重點談談對交互設計的感受吧：個人覺得設計師應該好好的思考一下收銀台的設計粒度，在我們不能確定用戶是否會遇到某類問題時，不妨放開懷抱，將粒度切的大一些，如果一味的把自己當作用戶，患得患失，其結果只會把自己的產品綁成個大粽子，這樣很可能導致在不明確具體問題的情況下，設計粒度過細。到後期再想優化，就舉步為艱了。
個人非常反對，設計師總是以“我覺得用戶可能”，“我覺得用戶一定”的論調在設計討論中去說服需求方，“覺得”只是一種推測，既然不能確定用戶會遇到你假設的問題，那為什麼不能先把設計粒度切大一些，等產品上線，觀察分析用戶使用的情況後，再對症下藥呢？究其原因，是因為設計師太怕用戶受挫，關心則亂下失去了一些設計原則。我想，在不影響用戶正常操作的情況下，對於一些假設的受挫場景，不妨放手一試，用戶不犯錯，你又怎麼知道自己的產品問題在哪裡呢。知錯而改之，總比一輩子都活在自己“覺得”的世界裡強。更何況未必錯！
說了這麼多，其實只是想引出一個話題，作為一個優秀的設計師，必須學會“如何均衡用戶體驗和系統實現”，要知道你設計的是一款產品，你必須對他的未來有一個規劃，而這個規劃，用戶體驗和系統實現之間的關系是非常微妙的。常常聽到很多設計師再抱怨“我想到個很好的體驗改進點子，但是開發告訴我系統實現不了，郁悶！”有沒有想過為什麼？我想很大一個原因就是因為前期設計粒度過細，到後面瓜就不好切了~~嗚呼哀哉！總之一句話：“該有的體驗一個也不能少，該有的原則同樣不能少！”粒度要怎麼切，很有學問，需要在不斷的實踐中去體會。
說到如何均衡體驗和系統實現，不妨拿新老收銀台做個比較，個人覺得非常有說服力,我們從老收銀台現有問題著手分析一下：
如果按上圖(老版)設計方案，當新加入一個資金渠道，並且該資金渠道又支持支付寶賬戶余額補支付功能，那麼你的系統實現成本就略嫌尴尬了，你會發現，在新增的這個支付渠道TAB下和余額TAB補支付的情況下，你都必須重復渲染這個資金渠道的實現代碼（譬如：圖中codeWidget部分網銀支付渠道的實現代碼），雖然我們可以把這塊抽成一個公用的組件widget統一調用,但是無可避免的要設置一些參數去實現一些個性化的顯示。並且頁面渲染時,會重復渲染,新增加一個資金渠道就等於X2的代碼渲染量,久而久之系統會越來越臃腫,性能也隨之下降,so bad,簡直就是一個惡性循環……
看到這裡其實我們可以看到，導致惡性循環的關鍵所在：支付寶賬戶余額付款，他存在與其他支付渠道組合支付的應用場景，而他的信息層次和其他支付渠道是同級的，非常簡單的一個層次組合邏輯，還不明白？想想，好好想想……
所謂對症下藥，那麼當務之急，我們要先把收銀台的信息結構梳理清楚，可以將支付渠道按支付寶賬戶和非支付寶賬戶支付渠道兩個緯度來劃分，我們來看看這麼做的好處：
首先，從體驗上看，我們將支付寶賬戶余額的顯示區別於網銀，信用卡，比之老版，我們加強支付寶賬戶概念的同時，使得各類支付渠道的層次感也更清晰了。這對於培養起用戶對支付寶賬戶的認知是非常有意義的。信息結構清晰了,直接受益的就是系統實現,可以看到新的設計方案大大降低了後續資金渠道接入的復雜度(由於支付寶賬戶余額始終在用戶的視野內，他可以很方便的與各類支付渠道進行組合支付，同時也解決了實現代碼重復渲染的尴尬局面)。可謂“雙贏”！
如上說述，可以看出設計規劃在產品設計前期是非常最要的，設計師們應該站的更高一些，看的更遠一些,，這樣設計出來的產品才內外兼修……
僅以此篇祝新版繳費還款收銀台發布順利，和一群敬業的同學們一起工作，讓我很愉快！