用戶體驗設計的工作不只是應該在項目之初就參與進去，而是很多體驗設計都應該放到底層設計的前面去。這是一個循環的迭代過程，但站在這個過程前面的應該是用戶使用的交互流程設計。
 
1、”還在考慮一些底層的邏輯關系問題，暫時不要去考慮交互設計的事情”、”底層的邏輯架構，在很大程度上決定了發展方向，而表現層修改的成本不高”、”我們的底層邏輯不是這樣的，這里的交互設計不能這樣做”。
上面這些話很有意思，這些現象也很普遍。
我相信大多數公司現在都是這種情況：產品負責人或架構師(或叫系統工程師)先把地層邏輯和結構設計好，然后才會去具體的體驗設計。
2、多少年來我們都在這樣做，我們甚至認為一定應該這樣。就好像在日本人沒有設計出來很輕巧的家電之前 美國人一直以為家電一定要放到柜子里面做成家具。
現在，我們應該整體的思考一下：產品設計的過程是不是必須這樣？ 這樣是不是一定合理？
3、不。
4、產品的存在是因為需求，用戶因為需求才去使用產品(無論這種需求是主動還是被動的) ；用戶通過界面達到和系統的交互 從而完成”需求”。
5、可以肯定地說：”用戶不知道也不關心系統底層的邏輯架構是什么？ 他只知道呈現給他的界面和他體驗到的交互過程是什么。”
6、”用戶的需求決定產品的方向，用戶的使用和交互過程決定了產品的設計“。
（記住：并不是”產品的設計決定用戶的使用和交互過程”。）
7、在用戶體驗設計領域有很大一部分人在做”交互設計”的工作，這些工作可以大致的描述為：
“我們在了解產品思路和用戶群特征以后(用戶研究)，會作一些典型用戶的角色模擬（角色設計）和使用情景模擬（情景設計），通過情景的再現演示來總結和逐步細化用戶使用中的各種交互需求（任務分解），最后用流程圖和線框圖的形式把設計結果表現出來”。
8、需要說明的是，交互設計畫出來的流程圖是”用戶使用流程”，而不是”底層業務邏輯流程”。
雖然他們很相近，但本質不一樣：一個是從用戶的角度出發，一個是從技術實現出發；使用流程圖是在描述用戶的交互過程和需求，底層業務邏輯流程是為了滿足用戶的需求。
把用戶使用流程演變成底層業務邏輯流流程，是在滿足用戶需求；把底層業務邏輯流程演變成用戶使用流程，是在想當然的認為用戶一定會按照你的設計是用產品。
9、很明顯”先設計底層業務邏輯流程再考慮交互流程的設計”是標準的工程師思路，這和整個行業先前都是工程師背景有關。
最后會發現：產品是給技術實現設計的，而不是給用戶設計的。（雖然做底層邏輯架構的人也會以為他們是在給用戶設計，但不可否認他們的特長不是這些。）
10、這種產品設計過程也無法催動技術的提升，而且經常還會導致：
用戶體驗設計師做了某些好的必須的體驗效果時，得到反饋 — “我們底層的邏輯不是這樣的，這個我們實現不了。只能放棄這部分的體驗”、”用戶為什么會這樣做呢？ 按照我們的設計他們不會這樣做呀！”、”按照現在的底層邏輯，這樣的交互流程設計作不了，不要考慮了…”等等底層架構規定了體驗設計的現象再普遍不過…
11、記住：用戶使用的交互流程是底層業務邏輯流程的需求，而不是底層的”表現”。
所以，用戶體驗設計的工作不只是應該在項目之初就參與進去，而是很多體驗設計都應該放到底層設計的前面去。這是一個循環的迭代過程，但站在這個過程前面的應該是用戶使用的交互流程設計。
我建議：作產品需求的PM們先去作一下產品的交互設計，然后再去考慮底層的業務邏輯和架構。

原文地址：http://uicom.net/blog/?p=575