用戶體驗是每一個產品經理必須要思考的問題，也是一款好產品的取勝關鍵。那么怎么樣才能做好用戶體驗，提升產品呢？讓我們看看筆者是怎么說的：

一、糟糕的用戶體驗

生活中總是會遇到各式各樣的產品，而我們每一次使用這些產品時都會產生體驗。有很多產品，會用得很爽。而有些產品，就是反人類的。

比如這個插座，充分節省空間的設計也是醉人，緊緊將兩個插頭挨在一起，保證你同一時間內不可以同時用，超級省電，呵呵。

有時候真想把設計師找出來打一頓，問問他是怎么想的，竟然設計這種反人類的東西出來。很無奈，現實中就是有那么多產品，使用的時候讓人極其不爽。而一旦使用不爽的時候，除非你家是壟斷機構，否則我一定換另外一個能讓我爽的產品。

當企業意識到產品不是自己生產得爽就行，還得讓用戶用得爽的時候，企業就意識到了用戶體驗的重要性，也因此開始去研究怎么樣的產品設計會提升戶體驗。

在互聯網時代，有一個人提出了：網站類產品應該從幾個方面來考慮用戶體驗，這也就是今天在互聯網界非常知名的《用戶體驗要素》。

二、用戶體驗要素

今天我們都知道了，網站類的用戶體驗要素設計分了五層：戰略層、范圍層、結構層、框架層、表現層。但每一層具體什么意思，可能就不一定記得了。

首先，我們來說，為什么要分層？

我們倒過來想，網站類產品設計出來后，用戶接觸到的肯定是一個網頁，而網頁這個產品是如何交付到用戶手里，讓用戶產生體驗的呢？

如果我們只看到——網頁是許多人共同的努力，伴隨著大量的分析、研究、決策，那么我們并沒有真正認識到事情的全貌。

將整個事情拆分成小塊一塊一塊地看，我們才能更清晰地了解到網頁類產品是怎么設計出來的。

用戶對網頁的體驗不僅僅是網頁顏色怎么樣，還包括網頁信息、網址好不好記、網名好聽還是不好聽等等。

顏色是屬于視覺方面的體驗；而網頁信息、網址、網名等屬于信息方面的體驗；網站按鈕則屬于功能類的體驗；為什么這個功能放這里，為什么網頁有10個頁面，9頁為什么不行，這些又屬于網站結構方面的設計。

就這樣把一個網頁抽絲剝繭全部拆分后，形成了我們今天看到的用戶體驗要素五層：

1. 戰略層

戰略層包括兩個方面：一個是產品目標，一個是用戶需求。

產品經理必須分析用戶能從這個產品中得到什么，也就是產品的用戶價值是什么。同時，產品經理要對自己的產品設定產品目標，可能是商業價值也可能是別的東西。如果開發一個產品沒有目標，開發個啥呢。

產品目標，就是我們能從這個產品中得到什么？

比如有人會選擇商業目標，比如實現一個億營收，OK，也沒問題。

另外呢，我們也要宣傳自己的品牌，讓別人記住我們的品牌，建立我們的產品成功標準。

用戶需求，就是用戶能從我們這里得到什么價值？

可以通過用戶細分建立不同的用戶群體，然后進行用戶研究創建用戶角色，形成用戶故事來確定我們的目標用戶和用戶需求，進而去分析。當我們滿足用戶需求的時候，目標用戶就獲得了這樣一個產品價值。

而對于產品經理而言，這一層的工作實際上就是調研背景、目的以及需求分析。簡單地說，就是我們要在什么背景下做什么事情；達到什么目的；用戶有什么需求、我們有什么需求，這兩者之間如何平衡。

這一部分就是用戶調研、需求分析的工作流程。如果形成一個文檔，也就是商業需求文檔和市場需求文檔，即BRD和MRD。

2. 范圍層

定義好了產品目標和用戶需求，那么緊接著我們要做什么呢？

我們根據用戶調研知道了用戶有什么需求，而用戶需求非常多，我們到底要做什么不做什么，要提供什么產品來滿足用戶的需求？

當我們帶著這樣的思考去想問題的時候，戰略層就進入到了范圍層。

已經確定好一個范圍了，接下來的時候就是要在這個范圍里干了。對于產品經理而言，就是要把之前所有的工作形成一個文檔記錄下來，保證在未來開發的過程中，避免因為模棱兩可的時候而重新復盤整個產品。

這里的這個文檔實際上就是產品需求文檔PRD。

產品需求文檔里應該包括哪些東西？

首先，我們要思考——針對用戶的需求，我們應該提供一個什么東西來滿足用戶的需求，讓用戶獲得產品價值。這一步是定義需求的關鍵步驟。當需求定義清楚之后，列成一個需求list，也就是需求清單或者需求池，很多產品經理會有一個Excel表格來做這個需求清單。

緊接著，考慮需求的優先級排序了，先做什么后做什么，明確我們的項目中所要進行的全部工作。最終，形成一個產品需求文檔PRD。

3. 結構層

當我們有了需求文檔的時候，就要開始很具體地設計一個產品的流程了。對于功能型的產品，主要是考慮清楚系統如何配合和響應用戶的行為。

比如支付產品，用戶點了收款，然后沒有收款二維碼，這是不行的。而對于內容型產品，主要考慮的是如何合理組織有效的信息；比如現在流行的feed流，這些內容都是怎么組織起來的，能夠讓用戶看到他們想看的信息。

設計一個產品，尤其到了交互設計這一階段，首先要解決的是兩個問題：

