產品設計七層自檢模型:為了更專業,更為了一種責任

18 評論 18960 瀏覽 123 收藏 63 分鐘

本文主要介紹了對產品設計評審的視角,這個視角可以用來幫助產品設計人員對自己產品的產品設計文檔進行自檢,或者作為團隊進行設計評審的參考。

如果你是一名新晉產品助理,是否遇到過好不容易接到獨立制作PRD的任務卻在提交評審前提心吊膽,評審中被產品經理擊中無數要害的窘境。

如果你是一名產品經理,是否遇到過Deadline緊張,分身乏術,自認為簡單的需求卻經助理幾次翻版都無法達到可用條件的設計的窘境。

如果你是一名UI設計師,是否遇到過陪著產品加班數個夜晚,盡管UI做得再完美都難抵設計被駁回的窘境。

產品設計,尤其是新功能新產品設計,是一個從“0”到“1”的過程。

市場在變、用戶在變,一個需求要經歷需求評審、設計評審、技術評審等各個不同的評審環節,在這些環節中產品設計需要經歷產品部、技術部、市場部、銷售部、實施部甚至各總監、經理的審視。任何一個環節出問題都可能導致評審不通過,項目延期甚至Cancel。

如何讓自己的作品可以披荊斬棘經過層層評審,是一件極具“藝術”挑戰的事情。有技、懂人、識流程是三個重要技能支撐。

本文不對以上三個技能做拓展,而專注于介紹我在日常工作中積累總結出的產品設計自檢辦法,與各位產品人分享,歡迎批評指正。

很幸運經歷過技術、運營崗位后投身產品職能,有幸就職外企、國企、創業企業并目前投身在民營企業中。所有這些經歷讓我可以從不同維度看到過不同的吐槽方式,看到了各職能部門間的界限,認識到產品的重要以及產品應該扮演的角色及起到的作用。

從自己做功能設計、接手需求管理到為新人的設計做預審把關,這些工作讓我逐漸形成了一套自己對產品設計評審的視角,盡管有許多概念來自讀書學習,但也逐漸融入到了習慣中。

感謝精煉經驗推出書籍傳播知識的大師們,本文主要介紹前文提到的對產品設計評審的視角,這個視角可以用來幫助產品設計人員對自己產品的產品設計文檔進行自檢,或者作為團隊進行設計評審的參考。以下切入正題。

七層自檢模型:

“產品設計七層自檢模型”(作者命名),將自檢內容劃分為7個部分,分別是:戰略層、范圍層、結構層、線框層、展示層、技術層及溝通層。

大部分產品人對前5層都不會陌生,是的,它是來自于用戶體驗要素的5層概念。這個5層概念除了可以用在產品設計自檢,同時也可以用在競品分析等其它產品工作中,對我個人十分有幫助。

只是在這一份七層自檢模型里,這5層可能不會與《用戶體驗要素》內所述概念完全相同,而會增加一些我的個人理解。

[戰略層] —— 確保產品設計方向沒有明顯的錯誤

在戰略層,進行產品自檢時,分別關注以下幾個部分:企業戰略、產品組合戰略、核心競爭力、環境、客戶、用戶、場景、痛點與動機、競品與標桿、定位與商業模式。

在進行這些部分自檢時,首先確認這些部分已經被準確識別,企業戰略是什么?產品客戶是誰,產品定位是什么?等等。其次確保這些戰略層信息融入到產品經理的設計過程中,檢查產品設計與戰略層是否有相?;蛘哌z漏的地方。

1.確保與企業戰略匹配

不知道有多少朋友會對“企業愿景”、“企業使命”、“企業核心價值觀”嗤之以鼻(曾經我是如此),自從完成創業及戰略課程后,我便不再有這樣的想法了。

如果把企業比做“人”,戰略管理部門就是“大腦”,通過制定統一的戰略指揮企業這個“人”往前行進。各部門(包括產品)則可比喻成“人”的各個身體部分??梢栽O想當“左腳“希望前行,而“右腳”卻希望后退是一件多么可怕的事情,要么這個“人”將停止行進,要么“跑偏”甚至“摔倒”。

回歸到產品上,作為企業創新與創造價值的落腳點,如果與企業戰略背道而馳后果可想而知。一個與戰略不一致的產品將給企業帶來巨大內耗,即使獨立評判這個產品本身的方向是對的,卻也掩蓋不了產品在戰略執行上的失敗。

每一個產品經理在產品設計過程中,尤其方案確定時一定要確保產品方案是與企業戰略匹配的。

2.確保與產品組合戰略匹配

一個企業會有不同產品線組合,一個產品線也可能由不同的產品組合而成。這些產品組合(或產品線組合)既然被稱之為組合,定有其既有的規劃好的“協同效應”(1+1>2)。就像實業中常見的“刀架+刀片”盈利模式,在這個產品組合(剃須刀架+刀片)中一部分扮演高性價比(刀架)的角色,而另一部分負責收益(刀片)。

轉到互聯網中,To B行業常見的通過提供SaaS管理工具、交易平臺等價值型功能獲得流量,最終通過廣告產品、金融產品或者咨詢類產品獲得盈利。每個戰略規劃出來的產品都有其意義,不可因為其離現金“遠”,難以獲得直接盈利而在心理上弱化其價值。

每一個產品經理在設計產品時都要弄清楚該產品的戰略位置、目標,與其在產品組合內的任務與價值(理論上企業績效考核也應與之匹配)。

3.考慮與核心競爭力匹配

市場競爭愈發激烈,處處紅海。產品想要獲得藍海機會,就需要具備出色的“定位”能力以及構筑“競爭壁壘”的能力。而要完成這兩點,最直接好用的應該就是企業自身的“核心競爭力”了,這個競爭力可能是專利、客戶關系、壟斷資源或其它。

并不是說每一個企業都一定有核心競爭力,也并不是說每一個核心競爭力就一定能被正在設計的產品用上。但至少我認為每一個產品經理應該捋一遍企業核心競爭力并試圖與產品、市場做“笛卡爾積式”地思考,即使最終尋求不到重合點至少不會遺憾沒有利用好企業自身優勢與資源。

