toB產品設計前三問+產品設計五部曲

8 評論 6845 瀏覽 98 收藏 10 分鐘

編輯導語:to B產品在規劃設計前需要考慮哪些事情呢?又有哪些注意事項呢?本文作者結合自身5年的產品工作經歷,通過復盤自己多年的工作心得,總結了一些經驗和方法論,最終為我們分享了toB產品設計前的三問以及產品設計的五部曲。

一、前述

本人從事產品工作5年,歷經三家公司,負責過大大小小10余個項目,也一直收到領導賞識。

因最近公司剛入職一位新人產品經理,在工作閑余中也經常一起探討toB產品經理,在開始規劃、設計一個中大型系統時需要掌握哪些方法論以及有哪些注意事項?

今日突然興起,想與大家一同分享下,我做產品5年來的一些心得,不求對各位有多大幫助,如果能引發各位的一些思考,目的就已達到。

以下為個人工作過程總結的經驗及部分方法論,各位需辯證看待。

二、產品設計前三問

萬事開頭難。

在最開始規劃一個產品前,如果沒有全面地從各個維度去思考各種場景及問題,那么這個項目推上線的一刻,就極有可能遭到各種質疑和吐槽。

當然我們可以通過快速迭代不斷地進行產品優化來彌補之前犯下的錯,但要付出的各項成本也會隨之增加。

把場景及問題想在前面,會是一個不錯的選擇。其中最核心的幾個問題如果可以尋求到答案,基本就成功了一半。

1. 如果是我用,我希望這個產品是怎樣的?

看似是一句廢話,但大部分人在高壓情況下,是否都可以靜下心來認真思考并且尋求到最終的答案了呢?

先以產品思維思考,永遠相信自己作為一個產品人的專業性,我們所學到的所謂可以有更好的用戶體驗的理論知識,在這個即將開發的系統里,有哪幾個關鍵部分是一定要去體現極佳的用戶體驗的?這需要我們認真的思考。

最好可以一想到這樣去實現就讓你感覺興奮,就基本達到了一個不錯的效果,因為你已經信心十足的開始了這次的產品設計開發旅程。

當然,我們還需要從各方面去綜合考慮問題,比如成本,是否需要在每一個模塊中都要投入大量的成本去摳細節,還是先以保障最常用的10%的功能達到了極佳的體驗及效果,這需要根據公司實際情況以及客戶的需要去做出決定。

2. 如果我是XXX,我希望這個產品是怎樣的

然后再站在用戶的實用場景上去思考。

如果我是XXX角色,基于我的身份,我關注的重點,我在使用系統時,我希望它是怎樣的?

這個問題其實很多產品相關書籍中都有所提及,那就是換位思考、基于用戶場景去設計產品。但是否進行了深入的思考并得到了讓自己滿意的答案,是需要我們耗費大量心力才能做到的。

3. 這個產品最終以什么形態存在,賣點在哪里?

作為產品經理,我們希望它是一個怎樣的產品?

這個問題代表了我們站在公司角度去思考投入大量資源去研發的系統,它需要為公司帶來什么,可復制性?商業價值?以及其他等等對公司有益的方面。

我們可以從老板、從前場同事那里得到一些答案,但這些都相對碎片化,我們需要結合自己大量的思考及調研,從而給出一個系統性的答案。

三、產品設計五部曲

1. 第一步:產品架構圖

產品架構圖,真的很重要。

通過產品架構圖,可以從宏觀角度去梳理整個產品的重要組成部分及如何組成。

通過產品架構圖,來判斷我們所設想的系統本身架構是否合理,與公司已有系統組成一個解決方案時是否合理,從而進一步指導、約束我們進行接下來的工作。

這里有一點需要提醒部分同學,尤其在前幾次繪制產品架構圖時,會把架構圖搞得很復雜,結構也不夠清晰,這個需要下功夫去苦練,去學習別人繪制的架構圖,要表達哪些重點內容。

隨著不斷地積累,你會越來越得心應手,它也會由一項極度困擾你的工作,變成你產品規劃及設計時的利器。

一張好的架構圖,結構是簡單的,清晰并且合理的。

