網頁制作poluoluo文章簡介：本文，我主要想表達的意思是：交互設計師一多半的時間其實是在做邏輯分析，從業務邏輯到產品邏輯的遷移；然後另一部分時間是在做按鈕的擺放。
本文，我主要想表達的意思是：交互設計師一多半的時間其實是在做邏輯分析，從業務邏輯到產品邏輯的遷移；然後另一部分時間是在做按鈕的擺放。（注意，我說的是部分，不是全部！）在這兩個過程裡需要注意的最重要的問題就是不能懶！（京東商城的設計完全不具備交互性，不做分析）。對照“看人下菜碟”的說法，我們來看看哪些是可以改進的。
1、如果用戶沒有登錄（注冊），用戶是否需要去點擊“兌換”OR“評論”按鈕？答案是否定的。這個時候用戶最需要什麼交互？是登錄！
當然，這裡會存在一個用戶是否需要注冊的行為？我個人認為，在積分商城這個產品場景裡，注冊是存在幾率很小的行為，完全可以放到登錄的引導頁面裡去。（積分兌換的前提是注冊用戶，且在網站上發生了用戶行為產生過積分才能兌換，就算是注冊送積分也是需要先完成整個注冊過程的 吧）
2、如果用戶登錄但積分不足，用戶最需要什麼交互？了解積分還差多少，如何獲得更多的積分。其他的交互行為對這類用戶來說都是多余的。
3、 如果用戶登錄且積分足夠，用戶最需要什麼交互？兌換。這個時候用戶是否需要“點評”交互？我覺得不需要，還沒有兌換使用，怎麼點評？“點評”這個交互行為 應該出現在用戶兌換之後再次浏覽到這個物品的時候。
下面，是我對積分兌換這個交互模塊做的改進。
1、如用用戶沒有登錄（注冊）：不做用戶持有積分判定（當然，也沒法判定）；不出現“兌換”按鈕，他的位置由登錄提示取代。
2、如果用戶登錄但積分不足：做用戶持有積分判定，同時提示積分差額；不出現“兌換”按鈕，他的位置由積分不足提示取代，可夾塞廣告，如何獲取積分。
3、如果用戶登錄且積分充足：做用戶積分判定；出現兌換按鈕。
讓我們再來重復一下那句關於交互與用戶體驗之間的關系的論斷： 優秀的交互設計應該是用最低成本的交互，最愉悅的滿足用戶的需求。
那麼，什麼是最低成本的交互？我的理解，用戶需要的時候才出現交互，用戶用不到或者不能使用的時候就不出現交互；當用戶需要交互的時候如果能二步完成就堅決不搞成三步。用一句通俗的話說就是：看人下菜碟。
在大的層面上，在對產品進行需求分析的時候我們會考慮不同的用戶群，他們對一個產品的使用需求和使用方式都是不同的，在這裡我們對用戶進行了劃分。我們把這個思想堅持到交互分析裡來，對於不同的用戶在不同的使用環境下需要的交互方式也是不一樣的。
之前，順網UED的同學們對用戶交互行為的分析提出了“交互表格”的方法：劃分2個緯度，頁面元素和用戶行為。最左邊一列是頁面可見元素（包括光標）；最上面一行，是用戶的行為（盡量按操作流程）。中間交叉的為場 景描述。通過這種枚舉的方式可以詳盡的列出所有可能存在的交互行為，然後我們對每個交互行為再劃分出不同的交互方式。
比如：我們要做一個積分商城的積分兌換交互。經過分析、合並，我們知道可能存在這麼幾個場景：①用戶未登錄（注冊）；②用戶已經登錄，但是積分不足；③用戶已登錄且積分足夠。
下面，我們選2個電子商務方面的代表網站（京東商城VS支付寶）來看一看他們怎麼處理的：
京東商城的積分商城頁面裡，不論你是否登錄（注冊）、積分是否足夠，積分兌換詳情頁的內容永遠保持“一致性”。當未登錄點擊兌換的時候會跳轉到登錄頁面；當登錄後積分不足點擊兌換的時候會彈出窗口提示積分不足； 當登錄且積分足夠的時候，會顯示兌換成功。
支付寶的積分商城裡對上述問題做了改進，我們看到支付寶的設計師對業務邏輯做了足夠的分析：先對用戶登錄行為做判斷；把用戶所持有的積分放在了所需積分的下面；積分不足的時候給出提示。
那麼，這些足夠了嗎？不，我覺得還應該有改進空間
（左：支付寶的積分兌換交互；右：我的修改版本）
當然，這裡只是一個簡單的交互條件限定，還可能會有更多兌換限制，從而出現更多的交互行為，比如：注冊多久的用戶對可兌換、實物兌換 的時候填寫收貨地址，發貨時間段（這個很重要！）、可兌換的數量、等等。
對於任何一個Web頁面而言，都必須承擔著2個功能：順利的完成本頁面的任務、流暢無誤的進入下一個任務。對於如何實現這2個功能，我的土方法就是：有的時候我需要強制你專一的完成本頁面的任務，不給你回路；如果這個頁面上你要完成的任務太多，我可以考慮幫你拆解。
比如，在注冊頁面除了注冊表單什麼都不放，什麼面包屑導航全部去掉，甚至LOGO也要搞成不可點擊的，這些都是為了“強迫”用戶完成本頁的任務；用戶在後台錄入產品的時候，可以考慮對產品的屬性進行分塊，然後把錄入頁面拆開（當然，你不能無限制的拆分！）….
我個人的感覺是，之所以交互過程被搞的很籠統，大部分原因在於交互設計師很懶。懶的做分析，認為只有流程能走通就OK了，不願意繼續細分；懶的做交互Demo，認為這些給技術說明白就可以了。前幾天做某個模塊的時候我偷了個小懶，在DEMO裡把工商銀行寫成“工行”，然後在PRD文檔裡做了詳細說明。今天再看測試，好家伙，還是“工行”！搞的我羞愧難當，這個問題的責任完全在設計師本身，設計師懶就不能指望技術勤快！當然，這裡還存在一個原型圖的制作問題，改日再談。
PS：為了迎合“微”時代，我以後的博客都會以“本文想表達的意思是….”開頭，看完導語如果你有興趣可繼續，如果覺得扯淡可以略過，省的搞到你讀著傷腦筋， 我想怎麼回復你的評論麻頭皮…