如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

本篇文章分別從頁面打開方式的類型、當前頁打開&新開頁面、彈出框三方面對頁面鏈接打開方式進行了探討，給大家提出一些意見以供參考。

頁面打開方式作為鏈接產品路徑的基礎，在設計的過程中，或多或少都會遇到選擇的困擾，尤其是產品功能復雜，層級較多時，如何讓用戶按照自己的意愿清晰的瀏覽信息，保持操作連貫性，是值得體驗設計仔細思考與分析的。

近期在所負責的設計項目中，團隊對鏈接操作的打開方式產生了分歧，借此機會整理了一些案例與資料，就這個問題進行分析探討，也給遇到同樣問題的同行一些參考意見。

一、頁面打開方式的類型

網頁中可操作的鏈接，主要有按鈕、icon 以及文字鏈接，設計中常用的打開方式則主要有以下三種：

1. 當前頁打開

點擊操作鏈接后，在當前的瀏覽器頁面中進行內容顯示與操作。

2. 新開頁面

點擊操作鏈接后，在瀏覽器中新開一個獨立的標簽頁面，進行內容顯示與操作。

3. 彈出框

點擊操作鏈接后，在當前的瀏覽器頁面中，彈出一個小尺寸的對話框，進行內容顯示與操作。

二、當前頁打開 & 新開頁面

首先來說說最具爭議的新開頁面&當前頁打開。在 HTML語言中，target目標有「target=_blank」和「target=_self」兩種屬性，分別代表「新窗口打開」和「當前窗口打開」，下圖是這兩個參數的屬性描述。

從這兩個參數的屬性上來看，「當前窗口打開」是系統默認的處理方式。這個打開方式在國外的網站中實現方式比較統一，用戶也形成了一致的習慣，但國內的形式則不盡相同，以至于一直頗具爭議，不同類型網站之間、同一網站不同場景之間也沒有一個明確的規則標準可供大家學習和參照。

針對這個問題的討論，可以聽到兩種不同的用戶聲音，并且都站在各自的角度闡述其道理。

舉個例子，我們以同類型網站（淘寶和亞馬遜）的打開處理方式進行對比，來看一下用戶習慣、功能場景對鏈接打開方式選擇的影響。

首先，我們確定一致的功能場景：用戶從首頁中根據各種篩選條件，查找到心儀的商品。來看一下兩個網站的處理方式：

可以看出基本是兩個極端，差異非常明顯，再來看個有意思的現象，亞馬遜中國的商品搜索方式竟然又和淘寶一致了，難道鏈接打開方式的差異竟是中外用戶習慣的差異？

這確實占了很大一部分原因，那么造成這種差異的原因主要有：

• 早期的 W3C標準不支持 target=”_blank”（HTML語言中，在新窗口中打開鏈接）的屬性，國外互聯網普及也比國內早，于是用戶慢慢養成了習慣。
• 默認當前頁面打開讓國外用戶覺得更有「禮貌」。如果用戶想新開頁面，可以鼠標中鍵、按住ctrl點擊鏈接或者右鍵新窗口打開，此時用戶更有選擇權，可以自己決定打開方式；如果默認新開頁面，則讓用戶失去了選擇權。
• 早期國內互聯網發展較為浮躁，網站想通過新標簽頁打開方式，提高PV。
• 國內網絡普及晚，部分用戶尤其很多老年人不習慣甚至或許不知道，頁中有個后退前進按鈕、面包屑可用，新開頁面便于他們的操作。

那么，淘寶中所有的頁面打開方式都是新開嗎？不是。像「我的收藏」、「已買到的商品」、「購物車」等功能頁面就是當前頁打開。

同一個產品內部，如此區別設計的原因我認為有：

• 用戶的目的較為明確，查找對象確定。（用戶想要查看的對象是確定的，如購物車中的產品，用戶有明確的目標，找到鏈接打開頁面即可，不像搜索查找商品，需要一步步縮小范圍甚至比對查看）
• 鏈接入口常駐在網站的信息欄，用戶可以隨時切換，操作方便，且不存在重新輸入的成本。

關于這兩種打開方式，到底哪種操作更順暢，確實難分高下，就跟「確定和取消哪個在左，哪個在右」是一種性質的問題，沒有好壞之分，關鍵是要看在哪種場景下使用更合適。

新頁面打開適用的場景：

• 頁面內容沒有關聯性，且從邏輯上沒有從屬關系，相對獨立。如：產品中的外鏈。
• 存在多頁面「比較」的操作，需要經常切換。如：淘寶商品詳情。
• 需要保留住前一頁的操作不丟失。如：知乎上過濾出來的結果列表。
• 功能分支存在穿插，當路徑發生交叉時，最好新開頁面。如：產品內部的跳轉鏈接，導致信息關聯的層級發生改變。
• 具有輔助功能的操作。如：使用文檔（PDF、圖片等）需要來回參照。

當前頁打開適用的場景：

• 流程性的功能頁面，前后操作存在關聯和影響。如：下單支付、按步驟新增。
• 同一層級內容間的操作。如：tab欄的切換。
• 同一路徑中的操作，用戶當前的操作會對主頁的內容產生影響。如：編輯一個配置，用戶操作完，會回到當前頁查看結果。
• 用戶具有明確目的性的操作，當前頁有利于鎖定用戶注意力。如：淘寶中「我的收藏」。

以上是結合功能場景進行的選擇側重，如果就「用戶體驗」一定要分出個高下，我個人還是比較支持默認「當前頁打開」，從體驗角度分析，「當前頁打開」略勝一籌的主要原因有以下兩個：

• 尊重用戶的決定。當前頁打開，將更多選擇機會留給用戶（鼠標中鍵、按住ctrl點擊鏈接或者可以右鍵新窗口打開），一個具有良好用戶體驗的產品，在用戶做操作的時候，總是能讓他們按自己的意志做出決定。網站對每個鏈接強制打開新頁面則剝奪了用戶的選擇權，因為不同的人有不同的瀏覽習慣和使用需求。
• 體驗一致。保持一致體驗的設計才能讓用戶產生信任感與安全感。當用戶在操作界面元素的時候，可以順暢的知道、理解，并且能預料到將會發生什么，不會被分神，也不會被打斷。任何違反這個原則的設計都將會演變成一種「以設計方意志為導向」的設計，而不是「以用戶為中心」的設計。