例如:如果你有牢固的客戶關系作為核心競爭力,那么你產品設計可能將首先圍繞這群穩定客戶展開。如果你有獨家技術專利,那么你的產品設計往往將圍繞這項專利進行開展。不是非得被核心競爭力所限定,只是往往圍繞著它們,你的產品將可能更易獲得成功。

設計完成后,重審產品與核心競爭力匹配程度將有助于確保公司資源與競爭力被充分利用,增強產品競爭力。

4.檢查與環境匹配

從PESTLE分析模型:政治、經濟、社會、技術、環境、法律六要素出發,產品經理可以對自己正在設計的產品的整體環境進行分析。找到當中有利因素利用、找到不理因素規避。

例如在互金早期相應制度寬松許多業務有利可圖,隨著法律要素的不斷收緊,互金也變得越來越難做。一個互金產品經理就應該很好的評估法律對產品現在與未來的影響,以確保產品設計及商業模式設計可以應對法律約束所帶來的風險。

設計完成后,重審產品與環境匹配程度將有助于排查產品與環境不匹配風險,避免不必要的后續資源浪費。

5.確認找到客戶、用戶、場景、痛點與動機

  1. 客戶作為最終制定產品購買決策的人或企業,沒有客戶產品將無法獲得回報;
  2. 用戶作為最終使用產品的人,對產品最后是否真的可以提供價值有重要影響,沒有用戶的產品將失去其價值;
  3. 場景是產品與現實業務的結合點,沒有場景產品功能無處落地;
  4. 痛點與動機是產品價值的來源。

這四點是在戰略層面需要產品經理收集整理的重要素材,它們將貫穿整個產品設計始終,用于各個設計點的決策與判斷。

設計完成后,重審產品客戶、用戶、場景、痛點與動機將有助于產品經理發現新功能點及優化點。

6.確認找到真正的競爭對手及標桿

找到真正的競爭對手除了可以用于做競爭分析以對產品風險進行評估外,還可以通過分析競爭力確認自己產品的定位。而另一個很重要的作用是:競爭對手以及其它領域的標桿是對產品設計進行檢驗的一個重要信息源。

產品經理可以通過對比尋找差異,通過思考差異找到設計優化點;還可以通過對比尋找相近點,增加自己對產品設計的信心。

對于一個手機購物APP來說,可以找到另外一款手機購物APP或者拼團APP再或者Web端購物網站來進行自檢。無論從產品分類設計、購物車設計到支付流程設計,我相信都會有可以對比和值得思考的地方。

7.確認定位

確定企業自身核心競爭力并尋找到真正的競爭對手后,企業便有了確定自身定位的基本依據。當企業對產品確定了定位后,產品設計應該遵照著產品定位的方向進行設計上的考量。

“一個面向知識青年的在線課程網站”和“一個面向幼兒益智啟蒙在線課程網站”,盡管均屬于教育行業,都是Web端產品,卻因為定位的不同,不論從產品風格、內容來源、展示形式以及收費方式上都將由各自獨特的考量點。

設計完成后,不要忘了回想產品的“定位”以確保設計可以適配對產品的定位。

8.確認商業模式

一個盈利模式是通過供應鏈金融獲得收益的供應鏈協同平臺,在產品設計時就不得不考慮在簡化流程與獲得更多業務與經營信息之前的權衡問題。而一個產品的成本結構對產品設計及研發的成本投入,也將決定產品設計的廣度、深度。系統與用戶的交互界面作為產品與用戶的溝通渠道之一,在維護客戶關系需要時,產品設計也可能配合銷售或運營團隊進行客戶溝通功能設計。

更多與商業模式有關的要素,我推薦商業模式畫布(BMC)以及精益畫布。從中你可能學到更多商業模式要素,幫助你通過商業模式角度自檢自己產品是否可以更好的滿足商業模式要求。

隨筆感悟1-不要過度追求戰略:

要站在戰略角度宏觀思考,但不要過度追求戰略,有的成功會誕生在錯誤戰略方向的路上。

在現今創業浪潮中,沒有戰略和策略的嘗試已經越來越難以成功。在這之中會有兩個極端:

  • 一個極端是過度追求戰略,遲遲不肯行動實踐,殊不知有更多的困難會潛藏在戰略選擇后的路上。
  • 另一個極端是藐視戰略的存在,盲目沖撞走一步、看一步。

而我認為精益方法正式這兩種極端的折中,因為:

  1. 我認為精益方法支持實踐中調整。
  2. 我認為精益方法是有戰略地試錯。

確定時間、給予目標,不成則換,成則加強。產品設計亦是如此。

[范圍層] —— 確保產品只做“該做”的不做“不該做”的

1.資源限定范圍

在產品設計與研發過程中,資金、人力、時間和技術是四大限制性要素。利用好這四要素約束好產品設計的范圍,將有利于規避產品延期或錯過機會窗口期的風險。

2.競品與定位限定范圍

找到競品,給產品設置好定位后,產品的范圍也將得以縮小。

例如初創SaaS企業管理軟件往往不是SAP、用友等大而全的大型企業管理軟件的直面對手,這些初創產品通常會尋求這些大廠所遺忘或忽略的利基市場或功能。這就是競品與定位限定的范圍。

3.用戶、場景、痛點與動機限定范圍

這四點是比較直觀的限定產品范圍的要素,不做非自己用戶的功能,不做計劃場景外的功能,不做沒價值的功能。

這里最重要的可能是區分痛點與動機,其實我想表達的是有強動機的痛點才是更有價值的需求,然而我們往往會發現大部分需求看起來是用戶痛點,用戶使用解除這類痛點的產品功能的動機卻不明顯。

產品設計完成后,反思用戶、用戶的場景、遇到的痛點以及真正使用產品功能的動機,確保有限資源內開發更好的功能范圍。

4.精益限定范圍

精益思想里的MVP方法提示我們不要在早期投入過多精力在追求產品完整性上,而應該更多考慮對產品價值的驗證。精益希望有小成本試錯,保留更多成本投入于經驗證的價值點。所以“精益”本身就是一個對產品范圍的限制。

