產(chǎn)品經(jīng)理要如何保證自己能夠在復(fù)雜的協(xié)同工作中展開正確的需求設(shè)計、并實際地解決用戶問題？在本篇文章里，作者就總結(jié)了自己的需求設(shè)計經(jīng)驗，并總結(jié)了7個步驟。一起來看看吧，或許會對你有所啟發(fā)。

作為產(chǎn)品經(jīng)理需要對結(jié)果負(fù)責(zé)，我們要推進(jìn)產(chǎn)品落地并實際解決用戶問題，但是在實際工作中我們會遇到很多質(zhì)疑的聲音，各種指點以及橫向縱向的需求，作為產(chǎn)品經(jīng)理我們應(yīng)該怎么正確的開展一個需求的設(shè)計呢，確保每個需求都能在正確的產(chǎn)品路線上？

一、深挖用戶背后的問題

用戶的需求不管是用戶直述，他人傳達(dá)或者上級要求，我們都需要對用戶進(jìn)行進(jìn)一步的分析，用戶口述的不一定是真實需要的，需要產(chǎn)品經(jīng)理站在用戶的角度去思考問題，我在大廠挖掘用戶問題主要通過溝通與觀察的方式。

在與用戶溝通的過程中不需要直接去問用戶遇到的問題，而是需要清楚地去了解用戶做的每一件事情，每個細(xì)節(jié)的步驟，這樣真正了解用戶后，產(chǎn)品經(jīng)理可以不斷模擬用戶進(jìn)而感受到用戶在實際場景下遇到的問題。（深入了解用戶后，我一般都是在腦海中不斷重復(fù)用戶的場景，來親身感受用戶會遇到哪些問題，提升自己的用戶同理心）

站在用戶角度去思考問題是挖掘到真正問題的有效方式，這里舉一個我在工作中遇到的例子。

當(dāng)時公司有個部門要做一個民航飛行員排班的系統(tǒng)，主要幫助飛行員查看自己的班次與未來的安排。該產(chǎn)品經(jīng)理組織研發(fā)團隊在web端開發(fā)了一個排班日歷，每個飛行員都能登錄web端來查看自己的飛行計劃。

這個產(chǎn)品經(jīng)理其實忽略了一個很嚴(yán)重的問題，就是飛行員去看自己的飛行計劃的話，需要打開電腦登錄到web端后才能查看自己的飛行計劃，明顯不合理。

比較合理的方式應(yīng)該是優(yōu)先開發(fā)移動端的排班日歷產(chǎn)品，隨時隨地方便飛行員隨時隨地查看自己的飛行計劃。出現(xiàn)以上問題的核心原因，就是產(chǎn)品經(jīng)理沒有優(yōu)先站在用戶角度去思考問題，脫離了用戶本身。

確認(rèn)用戶問題或價值后需要判斷該問題是通用問題還是個別場景下產(chǎn)生的問題，通用問題就需要安排在主路線上迭代，優(yōu)先級會高一些，個別場景下的問題則優(yōu)先級會低一些。

這樣當(dāng)我們被輸入需求時，由于產(chǎn)品經(jīng)理站在了用戶角度去思考問題，就會發(fā)現(xiàn)有很多的被輸入需求是沒有必要做的，或是并不緊急的，也會避免成為只會接收需求的工具人。所有的有效需求都需要進(jìn)行管理與跟進(jìn)（我們用的是內(nèi)部的需求管理工具），這樣我們在工作中才會有持續(xù)性，保證產(chǎn)品穩(wěn)定的向前發(fā)展。

這里引用一個討論思考，“什么是問題（痛點），什么是需求”。

有個回答我還是比較認(rèn)同的，說的是問題（痛點）是客觀存在的，而需求就是藥方，產(chǎn)品經(jīng)理是開藥方的人，每個產(chǎn)品經(jīng)理開的藥方可能都會有出入。需求的有效性就需要看產(chǎn)品經(jīng)理的同理心能力了。提升同理心的有效方式就是不斷觀察用戶并成為用戶，所以當(dāng)你遇到問題時，就回歸用戶本身去思考，就會找到對應(yīng)的答案。

二、確認(rèn)最優(yōu)解決方案（最小MVP）

當(dāng)我們確認(rèn)問題后，就需要制定解決方案。解決方案可能會有很多種，但是我們需要找出最優(yōu)解決方案同時是最小的MVP來解決當(dāng)前的用戶問題，避免大而全的情況。這樣上線后能根據(jù)用戶的反饋來快速迭代，避免過度設(shè)計的情況。