小結

當我們不知道兩種方式如何選擇時，或許「不強制用戶」才是最好的體驗。因為我們面臨的用戶多樣，電腦操作熟悉程度多樣，因此不同用戶對于打開方式的習慣也具有多樣性，這個是設計者無法揣測和調查清楚的。

在「兩害取其輕」的情況下，在當前窗口打開鏈接，不失為一個選擇，尊重用戶自己的決定，讓用戶對交互界面自主可控。

三、彈出框

彈出框（彈層）又叫模態對話框，是指在用戶想要對當前對話框以外的應用程序或內容進行操作時的提示方式。它一般覆蓋在整體頁面之上，避免了頁面跳轉。

彈出框通常是為了顯示一個單獨的內容，在不離開整體頁面的情況下有一些互動，提供信息和交互。

如下圖知乎中的「寫想法」，用戶可以快速的在彈出框中記錄個人想法，記錄發布后，很順暢的回到之前的路徑上繼續操作，便捷，操作思路清晰。

△ https://www.zhihu.com/

現在很多產品中的新增、創建，也都會采用彈出框的交互方式，當然前提是在彈出框中編輯的內容不是很多，此時彈出框不僅承載了信息編輯的功能，還可以作為上下文的跳轉，幫助用戶銜接路徑。

如 iconfont 中的新建項目，用戶新增后，頁面會直接跳轉到新的項目空間。

△ http://www.iconfont.cn

彈出框適用的場景：

• 內容簡單，沒有復雜的操作，且具有臨時性。如：新增一個收貨地址，進行簡要的輸入編輯。
• 更為詳細的輔助說明，是對當前內容的快速擴展。如：縮略圖，點擊放大查看。

因此，彈出框可以較好的實現上下內容層疊的感知，不打擾用戶的主路徑，同時作為頁面承載元素和用戶操作的補充，起到承前啟后的作用。

總結

本文結合這三種鏈接打開方式的頁面交互關系，進行適用場景舉例，并總結每種方式的優缺點，方便在設計中更好的根據不同的場景選擇合適的頁面打開方式。

當然，以上總結也是基于我個人的理解與經驗，沒有統一的用法和標準，在具體設計實踐中，仍要靠設計者的直覺和經驗來進行綜合考量與判斷。

作為體驗設計師，如何規劃用戶瀏覽路徑，是個需要嚴肅對待的命題。沒有絕對的好與壞，但一定要結合產品類型、場景、目標用戶等進行具體問題具體分析。

藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

用戶體驗一直是我們在產品設計中反復強調的問題，那么我們應該怎樣提升用戶體驗呢？

經過項目中不斷的探索與研究，結合幾個方法論，我們整合出了一套用戶體驗提升的方法流程——用戶體驗提升模型。下面就來詳細的介紹一下，希望能給大家幫助和啟發。

先問幾個問題？

• 你知道你所負責的產品/設計方案的用戶體驗好還是不好？
• 產品/設計方案體驗不好時應該怎么做？
• 這個產品/設計方案的體驗具體有哪些問題？
• 怎么優化出現的體驗問題？
• 哪些模塊或頁面的問題最迫切需要解決？先優化哪些？后優化哪些？

用戶體驗提升模型能很好的幫我們解決以上問題。

先介紹一下用戶體驗提升模型的流程：線上版本調研 – 協作啟發式評估 – 問題分析整理 – 優化方案。

這篇文章也會以這個流程一一介紹。

一、線上版本調研

也可以是設計方案，我們采用了 SUS系統可用性量表進行調研，SUS 是評估產品可用性的一個花費少，但十分有效的工具。該量表包含了10條定向問題，每個問題均為5分，按強烈反對（1分）到非常同意（5分）評分。（各位小伙伴可自行網上查詢系統可用性量表，有很詳細的介紹，在這里不贅述了。）

最佳的方式是在線上直接上一個問卷調研來收集真實用戶的反饋，然后對收集到的結果做如下算法：

• 對于奇數序號的問題，將其得分減1；
• 對于偶數序號的問題，將其得分被5減去；
• 將所有問題的減法后得分加在一起，然后乘以2.5；
• 計算出的結果即為我們產品可用性的得分。

1. 那么如何通過評分看出一個產品的好壞？

上圖是一個評分參考，通過數據得出，系統可用性量表最終算出的評分達到70分左右，就可以比市面上一半產品可用性要好，也就是說這個產品的用戶體驗算是合格了。

但是系統可用性量表的評分結果是抽象的，這個分數只能讓我們大概了解產品用戶體驗的好壞，在具體問題上卻是缺失的，那我們知道產品評分較低時我們如何聚焦產品的優化方向呢？

二、協作啟發式評估

1. 為什么是協作啟發式評估而不是啟發式評估？

因為啟發式評估主要由幾名交互專家以角色扮演的方式來完成設置的任務給出評估結果。優點是成本低、快捷，缺點也顯而易見，一是交互專家團隊中不一定有或者很少，二是可用性問題意見一致率很低，并不能很明確的指出為什么這是一個體驗問題，有很多個人因素的主觀見解。

因此我們決定用協作的形式來進行評估，而且不需要交互專家，可以是用戶、測試、設計、產品、運營、商務等等，只要愿意參與測試，就可以。協作啟發式評估以小組為單位，能夠很好的整合出更多的問題，而且更準確。你說他們也不是交互專家，能起到好的結果嗎？竟然都整理出方法了，那答案當然是能啊。

為什么能，因為整個評估過程中，我們是有的可用性原則來給予啟發的，有了這套可用性原則，一秒變專家。