產品設計完成后,確保自己只在靠譜的價值點投入更多資源,對于尚未確定的價值點,小心謹慎控制好范圍。

隨筆感悟2-產品設計不好弄?別忘了讓運營、實施手段顯身手

宏觀的產品包含了服務,宏觀的服務包含了產品。在產品設計過程中,尤其是To B產品,總是融合了很多業務領域的概念和方法。

每一個產品經理都會嘗試讓產品簡單得小孩子都可以直接上手,可是對To B產品設計來說真的很難,To C時而如此。在絞盡腦汁都難以克服時,千萬不要首先想著用復雜的設計去滿足復雜的場景,別忘了我們還有運營甚至實施人員可以引導用戶更好的使用產品?,F場培訓、駐場指導,使用手冊本身也可以理解為“產品服務”的一部分。

有時運營和實施手段來規避產品復雜度還是有其實用意義的。

[結構層] —— 確保用戶的使用及體驗路徑設計合理

1.信息架構檢查

信息架構是用戶對產品的最初一層“邏輯”認知,是產品面向用戶呈現的邏輯框架,決定了用戶是否可以快速認識產品、快速學習產品以及在使用中快速定位到需要的功能。一旦信息架構設計得不夠好,用戶使用系統會遭遇“操作阻塞”,頻繁的“操作阻塞”會帶來疲勞,自然而然產生抵觸,在遇見更為通暢的可替代產品后,可能就會轉向新產品。

對于To C產品,信息架構尤為重要,對檢查需要更為苛刻,這也是To B和To C產品一個側重點不太相同的地方。對于To B產品,有實施團隊、運營團隊通過提供使用說明書撰寫、培訓、手把手指導等手段引導用戶學習產品。同時對用戶來說,To B產品的切換成本通常比To C的高,因為往往需經過企業決策流程。但無論如何在條件允許的情況下,想方設法設計出良好的信息架構會讓用戶更喜愛你的產品。

(1)寬度與深度檢查

寬度太大的信息架構,用戶初入門時學習產品的成本較高,不易將產品的功能范圍、價值裝入大腦,也難以通過自己學習定位具體功能,完成產品的關鍵路徑;深度太深的信息架構,老用戶操作成本較高,為完成一個業務需要過多系統操作。

在進行該部分自檢時,可以簡單利用數量做為檢查指標:

  • 對于寬度我個人習慣是借鑒“7±2”原則,“7±2”原則大致說的是人的短時記憶容量為7±2既5~9。對于信息架構中出現寬度超過7時(無論哪一級),我都會小心檢查,確保架構對用戶足夠清晰合理。
  • 對于深度根據產品類型不同可能會有較大差異,例如內容產品(新聞資訊)往往2~3層的深度基本可以覆蓋大部分業務場景。而對于Word這樣功能較多的文字編輯軟件,稍微復雜一些的操作可能需要我們下探到4-5層,甚至要通過加載項開啟。

在互聯網產品設計過程中,不同產品確實有不同,但是每個產品經理或者團隊可以設計一個針對某一個產品信息架構設計的規范,幫助自己時刻檢查信息架構設計的合理性。例如:主業務流程起點深度不能超過2層,次級業務流程起點深度不能超過3層等等。

(2)層次邏輯檢查

設計信息架構就像你在寫一篇馬上要給用戶背的文章,信息架構的寬度、深度有助于減少需要在用戶大腦內存儲內容的大小。但是在信息架構設計過程中最重要的可能還要屬層次邏輯檢查,既要保證不同層次間的邏輯關系,又要保證層次內的邏輯關系。

好的信息架構層次邏輯設計,就像好的文章層次邏輯一樣,可以幫客戶更容易找出文章段與段、句與句間的邏輯,這樣邏輯清晰的文章用戶更容易記憶和回想,背誦和使用起來難度也將減少很多。

對于層次間邏輯檢查,需要確保每一個上層與其下層之間的“關系”是合理的,并且層次間的邏輯劃分是對用戶場景有意義的,有一些處于灰色地帶難以界定的下層需要設計統一的規范進行安排。如下圖內我舉了一個關于“新聞查看”的例子來說明層次間邏輯的重要性。

在這個例子里混合劃分方案我認為是最不合理的,有兩處明顯的不合理:

  • 一是主題和呈現方式分類大范圍混用
  • 二是層次內邏輯不清晰(這部分在下一小節介紹),時政->視頻->體育->語音這個順序組合沒有發現任何明顯的邏輯關系。

其次我們看看按呈現方式劃分方案,該方案的劃分咋一看較為合理,因為用戶可能有的喜歡閱讀,有的喜歡看視頻,有的喜歡聽語音。但是如果回到用戶真正“查看新聞”的場景,我們會發現看新聞的場景往往代表他們有空,而在有空的情況下查看新聞,在主題和呈現方式上,主題應該占據更重要的位置,因此使用呈現方式來劃分新聞可能就沒有按主題形式來劃分新聞更能滿足用戶需求。(因為舉例是為了介紹概念,因此以主觀分析為主)。

對于層次內邏輯檢查,需要確保同層次內的信息維度是一致的,或者至少是遵循了一種確定的規范的。容易出現歧義的分類要盡可能避免,不能輕易將區分歧義的任務留給用戶。

例如采購管理、庫存管理、結算管理,每個管理功能都需要做一些基礎參數配置,那么這個參數配置入口就最好放置在層次內的同一個位置上,或者統一抽取出來組成集中配置入口,便于用戶查找。如果這個配置入口在不同功能內放置在不同地方,有的采用Tab做入口,有的采用按鈕做入口,有的采用二級菜單做入口,有的放在系統統一配置內,那用戶可能就要瘋了。

(3)文案檢查

層次邏輯檢查,往往只是在產品設計者層面使得信息架構清晰了。但真正想把層次邏輯準確呈現給用戶,還需要合理文案的配合。

