UE設計

UE設計，也有人叫做UX，其實就是UserExperience的縮寫。用户體驗設計，就是最大程度上是網站的功能設置界面設置更加人性化，方便用户，滿足用户體驗基於以用户為中心的設計原則，採用焦點小組、可用性試驗、用户測試等易用性研究方法，對用户在使用產品過程中的體驗感受進行正確準確的評估、充分認識用户的真實期望和目的、對用户操作流程的預設設計進行修正和有效的改進，保證產品核心功能及用户任務需求的平衡，促進人機界面的協調工作，提高產品易用性減少產品BUG。

用户訪談的好處，是增強產品和用户之間的聯繫，就像一個黑匣子。對用户的訪談，就是一個試圖打開黑匣子的過程。打開了黑匣子，我們就可以改造他們之間的路徑，從而使兩者無縫融合。就像是研究DNA，對結構的研究可以重塑基因。反映到產品上，就是我們可以以用户的心理模型去創造產品，或者是用富於創造的產品去影響用户。

需要解決用户的需求時，對於相關產品的研究就會作出幫助。如果説對用户的需求，可以對產品有縱深的認識。那麼對產品的分析，有利於橫向去加深對產品的理解。在分析期間，會發現產品各功能間，產品和用户間千絲萬縷的聯繫。

事實上，因前面工作的鋪墊。只有瞭解了用户，瞭解了相關產品後，定位才會更加明確。最初時，時時需要一個定位，卻感覺模糊，在此刻，就清楚許多。

基於對用户和產品的分析，此時會提出一些新的功能。從產品長遠的發展，對用户使用的引導，以及易用性綜合考慮，慎審地推出每一項功能。

產品的印象開始在腦海裏浮現。此時，將信息注入到產品結構中去。導航、管理等是很重要的幾項，需要格外小心。另外，不同的頁面有不同的信息，以及頁面與頁面間的信息跳轉，甚至是產品間的跳轉，每條信息都需要經過審核。如果對產品沒有幫助，或者對用户是負擔，都不要向里加。

就個人而言，在頁面原型階段，除了用visio來畫結構圖，還是不自覺得要用ps去協助找感覺，這個過程，對自己而言也是一個迭代的過程。當然，之前那些階段，使整個產品的結構都在腦海裏快成型了，這個只需要把它落實到紙上。原型的確認，需要堅持。如果是你自己做了這個過程，而且每一點都是經過思考的。那麼就去説服來自各方的反對。事實上，你要相信，人們相信思考的價值，只要你付出了，就有回報，最怕沒有付出天天在那裏抱怨。

不必多説了。可能會比較多icon字體，區域的劃分，模塊的統一，風格的設定等等。

一、提交需求彙總，明確改版目的

根據領導和各主編的意見，劃分各自權重，制定更改初步方案。

二、發現並總結問題

分析數據（如無數據分析圖示可採用抽樣分析的方法）、閲讀相關文檔、統計反饋信息、分析相關統計圖標、簡單的測試評估，從而發現和總結產品存在的問題和弊病。

三、確定目標，提出預期效果

對新需求流程和功能方面的用户使用性方案進行分析和監測，優化模塊佈局和邏輯流程。提出改版後需要的預期效果，做成頁面交互示意方案。細化內容和技術需求，寫出詳細輔助説明文檔。

四、討論設計原型，演示概念和想法

同相關領導，以及商業方面的專家、市場人員、質量保證、等各個部門的溝通，確保設計不會出現用户羣公司等各方利益的偏頗，還有理解不到位造成的實施方面的問題。

五、人員調度、時間計劃

確定人員分工及詳細的業務流和相關階段性時間計劃。

六、同步產品設計

配合並監督設計和製作部門工作，符合內部設計流程和標準，發展一些重要附加值的概念，修訂產品。

七、測試階段

同質量控制部門溝通，提供在測試階段需要的清晰理解。

1.數據提煉：

數據分析及分析報告，對產品進行易用性評估並出具報告。

2.用户測試：

確定產品功能核心（也就是“預設用户體驗目的　即用户任務”），設定用户體驗目的。

3.產品評估：

對現有產品用户界面及邏輯流程評估，引導產品創新。

4.用户分析：

分析特定目標用户羣特徵和網站使用習慣，確定我們有什麼樣的人，以及我們希望有什麼樣的人。

5.制定規範：

內部設計標準和流程。

首先要獲得運營人員的支持，如果他們不參與進來，整個過程會很難做。通過不斷的交流，他們可能會很樂意一起做用户訪談等的工作。這個看你的溝通能力了。然後獲得團隊其它同事的支持。需要不斷展示階段性成果，大家會慢慢認識到ue工作的作用。有過這麼一次以後，團隊裏認識到這個職位的職能，以後就可以開展更深入的工作了。

前面一段時間的思考。10%的用户是活躍的，是領袖，是流行者。而80%的用户都是可引導的，產品設計成什麼樣，用户就會是什麼樣子。我們幫用户創造價值，定位在挖掘用户深層需求去做創新，而不是表面性的“用户説一，我們做一”。

UE=UserExperience=用户體驗。

用户使用流程的交互設計是站在產品和體驗兩個角度，更合理的進行產品設計。即保證完整的業務邏輯和產品利益，又用最小的交互成本讓用户完成任務；“界面呈現的交互設計”更多是站在易用性的角度優化“人機交互過程”，讓交互成本再小，易用性更強。

在成熟的團隊，或者交互更復雜的產品中，有人專門做偏向於產品的“流程交互”，有人做偏向於UI的“頁面交互”更合適些，因為你經常會發現你的產品人員不懂界面設計，你的界面設計人員不能產品流程…

還是那句話：團隊中如何分工無所謂，有什麼樣的職位無所謂。不一定非得分開“流程交互”和“頁面交互”，但這些事情都是要有人做的，分不分開要看你的實際情況。