說到可用性原則，了解用戶體驗的都知道尼爾森的十大可用性原則，但是從1995年提出到現在，已經過去了二十多年，互聯網世界已經發生了巨大的變化。在這樣的情況下，尼爾森的十大可用性原則明顯有些不那么符合或者說不能給出針對現今產品太全面的啟發，所以，我們重新整理了一套可用性原則，這套可用性原則更針對現今互聯網產品，基本可以覆蓋到所有出現的用戶體驗問題。

我們稱之為21條可用性原則。

有了這21條，可以讓任何沒有用戶體驗知識的人參與到協作啟發式評估中來了，一秒變專家了。當然，這21條可用性原則我們也會迭代優化，目的是做到更符合現今產品、更全面的可用性原則。

2. 通過什么來確定的這21條可用性原則？

首先，我們都知道用戶體驗五要素，這已經是做產品設計的基本常識了。我們來看這五個層級對用戶體驗能產生影響的有哪些？戰略層一定不會，如果一個產品立項了、已經上線了，一定是戰略層成立了，如果戰略層出現了問題那就要重新考慮產品要不要做或者是改變方向了。那么剩下的4個層級呢？范圍層、結構層、框架層、表現層，其實都會出現用戶體驗的問題。那我們看看這幾個層級所包含的內容，視覺呈現、界面設計、導航設計、信息設計、交互設計、信息架構、功能規格、內容需求，這樣的話就有8個大類，然后我們通過多年的經驗和對尼爾森可用性原則的理解，把可用性原則對應到這8個大類中，最后得到了這分類明確的21條可用性原則。

但是分了這8個類有什么用呢？讀下去，你就會知道。

3. 具體方法

先說說調研的具體方法。我們以協作啟發式評估的方法，組織好調研小組（8人以上，樣本越多越好，反正最后還要去重），宣講完流程方法和操作任務，就可以開始進行評估了。我們一般為了省時間，宣講完就把表格發下去，讓他們自己找時間完成表格，然后再收回來。

這個表格就是用戶體驗問題記錄表。包括問題所在位置、對應的21條可用性原則、嚴重程度等級、問題描述。

三、問題分析整理

1. 收集了一堆問題之后應該怎么做呢？

通過小組會議討論，把相同、相近的問題統一成一個，可優化的問題保留下來，不是體驗問題的去掉，然后整理到一起，這就是整個產品存在的大大小小、各種各樣的問題了。

接下來，我們引入另一個方法，就是用戶體驗八陣圖。

這張用戶體驗八陣圖的8個點是不是有些眼熟？沒錯，就是21條可用性原則里的8大分類，這就是上文為什么分為8個類的原因。中心向外為問題嚴重等級，依次為：小問題（1）、次要問題（2）、主要問題（3）、災難性問題（4），一一應對到「用戶體驗問題記錄表」中的「問題嚴重等級」。

2. 怎么使用呢？

首先，對記錄表里的「問題位置」進行歸類，以模塊化區分，比如把登錄注冊流程做為一個模塊，用一張八陣圖來表示，最終把產品的每個模塊都用一張八陣圖來承載所對應的體驗問題。

然后，把收集到的問題以「點」的形式點到對應模塊的八陣圖當中。

哪個模塊問題最多？問題出現在哪個方向上？是視覺？還是交互？還是內容？哪些問題很嚴重需要迫切解決？一目了然。

四、優化方案

• 通過 SUS系統可用性量表知道了產品的整體體驗處于什么水平。
• 通過協作啟發式評估知道了產品的用戶體驗到底有哪些問題。
• 通過21條可用性原則知道了如何避免出現體驗問題。
• 通過用戶體驗八陣圖知道了哪些模塊最迫切需要優化。

知道了這些，我們進行產品優化的時候還會不知道如何下手嗎？接下來就要靠你自己了，你一定會做的更好。

當然，這套模型只能對線上產品的用戶體驗提升起到一定幫助，一個產品真的厲害還要從戰略層一步步做起，我們需要去清楚的知道產品的目標是什么，我們能提供什么，我們想要去得到什么。對于產品的迭代，我們可以從使用人群（目標客戶），主要功能（產品的服務方向），產品特色（與競品的差異化），商業價值（盈利模式）上深入研究。

藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

系列位置效應大家可能有點陌生，因為它不像格式塔那樣被大家熟知，但是當我看了它的概念之后，我決定和大家分享一下。

如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

所以跟大家分享下，我的一些相關思考。

 1. “+”的運用場景 

我們常見的產品中，采用“+”功能的場景，大致分為兩種：a.（上傳）內容選項；b.（聚合）快捷功能。

a.（上傳）內容選項

根據“+”的直觀表意，大致也能猜到它的運用跟“添加”、“上傳”某個東西相關。

比如：微博，點擊“+”入口后，是選擇所要上傳的內容類型。（可以曬自己精修X小時后媽都認不出來的自拍、也可以曬逗比的小視頻、或者老子就想搞一場直播）。

比如：下廚房左上角的“+”，點擊后，是選擇上傳作品，或者創建菜譜的選項。

再比如：工具類產品：Google drive，dropbox、百度網盤、微云，點擊“+”后，同樣是選擇上傳不同文件的入口。 

可以看出，這種情況下的“+”功能，多指“添加”、“上傳”的含義，所承載的內容，是同一緯度下的不同選項。

b.（聚合）快捷功能。

眾所周知，產品為了節省界面空間，同時避免過多功能給用戶不必要的干擾，會選擇把一些不常用的快捷功能收到二級展示。常見的產品中，他們選擇把這些快捷功能塞進“+”里。

那么，你是不是覺得“+”功能跟“…”功能承載的內容是一樣的？比如：樂趣首頁右上角“...”，同樣是對頻率較低的功能的集合。

那為什么有的產品不直接用“...”，還是選擇用“+”呢？

通過分析發現，“+”雖然也是聚合快捷功能的入口，但承載的功能有一個共性：都是圍繞著用戶主動打開、發起、新建...等操作進行的，因此用“+”更貼切。

比如：微信里的“+”，包含著：“發起群聊”，“添加朋友”，“掃一掃”，“收付款”，其實都跟“添加”有關。 

比如：淘寶也是類似的處理方式。