認真檢查調整文案的字數,會讓信息架構看起來更簡潔。認真檢查文案本身的清晰程度,避免歧義并切近用戶及場景習慣將極大程度增加產品的易用性?!皳缸盅邸卑愕摹皬娖劝Y”我認為本該就是產品經理的習慣和責任,真正逼迫產品經理暫時改掉這個“強迫癥”的不應該是自己的懶惰或不重視,而應該是ROI與MVP這兩個希望產品可能更快遞送價值和獲得回報的思維工具。

(4)層次的呈現方式檢查

信息架構的深度可以抵達4-5層之深(甚至更多),除了菜單欄、導航欄以外,其實還有Tab甚至按鈕等信息架構承載形式(往往它們用于承載信息架構末端的信息)。

合理利用Tab及按鈕等呈現方式,可以節省菜單及導航的復雜性,增強用戶的體驗流暢程度。

(5)一致性檢查

以上提到的層次邏輯、文案及呈現方式,僅考慮單獨優化的情況,但實際上,對于信息結構來說更重要的一點是一致性。如果一個每一個一級菜單都遵照層次邏輯、文案和呈現方式設計,但是各自所遵照的層次邏輯、文案和呈現方式不同,則可能會給用戶增加學習成本,需要為不同的一級菜單記憶不同的邏輯。

為了減少這樣類型的用戶負擔,在結構層的最后,需要對信息結構設計的整體一致性進行檢查,保障用戶可以用最小的邏輯負擔承載下我們產品提供的強大價值。

信息架構的設計還有許多有意思的地方需要動腦筋開動,例如一個網站可以具備兩套甚至多套導航入口,最終滿足不同邏輯習慣的用戶。

2.驅動模型檢查

市場上遇到太多的產品實際上真的提供了價值并可以滿足用戶需求,可是為什么卻遲遲不被用戶認可以獲得大范圍使用呢?

產品往往創造價值,但是價值不是自然而然與用戶連接在一起的。在創造之后還需要一個傳遞價值的過程,這個過程會遇到許多不一樣的阻力。常見阻礙用戶選擇產品的阻力來自于三方面:

  • 一是痛點不被用戶所知
  • 二是產品不被用戶所知
  • 三是產品價值難以被用戶所知

第一、第二點大部分在于市場營銷(產品運營)范疇,在產品設計自檢過程我們著重關注第三點。在進行驅動模型檢查時,我主要檢查兩個方面:

  • 一是產品核心價值功能入口是否充分暴露(驅動用戶啟動體驗)
  • 二是關注產品核心價值功能從入口到價值體現的過程是否通暢(驅動用戶完整體驗)

有許多產品核心價值可能來自于多個功能使用完畢的疊加,盡管功能入口暴露充分,但是因為用戶遲遲不能完成前期步驟而使得產品價值無法體現,導致產品最終被放棄。

3.實體關系檢查

隨著設計的逐步深入,產品經理容易基于當前設計的框架、思維以及競品或標桿的實現打磨自己的設計,而忘記用戶思維的構建。一個產品至少擁有四個實體邏輯框架:一個是現實業務的實體邏輯框架,一個在產品經理心中,一個在技術部門心中,另一個在實際用戶心中。

理想情況下我認為:

  • 現實業務的實體邏輯框架是產品經理心中的實體邏輯框架的基礎,是對當前現實業務的直接反映。
  • 產品經理心中的實體邏輯框架是對當前現實業務的簡化和抽象(因為有了技術手段),用于產品設計及用戶培訓。
  • 技術團隊心中的實體邏輯框架是對產品經理心中的實體邏輯框架在技術角度的補充實現,增加了技術實現需要的部分及優化,最終的呈現形式是數據庫結構設計。
  • 用戶心中的實體邏輯框架是產品上市后,實際在用戶心中形成的實體邏輯框架,是用戶對產品功能與現實業務的實際理解。

在實體關系檢查部分,我主要檢查兩個方面:

一是現實業務的實體邏輯框架 VS.?產品經理心中的實體邏輯框架。

確保產品經理心中的實體邏輯框架充分借鑒合理的現實業務實體邏輯,包括詞匯與關系,避免生造詞以及難以直觀理解的業務關系。

另外還關注從產品設計層面是否可以對現實業務進行簡化和合理的重構,幫助用戶真正減輕業務壓力。

二是產品經理心中的實體邏輯框架 VS. 用戶心中的實體邏輯框架。

理論上我認為這兩部分實體邏輯框架一模一樣是最理想的狀態,因為它是產品經理認為在業務層面最為簡約高效的邏輯關系。但是現實情況往往差強人意,產品經理設計的產品實體邏輯關系A往往被用戶理解成A’甚至C或者D。

這一層檢查需要更多的是產品經理的現實“仿真”能力以及“用戶同理心”。站在用戶角度看看他們在第一次看到系統時、在使用系統時是怎么理解系統的。

最后,還想要強調一下關于“避免生造詞”的檢查。

為了保持系統對用戶的簡單和清晰,產品經理應該確保系統內對同一個實體的名稱、狀態、操作使用同樣的文案,與實體無關的信息也盡可能有自己的文案規范。盡可能避免相同概念采用多種文案的情況,例如“編輯”、“修改”這樣的操作,常見都是對一個實體的更新,如果沒有特殊區別,不應該在一個系統內同時存在。

4.用例路徑檢查

產品由若干獨立的用例組成,每一個用例由不同呈現(頁面)和交互(操作與反饋)組成。用例獨立流程檢查包括:

(1)用例路徑長度檢查

用例路徑的長度往往來自于現實業務的復雜度以及系統業務需要,用例越復雜,往往路徑越長,當系統希望額外獲得用戶信息那么路徑也可能被延長。

通過競品、標桿研究,我們可以找到常見完成某一個用例的參考路徑長度,通過對比找到差別較大的用例,檢查是否需要優化。也可以通過思路推導的辦法,先將用例路徑規劃為最短路徑長度,然后通過一個一個要求增加路徑長度的理由逐步增加路徑長度,最終得到一個合理的最短路徑。

(2)用例路徑阻力

