1. 為什么“用戶體驗要素”值得反復拆解產品經理圈子里有個挺有意思的現(xiàn)象幾乎所有人都聽過《用戶體驗要素》這本書但真正能把里面那套五層模型落到日常需求評審、原型設計和上線復盤里的人其實不多。更多人記住的是那句“用戶體驗就是產品好不好用”然后繼續(xù)在需求文檔里堆功能點。我自己帶過幾個從零到一的產品項目也接手過一些“功能齊全但用戶就是不買賬”的爛攤子踩過的坑讓我越來越確信一件事——用戶體驗不是界面美化也不是交互細節(jié)的堆砌它是一套從戰(zhàn)略到表現(xiàn)的完整決策鏈條。你跳過任何一層后面都得用更高的成本補回來。這篇文章我想聊的不是讀書筆記而是把“用戶體驗要素”這套框架拆成能直接上手用的東西。核心關鍵詞就三個用戶體驗、五層模型、產品設計。我會講清楚這五層分別解決什么問題、每一層的產出物長什么樣、層與層之間怎么銜接以及在實際項目中怎么用這套框架去排查問題。不管你是剛入行的產品助理還是做了幾年但總覺得“差點意思”的交互設計師或者是一個需要把控產品方向的創(chuàng)業(yè)者這套東西都能幫你把模糊的“體驗不好”翻譯成具體的、可執(zhí)行的改進項。先說一個我自己的判斷大部分產品的體驗問題根源不在執(zhí)行層而在戰(zhàn)略層和范圍層沒想清楚。表現(xiàn)層的問題最容易被發(fā)現(xiàn)也最容易被當成全部問題來治結果就是改了一版又一版UI用戶該走還是走。五層模型最大的價值就是逼著你從下往上檢查而不是從上往下瞎猜。2. 五層模型到底在解決什么問題2.1 從抽象到具體的決策漏斗《用戶體驗要素》里把用戶體驗拆成五個層級戰(zhàn)略層、范圍層、結構層、框架層、表現(xiàn)層。很多人把它理解成一個瀑布式的開發(fā)流程先做完戰(zhàn)略再做范圍一層層往下推。這個理解不算錯但容易讓人誤以為必須嚴格按順序來。實際上它更像一個決策漏斗——越往下的層級越抽象越往上的層級越具體每一層都在回答一個核心問題。戰(zhàn)略層回答的是“我們?yōu)槭裁匆鲞@個產品用戶想從中得到什么”。范圍層回答的是“我們要做哪些功能不做哪些功能”。結構層回答的是“這些功能怎么組織用戶怎么在信息之間穿梭”?？蚣軐踊卮鸬氖恰敖缑嫔系脑卦趺磾[放導航怎么設計”。表現(xiàn)層回答的是“最終呈現(xiàn)給用戶的視覺和感知是什么樣的”。我習慣用一個類比來解釋蓋房子。戰(zhàn)略層是“這房子給誰住、用來干嘛”范圍層是“要幾個房間、有沒有車庫”結構層是“房間怎么連通、動線怎么走”框架層是“家具擺在哪、開關裝在哪”表現(xiàn)層是“墻面刷什么顏色、地板用什么材質”。你不會在沒想清楚給誰住之前就開始挑瓷磚但現(xiàn)實中很多產品就是這么干的。2.2 每一層的核心產出物光知道五層的名字沒用得知道每一層該產出什么。我整理了一個對照表這是我在實際項目中反復用的檢查清單層級核心問題典型產出物常見失誤戰(zhàn)略層為什么做、為誰做用戶畫像、產品目標、成功指標目標模糊用“提升體驗”當目標范圍層做什么、不做什么功能列表、需求優(yōu)先級、內容清單功能蔓延什么都想要結構層怎么組織、怎么流轉信息架構圖、流程圖、交互邏輯分類混亂用戶找不到東西框架層怎么擺放、怎么引導線框圖、導航設計、界面布局信息層級不清重點不突出表現(xiàn)層長什么樣、感覺如何視覺稿、設計規(guī)范、動效方案風格不統(tǒng)一視覺壓過功能這張表我建議你打印出來貼在工位上。每次需求評審或者方案討論卡殼的時候對照一下大概率能定位到是哪一層沒對齊。比如團隊在爭論按鈕放左邊還是右邊這其實是框架層的問題但如果戰(zhàn)略層的目標用戶都沒定義清楚這個爭論就沒有判斷標準最后只能靠“我覺得”來收場。2.3 為什么不能跳層跳層是產品設計里最常見的隱性成本。我見過一個項目戰(zhàn)略層只寫了一句“做一個面向年輕人的社交產品”然后直接跳到表現(xiàn)層開始畫界面風格很潮、動效很炫上線后留存率慘不忍睹。復盤的時候發(fā)現(xiàn)范圍層沒定義清楚核心功能是什么結構層沒想明白用戶怎么建立關系框架層沒解決冷啟動時內容從哪來的問題。表現(xiàn)層做得再好也撐不起一個空殼。跳層的另一個表現(xiàn)是“用表現(xiàn)層的問題掩蓋結構層的問題”。比如用戶反饋“找不到某個功能”產品團隊的第一反應往往是“那我們把入口放大一點、顏色調亮一點”。這可能在短期內有效但如果根本原因是信息架構不合理放大入口只是讓用戶更快地走進死胡同。正確的做法是回到結構層重新審視分類邏輯和導航路徑。注意五層模型不是讓你每次做需求都從戰(zhàn)略層重新推導一遍。對于成熟產品的迭代戰(zhàn)略層和范圍層通常是穩(wěn)定的你只需要在結構層、框架層、表現(xiàn)層里做調整。但如果是新產品或者大版本重構從下往上完整走一遍是值得的。3. 戰(zhàn)略層把“用戶想要”翻譯成“產品目標”3.1 用戶需求不是問出來的戰(zhàn)略層最核心的兩件事定義用戶需求定義產品目標。聽起來簡單做起來最難。因為用戶需求往往不是用戶直接說出來的。亨利·福特那句“如果我問用戶想要什么他們會說想要一匹更快的馬”被引用爛了但道理是對的。用戶能描述的是他們遇到的問題不是解決方案。我在實際項目中用的是一個“三層追問法”。第一層問“你遇到了什么不方便”第二層問“這個問題在什么場景下發(fā)生”第三層問“如果這個問題解決了你的感受會有什么變化”。舉個例子用戶說“你們的搜索功能不好用”這是第一層。追問下去發(fā)現(xiàn)是在商品數(shù)量超過一定量之后搜索結果排序不符合預期這是第二層。再追問發(fā)現(xiàn)用戶真正在意的是“快速找到符合預算且評價好的選項”這是第三層。到了第三層你才知道要優(yōu)化的不是搜索框的樣式而是排序算法和篩選條件的設計。這個方法的要點是不要問用戶“你想要什么功能”而是問“你在什么場景下遇到了什么阻礙”。功能是解決方案場景和阻礙才是需求本身。3.2 產品目標要可衡量“提升用戶體驗”不是產品目標因為它沒法衡量。戰(zhàn)略層的產品目標必須是具體的、可量化的。我通常會把目標分成三類用戶目標、業(yè)務目標、技術目標。用戶目標關注的是用戶行為和感受的變化比如“新用戶首次完成核心操作的時間從3分鐘降到1分鐘以內”。業(yè)務目標關注的是商業(yè)指標比如“注冊轉化率提升15%”。技術目標關注的是系統(tǒng)能力比如“頁面加載時間控制在2秒以內”。這三類目標之間往往存在張力比如為了提升注冊轉化率把流程簡化可能會犧牲一些用戶信息的完整性。戰(zhàn)略層的作用就是把這些張力擺到桌面上讓團隊知道優(yōu)先級是什么。實操心得戰(zhàn)略層的目標不要超過三個。超過三個等于沒有重點。我見過一個項目的戰(zhàn)略文檔寫了八個目標結果每個季度都在調整優(yōu)先級團隊疲于奔命。后來砍到兩個核心目標反而推進得更快。3.3 用戶畫像要具體到能吵架用戶畫像不是畫一個卡通人物寫上“張三28歲白領”就完事了。好的用戶畫像應該具體到團隊能為了“這個功能張三會不會用”而吵架。我習慣用“場景行為痛點”的結構來描述用戶畫像。比如“通勤場景下的內容消費者”每天早上8點到9點在地鐵上單手操作手機網絡信號不穩(wěn)定主要行為是快速瀏覽標題和短內容痛點是加載慢、操作復雜、內容太長看不完。這個畫像一出來很多設計決策就有了依據(jù)——按鈕要大、操作要少、內容要短、加載要快。如果團隊在爭論要不要加一個復雜的手勢操作對照這個畫像就知道答案了。戰(zhàn)略層還有一個容易被忽略的產出物不做什么。明確列出“我們不為哪些用戶服務”“我們不解決哪些問題”這比列出要做什么更能統(tǒng)一團隊認知。我見過太多產品因為想討好所有人最后誰都沒討好。4. 范圍層功能取舍的決策框架4.1 功能列表不是越長越好范圍層的核心任務是決定“做什么”和“不做什么”。大部分團隊在這一層的典型問題是功能蔓延——每個需求評審都有人提“順便把這個也做了吧”結果版本越做越大上線時間一推再推核心功能反而沒打磨好。我用的方法是“功能價值矩陣”。橫軸是“用戶價值”縱軸是“實現(xiàn)成本”把每個候選功能放進四個象限高價值低成本優(yōu)先做、高價值高成本規(guī)劃做、低價值低成本有空做、低價值高成本不做。這個矩陣的關鍵是“用戶價值”的評估標準要統(tǒng)一不能憑感覺打分。評估用戶價值的時候我會問三個問題這個功能能幫用戶完成什么任務不做這個功能用戶有沒有替代方案這個功能影響的是核心用戶還是邊緣用戶三個問題的答案越具體打分越靠譜。4.2 需求優(yōu)先級不是拍腦袋優(yōu)先級排序是范圍層最容易引發(fā)爭論的環(huán)節(jié)。產品說這個重要技術說那個做不了設計說另一個體驗更好。我的經驗是把優(yōu)先級判斷拆成可量化的維度讓爭論有據(jù)可依。我常用的維度有四個用戶覆蓋度影響多少用戶、使用頻率用戶多久用一次、業(yè)務影響對核心指標的影響程度、實現(xiàn)復雜度技術成本和依賴關系。每個維度按1到5分打分加權求和。權重根據(jù)產品階段調整——早期產品更看重用戶覆蓋度和使用頻率成熟產品更看重業(yè)務影響。這個方法不能保證結果絕對正確但能讓討論從“我覺得”變成“數(shù)據(jù)說”。而且打分的過程本身就能暴露很多信息比如技術團隊在評估復雜度的時候可能會提出更簡單的替代方案。4.3 內容清單和功能清單一樣重要范圍層不只是功能列表還包括內容清單。特別是內容型產品內容的質量、數(shù)量、更新頻率直接決定了用戶體驗。我見過一個知識付費產品功能做得很完善但內容更新跟不上用戶來了發(fā)現(xiàn)沒什么可看的很快就流失了。內容清單要明確內容從哪來UGC還是PGC、內容怎么分類、內容怎么更新、內容質量怎么把控。這些問題如果在范圍層沒想清楚到了結構層和框架層就會變成無解的難題。比如UGC內容如果沒有審核機制到了表現(xiàn)層就會出現(xiàn)大量低質量內容影響整體體驗。常見問題范圍層和結構層的邊界在哪里我的判斷標準是范圍層回答“有什么”結構層回答“怎么組織”。比如“有文章、視頻、音頻三種內容形式”是范圍層“這三種內容怎么分類、怎么關聯(lián)、怎么推薦”是結構層。5. 結構層讓用戶不迷路的信息架構5.1 信息架構的三種組織方式結構層的核心是信息架構和交互設計。信息架構解決的是“內容怎么分類”交互設計解決的是“用戶怎么操作”。這兩件事經常被混在一起討論但它們的判斷標準不同。信息架構的好壞看用戶能不能找到東西交互設計的好壞看用戶能不能順暢完成任務。信息架構有三種基本的組織方式層級式、矩陣式、線性式。層級式最常見適合內容有明確從屬關系的場景比如電商分類。矩陣式適合內容可以從多個維度訪問的場景比如按價格和按品牌都能篩選。線性式適合有固定順序的場景比如注冊流程。選擇哪種方式取決于用戶的心智模型。用戶在想找某個東西的時候腦子里通常已經有一個分類預期。如果你的分類和用戶的預期不一致用戶就會迷路。我常用的驗證方法是“卡片分類法”把內容項寫在卡片上讓目標用戶自己分組看看他們的分類邏輯和你的設計是否一致。5.2 交互流程要畫到“異常路徑”畫流程圖的時候大部分人只畫正常路徑用戶打開頁面、點擊按鈕、完成任務。但真正影響體驗的往往是異常路徑網絡斷了怎么辦、輸入錯誤怎么辦、權限不夠怎么辦、內容為空怎么辦。這些異常路徑如果在結構層沒考慮到到了開發(fā)階段就會變成臨時補丁體驗很難保證。我習慣在流程圖里用不同顏色標注正常路徑和異常路徑異常路徑至少要考慮四種情況加載失敗、輸入無效、權限不足、內容為空。每種情況都要有明確的用戶提示和下一步操作建議。比如內容為空的時候是顯示“暫無內容”還是推薦其他內容是引導用戶去創(chuàng)建內容還是返回上一頁這些決策在結構層就要定下來。5.3 結構層的驗證方法結構層的方案怎么驗證最常用的方法是樹狀測試和可用性測試。樹狀測試是給用戶一個任務讓他在信息架構樹里找到目標內容看能不能找到、需要幾步找到?？捎眯詼y試是讓用戶實際操作原型觀察他在哪里猶豫、在哪里出錯。這兩種方法我都在項目里用過說句實在話樹狀測試更適合驗證分類邏輯可用性測試更適合驗證交互流程。如果時間有限優(yōu)先做可用性測試因為用戶的實際操作行為比分類偏好更能暴露問題。測試樣本不用多5到8個目標用戶就能發(fā)現(xiàn)大部分嚴重問題。實操心得做可用性測試的時候不要問用戶“你覺得這個設計怎么樣”而是給一個具體任務比如“你想買一雙跑步鞋預算500以內請找到符合條件的商品”。觀察他的操作路徑記錄他在哪里停頓超過3秒、在哪里點了返回、在哪里皺眉頭。這些行為信號比口頭反饋可靠得多。6. 框架層界面上的每一像素都有理由6.1 線框圖的三個層次框架層的產出物主要是線框圖。線框圖不是隨便畫幾個框它要解決三個層次的問題信息層級、導航路徑、操作入口。信息層級決定用戶先看到什么、后看到什么。導航路徑決定用戶怎么在頁面之間跳轉。操作入口決定用戶在哪里完成核心操作。我畫線框圖的時候會遵循一個原則一個頁面只解決一個核心任務。如果一個頁面上有多個同等重要的任務用戶就會分心。比如商品詳情頁的核心任務是“讓用戶決定買不買”那么加入購物車和立即購買就是核心操作其他如分享、收藏、客服都是輔助操作在視覺權重上要明確區(qū)分。線框圖階段不要糾結顏色和字體那是表現(xiàn)層的事。框架層關注的是布局和層級。我見過太多團隊在線框圖階段就開始爭論按鈕顏色結果結構問題被掩蓋了。6.2 導航設計的常見陷阱導航設計是框架層最容易出問題的地方。常見的陷阱有三個導航層級過深、導航標簽含義模糊、導航狀態(tài)不清晰。導航層級過深是指用戶要點擊很多次才能到達目標頁面。移動端一般建議不超過三層桌面端可以適當放寬。如果層級確實很深就要考慮用搜索、快捷入口、推薦等方式來縮短路徑。導航標簽含義模糊是指用戶看了不知道點進去是什么。比如“更多”“其他”“相關”這種標簽用戶無法預判內容。好的標簽應該是具體的、用戶能理解的比如“相似商品”“購買過的人還看了”。導航狀態(tài)不清晰是指用戶不知道自己當前在哪個位置。面包屑導航、高亮當前菜單項、頁面標題都是解決這個問題的常用手段。特別是移動端用戶很容易迷失清晰的導航狀態(tài)能顯著降低焦慮感。6.3 框架層的檢查清單框架層方案完成后我會用一份檢查清單過一遍用戶第一眼看到的是不是最重要的信息核心操作是否在拇指可觸達的范圍內移動端頁面之間的跳轉邏輯是否一致返回操作是否符合用戶預期空狀態(tài)、加載狀態(tài)、錯誤狀態(tài)是否都有設計信息密度是否適合目標用戶的使用場景這份清單看起來簡單但能篩掉大部分框架層的低級錯誤。特別是空狀態(tài)和錯誤狀態(tài)很多團隊只設計正常狀態(tài)用戶遇到異常時看到一片空白或者一堆報錯代碼體驗直接崩掉。7. 表現(xiàn)層視覺不只是好看7.1 視覺設計的三個功能表現(xiàn)層是最容易被誤解的一層。很多人覺得表現(xiàn)層就是“把界面做好看”但實際上視覺設計承擔著三個功能引導注意力、傳達信息層級、建立情感連接。引導注意力是指通過顏色、大小、對比度等手段讓用戶的視線按照你期望的順序移動。比如電商詳情頁用戶第一眼應該看到商品圖片第二眼看到價格和核心賣點第三眼看到購買按鈕。如果視覺設計沒有引導用戶可能第一眼看到的是促銷廣告反而忽略了商品本身。傳達信息層級是指通過視覺手段區(qū)分信息的重要程度。標題和正文的字體大小、顏色深淺、間距大小都在告訴用戶哪些信息更重要。如果所有信息看起來都一樣重要用戶就不知道從哪里看起。建立情感連接是指視覺風格傳遞出的情緒和調性。同樣是工具類產品有的看起來專業(yè)嚴謹有的看起來輕松活潑。這種調性要和目標用戶的心理預期匹配。面向企業(yè)用戶的產品用太活潑的配色用戶會覺得不靠譜面向年輕用戶的產品用太沉悶的配色用戶會覺得無趣。7.2 設計規(guī)范的價值表現(xiàn)層最容易被忽視的產出物是設計規(guī)范。設計規(guī)范不是限制設計師的創(chuàng)造力而是保證產品在不同頁面、不同狀態(tài)下的一致性。沒有設計規(guī)范的產品做幾個版本之后就會出現(xiàn)各種不一致按鈕圓角不一樣、顏色深淺不一樣、間距大小不一樣。用戶可能說不出來哪里不對但會覺得“不精致”。設計規(guī)范至少應該包含色彩系統(tǒng)主色、輔助色、語義色、字體系統(tǒng)字號、字重、行高、間距系統(tǒng)基礎單位、常用組合、組件庫按鈕、輸入框、卡片等。這些規(guī)范要同步給開發(fā)和測試確保實現(xiàn)和設計一致。常見問題設計規(guī)范做多細我的經驗是核心組件和常用頁面要細邊緣場景可以粗。比如按鈕的各種狀態(tài)默認、懸停、點擊、禁用、加載要定義清楚但某個很少出現(xiàn)的彈窗可以靈活處理。規(guī)范是為了提高效率不是為了增加流程。7.3 表現(xiàn)層的驗收標準表現(xiàn)層做完之后怎么驗收我通常從三個維度檢查一致性、可讀性、適配性。一致性是指同一類元素在不同頁面是否表現(xiàn)一致。比如所有的主按鈕是不是同一個顏色、同一個圓角、同一個點擊反饋?？勺x性是指文字是否清晰易讀包括字號是否夠大、對比度是否足夠、行高是否舒適。適配性是指在不同屏幕尺寸、不同設備上是否都能正常顯示。這三個維度里適配性最容易被忽略。設計師在電腦上看效果很好到了手機上發(fā)現(xiàn)文字太小、按鈕太擠。我建議在表現(xiàn)層階段就用真機測試不要等到開發(fā)完成才發(fā)現(xiàn)問題。8. 五層模型在實際項目中的排查應用8.1 用五層模型定位問題五層模型最大的實用價值是排查問題。當用戶反饋“體驗不好”的時候你可以從下往上逐層檢查定位到具體是哪一層出了問題。我整理了一個排查表這是我在實際項目中反復用的用戶反饋可能的問題層級排查方向“不知道這個產品能干嘛”戰(zhàn)略層價值主張是否清晰“功能太多太亂”范圍層功能優(yōu)先級是否明確“找不到想要的東西”結構層信息架構是否合理“不知道怎么操作”框架層導航和引導是否清晰“看起來不舒服”表現(xiàn)層視覺規(guī)范是否統(tǒng)一這個表不能覆蓋所有情況但能幫你快速縮小排查范圍。比如用戶說“找不到想要的東西”你先檢查結構層的信息架構而不是急著改界面顏色。8.2 從表現(xiàn)層反推結構層問題有時候表現(xiàn)層的問題其實是結構層問題的癥狀。比如用戶反饋“頁面太亂”你去看表現(xiàn)層發(fā)現(xiàn)視覺設計確實有問題但改了一版之后用戶還是覺得亂。這時候就要往上追可能是結構層的信息分類不合理導致頁面上堆了太多不相關的內容。我遇到過一個典型案例一個后臺管理系統(tǒng)的用戶反饋“操作效率低”。表現(xiàn)層看界面很整潔按鈕也很清晰。框架層看導航和布局也沒問題。追到結構層才發(fā)現(xiàn)核心操作流程需要跳轉五個頁面每個頁面都要重新加載數(shù)據(jù)。用戶效率低的根源是流程設計不合理不是界面問題。后來把五個頁面合并成兩個效率問題就解決了。這個案例說明一個道理表現(xiàn)層的問題好改結構層的問題難改但結構層的問題影響更大。如果只改表現(xiàn)層可能短期內用戶不抱怨了但根本問題還在。8.3 五層模型的迭代應用五層模型不是一次性的而是持續(xù)迭代的。產品上線后用戶行為數(shù)據(jù)會告訴你哪一層需要調整。比如數(shù)據(jù)顯示用戶在某個頁面停留時間很短就離開了可能是框架層的信息層級有問題。如果用戶在某一步驟的流失率很高可能是結構層的流程設計有問題。我習慣在每個版本復盤的時候用五層模型過一遍戰(zhàn)略層有沒有變化范圍層有沒有新增或砍掉功能結構層有沒有調整框架層和表現(xiàn)層有沒有優(yōu)化這樣能保證產品迭代是有邏輯的而不是東改一下西改一下。實操心得不要試圖一次性把五層都做到完美。資源有限的情況下優(yōu)先保證戰(zhàn)略層和范圍層清晰結構層合理框架層和表現(xiàn)層可以快速迭代。戰(zhàn)略層和范圍層的問題如果拖到后面才發(fā)現(xiàn)返工成本極高。9. 常見問題與避坑指南9.1 五層模型用不起來的原因很多人學了五層模型之后覺得“道理都懂但用不起來”。我觀察下來主要有三個原因。第一個原因是團隊沒有共識。產品經理學了五層模型但設計師和開發(fā)不認討論的時候還是各說各的。解決辦法是在項目啟動會上就把五層模型作為共同語言每個決策都明確是在哪一層做的。第二個原因是時間壓力。項目排期緊團隊覺得“沒時間想那么多”直接跳到畫原型。結果原型改了一版又一版反而更浪費時間。我的建議是哪怕只花半天時間把戰(zhàn)略層和范圍層對齊后面能省下好幾天的返工。第三個原因是缺乏驗證。五層模型每一層都需要驗證但很多團隊做完方案就直接開發(fā)沒有用戶測試。我的經驗是結構層和框架層至少要做一輪可用性測試表現(xiàn)層至少要做一輪視覺走查。這些驗證花不了太多時間但能發(fā)現(xiàn)大部分嚴重問題。9.2 五層模型不是萬能藥五層模型是一個思考框架不是操作手冊。它幫你把復雜問題拆解成可管理的部分但具體怎么拆、怎么解還是要靠你的判斷。不同產品、不同階段、不同團隊五層模型的用法都不一樣。比如To B產品和To C產品戰(zhàn)略層的側重點完全不同。To B產品更關注決策鏈和業(yè)務流程To C產品更關注用戶動機和使用場景。再比如早期產品和成熟產品范圍層的策略也不同。早期產品要快速驗證核心價值功能要少而精成熟產品要滿足不同用戶群體的需求功能可以更豐富。我見過一些團隊把五層模型當成 checklist每層都填一堆文檔結果文檔很厚但產品還是不行。問題在于他們把模型當成了目的而不是工具。模型是幫你思考的不是替你思考的。9.3 五層模型和其他框架的關系五層模型和其他產品設計框架并不沖突而是互補的。比如設計思維Design Thinking強調同理心、定義問題、創(chuàng)意發(fā)散、原型驗證這和五層模型的戰(zhàn)略層、范圍層、框架層、表現(xiàn)層有對應關系。精益創(chuàng)業(yè)Lean Startup強調最小可行產品和快速迭代這和范圍層的功能取舍、表現(xiàn)層的快速驗證也有交集。我的建議是把五層模型作為底層框架其他方法作為具體工具。比如用設計思維的方法做用戶調研用精益創(chuàng)業(yè)的方法做功能驗證但整體上還是用五層模型來組織思考。這樣既有框架的完整性又有方法的靈活性。10. 我個人的一些實操體會做了這么多年產品五層模型對我最大的幫助不是讓我知道該做什么而是讓我知道不該做什么。每次團隊討論陷入細節(jié)爭論的時候我就會問一句“這是哪一層的問題”這個問題往往能讓討論回到正確的軌道上。還有一個體會是五層模型里戰(zhàn)略層和范圍層是最需要反復確認的。因為這兩層的變化會直接影響下面三層。我見過太多項目因為戰(zhàn)略層目標變了導致范圍層功能要砍結構層流程要改框架層和表現(xiàn)層全部重做。如果能在戰(zhàn)略層和范圍層多花一點時間對齊后面的返工成本會低很多。最后分享一個小技巧每次做新功能或者改版的時候先寫一句話描述這個功能在五層模型里分別是什么。比如“戰(zhàn)略層提升新用戶留存范圍層增加新手引導結構層引導流程嵌入核心操作路徑框架層用氣泡提示和進度條表現(xiàn)層品牌色和插畫風格”。這一句話寫出來團隊對要做什么就清楚了后面執(zhí)行起來也順暢得多。這個內容后續(xù)還可以這樣擴展針對不同產品類型工具類、內容類、電商類、社交類分別整理五層模型的側重點和常見陷阱或者把五層模型和數(shù)據(jù)分析結合起來用數(shù)據(jù)指標來驗證每一層的效果。這些方向我在實際項目中都有嘗試后面有機會再展開聊。