再比如：愛奇藝的“+”，里面包含的也是跟“添加”，“上傳”相關，像上傳視頻、掃一掃、我要直播….

反過來看“...”，它聚合的功能，大多是相互關聯較弱，且沒有主動添加、上傳等含義的。因此，用一個相對模糊，沒有指向性的符號詮釋，更為合適。

由上可以看出，在這種情況下，“+”作為聚合快捷功能的入口，包含的是頻率較低，且跟主動“新建”、“發起”、“掃描”等相關的功能。

 2. “+”的展開方式 

當用戶觸發界面中的“+”時，常見的展開方式有3種，分別是：a.氣泡彈出框；b.動態欄；c.沉浸模式。

a.氣泡彈出框

氣泡彈出框，這個控件又常被稱為Popover，一般是由一個矩形和三角箭頭組成的彈出窗口，通過點擊Popover內的按鈕或者非Popover的屏幕其他區域可關閉。 

比如,以微信為代表的“+”的展開方式，采用的就是Popover。一般用于聚合快捷功能。優點是觸發“+”到Popover的距離很近，操作順手，效率高（更像是導航的延伸）。

b.動作欄

動作欄，這個控件官方稱之為Action Sheet，是用戶觸發“+”后，出現的一種模態彈出框，里面包含一組與當前情景相關的選項，一般用于上傳內容選項。 

在iPhone屏幕上，為了便于單手持握時操作，Action Sheet通常占據屏幕底部區域。

比如：以Google drive、Dropbox為代表的產品，需要選擇上傳文件類型的選項。

在這個部分，同事們討論有些爭議點，在于：google drive 和 Dropbox或者微博，它們的加號本來就在底部，所以彈窗讓用戶感覺視線統一。

而有的產品“+”在上面，彈窗從底部出來，擔心注意力切換和手指移動的路徑比較長，顯得割裂。

帶著這個問題，我調研了下有類似情況的產品，會不會讓人覺得不舒服。

后來發現，不會的。原因在于我們常用的、擁有10億+用戶的微信，發朋友圈時操作就是這樣，而我們并沒有感覺很割裂，反而已經習慣。

同樣，iPhone自帶的“提醒事項”App，也是這樣處理。

后來看了規范發現，iOS確實意識到在iPad上，如果繼續將Action Sheet顯示在屏幕底部，如果頻繁操作使用會比較累。因此，做了特殊處理。而手機屏幕上以底部為主，同時點擊空白區域取消的操作，也是系統用戶所熟知的。

總的來說，操作欄適合承載同一緯度下的內容選項，同時，就算“+”在頂部，采用底部動態欄，體驗上也是沒問題的。

c.沉浸模式

沉浸模式，指的是當觸發“+”時，用戶在全局蒙層上進行功能操作，同樣適用于上傳內容選項。

優點是拓展性更強，體現在：1.提升收益；2.品牌認知；3.內容運營。

1.提升收益

比如：微博，采用沉浸模式，下面是上傳不同狀態類型的入口，上面可以增加廣告收入。

再比如：微云，在沉浸模式下，可以植入自己的“會員”廣告，從而提升會員轉化。

2.品牌認知

比如：有道云筆記，在頂部的空間內，宣傳自己的品牌slogn：“記錄，成為更好的自己”，是一種品牌情感化的傳遞。  

3.內容運營

像“好好住”，它們在這個頁面加入“話題”運營推廣。從而給UGC內容模塊帶節奏。

大多數產品都想營造社區氛圍，建立用戶關系，從而增加用戶粘性，提升產品留存。

但要想擁有濃厚的社區氛圍，首先要有內容、才有人愿意看、才有人在里面互動。

現實問題是，有很多用戶有想發狀態的心，但不知道發啥，從而放棄。因此，我們應該作出相應的引導。

比如，“好好住”在發布環節，增加話題運營“#每天一張生活日常#”入口，就是解決剛才說的“用戶不知道發什么”的問題。運營同學想點子、造話題、帶節奏，從而提升用戶的發布量。

因此可以看出，“沉浸模式”，對于那些有拓展需求（收益、品牌、運營）的產品更適用。

不知道你有沒有發現，相比國外，國內采用這種“沉浸模式”的產品偏多。或許在中國這個互聯網競爭如此激烈的大環境下，大家不愿意放棄任何一個能夠運營或留住用戶的機會。 

總結 

總的來說，在常見的產品中“+”功能的運用場景有：（上傳）內容選項、（聚合）快捷功能；它的展開方式可分為：氣泡彈出框（適合承載快捷功能）、操作欄（適合容納內容選項）、沉浸模式（容納內容選項的同時，拓展性更強）。其實，交互形式沒有好壞之分，只有哪個更適合自己的內容需求和產品目標，正如Louis Sullivan所說：“形式追隨功能”。

小tips：日常工作中有太多類似“+”這種，看似一個不起眼的小功能，被大家忽略。我們習慣性看一下競品，拍腦袋決定方案。

但是，慢慢你會發現，只有深挖和分析這些所謂的“小細節”，才能知道別人這么做背后的原因、才能舉一反三的去運用、才能更好的兼顧統一性和拓展性，而不是停留在浮于表面的模仿。

希望這篇文章對你有所幫助。 

藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務。

交互設計篇-如何處理需求

夜月薰衣茶 PMIP

如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

如何處理需求，是產品經理的基本功，不管是來自老板還是客戶的，亦或來自企業內部（運營、業務）及產品本身的發展，產品經理都需要把需求的收集、分析、管理做到有效進行。

一、需求收集

用戶調研

運用場景：

產品規劃初期或者遇到重大版本迭代，需要重新架構設計時，將會進行用戶問卷、用戶訪談的方式去挖掘用戶的真實需求。

  基本方法:

用戶問卷-定量研究的方法，問卷問題一般為15個左右，包含用戶基礎資料信息（包括年齡、收入、教育水平等人口統計學范疇信息）和主觀性的信息（包括用戶做這項活動的態度、行為、目的等方面的信息）兩大部分，收集到這些數據后進行分析并得出一定結論。