單純檢查用戶路徑的長度不能代表用例設計的好壞,因為用例路徑復雜度取決于路徑上每一步阻力的總和。因此路徑檢查還需要考量用例整體阻力,這取決于用戶在路徑上每一步交互與操作的復雜度。

這一檢查,我們可以通過[線框層]部分檢查的結果來匯總得出。

(3)用例路徑阻力分配檢查

在檢查完路徑長度、路徑阻力后,非常容易忽視的一步是用例路徑阻力的分配。這涉及到用戶行為學及心理學知識,例如“沉默成本”、“損失厭惡”等。

例如在一個重要卻復雜的用例路徑中,利用”沉默成本”概念,將業務劃分為5步,其中把阻力低的環節布置在前四步,而把最復雜的步驟放在第5步。當用戶進入第5步后發現都已經完成4步了,為了“沉默成本”將可能增加他繼續完成該步驟的幾率。

5.長業務路徑檢查

長業務路徑檢查的基本方法與用例路徑檢查基本一致,只不過長業務路徑往往是多個用例路徑的結合。

例如“商品購買業務”是“商品搜索”、“詳情查看”、“商品選擇”、“訂單支付”、“訂單跟蹤”、“訂單評價”六個用例的結合。因此需要站在業務路徑角度審視路徑,同時要保證各用例間的銜接,確保用戶可以很好地完成整個業務。

6.新用戶入門路徑檢查

新用戶入門路徑檢查的基本方法與用例路徑檢查基本一致,只不過產品經理在此時要以新用戶的角度來審視整個路徑。確保產品核心價值路徑可以被新用戶成功探索,在用戶的實體邏輯框架構筑期間,通過引導等手段幫助用戶構筑邏輯。

例如可以通過隱藏高級功能選項,增加新手指引或者動效動畫的形式減輕新用戶操作復雜度和邏輯學習負擔。

7.老用戶高頻路徑檢查

老用戶高頻路徑檢查基本方法與用例路徑檢查基本一致,只不過產品經理在此時要以老用戶的角度來審視整個路徑,確保老用戶可以快捷,高效地完成業務。

例如減少不必要的彈窗提示,增加重復業務的模板管理或流程配置項。

有時,我們會發現針對“新用戶”和“老用戶”的檢查結果會有所沖突,例如新用戶需要更少的高級操作來突顯關鍵路徑,而老用戶可能需要高級操作來準確完成業務。此時我們就需要在產品設計上進行權衡了。

在產品創立初期,技術資源少,檢驗產品價值時,可以更多考慮核心用戶感受適度平衡。到了技術資源充足時,可以考慮把新用戶和老用戶的路徑獨立開,變成兩套路徑獨立設計,這樣就可以更精細地服務新老用戶了。

隨筆感悟3-運營經理的“漏斗模型”,產品經理的“白墻模型”

運營體系的同事經常使用漏斗模型來分析用戶在關鍵路徑中的流失情況,而我將“漏斗模型”的思維采用到產品[結構層]設計的分析中,形成了“白墻模型”(相信應該有前輩定義過該分析方法,但目前我的閱讀范圍沒有覆蓋,所以就自己取了個名字)。白墻模型是首先以用例為單位來分析產品[結構層]的。

在“白墻模型”里,用白墻面積代表用例路徑上每一個頁面的阻力。阻力又劃分成兩方面:一部分是“動腦復雜度”,另一部分是“操作復雜度”,分別用白墻的高和寬來表示,路徑上的白墻的面積總和就代表這個用例路徑的用戶阻力。

一個用例要完成的事情,可能會擁有多個路徑,例如例子上骨科完成商品挑選,可以通過三個路徑“搜索挑選”、“分類篩選”以及“廣告直連”。當然除了分析一個用例路徑的阻力還不足以分析出路徑的好壞,還需要結合通過路徑達完成用例后,用戶對完成結果的滿意度。例如通過廣告直連查看到的商品往往可能并不是用戶真正想要的,而通過分類篩選出來的結果可能更精準。

“白墻模型”對我有什么幫助呢?

  • 首先,這個模型幫助我建立了網站地圖的思維,在大腦里將形成整個網站的網站地圖,并給這個地圖的每一個環節增加了阻力表示,讓我可以快速找到阻力大的業務,滿意度低的業務或者對可選用例路徑進行篩選。
  • 其次,為[結構層]的路徑優化提供具象的表達,通過白墻面積高、寬的具象化,路徑不同頁面的具象化,幫助我在阻力(白墻總面積)已經無法減小的情況下,可以考慮結合用戶行為分析進行阻力分配策略的設計。因為在我內心存在一種理解,那就是盡管路徑阻力一樣大,但是阻力的合理分配和調整仍然可以促進用戶路徑目標的更好達成。畢竟環境、用戶、技術在變,阻力組合也要隨之而變。

減小白墻面積,分配白墻面積,平衡阻力與滿意度,就像是游戲,讓設計變得游戲化,充滿技巧和趣味。

[線框層] —— 確保用戶路徑上的每一步布局與交互設計合理

1.頁面導航檢查

頁面是人機交互的信息承載,導航是頁面跳轉的銜接,在結構與文案已經在[結構層]定義清楚的情況下,[線框層]需要產品經理選擇合適的導航樣式承載頁面跳轉訴求。

  1. 邏輯位置展示檢查。在進行頁面導航檢查時,首先我們要檢查頁面是否清晰告知了用戶他目前身處什么位置?例如一些系統通過面包屑或者導航高亮的形式來告知用戶。
  2. 關鍵路徑強度檢查。在進行頁面導航檢查時,在關鍵路徑中,我們要考慮在[線框層]是否給予了足夠的強度來告知用戶他們下一步應該做什么?例如一些系統在業務路徑中增加了步驟導航欄,標識用戶正處于什么業務的什么環節,下一步環節做什么。
  3. 路徑前后通道檢查。在進行頁面導航檢查時,我們要明確在路徑中某一環節某個狀態是否可以回退上一步,進入下一步,以及是否可以跳出路徑。確保進行回退、前進及跳出的導航操作存在。
  4. 多余導航檢查。導航往往占用很多頁面區域,結合業務路徑上下文背景,我們可以針對部分頁面進行導航欄優化,上下文環境中不需要的或者低頻的導航去掉。
  5. 任務式引導檢查。任務式引導式關鍵路徑強調的一種形式,越來越多的系統希望通過任務式引導來減少用戶負擔,清晰準確完成產品業務路徑操作。產品設計過程中,注意結合實際情況檢查系統所提供的用例及路徑,探索是否有形成任務式引導的必要和可能。