1. 如何組織產品中的頁面
2. 如何組織頁面內的元素

也就是這個產品要多少個頁面，每個頁面上都怎么樣組織元素。這就是交互設計這個環節要考慮的事情了。一般會先形成一個概念模型，設計好一個用戶通道，然后在用戶操作的路徑上設定好限制——萬一用戶操作錯了，要有提示，或者根本不給用戶犯錯的機會。

最后，要讓用戶理解我們的設計、如果用戶不知道我們的設計是干嘛的，那么做出再好的東西，也無濟于事。

而對于內容型產品，首先是選定一個合適的內容展示結構，一個合適的結構可以讓用戶一眼就看到他想看的內容，而一個好的內容也都是結構化呈現的。

總之，內容也一定是需求導向。如果提供了沒有用戶看的內容，可想而知用戶就不來了。

那么，這一層對應的是產品經理的哪一部分工作呢？——是業務流程圖的繪制和功能框架圖的繪制。

給大家看看兩個圖具體長什么樣子：

功能框架圖

業務流程圖

ps：有人說產品結構圖和產品框架圖都差不多，我通過查資料、搜集各種解釋后發現：結構圖一般是PPT做的做匯報展示用；框架圖一般是思維導圖做的，放在需求文檔里。這倆張圖本質描述的是一個事情，都是說產品具備哪些功能點。

4. 框架層

當我們設計好用戶的路徑、組織好產品中的頁面、確定需要幾個頁面，然后確定好這個頁面里面有什么元素的時候。接下來，我們就需要具體地去設計這些元素在這個頁面里的位置，以及這幾個頁面的前后關聯了。

在設計這些頁面和元素的過程中，不可避免的是文案。用戶很多時候都是靠文案來理解你的產品功能的，因此信息設計（文案）在框架層這里要著重注意一下。

文案很重要的，它是產品經理傳遞想法給用戶的關鍵路徑。很多時候，用戶面對的是一個不會說話的產品。而文案，是產品經理為數不多的能夠用語言和用戶溝通的方式。

對于功能型的產品，還有一個點是界面設計。當用戶操作了功能按鈕、操作了頁面元素之后，頁面要給用戶什么樣的反饋。這其實就是讓用戶擁有做某些事情的能力。

而在內容型的產品里，這個設計就變成了導航設計。允許用戶在各種內容之間穿行，也就是讓用戶擁有去某個地方的能力。

在設計的時候，有兩個準則：

一個是習慣，不要挑戰用戶的使用習慣。很多設計師會有一種想法——要設計一個新的東西。這個新東西如果讓用戶喜歡，那么一定是新的里面帶著大量舊的，用戶從舊的熟悉的東西里面發現有一點點新奇，這個是用戶喜歡的。而全新的東西是在挑戰用戶的認知，用戶對于一個不理解的東西會很有抵觸。所以，設計不要挑戰用戶的習慣，更不要去挑戰用戶的認知。

另一個是比喻，恰當地使用生活中的事物作為設計的比喻。比如超市的購物車被
比喻成了各大電商的購物車標識，這個設計很好地借鑒了生活中的常識。而如果你設計了一個非常浮夸的標識，用戶根本不知道是啥，想想這個用戶點擊量也不會提高。

5. 表現層

最后，我們還有表現層。在這里所有的產品的關注點都是一樣的——為最終產品創建感知體驗。

用戶對互聯網的產品，絕大多數都是通過視覺來感知到的。所以這一層對于互聯網產品而言，更多的就是視覺設計。

這里面包括了幾個準則：產品內部一致性，避免支離破碎感；同時，視覺設計對于重點地方要有對比，形成自己的視覺模型、風格指南，能讓整個團隊、整個產品都保持一致。這里不做過多贅述，視覺設計有一整套的邏輯，以后給大家分享。

這部分是由產品經理和UI設計師一起來完成的。在實際的工作流程中，UI設計師其實是產品經理在視覺上的執行者。本質上，產品經理要自己想明白，用戶需要個什么東西。憑著感覺說這個好看、這個不好看是不行的，感覺不靠譜，得要有邏輯。

二、總結

對于產品經理而言，在用戶體驗要素這方面的設計，其實就是產品一系列工作流程的外在體現。各種各樣的決策堆積起來，最終交付到用戶手里形成用戶體驗。

戰略層，確定產品目標和用戶需求，這是PM設計產品的來源，也是做一個產品的開端。

范圍層，當我們獲取到用戶需求、明確好產品目標后，PM就會想——我們可以提供給用戶什么解決方案來實現用戶的需求。這時候，我們會寫需求文檔記錄下我們提供的解決方案。

當文檔完成后，PM會兼職做UE的工作，也可以找UE一起來做，開始進入了結構層的設計——這些解決方案要做幾個頁面在哪個頁面呈現。然后UE就去設計去了——這個東西用按鈕表示；這個東西用文本框表示；按鈕放在這里表示可以點擊，可以確認；文本框放在哪里，用戶一眼能看到說明等等。這都是UE的工作，而這就是框架層的工作。

匯總一下：

• 一個產品交付給用戶，實際上就是PM把一個用戶需求或者一個點子變成最終產品，交付給用戶使用的一套流程。
• 每一層都涉及到各種決策：我們做什么，不做什么；用什么元件，不用什么元件；什么位置，什么顏色。
• 每一個流程上的每一個決策，最終都會交付到用戶那里，當用戶使用一次之后，產生用戶體驗。

本文由 @大林的小白?原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議