用戶訪談-定性研究方法，訪談問題分類包括開放性的問題和專業性的問題。問題盡量從簡單到復雜，由較寬泛趨于精細；訪談的過程中的問題盡量說的簡單易懂，避免專業詞匯，讓回答問題的用戶清楚明白你說什么；避免問一些引導性的問題；不要因為冷場而尷尬過多，多次重復進行講解，留有一定的時間讓用戶思考如何回答；盡量問用戶一些開放性的問題讓用戶進行思考回答；用戶描述的過程中盡量描述真實使用場景與案例。

兩種方法基本為相互補充進行的一個方法，對于不熟悉的業務，問卷編寫初期不知該如何進行挖掘用戶的問題，尋找五個左右的用戶進行相關業務及主要業務用戶使用場景訪談，將會總結出一些問題然后加入你要調研清楚的問題包括客觀問題和主觀問題進行用戶問卷編寫、發放與收集。

用戶反饋

  運用場景：

產品專家用戶的反饋，包括運營、客服直接獲取用戶的反饋，通過從微博、論壇、貼吧、軟件用戶評論等方面尋找用戶的反饋。

  基本方法：

市場反饋  做運營、客服、市場等人員和用戶進行產品銷售推廣、運營活動的過程中和用戶直接交流，一些專家用戶直接反饋出來的需求。具體也要根據產品是直接面向c端客戶還是企業級別的客戶，兩者有很大差異。

訪談  在和用戶進行訪談的過程中，一些專家級別的用戶直接反饋對現有產品在使用過程中的一些不滿和改進的建議等。

查詢相關網站 比如產品下載市場、百度貼吧、微博、論壇、微信群、QQ群等各種用戶有自由發表言論及感受的地方，用戶的直接反饋。

用戶直接反饋的信息，需要進行分析其需求的真偽性。

產品定位發展

  運用場景：

產品最終要幫用戶解決一個什么樣的問題，市場發展環境和公司可支配資源等方面進行綜合評估產品的前期、中期、后期的目標定位。

 基本方法：

相關行業專家詢問  在發覺一個新產品及市場時，不明確當前市場狀況可直接找行業內的一些專家進行聊天交談，他們對于市場的現狀很熟悉，可向該類專家詢問產品的定位與發展方向問題。

投資行業的專家交流 最了解市場、發覺市場前景行業及創業想法的投資者，他們對于市場發展的方向及敏感度有一定的專業看法，可與其交流產品的發展方向性的問題。

相關行業專家、投資專家給予的建議和方向最終還需要結合本身公司的定位發展與界定產品的發展定位。

商業畫布  一種能夠幫助處于高層決定者激發創意、降低猜測、明確目標用戶、合理解決其問題的工具，可直接判斷出公司產品發展的的優勢、資源等最直接有效的方法。

以下為商業畫布九宮格主要內容：

數據分析

  運用場景：

產品或運營人員對用戶操作規律，用戶流失查詢等方面進行查看分析，決定產品功能優化迭代最有效直接的證明。

  基本方法：

數據埋點  第三方數據服務平臺或者用自己平臺后臺注入相關代碼進行統計。程序員在程序編寫時將主要操作、按鈕進行數據埋點，通過網站即可查詢相關數據。

第三方數據平臺 專業做數據的網站會定期進行相關行業數據的發布，查看專業的報告即可獲取一些相關數據。

結論

針對收集的需求，大致可分為以下幾類:

產品運營類—某項調研結果直接反應出一種現象，將會指導產品運營人員的運營方向朝著這方面努力。比如一款產品預約功能，從團隊做用戶問卷的結果反饋中，用戶更偏向于用微信公眾號進行預約，運營團隊需要相對在微信公眾號預約增加相對的運營的投入。

功能優化類—用戶使用某款產品的某個功能目的就是為了達到其某個目的，對于功能效率或用戶體驗上滿足，將會直接影響用戶的去留，優化該功能的用戶體驗滿意度及效率將會提升用戶的留存量。

新功能—產品功能的延伸或新增，通過用戶研究，發現用戶針對某個需求的實現很迫切，該需求就算新功能，可評估該功能緊急程度及效果進行功能設計滿足。

二、需求分析

 

重要度、頻率二維度

 運用場景：

當接到多個需求，因為時間原因，只能進行個別需求滿足，評估優先級時，可用該方法進行簡單需求評估分析。

 基本方法：

將功能需求按照重要度和頻率進行四象限劃分，重要高頻象限中的需求要首先進行解決。重要度和頻率如何進行衡量，頻率衡量即使用的頻次，重要度衡量判別是否會因為該需求的缺少而影響用戶使用。

KANO模型分析

  運用場景：

產品重大版本迭代，因為時間等問題，只能選擇個別兩三個功能進行優化，但是優化的需求點比較多，可以直接向用戶進行問題編輯，查看用戶滿意度選擇進行優化。

  基本方法：

(1)從顧客角度認識產品或服務需要；

(2)設計問卷調查表；

(3)實施有效的問卷調查；

(4)將調查結果分類匯總，建立質量原型；

(5)分析質量原型，識別具體測量指標的敏感性

二維屬性歸屬分類

場景化思維

  運用場景：

通過模擬或發現真實場景，預測用戶行為從而進行設計。

  基本方法：

從交互五要素考慮，人、目的、行為、環境、媒介幾個關鍵點去創造用戶真實的使用場景。在什么地方，哪個人做了什么事，運用了哪些東西，達到了什么樣的目的，遇到了什么樣的問題，怎么進行處理解決。例:在淘票票購買電影票后，付款時推薦購買零食信息。

用戶體驗地圖

 運用場景：

適用于任何場景，更適合在可能存在問題或者改進機會的事件上。

  基本方法：

• 歸納用戶該使用場景下的觸點

• 畫出情感坐標

• 尋找用戶進行觸點體驗情感、意見描述

• 歸納用戶體驗意見

• 繪制情感曲線

• 標注用戶重要性意見

需求分析的方法很多種，以上僅列出部分，方法只是分析的一種工具，最主要還是通過方法分析需求得出的解決方案。

