《用戶體驗要素》澄清了 UI 原型設計中看不見確感受得到的那一層

表現層：

其它4層基本弄定的情況下， 再進行美化設計， 從美學角度來佈局， 用色等等， 這1層基本是終究產品內含， 所以包括的東西也最多， 而光靠美工 PS 是沒法達成的；

PhotoShop 可使它更美觀；美觀是用戶體驗的1部份；

框架層：

大體的介面流轉和介面元素選用以顯現特定資料並與使用者交互， 這1層除不太美觀漂亮外， 基本該顯現甚麼資料、該接收甚麼樣的使用者交互要求等這些結構層的內容， 在這1層都包括並體現了， 然後這1層更重要的是， 把這類資料的種類和使用者的要求， 和要求與資料在使用者與系統交互之間的各種體驗具體化，

結構化， 流程化， 產生實體地直觀表現出來， 包括介面元素、資料組織、交互流轉、回應結果走向等等。

Axure 可以顯現出交互的流程並配以相對真實的資料和介面元素和跳轉關素；交互也是用戶體驗的1個很重要的部份；

結構層：

框架層的很多東西都源自這裡， 如果沒有這1層的內容， 你會發現你想用 Axure 畫出個清晰的東西來， 很難！不知從何下手， 即便下手了， 也很散亂， 前後錯位。 所以， 可以這樣描寫， 框架層是驅體， 那末結構層就是靈魂， 只有有靈魂的驅體， 才是靈動的、有生氣的、通情達理的。 這1層更多斟酌的就是這些靈魂的東西， 具體到該給用戶哪些功能來用， 哪些資料需要處理， 顯現出來哪些資料，

固然僅此而已， 而不需要更具體化的交互的介面元素， 資料顯現的介面元素， 但交互的進程確是要清晰可見的只要你能按現實中的思惟方式推演得出， 順暢且通情達理， 那末這就是可行的， 否則， 需要進1步考量。 就如1個人在做1些事情， 這是框架層看到的， 如果細揣摩， 就會發現， 這個人做事情是有條理的， 這個條理就是結構層需要解決的事情， 至於姿式動作是不是優美， 就不是這1層該細化的事情了。

OmniGraffle、Visio 這1類工具能畫流程圖， 流程圖就是1個業務流轉關係的邏輯思惟進程， 相對抽象， 但確主載著利用的顯現和回應能力， 這是1層看不到的， 確能感受得到的用戶體驗部份， 比猶如樣1個資訊， 你是需要使用者點了好幾層， 翻了好幾頁才找到，

並輸入1大堆本可以自動生成提供， 最少可選的資料， 還是簡化這些， 僅讓使用者輸入必要的內容， 這個確決定著後續的局勢發展， 雖然看不到， 但這些內容肯定後， 指點框架層的時侯， 就會被看到其作用的結果， 雖然它本身只能感受得到， 確看不到。 。 。 。 。 。

範圍層：

這1層可以叫做需求的邊界界定。 常常很多專案失敗， 就是由於需求無邊界， 用戶1再地提出不同的新需求和對原有需求的變更， 終究也弄不清到底要的是啥了。 這時候侯需求的邊界界定很重要， 當前只完成這些任務， 再有新的可以提， 留到下1個版本中升級完善， 或變更也能夠， 但只能在某些特定的範圍內來做， 簡而言之， 界定了範圍， 接下來的工作目標， 就是這些界定的需求，

而且這些需求也是經過1系列討論、研究肯定為最重要和緊急的。 在實際開發進程中， 也一樣需要遵從範圍層所界定的內容,才能使開發工作可以量化並按時完成交付使用， 另外， Scrum 敏捷開發中， 每個衝刺也界定了這1次要完成的需求範圍或需求複雜度， 這都是非常重要的。

這1層使用的工具可能就是頭腦了吧， 或像 XMind 這類思惟導圖的工具會比較有用吧。

戰略層：

這1層， 固然離不開出資人的考量， 首先是這個需求是不是切實存在， 用戶群體的廣泛性， 最重要的是， 利潤點是不是公道、豐富， 額外還要考量， 環境是不是具有， 就如當下， 基本每個人都在拿著1部 Android 手機， 而 iPhone 相對就小眾1些， 但確是高端人群， 所以這些都是這1層需要考量的，

如果不斟酌到這些， 早些年， 誰也不會傻到， 給每個人買1部 Android 手機， 然後開發利用求他們下載來用， 這純屬笑話， 但笑話中確無不流露現實環境狀態的重要性；再比如 JAVA 語言的發明， 在當初的環境下， 確切沒法到達其最初目的， 後來轉戰 Web 1舉成名， 而今在 Android 上， Java 終究達成了其最初的設計意圖， 機上盒和便攜裝備上的開發利用。 總之， 戰略層， 決定了方向， 方向如果錯了， 後面做再多也是錯的， 或有時會成功， 那不是偶然， 而是下面各層履行中， 不斷對戰略層進行了修正， 這其實還是戰略層的問題， 其實不是其它層的， 只是你會看到其它各層中在貫徹履行而已， 其實不會改變這1層面；但確會存在， 各層的回饋下， 戰略層不斷修正以使其它各層可行、公道。