最優(yōu)解決方案也是需要站在用戶的角度去思考，用戶的使用成本越低，越簡單易懂，也就越接近最優(yōu)的解決方案。

再回到飛行員排班系統(tǒng)的案例上，解決方案是在移動端開發(fā)排班日歷工具，我們當(dāng)時公司是有自己內(nèi)部的協(xié)同工具（市面的協(xié)同工具有飛書、釘釘、美團大象、企業(yè)微信等），在協(xié)同工具上有相應(yīng)的日歷產(chǎn)品，民航飛行員也屬于公司內(nèi)部員工，平時也都在協(xié)同工具上進(jìn)行日常辦公。

所以整個事情的一個最優(yōu)解決方案應(yīng)該是民航排班系統(tǒng)與公司內(nèi)部的日歷協(xié)同工具做對接（借用日歷的能力），將排班計劃直接顯示在飛行員的日歷上。這樣用戶能比較方便的獲取自己的飛行計劃安排，也無需再去開發(fā)一個移動端的排班日歷頁面，避免重復(fù)造輪子，減少了研發(fā)周期提升了用戶體驗。

產(chǎn)品經(jīng)理不要為了做產(chǎn)品而做產(chǎn)品，而是應(yīng)該對用戶負(fù)責(zé)，通過最簡單的方式去解決用戶的問題。

找到最優(yōu)解決方案后需要橫向縱向去同步當(dāng)前的方案，最好設(shè)計比較簡單的原型界面（需要精準(zhǔn)但不用太細(xì)節(jié)，主要目的是要把事情說清楚），提高溝通的效率，推進(jìn)相關(guān)干系人制定相應(yīng)的計劃。

作為產(chǎn)品經(jīng)理我們是有義務(wù)去推進(jìn)各方（橫向與縱向的相關(guān)干系人，核心用戶、上下級、同級等）針對解決方案達(dá)成一致性的。這一過程也會遇到不同的阻礙與問題（兄弟部門不配合、方案有不同意見等），但是產(chǎn)品經(jīng)理要堅持站在用戶的角度去正確地推進(jìn)事情（我們經(jīng)常會遇到什么歷史原因、時間緊張等問題，這些都是需要站在用戶的角度去解決），只有正確地去推進(jìn)事情，最終才能使用戶滿意，產(chǎn)品才會有價值。

三、產(chǎn)品交互設(shè)計

各方干系人達(dá)成一致后，開始進(jìn)行詳細(xì)的交互設(shè)計，在此之前由于已經(jīng)確認(rèn)了用戶問題與解決方案，我們在設(shè)計交互的時候要根據(jù)解決方案去制定用戶的交互流程，遵循“延續(xù)解決方案，先邏輯后交互，交互體驗閉環(huán)”的原則。

有些公司是有交互設(shè)計師的（我們部門沒有交互設(shè)計師，主要由產(chǎn)品經(jīng)理承擔(dān)該部分的職責(zé)），產(chǎn)品經(jīng)理要把控整體交互邏輯（頁面跳轉(zhuǎn)、點擊交互、界面文案設(shè)計、按鈕位置等。這些與用戶發(fā)生交互的點都屬于交互設(shè)計的設(shè)計范圍），要遵循前期整體的解決方案來進(jìn)行設(shè)計。不要為了交互而交互。交互設(shè)計也是需要遵循MVP的原則，不要過度設(shè)計。

這里舉一個搜索的例子。

交互體驗閉環(huán)就是從用戶點擊搜索的功能開始到結(jié)束，用戶的整體操作分為：點擊搜索-輸入搜索關(guān)鍵詞-查看關(guān)鍵詞搜索結(jié)果目錄-查看結(jié)果詳情-關(guān)閉搜索（在準(zhǔn)備PRD文檔時也是按照這個路徑去準(zhǔn)備需求，這樣能看到完成的用戶路徑，不會遺漏需求點）。

每個環(huán)節(jié)都是用戶與產(chǎn)品發(fā)生交互的部分，需要設(shè)計用戶在操作每個動作后的展示結(jié)果與路徑。而且需要保障整體交互流程為最小MVP的流程，設(shè)計完成之后需要產(chǎn)品經(jīng)理不斷在腦海中模擬整個交互流程，看看是否還存在用戶使用卡點。模擬用戶操作需要化身在用戶的使用場景中去模擬，這樣才能最接近真實的使用情況，發(fā)現(xiàn)當(dāng)前交互設(shè)計中的問題并提前解決，當(dāng)然此項技能需要產(chǎn)品經(jīng)理不斷的練習(xí)和提升的。