三、需求管理

  

需求提交

簡單來說，就是將收集到的需求，在評估完優先級，確認做具體需求功能時將該需求開發計劃告知相關開發、測試等人員，讓其明確即將完成的功能需求。如功能需求相對應的方案設計、業務流程等內容提前與開發總監溝通好上傳至公司統一管理文件處，具體根據不同公司的實際情況。

需求評估

需求功能的相關開發者、測試針對該需求達成統一認知和開發周期認定，使得相關開發人員在開發周期內有效配合開發，測試人員明確該如何進行有效測試，針對同一需求能夠有效推進實現。

需求跟蹤

 在開發過程能夠及時跟進開發，一確保其開發功能達到預期效果，二有任何異常情況的發生能及時進行處理解決，三有效把控需求的開發周期，保證需求按期交付。

需求變更

當需求提出方提出需求變更或者在內部評審、開發過程導致需求變更，做好相關需求變更的把控，以防需求變更后導致項目無法執行。

      a.評估需求變更與原需求的差異

首先，明確需求變更的原因—是需求提出方進行需求變更還是內部原因導致需求變更。其次，需求變更后與原先需求定義是否有較大沖突，如有較大沖突，評估變更前后的利害關系，哪個更能有效達目的/效果，按評估結果執行；如無較大沖突，評估與原需求的緊急程度及時間安排，進行需求變更解決。最終，有效記錄需求變更計劃及原因，定期進行總結，評估相關解決方案。

       b.評估需求變更導致的結果

如需求變更后，利大于弊，允許變更，但需按照需求變更的規程執行，以防出現意外情況產生不必要的責任，失去相關控制。如需求變更后，利小于弊，拒絕變更.

藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

幾個案例解析：如何一步步做出合理的策劃方案

人人都是產品經理 2018-08-19 15:01:59

如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

做產品方案的時候，我們經常會走進死胡同或者跑錯路，最后不論是開發還是市場，對結果都不滿意，產品自然就成了背鍋俠！但是往往我們出方案的時候，多想一些問題，或許結果就不一樣，跟新人交流的時候，發現一些能力需要可以單獨訓練，有意識的去理解一些東西，長期積累就會有自己的一套解決問題的思路。

1. 辨別真偽的能力

辨別真偽也就是老生常談的真偽需求的能力，在產品經理的行業里，經常會進行需求的評審，需求的界定，看這個需求是否是真的有效

舉個例子

行業：外賣行業

案例：打包費審核的功能

功能出發點：解決商家亂設打包費的需求

解讀：如果從這個角度來講，打包費審核完全沒必要，原因有

• 未必所有的商家都亂設打包費，只是個別現象
• 及時設置了打包費審核，后臺審核了，也沒辦法解決，除非后臺做強制性的更改或下架商品的功能
• 打包費是商家自主行為，如果商家惡意設置打包費，是給自己添堵
• 如果真想解決此問題，在商家上傳商品的時候設置打包費的選項，一個餐品打包費最多是多少
• 或許極個別的商家的打包費真的會比較高，可以在商家管理后臺做好打包費配置即可，從源頭控制

很顯然，要在后臺做一個打包費審核的功能，還需要讓人專門處理此業務，對系統來說，是降低效率又不見得有效果的，所以，界定為偽需求。那么既然存在這樣的問題，可替代方案如下：

1. 商家添加商品時打包費又兩個選擇【收打包費】【不收打包費】，打包費為行業標準，1元/份餐品；
2. 對于大型的打包盒，比如說探魚這些商家，打包費可以開放設置（大型連鎖或者知名品牌可以認定為不需要通過打包盒來賺取利潤）。

辨別真偽的能力不僅僅體現在能辨別出來，更多的是能夠用更靈活的方式來解決來自運營、消費者產生的問題，且不增加過多的額外工作。

2. 找到合適定位的能力

合適定位的能力，這個說的有點虛，用通俗的話來講，就是找個抄的對象。在國內想要做一個App有大量的抄襲模仿對象，各大知名廠商已經做了很多的研究，剩下的就是模仿和創新。能不能找到合適的模塊去進行創新，這個就比較重要。

案例1：外賣行業，推薦商家

功能出發點：外賣行業的推薦商家，很多事按照細分的行業來做的，比如說美團跟餓了么的【必吃菜品】【品質聯盟】這些，但是對消費者來說，這真的是我想要的選擇么？

解讀：從消費者的心理出發，我去找吃的，可能出于幾點

• 找新鮮：看看這附近有什么新鮮的店鋪開業或者新的口味，外賣一個月都是那幾家，早就膩了
• 找實惠：外賣分量不夠，10塊錢管飽的那種最好
• 速度快：能告訴我最快的是哪家么？

其次還有可能

• 這兩天身體不舒服，想吃點口味淡的
• 我是湖南湖北人，我想吃點重口味的
• ……

因此，從這類具有標示性的標簽入手，會更有效果。此類功能類似于一點點的餐牌設計以及lofter的標簽設計，將商家分配不同的標簽跟消費者的消費場景對應上，交叉進行推薦，比如說一個商家有很多種口味，那對應的消費者人群也會多，消費者通過對應標簽可以快速找到對應的商品，對消費者和商家都是互利的，我們經常會遇到一個外賣店鋪有幾十種餐品，找半天還是不知道吃啥。

（配個截圖，此功能已實現，后續看數據情況，再做追蹤）

順便說一下，之前餓了么有個版本放大對餐品的顯示，做餐品的推薦，后來又改回來，具體是什么因素，不確定，但那也是一種嘗試。

案例2：荔枝FM飛機稿

出發點：那是很早以前的一個版本，因為不好用，所以就干脆做一個交互飛機稿，當時做的時候有以下幾個因素：

• 體驗不好，最古老的版本體驗非常不爽（詳情可以戳這里：http://www.woshipm.com/ucd/209199.html）
• 當時在做交互設計，就嘗試用新的交互設計思路去設計

解讀：