2.信息錄入檢查

因為信息錄入是用戶與系統交互時最耗用戶操作的交互類型,與用戶對產品的滿意度有很大關系,需要用心設計,不可小視。信息錄入的兩種主要場景是用于信息登記及用于信息查詢:

  • 信息登記類型的信息錄入,目的是將信息登記入系統存儲以便后續業務的開展;
  • 信息查詢類型的信息錄入,目的是告知系統希望檢索的信息范圍,以便系統為用戶找到所需信息。

對信息登記類型的信息錄入區域進行檢查,著重確保用戶理解所需要填寫的內容,準確錄入信息:

  • 在文案及布局上,恰當的文案及區域劃分,將關聯性強的信息打包在同一個錄入區域有助于用戶快速地在大腦中調取需要填寫的信息。
  • 在組件上,可窮舉的內容可考慮采用可窮舉的交互組件(如下拉菜單),可校驗的內容配合校驗提示組件及時向用戶反饋校驗失敗的內容,可自動帶出的內容可利用級聯等形式為用戶自動帶出,減少用戶的思考和輸入復雜度。

3.信息展示檢查

目前計算機與人的主要交互形式主要還是基于視覺、聽覺,部分硬件設備會支持觸覺,本小節將主要基于視覺介紹對產品設計信息展示的檢查。在視覺上可以采用的元素主要包括靜態(文字、靜態圖片及布局)和動態(視頻、動畫、動態圖片及動效)兩種。

信息展示的重要目的是通過合理地使用靜態元素與動態元素結合的方式向用戶高效地傳遞信息,因此在進行信息展示檢查時,我主要考量:

  1. 組件與樣式選擇:不同類型的信息適合使用不同的組件與樣式,例如訂單數據使用列表展示,百分比占用使用餅狀圖展示,商品列表使用圖文混合列表,商品詳情使用圖文組合。檢查你所設計的產品的每一個主要展示區域,通過與競品標桿比較以及用戶習慣檢查需要展示的信息使用了恰當的組件與樣式。
  2. 易讀性:信息展示于頁面,頁面就像一個小型的產品,也需要[結構層]設計。主次分明,維護恰當的邏輯關系,并且提升通頁的一致性將有助于用戶更輕松地習得信息展示所要傳達的內容。
  3. 實用性:用戶閱讀信息尤其既有的目的,信息展示設計得讓用戶可以更快完成閱讀目的將有助于提升用戶效率,進而提升用戶滿意度。當然有時這個實用性來自于系統要求,我們可以會考慮給用戶暴露一些對產品有價值的“信息”來達到產品目的。

4.功能操作檢查

功能操作是用戶與產品交互的重要連接,功能操作就像信息架構的最末級節點,為了保證操作更為符合用戶的邏輯,我們需要對操作的數量、文案、放置的位置進行檢查。

(1)操作數量:

在思考可能存在的操作時,我們往往可以從現實業務中收集業務操作、從正向操作中聯想到逆向操作、從實體上尋找“增刪改查”操作或者實體間的相互操作。這些操作數量往往非常龐大,可是卻不總是必要的。

例如對于訂單下單我們可以支持取消訂單,可是對于已支付訂單就不應該隨便設計取消支付操作了。對操作數量的控制需要產品經理仔細核對每一個所設計操作的必要性,以及某些低頻操作是否可以用另外的操作所替代。

如果可以那么就可以為系統減少不必要的操作數量,從而減低系統實現以及用戶學習產品的復雜度。

(2)操作文案:

好的操作文案就像好的[結構層]文案,幫助用戶快速理解操作的含義而無需在查看操作釋義。

檢查操作文案時,我一般會檢查并控制文案長度、與操作所對應的實體對照確定邏輯關系證件,并且盡可能確保操作與操作間不存在歧義以避免用戶困擾。

例如對“購物車”設計一個[丟棄]操作就不如文案[清空]來得恰當。

又例如對一個“視頻”設計[查看](實際是查看視頻詳細信息)和[觀看]操作,就不如[詳情]和[播放]來得清晰。

(3)操作位置與多入口:

從一方面看,用戶可能會在不同場景針對不同實體觸發同一個動作,因此設計產品時我們會考慮順應用戶業務路徑設計銜接操作,以滿足用戶操作連續性。

但從另一個方面看,每一個操作就像是一個選擇,對用戶來說選擇多了未必是一個好事情。產品經理需要掌握這兩方面訴求的平衡,對核心業務路徑提供操作便利上的支持,如果難度較大,可以考慮使用任務式引導。而對非核心業務路徑上的操作,需要檢查必要但是低頻的操作并考慮將該其放入核心業務路徑之外的承載頁面里,或者隱藏到“更多操作”里。

5.頁面信息自動填制與保留檢查

用戶在產品中或業務路徑中流轉時,會填制各種信息。產品經理通過合理的頁面信息填制與保留設計,可以避免用戶因為重復填制而產生的負面情緒和滿意度下降。

例如電商平臺下單時,產品級默認送貨地址往往自動帶出。

例如分步填寫注冊信息時,回退上一步或重新進入下一步,能保留的信息避免用戶重新填寫。

6.上下文環境檢查(線上、線下)

進行[線框層]設計非常重要的一步,也最容易被忽略的一步是上下文環境檢查。當在設計某一個頁面時,設計師容易基于當前頁面本身思考而忘記用戶在實際業務執行至本線框頁面的上下文環境。

在這一步檢查中,設計師需要身臨其境地體驗產品,了解用戶執行整個業務路徑至此了解什么、不了解什么、與系統交互的此時手上是否握有什么材料,材料的樣式如何。這些都將幫助產品經理設計出最“接地氣”的產品。