交互設(shè)計完成后可以找相關(guān)干系人進(jìn)行溝通，有時我會直接給核心用戶去演示，目的是提前通過交互原型去觸達(dá)用戶，看看是否能解決用戶的問題，如果有問題也能提前優(yōu)化解決，避免造成無效的研發(fā)投入。

四、協(xié)同UI進(jìn)行視覺設(shè)計

視覺設(shè)計也需要延續(xù)解決方案與交互設(shè)計的整體邏輯，主要需要保證視覺的一致性，減少對用戶的使用干擾。產(chǎn)品經(jīng)理需要把控整體的邏輯，設(shè)計負(fù)責(zé)整體視覺與規(guī)范，產(chǎn)品與設(shè)計思路不一致時要進(jìn)行同分討論共同尋找解決方案。

此時的設(shè)計可能會針對交互、邏輯提出相應(yīng)的疑問，產(chǎn)品經(jīng)理則需要始終站在用戶角度去分析解答問題。

此階段要遵循“先邏輯，后視覺”的規(guī)則，不要為了設(shè)計而設(shè)計，避免造成過度設(shè)計。

設(shè)計完成后可以找相關(guān)干系人進(jìn)行討論確認(rèn)，視覺設(shè)計能呈現(xiàn)最終的產(chǎn)品交付效果，相關(guān)干系人也能直接看到交付物，其實在每個關(guān)鍵階段與核心干系人進(jìn)行討論后及時發(fā)現(xiàn)問題，最終就不會產(chǎn)生需求偏差，就把問題牢牢控制在需求設(shè)計階段，提升產(chǎn)品整體的研發(fā)效率。

五、完善需求PRD文檔

交互與視覺都完成以后再最終完善PRD文檔，產(chǎn)品經(jīng)理從用戶的問題挖掘就已經(jīng)開始準(zhǔn)備PRD文檔了，整個過程都在調(diào)整與準(zhǔn)備，直到視覺設(shè)計完成后再最終將PRD文檔完善。

我一般在設(shè)計解決方案的時候準(zhǔn)備第一個版本，交互設(shè)計的時候準(zhǔn)備第二個版本，UI完成以后再進(jìn)行收尾準(zhǔn)備第三個版本，研發(fā)評審后會準(zhǔn)備第四個版本，開發(fā)與測試過程中優(yōu)化第五個版本（比較小的需求可能就需要1到2個版本就ok了），每次都是逐步完善（修改或補充的部分需要與相關(guān)干系人同步確認(rèn)，尤其是研發(fā)階段，更改的內(nèi)容一定要告知對應(yīng)的研發(fā)，達(dá)成一致后再進(jìn)行更改），補齊相關(guān)的內(nèi)容，PRD文檔是逐步迭代，最終與上線內(nèi)容保持一致。

六、加入敏捷迭代計劃

完成以上工作，該需求就可以加入至迭代計劃中并準(zhǔn)備研發(fā)評審。此時由于還沒有進(jìn)行詳細(xì)研發(fā)評審及評估，可以先找技術(shù)負(fù)責(zé)人預(yù)估一個時間并同步至相關(guān)干系人（可以告知安排在哪個迭代，預(yù)計多長時間），研發(fā)準(zhǔn)確評估后再進(jìn)行修正。

關(guān)于敏捷迭代的流程可以參考我在大廠的實踐案例（敏捷開發(fā)篇）。

七、小結(jié)

以上是我在大廠工作中得到的經(jīng)驗總結(jié)，產(chǎn)品經(jīng)理始終要以用戶問題為出發(fā)點，當(dāng)用戶在實際場景中或在使用產(chǎn)品中遇到問題，我們產(chǎn)品經(jīng)理才去開藥方（需求），而且要以優(yōu)先最小的成本（MVP）去解決問題。

而需求包括解決方案+交互設(shè)計+UI視覺稿。研發(fā)就能按照藥方（需求）去生產(chǎn)藥物（落地產(chǎn)品），最終解決用戶的問題。整個環(huán)節(jié)都需要產(chǎn)品經(jīng)理投入比較多的精力去思考，不斷反復(fù)思考用戶的背后的問題本質(zhì)。