當時荔枝FM算是國內比較早做電臺的，同期出了喜馬拉雅聽，剛開始也沒有荔枝FM那樣火，但從交互上，主要由兩個點：

1. 模擬電臺操作：荔枝FM當時還是走擬物化設計（新進入互聯網的可能覺得是歷史），那從FM收音機的角度來說，都有一個旋鈕，或者是老式的隨身聽，因此在主頁的界面設計以及播放界面設計都有參考古老隨身聽的樣式，既然復古，我們就徹底點
2. 數據整理：在當時做荔枝FM的飛機稿時，主要做的是數據層的整理，把繁雜的內容數據變得有序可循，讓用戶和博客可以更快找到合適自己的內容

對于合適的定位可以理解為：每個事物或許有自己固有的長相，但或許我們找到合適的邏輯后，只要抓住根本，那最后怎么玩，還是大家說了算，打破陳規，才更好玩。為什么音樂軟件就一定要有那么大的播放界面；為什么訂餐軟件就一定要宣傳店鋪，不能是商品？

3. 解決問題的能力

這個就老生常談了，解決問題的能力體現在對系統的掌握程度和開發自由度兩個層面，產品經理實質是提供解決方案的，任何需求到手后，我們需要分析如何快速解決該問題。

案例1：招聘面試流程

出發點：銷售類崗位進行招聘時，都是一大批一大批的面試，一個人可能同時面試很多崗位，一個公司會面試很多個求職者，因此提率，對求職者和公司都是最大的需求

解決方案：排隊叫號，跟銀行排隊一樣，針對這個場景，我們梳理了核心的問題

• 面試人員取號
• 面試人員查看各崗位當前排隊情況及投遞請求
• 企業招聘人員查看簡歷并選擇是否面試，對面試的人進行初步評論
• 叫號及數據導出

針對以上四個問題，設計出如下流程（省略取號的環節，主要核心的流程是企業的發送通知循環以及面試后的符合不符合操作循環）

從流程圖可以發現，核心邏輯并不復雜，解決了通知求職者來面試的需求以及對求職者進行評價需求即可；除此之外還可以做一些其他的功能，如求職者可以看到當前排隊情況，根據實際情況進行簡歷投遞，避免出現大量等待情況，可預知自己還要多久可以面試，在這時間內是否可以投遞其他公司，進行多項選擇；對于企業解決各種紙質簡歷分辨不清，電子檔簡歷，電子記錄每一個求職者和操作，可以清楚知道今天面試記錄，電子檔案，更清楚，提高雙方的效率。

4. 了解數據的能力

對于數據，很多人應該不會陌生，如何從雜亂的數據找到規律，怎么處理數據之間的關系？

1. 一級頁面到二級頁面的流失率和轉化率
2. 每個頁面轉化功能的設計及數據統計
3. 數據解讀

最近在做小程序相關的項目，把騰訊的數據統計貼上來:

訪問趨勢類：

• time 時間
• session_cnt 打開次數
• visit_pv 訪問次數
• visit_uv 訪問人數
• visit_uv_new 新用戶數
• stay_time_uv 人均停留時長 (浮點型，單位：秒)
• stay_time_session 次均停留時長 (浮點型，單位：秒)
• visit_depth 平均訪問深度 (浮點型)

訪問分布：

• access_source_session_cnt 訪問來源分布
• access_staytime_info 訪問時長分布
• access_depth_info 訪問深度的分布

訪問留存

• visit_uv_new 新增用戶留存
• visit_uv 活躍用戶留存

訪問頁面：

• page_path 頁面路徑
• page_visit_pv 訪問次數
• page_visit_uv 訪問人數
• page_staytime_pv 次均停留時長
• entrypage_pv 進入頁次數
• exitpage_pv 退出頁次數
• page_share_pv 轉發次數
• page_share_uv 轉發人數

總結

產品經理從拿到需求開始就需要對需求進行分解，判斷到底什么樣的方案可以解決此問題，并結合當前系統的一些功能點，給出最佳的方案；在交互設計的時候是參考競品還是微創新，就看實際業務需求；最后就是核心業務梳理，一個功能的核心業務是什么，還有哪些可以搭配讓功能更完善的，考慮進去，做產品是一個分解、組合、刪減、再組合的過程！

藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

面向中小企業SaaS的權限管理系統

人人都是產品經理 2018-08-19 15:02:17

如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里

本文基于面向某個垂直行業的SaaS系統的設計經驗，抽象出一套適合中小企業的權限管理體系，目標是最大限度保留系統彈性的同時，把系統復雜度和開發成本盡可能降低。enjoy~

面向企業級的SaaS（軟件及服務）系統，由于企業用戶的規模和內部管理模式千差萬別，設計一套具備足夠彈性、符合絕大部分目標企業用戶需求的權限管理系統，是一個很大的挑戰。

我們可以看到，市面上面向多個行業的綜合性SaaS系統，例如銷售易、紛享銷客等，由于它們的目標客戶跨越了多個行業、多種規模，這些企業具備各種各樣的內部管理風格和模式，在權限系統的管理上，往往做得非常復雜，不僅具備部門、角色、職位、數據等各個維度的權限管理，各個功能模塊還有自己獨立的權限管理，雖然具備最大的彈性，卻給企業的系統管理帶來較大的負擔。

提煉的三個核心原則：

• 企業-管理員-普通賬號三級權限
• 功能和數據權限分離
• 部門和角色分離

圍繞上述三個基本原則，我們力圖在滿足中小企業需求的前提下保持足夠的彈性，并嚴格控制復雜度和開發成本。詳細描述如下。

1. 權限從上到下分為三個層級：企業賬號（老板賬號）、管理員賬號、普通賬號

對于中小企業來說，公司的實際控制人，往往是公司的創始人或自然人大股東，因此企業賬號的使用者以及對應綁定的手機號碼，都是公司的實際控制人，他應該掌握最核心、權限最大的企業賬號，所以也可以稱為“老板賬號”。