例如在設計信用卡綁定或支付模塊時,產品經理要聯想到用戶此時手上拿著信用卡,如何引導他們輸入信用卡效期,以及背后的三位安全碼。信用卡效期“月月/年年”的格式,以及卡片背后的安全碼其實是一大交互難點。

但我們看到大部分產品通過錄入組件備注“月月/年年”以及圖片展示的安全碼位置最終解決了用戶錄入難題。

[展示層] —— 確保用戶路徑上的每一步視覺設計設計合理

在我的職能范疇里,因為有對應UI團隊的關系,大部分專業的UI設計都轉交由專業團隊負責,但是做為“挑剔”的產品設計人員,在高保真設計出來后,還是應該從自己認為對用戶合適的審美角度來對UI團隊提出建議,與UI團隊一起協作為用戶產出更好的體驗與價值。

因為篇幅關系,也因為UI部分尤其專業的技術性,我并不是專家,因此我將簡單從我檢查UI設計的基本原則入手簡單介紹我的檢查辦法。

1.整體主題檢查

不同的產品定位、客群及使用場景多多少少會幫助我們限定網站整體主題的范圍。

例如面向高端商務人士的個人計劃工具產品,就不太可能出現花哨、七彩的產品主題,而可能是黑金或扁平的簡約“工作風”。

例如面向中年群體的養生知識產品,就不太可能是滿是Kitty貓和動畫的產品主題,而可能是類似報紙版面或者其它沉穩靜態風格的主題。

2.頁面字體檢查

關于自己,我往往使用以下約束,在一個展示頁面盡可能不超過兩種字體,不超過三種字號,字體顏色不超過三種,不超過兩種強調方法(加粗、下劃線、斜體)。

因為字體過多變化將導致頁面復雜度提升,就像給書本劃重點全都劃上時,就好像沒有重點一樣,甚至弄臟了書本,給視覺帶來疲勞。

3.頁面色彩檢查

頁面色彩是一個極具深度的學科。色彩有其心理學作用,有冷暖,有關聯主題,也往往有其設計慣例。在進行色彩檢查時,與競品對照,但更多我遵從自己內心的第一感覺,也可以多找幾位朋友一起給予反饋。

例如橙色常用于代表美味,紫色代表神秘,深藍色可能有點憂郁..

例如政府網站常以藍白為主。

4.頁面元素間距檢查

頁面組件等各元素的間距,上留底,下留底,側邊留白都是設計規范的重要組成。間距與色彩檢查相近,需要通過內心第一感覺以及多人的反饋來進行設計檢查。

5.頁面動效檢查

動效不僅可以通過動作來吸引眼球,為產品贏得強調的作用;動效還具有時間性,可以幫助我們進行主次或步驟的演示;同時動效還具有體驗提升的作用,幫助用戶獲得產品使用體驗上的提升。

例如可以通過圖表動效來吸引用戶目光聚焦到圖表。

例如可以通過引導動畫來幫助用戶一步一步習得產品試用步驟。

例如在系統阻塞時播放等待動效,或者在用戶點擊“加入購物車”按鈕時產生將商品縮小并丟入購物車的動效。

[技術層] —— 確保產品設計通過基本技術檢查

互聯網上已經有很多文章在探討產品經理是否需要技術功底,其實這本身就是一個很寬泛的問題。在不同的環境中,對產品經理是否需要技術功底答案是不一樣的。

以下是我認為基礎的需要產品經理考慮到的技術方面:

1.足夠靈活的實體關系

因為產品經理是業務與技術銜接的紐帶,產品經理需要具備一定的面向對象設計能力,確??梢栽O計出或者幫助技術架構師檢查出明顯的實體關系錯誤。

如果技術因為不熟悉現實業務而設計出不夠靈活的實體關系,很可能造成頻繁的數據結構重構,這是大部分產品項目不愿意看到的。

UML用例、類圖和狀態圖是比較不錯的實體關系梳理工具,建議產品經理,尤其是To B的管理系統產品經理學習。

2.深思熟慮的運算過程

因為設計工期著急的關系,產品經理在設計功能時往往注重從戰略層到展示層的5層體驗設計,卻忽略了從技術層面審視功能間的邏輯沖突及運算過程。

例如一個指標評價功能,在設計評價指標算法時,要么會遇到評價指標公式不公平的情況,要么會遇到評價指標公式參數無法取得的情況,再要么發現所設計的呈現的圖表方式、維度根本與實際用戶需要的不一致。

運算過程的檢查,需要產品經理深思熟慮地把系統運算過程在大腦里冷靜的檢查一遍,確保邏輯與算法設計的完整性,切不可浮于表面。

3.滿足MVP的技術替代方案檢查

做產品設計,尤其是To C產品設計,精益方法與MVP是非常有用的工具。越是思維縝密,技術功底足的產品經理越容易陷入“完美”技術方案的思維。

但是一個產品或功能初期真正需要的往往不是完美的技術方案,而是一個可以驗證用戶訴求,并快速滿足用戶期望的產出。在技術層面,產品經理積累越多經驗和理解,將有助于他站在技術的角度以及精益的角度給予產品最適合當下的“完美”設計。

4.基本的可行性檢查

大部分產品經理不會遇到此問題,但是本條備注給初入行業的新人們。具備對自己設計的產品進行基本可行性分析能力將有助于產品設計與研發的高效交流,避免技術評審遲遲得不到通過而影響進度。

[溝通層] —— 確保產品設計可以獲得高效溝通

1.清晰的溝通對象

在產品設計的溝通過程中,因為時間關系準備溝通素材的時間總是很匆忙,以至于許多產品經理可以希望使用一套素材面向多方展開溝通。

對于溝通能力極強的產品經理來說或許可以完成溝通任務,但這樣的溝通結果往往可能不會太理想。因為我們知道我們要面對的是有不同溝通訴求的干系人,他們可能是:設計評審小組、上級領導、研發團隊、用戶、客戶…

檢查并識別出自己所設計的產品的重要干系人,確保他們合理的訴求可以在產品設計中體現出來,并且需要他們關注的點以及他們關注的點在溝通素材中展示出來。