2. 第二步:業務流程圖

分享一下我的個人經驗。

通常我會繪制多張業務流程圖,一張用于梳理整體主流程的業務流程圖,針對部分無關緊要的環節,不需要在該流程圖中呈現。

通過這張流程圖,可以讓研發更好的了解整個系統的主要業務流程是如何的。

如果事無巨細的在該流程圖中呈現,往往可讀性就會降低,同時會讓初次接觸該需求的研發同學摸不到產品的重點,在進行底層構設計時可能會出現頭重腳輕的情況。

然后再基于各個大的功能模塊,繪制多張詳細流程圖。通過局部詳細流程圖,可以幫助我們梳理所有可能遺漏的小流程,同時也有助于研發在開發時針對各個模塊都有十分詳細的開發參照。

3. 第三步:功能腦圖

完成上述兩步,可能我們感覺已經可以進入到原型設計的階段了,其實還沒有。

完成了系統整體架構的設計,梳理完流程,接下來就是一個更需要耐心的工作了:繪制功能腦圖。

這里只有一點提醒:能多細就多細,把所有涉及到的功能點都放到腦圖中,這樣才可能最大限度防止功能點的遺漏。

4. 第四步:原型設計與PRD

原型設計是各位小伙伴入行開始就必須要具備的從業技能,在此就不多做贅述。

僅一點提醒:對照第三步中制作的功能腦圖,每完成一個頁面都需要逐項檢查,是否覆蓋了在初期構想系統時所有的功能點。

當然也會出現在原型設計時發現腦圖中有遺漏的功能點,此時千萬別偷懶,將該功能點老老實實補充到腦圖中,在此也不贅述原因,實操過程中,你會發現他的益處。

PRD不在字數多,最重要都就是是否夠清晰明了。有時我們寫了上萬字的PRD,研發同學真的不會逐字去讀,冗長的PRD可能最終只能變成我們和研發據理力爭時的呈堂供正。

但好像此時也不會起到什么積極的效果,所以一定要有條理,爭取不寫一句廢話。

5. 第五步:復盤

ok,你已經完成了90%的工作,馬上就要成功,但是,最后這10%的工作如果做不好,可能會讓之前付出的努力大打折扣。

一定要復盤?。。。?/p>

去重新審視一、二步制作的架構圖、流程圖,最終輸出的原型是否發生了偏離?如果有偏離,哪個是更合理的?你需要大量的思考。

當然也不必非要堅持一開始構想的東西,畢竟原型圖更加具象,更有助于我們去整體的看待本次設計。思考之后再慎重作出決定要在哪一步進行修改。

四、給產品人的小建議

  1. 不斷糾結的過程其實很有意義
  2. 那些容易被忽略的細節殺死了用戶體驗
  3. 適當考慮實際情況,但不能被過分影響
  4. 碎片化的思考時間會有奇效

以上幾條是我留下的心得,也可以叫做伏筆,本篇不展開討論,后續會 不斷更新文章,和大家一同探討設計中的糾結與思考、現實與理想的種種。

 

本文由 @David‘s D 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 可惜了,外包產品用戶體驗不是著重點!

    來自河南 回復
  2. 沒啥補充的 你這頭像有點東西

    來自北京 回復
    1. 見頭像如見本人

      來自北京 回復
  3. 每個人對于架構圖,都是只說不練,沒圖說個……

    來自浙江 回復
  4. 在原型和PRD階段,最好把所有的二次確認,終止操作,錯誤提示,前端報錯,后端報錯,無網絡等提示和操作統一

    來自廣東 回復
  5. 你怎樣確保設計前三問不是個人觀點而是客觀事實?
    我比較傾向問:
    1. 產品給用戶提供了什么價值?
    2. 產品形成了什么商業堡壘?

    來自廣東 回復
    1. 我個人認為,每一個產品都沒有絕對的客觀事實,作為這個產品的掌舵人依靠數據分析結果、足夠的調研及思考,去給出設計前三問的答案,他可能就是在基于理性數據及客觀事實的基礎上,得出的一個主觀結論。

      來自北京 回復
  6. 歡迎各位在評論區補充你的個人經驗

    來自北京 回復