但是在實際場景中，公司的實際控制人并不會直接管理公司的業務支撐系統，因此，需要在系統首次部署時，創建好企業賬號，并由企業賬號授權給某一個或多個系統管理員，由系統管理員去完成日常的角色創建、員工導入等工作。系統管理員，對應的一般就是HR或行政部門的管理人員。當然，企業賬號的權限高于管理員賬號，如果是小微型企業，也可以由企業賬號直接替代管理員賬號的功能。

除了企業賬號和管理員賬號之外，其他各級員工所持有的賬號，都屬于普通賬號。普通賬號的部門、角色、數據等權限的設置，一律由系統管理員配置。

三個權限層級示意圖如下：

在實際系統中的核心業務步驟如下：

（1）企業購買系統時，創建一個企業賬號，這個企業賬號綁定的手機號碼為公司實際控制人的手機號碼。該手機號碼必要時可以解綁（例如公司實際控制人變更），由于該功能觸發頻率很低，因此不需要在前端功能中實現，只需要在購買協議中寫明，“購買企業可以通過書面方式提出企業賬號手機號碼綁定變更需求”即可。

（2）在部署和培訓階段，可指導企業賬號持有人創建一個或多個管理員賬號，該賬號一般授權給行政總監或人力資源總監，后續配置即由管理員賬號進行。

（3）管理員賬號持有人需要接受系統培訓，掌握部門創建、角色創建、功能和數據權限分配等基本操作。管理員所有操作都必須記錄在案，供企業賬號持有人監督，且管理員操作觸發異常行為規則（如大量分配高等級權限等）時，系統會通過短信方式通知到企業賬號持有人，確保企業賬號對管理員的全方位掌控。

（4）企業賬號可隨時將管理員賬號禁用或設定為離職，但管理員賬號不可對企業賬號進行任何配置或操作。

（5）企業賬號默認擁有所有權限。

2. 功能權限和數據權限分離

功能權限，定義為可見、可以操作的功能范圍。例如某一部分菜單，或者某個頁面里的各種操作。

數據權限，定義為若干個數據類型里的具體可見范圍，例如“客戶”就是一個數據類型，它的權限舉例如“無權限”、“我的客戶”、“我所在部門的客戶”、“我所在部門及下級部門的客戶”。

通過功能權限和數據權限的分離，我們可以做到以下場景：需要開拓和維護客戶的角色集合，都可以擁有“客戶”這個菜單的權限，但不同的角色進入“客戶”菜單的列表時，看到的客戶范圍各不相同，極端情況是看不到任何客戶。且不同角色在同一個客戶頁面上，能進行的操作也不同，例如有的角色可以新建客戶，有的卻不行，這就要由功能權限來控制。

可見，通過功能權限和數據權限的分離和配合，我們在具體的權限分配上有了非常大的彈性，且在技術層面的后臺系統的設計上，也非常合理、清晰。

而在具體設計上，需要保證以下4點：

1. 正確區分功能和數據，入口性和操作性的都應該歸類為功能
2. 正確對數據進行分類，避免存在分類后的某些數據存在交集
3. 數據分類到多細的顆粒度，需要由行業特性決定
4. 數據權限區分為查看、編輯和刪除

示例圖如下，由于涉及具體產品，對某些文字進行了打碼：

3、部門和角色分離

部門的定義，自然就是公司行政組織架構下的部門。

在本設計方案中，角色等同于職位，而在許多大型的SaaS系統中，為了更大的靈活性，往往會把角色和職位分開，但根據我們的判斷，對于中小企業，設定角色一個就夠了，職位當然還存在，但僅僅是一個不涉及權限管理的文本title了。

以一個銷售公司來說，角色可以包括：“渠道專員”、“渠道總監”、“銷售專員”、“銷售經理”、“總經理”等等。

所謂的部門和角色分開，就是不同的部門可以有相同的角色，例如如果有渠道一部、渠道二部，則這兩個渠道部的員工的角色都可以設定為“渠道專員”，這兩個部門的管理者都可以設定為“渠道經理”。再配合功能和數據權限，則進一步配置“渠道專員”具有“渠道”菜單的功能權限，其能夠查看的渠道數據權限范圍則僅為“我的”，而“渠道經理”同樣具有“渠道”菜單的功能權限，但其能夠查看的渠道數據權限的范圍則擴大為“部門”。

具體設計上：

1. 最大部門即為公司
2. 管理員賬號和普通賬號均可禁用或設置為離職
3. 不同部門可以配置相同角色
4. 相同角色的功能權限和數據權限是一樣的

4. 權限系統和其他功能設計的關系

總結完權限系統三個核心的基本原則后，我們還需要指出一點：權限系統的設計方案，在整個系統中絕不是孤立的，它能否實現設計目標，并和整個系統完美配合，還需要做到以下幾點：

首先，菜單和功能的設計，必須是最小顆粒度，否則就和數據權限產生沖突。例如：我們只需要一個“客戶”菜單即可，不同角色在“客戶”菜單里能干什么事情，由功能權限和數據權限配合進行控制，但切不可出現“我的客戶”+“全部客戶”兩個菜單，這明顯和數據權限有根本沖突，且也是一種不優美、不合理、擴展性差的設計。

其次，數據的分類，必須符合業務需求，且劃分合理。有些數據都是公開的可以不歸入數據權限進行管理，所有角色默認都有即可；有些數據需要進一步細分，例如同樣以“客戶”舉例，在某些公司的業務規則中，就需要將客戶的基本信息和聯系信息分開控制，管理層可以看客戶基本信息，但只有客戶負責人才可以看聯系信息，這種情況就需要將客戶的數據權限分為“客戶基本信息”和“客戶聯系信息”兩個。

最后，權限變更的記錄和所有賬號的行為軌跡記錄一樣重要。權限系統本質是進行權力的限制，沒有監管的權力必定是會失控的。在出現問題的時候，必須同時配合權限變更的記錄、角色變更的記錄和賬號的行為軌跡記錄進行追責和存證，確保維護企業的合法權益。

總結

在合理設計的前提下，權限系統也并非越復雜越好。只有符合目標客戶需求并具備最大彈性的權限系統，才是最好的。

藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務