2.清晰的方案溝通

在我所經歷的諸多項目中,一個產品的設計一般會經歷方案設計(BRD+MRD)以及功能設計(PRD)兩個階段。本小節我們重點介紹方案設計檢查:

(1)清晰的需求背景描述

當你遇到過辛苦熬夜通宵設計的產品被關鍵干系人一句“這不是我想要的功能”打回時,你便會領悟到需求背景的重要性。

產品經理需確保需求背景與關鍵干系人(需求發起人)一致以確保產品設計走在正確的道路上;另外還需要確認需求背景被傳遞到研發與測試,幫助他們在研發測試過程中提出好的建議以及做技術層面的決策。

(2)清晰的價值闡述

沒有領導和客戶會在溝通一開始就喜歡聽產品經理津津樂道地描述我們的產品設計是多么專業、好看和細致入微,他們更關心的是我們的產品可以滿足用戶的什么需求,為用戶帶來什么樣的價值。

在嘗試通過簡單的話語清晰描述出產品或功能的價值會幫助你認識到自己設計產品的改進,以及將用戶帶入你及你的產品。

(3)清晰的系統邊界

在產品工作過程中,尤其是產品運行在復雜環境時,系統邊界的確立對溝通尤為重要。

分別針對“用戶-系統”及“系統-系統”邊界的闡述,有助于溝通對象構筑思路,保證他們清楚產品與誰對接,提供什么,需要什么。

(4)清晰的功能范圍

功能范圍產品對外提供價值的承載,是溝通及與功能設計銜接的重要內容。說清楚產品提供什么,和不提供什么,有助于溝通對象了解產品的范圍,確保與需求達成一致。

3.清晰的功能設計溝通

  1. 清晰的用例與業務流程。用例表達最基本的使用場景,業務流程描述業務的執行過程,對用戶及研發團隊理解產品背景有重要幫助。檢查用例與流程表述清晰,確保研發團隊可以快速理解并準確開發功能。
  2. 清晰的結構層設計。結構層設計是產品的基本組成框架,對用戶及研發團隊理解系統功能結構有重要幫助。檢查結構層設計表述清晰,確保研發團隊可以快速理解并準確開發功能。
  3. 清晰的線框層&展示層設計。線框層與展示層設計,對研發團隊開發出與產品經理期望的前端效果有重要幫助。檢查結構層設計表述清晰,確保研發團隊可以快速理解并準確開發功能。

4.清晰的非功能設計溝通

響應時間、支持并發、加載時間等非功能性需求是產品設計在性能方面的補充。檢查非功能設計表述清晰,確保用戶擁有合理的體驗并引導研發拿捏技術實現復雜度。

5.清晰的進度管理計劃

沒有清晰的進度管理計劃難以確保產品及功能按預期上線,所以在溝通方面,產品經理需要檢查產品項目已經進行了有效的進度溝通。

6.清晰的會議與溝通計劃

設計評審會,設計宣講會,迭代啟動會,功能發布會、戰略層變更、需求變更、團隊調整或者臨時發現的設計風險點…產品項目總是需要許多的固定或臨時會議或溝通來完成協調。

產品經理需確保有清晰的會議和溝通計劃,以確保產品開發進度以及干系人在合適的時間得到應該獲知的產品信息。

文末

產品設計是一個自上而下,自宏觀入微觀,自粗到細的過程。在遇到系統分支龐大的情況下,產品經理往往會跳出這種自上而下的遞進邏輯,選擇對不同分支分而治之。這種自上而下和分而治之的思路切換勢必容易造成考慮不夠周全的情況。

產品設計自檢就是為了幫助產品經理在完成產品設計后,重新快速地對自己的作品進行一輪檢查,盡可能多地避免失誤從而提升設計質量。

本文從7層結構出發描述的是作者自己在用的一套思維框架,越往這個樹狀框架的枝葉走,內容越落地,但是也越可能不夠完整,因為最底層的它們均是由經驗匯聚而成。

作者的產品設計經驗面對龐大的產品領域來說仍然很小很小,另外回憶經驗的過程多少也會有所丟失。但仍然希望分享出一些自己的思考及經驗,與各位產品人共同成長。

若這個經驗或多或少能給部分朋友帶來幫助,那我將倍感榮幸。

文末,愿所有勤奮的人,快樂:)

附錄:Mindmap

 

本文由 @Talen 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自 unsplash,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 結構清晰,內容詳實 提供了一個好的框架供繼續完善,是一個好的“產品”~~謝謝LZ

    來自廣東 回復
    1. 打賞的時候忘記登錄了,好氣,應該提示一下 哈哈

      來自廣東 回復
    2. 謝謝:)

      回復
  2. 文章邏輯清晰,從戰略層,范圍層、結構層、線框層,展示層,技術層和溝通層7個層次系統的闡述了產品,剛看文章以為就是用戶體驗要素講的,沒什么新鮮的事情,細看后發現文章有好多個人觀點,個人的總結和分享,雖然文章很長但是卻值得讀

    來自上海 回復
  3. 厲害了

    來自上海 回復
  4. 寫的很精彩

    來自廣東 回復
  5. 厲害厲害

    來自北京 回復
  6. 受教了!

    來自廣東 回復
    1. 謝謝:)

      來自遼寧 回復
  7. 文章很贊!望有機會多多交流!

    回復
    1. 謝謝:)

      來自遼寧 回復
  8. 大佬,可以幾個微信交流下么?

    來自廣東 回復
    1. 謝謝:)

      來自遼寧 回復
  9. 很全面邏輯框架

    回復
    1. 謝謝:)

      來自遼寧 回復
  10. 文章邏輯清晰,從戰略層,范圍層、結構層、線框層,展示層,技術層和溝通層7個層次系統的闡述了產品,剛看文章以為就是用戶體驗要素講的,沒什么新鮮的事情,細看后發現文章有好多個人觀點,個人的總結和分享,雖然文章很長但是卻值得讀

    來自北京 回復
    1. 謝謝:)

      來自遼寧 回復