從點餐小程序提及，談談如何從0到1設計一款toB類產品

本文轉載自公衆號一鳴說 做者一鳴 十二贊產品經理

**摘要：** 本文以筆者實際工做經驗爲例，講述了 toB 類產品從0到1的過程。

本文章節

– 前言 – 第一章 概念 – 第二章 產品價值 – 第三章 定位 – 第四章 產品設計 – 第五章 交互和視覺設計 – 第六章 後續

**前言** 最近一陣子有一些總結，恰好週末有空，就來談談本身的想法吧。本期談的是「餐飲應用」，對不少人來講，這是一個既陌生又熟悉的行業，熟悉的是你們或多或少都去過餐廳裏面吃飯，陌生的是不少人並不瞭解餐廳的運做模式。行業經驗一直是個人薄弱項，針對一個行業作的應用，若是產品經理自己對這個行業不甚瞭解的話，那麼作出來的產品必定是有問題的，目前的我只能摸着石頭過河，一遍摸索一遍前進。

前面的不少文章，我講得幾乎都是方法論的東西，談到了產品經理的分級問題，這裏能夠插入一點談談我對不一樣等級產品經理的分級概念：

第0級是爲未入門的產品經理，俗稱門外漢或產品新人，是對「產品設計」有必定了解，可是不具有方法論的人，只能觀察到產品的表象，全部對產品的理解停留在表現層，作競品分析停留在產品A有某個功能而產品B沒有等等。不少人說的產品設計這個行業門檻低，其實指的就是成爲產品新人門檻低，凡是會說話的，均可以對產品發表意見：「我以爲這個功能很差用。」等等。

第1級是初級產品經理。初級產品經理算是真正進入了這個行業，標誌就是可以熟練運用各類前人總結的方法論，（說是前人，實際上也就近10年）設計產品遵循必定的規則。成爲初級產品經理，一個簡單的要求就是熟讀業內關於方法論的書籍至少20本以上。實際上，當我讀到第18本關於方法論的書籍時，忽然頓悟，無非就是這麼一回事。作產品和之前我學數學是同樣的，先學理論，再用理論去解題。作產品設計也是同樣，先學這些產品方法論，再把方法論應用於產品設計中，這就是初級和爲入門的差距，未入門的產品經理設計產品是根據本身喜愛而非理論。他們沒有辦法理解本身雖然是其中一個用戶，可是不能表明用戶。低階的初級產品經理具有了獨立設計一個功能模塊的能力，而高階的初級產品經理已經具有的獨立設計一款產品的能力。目前個人自我認知是我仍處於初級。

第2級是中級產品經理，他們已經對本身所處的細分行業有較深的瞭解。設計產品更多的是「道」而非「術」，中級產品經理已經幾乎不會去關注產品的交互、視覺和功能，由於這是初級產品經理考慮的事情，中級產品經理更多的是分析這個行業的走向，開始逐漸以商業的角度去分析問題。高階的中級產品經理通常已經成爲了本細分行業內的知名人物，頻頻出如今各種會議現場作主講。

第3級是高級產品經理，這一級別的產品經理是百裏挑一的存在，恐怖如斯！吾輩恐怕是難以望其項背，我也難以描述這一級別的產品經理究竟是什麼樣的了。（發現一激動又扯遠了。咱們回到正題。）

本文實際上是前一個月工做的總結。本文的重點仍是方法論，以實際的案例來展示產品經理在設計一款新產品從0到1的整個設計思考過程，對於產品新人應該會有一些幫助。（若是須要更深刻了解產品，可訪問 www.12zan.cn）

另外，因爲筆者水平有限，文中不免有疏漏之處，懇請前輩批評斧正！

**第一章 概念** 1.1 toB類和toC類產品的區別

toB類產品和toC類產品在初始設計階段就有很大的不一樣，更多的是設計理念的不一樣。簡單講，toB類重實用，toC類重易用。

toC類產品只要「好玩」「爽」就能夠了，主要目的是佔據用戶的時間。toC類產品重點關注的大可能是在用戶體驗層面的東西。而toB類產品除了要考慮以上這些之外，最重要的toB類產品必須提供必定的「用戶價值」，企業級用戶首先關注的一個問題，這個產品可否解決他的問題。可以解決問題就提供了用戶價值，這纔是他們選擇一款產品的緣由。不是說toB類產品的用戶體驗不重要，而是說這些都只是錦上添花的東西，這裏面的「錦」就是「解決用戶的問題」。例如解決中小企業搭建服務器成本高的問題，誕生了雲主機；解決中小企業內部管理及溝通問題，誕生了釘釘和企業微信等。

在作toB產品的時候，產品經理必須「死扣」一點，那就是這個設計或者這個新功能解決了什麼問題？

**第二章 產品價值** 2.1 用戶價值

用戶價值指的是產品給用戶帶來的價值，其實就是上面講的解決的用戶的問題，解決問題是產品的核心價值。不少新手在前期獨立負責產品設計工做的時候，容易走進一個誤區，那就是作「功能的疊加」，逐步給產品增長功能自己沒有錯，關鍵要看增長的這個功能有沒有「提供用戶價值」，更準確地講，對要解決的問題有沒有幫助。對於有明確目標的用戶，他並不會關注你提供了多少功能，而只關心這個產品是否真正知足了他的需求。

對於低階初級產品經理而言，最大的能力就是「知道如何去作」，也就是在明確一個功能以後，可以準確無誤地設計出這個功能。然而對於高階初級產品經理而言，最重要的能力就是「找對問題」的能力，找到的問題越真實，產品可以提供的價值也就越大。

當咱們在推銷咱們產品的時候，面對目標用戶，如何打動他？你是告訴他：「咱們這款產品有A功能，B功能和C功能，功能不少。」仍是「咱們知道你遇到了XX問題，這款產品恰好可以解決你的XX問題。」若是你是用戶，哪一種說法更吸引你。（這裏忽然想起來蘇傑先生說的一句話：任何產品需求，挖到最後都是人性。寫到這裏忽然感同身受。）

2.2 痛點

痛點是什麼？痛點就是沒有解決的問題。咱們來分析餐飲行業存在哪些痛點，咱們以商圈內的中小餐飲店鋪爲例：

（1）曝光度問題，也就是推廣問題，餐廳自己產品味道很好，口碑也很好，可是你們都不知道。

（2）到店排隊問題，店內顧客多的時候，後到店的顧客就是排隊，如何管理排隊的顧客的問題。

（3）點餐問題，從把餐單給顧客到顧客店外餐確認再傳遞後後廚，這個過程可能有10到20分鐘。

（4）結帳問題，部分顧客可能存在着逃單的狀況。

（5）評價問題，餐廳並不知道用戶對餐品的見解，顧客以爲哪款好吃哪款很差吃。

以上只是粗略地按照顧客消費的流程大體列了幾個痛點，實際存在的痛點遠遠大於以上說的這些。產品經理可以挖掘到的痛點越多，離用戶也就越近，同時離產品成功也就越近。

2.3 最小可用產品

開始準備着手設計產品後，是一開始作一個行業的全流程解決方案，仍是從一個切入點着手，再慢慢發散造成行業解決方案？在互聯網早期，這是一個須要思考的問題。而如今，這一點已經造成了常識。互聯網行業區別於傳統行業的特色是直面用戶，可以快速的收集用戶的反饋。互聯網產品通常都是首先推出一個最小可用版本，而後聆聽市場反應，根據用戶反饋快速地迭代更新。

若是從一開始就把一個大而全的產品開發完畢再推廣上市，可能存在的問題是，因爲開發週期較長，這個東西早已不流行或者競品早就已經搶佔市場，從而形成了浪費。

產品的最小可用版本並非指設計一款粗陋的產品，附加幾個功能就推上去了。而是指最初的版本須要直指這個行業最核心的問題，去解決這個問題而作的產品。每一個行業都會遇到不少問題，有的是小問題，有的是大問題，而有的是核心問題，可以把這些問題都解決的，那就是行業解決方案。

個人一個思路是，作行業的解決方案，第一個版本的產品必需要作一款「效率工具」，可以提高工做中某個環節效率，減小時間成本的工具。設計產品的第一個版本的時候尤其謹慎，須要直擊硬核需求，用最小的開發成本撬動產品萌芽。

因此通過反覆幾輪的產品討論，最終決定以點餐應用做爲餐飲行業的切入點。主要緣由有：

（1）點餐環節是餐飲解決方案中最核心的需求，任何流程都避不開這個環節。

（2）將點餐環節信息化，可以大大提高餐廳的效率，直接節省人工成本，以餐桌數50桌的中型餐廳爲例，一個月光點餐環節能夠省下5到10萬的人力成本。

**第三章 定位** 3.1 產品定位

有句話是這麼說的：「一個好的產品只要一句話就能講清楚。」這句話的含義就是一款定位明確的產品可以用一句話就能夠講完，若是一句話說不完，那就說明這款產品要麼是定位不明確要麼就是想作成微信這一類的巨無霸應用。簡單講，產品定位就是告訴用戶，這款產品是作什麼的。那麼咱們回到這款「點餐小程序」，他的定位是什麼？第一版的定位就很明確，這是一款提高顧客點餐效率的工具。

咱們明確了產品的定位，以後在設計功能的時候，就有了一個基準，符合定位的就作，不符合定位的就不作，這就是產品定位的用途，限定了產品功能的一個大框架。

作產品，常常講究一個「極簡」思惟，那就是「功能一個很少，一個很多」。要作到這個並不容易，一個小技巧就是，每款產品都當成一張白紙，不要預設什麼功能，只有確實須要，再往上加。

3.2 用戶定位

用戶定位決定了這款產品是給誰作的。用戶千差萬別，需求場景更是迥乎不一樣。從街邊的沙縣小吃到富麗堂皇的大酒店，餐飲行業的跨度很是大，他們的需求可能徹底不一樣。

爲「某些人」作，而不是所有人作，這就是「用戶定位」。顯然咱們沒有辦法支持全部人的需求，只能選擇類似度較大的中間羣體而作。用戶定位是否準確決定了產品以後的走向。

仍是以點餐應用爲例，街邊比較小型的店鋪面積在10平方米之內的沙縣小吃可能不是咱們的目標用戶，由於他們的痛點不在點餐環節。居於城市中心的大酒樓，也不是咱們的目標用戶，他們的點餐環節承載的意義不只僅是點餐，這個環節沒有優化的意義。基於此，這款點餐應用的目標用戶應該是：「商圈內餐桌數在20到100桌的餐飲店鋪」。

3.3 市場調研

市場調研的用途是探究產品所在市場的容量。這一塊幾乎是個人知識盲區。

市場調研只要是探討整個市場的規模有多大，已經目前是否已有成熟的競品等。

**第四章 產品設計** 4.1 產品設計

對產品進行定義以後，就要開始設計產品。這種從0到1的設計最考驗產品經理的思考能力和邏輯分析能力。

第一步要作的是，搭建產品架構，常見的要求就是模塊化，低耦合度，高拓展性。若是產品不迭代，那怎麼設計都沒問題，只要能用就好。考慮迭代，那麼整個產品架構很是重要，須要充分考慮以後的拓展性，這就須要考驗產品經理對業務發展的前瞻性了。各個模塊之間相互獨立，下降耦合度，避免出現牽一髮而動全身的狀況。

4.2 流程

肯定了產品要解決的問題，下一步就須要思考這個問題出現的場景，以及解決這個問題的流程。以點餐環節爲例，咱們先構想一個初步的流程，再把流程逐步完善。

首先，商家須要在後臺上傳商品，用戶在前臺看到商品，而後選擇商品下單，商家看到用戶的點餐信息。這是一個天然的、基礎的流程。到這裏就出現了兩個平臺，「前臺」和「後臺」，有什麼區別呢？通常來講，前臺面對的是終端用戶，然後臺則是爲前臺服務的。從上面這個例子能夠看出，用戶（實際上，這裏的用戶有兩類，直接用戶和間接用戶。下面把直接用戶稱爲商家，間接用戶稱爲用戶。）想要在前臺看到商品，總要先把商品給上傳上去，從哪裏上傳，誰去上傳？天然是商家在後臺上傳商品。

顯然上述的流程並不完善，只是一個粗陋的描述，咱們須要把每個環節精確到「操做」。還有這裏的前臺，用什麼呈現顯示，這些都是問題。每一種呈現方式的優缺點分別是什麼，這些都是產品經理須要思考的問題。能夠預料的是，讓用戶本身掃碼打開小程序，這是一個比較完美的方式，將各方的成本降到最低。對於商家不須要購買額外的設備用於點餐，對於用戶不要安裝APP或者其餘的東西，使用小程序能夠「用完即走」。

咱們繼續完善流程。站在用戶的視角，進店引導入座，告知掃碼，打開小程序開始點餐，點餐完畢提交訂單，商家看到訂單開始配餐。

再仔細思考，上述流程還有哪些環節能夠繼續優化的。既然點餐都到線上了，那能夠同時把付款環節也留在線上，全流程的信息化。

上述的流程還能夠再繼續細化和優化，涉及到保密要求，再往下講就涉及到真實的業務場景了。剩下的環節讀者能夠自行思考，思考用戶的操做流程的意義在於爲後續的設計功能提供依據，功能是圍繞着流程來的。流程中須要的功能一個都不能少，流程中不須要的功能也不用添加。作到這一步，就達到了功能的「極簡」。

在考慮用戶操做流程的時候，須要注意的是，要細化到每一步操做，這裏的操做指的是：點擊一次按鈕，掃碼，滑動，長按等操做，用戶每接觸一次屏幕，便算一次操做。若是能作到將用戶流程細化到這個程度，後續設計功能和交互將很是容易。

4.3 功能

肯定完流程以後，下一步就是設計功能了，以後再往下的設計工做將愈來愈簡單。後續設計工做基本就考驗一些基本功和方法論。

設計功能時最重要的就是取捨了，這是一個很大的難題。任何一個功能進行深刻研究，都有無限拓展的可能。功能設計宜精不宜廣，十分考驗邏輯分析能力，尤爲在考慮功能的完備性和自洽性方面。任何一個功能都會涉及到多種可能，每種狀況的判斷如何，每一次用戶的操做可能引起的結果分別是什麼，這些都是產品經理須要考慮的問題。

即使是同一個功能，在針對不一樣的用戶羣時，操做邏輯可能也會不一樣，高頻操做或是低頻操做，使用較難理解的方式去實現複雜的功能，仍是用更簡單的操做邏輯，多作幾步去實現這個功能，每一次決策都考驗着產品經理對行業以及用戶的理解。功能設計這部分，是產品設計的重頭戲，後面還有幾篇文章會詳細講解，這裏不贅述了。

4.4 產品文檔

肯定了產品功能以後，須要依據要實現的功能撰寫產品文檔。可能在大公司會要求寫各類完備的PRD文檔（即使這些徹底用不着），若是開發團隊超過100人，那麼完備的產品文檔是頗有價值的。若是開發團隊在10人之內，用這種裹腳布似又臭又長的PRD文檔就不合適了。在團隊較小時，首先看重效率，而在團隊大到多一我的少一個都無所謂的時候，這時候就首重不出錯，不背責，最後纔是效率問題。沒有人會喜歡面對一個一句話就能夠說清楚的開發需求，結果要照着百科全書般的文檔去作開發，發現其中99%的話都是廢話。

常有人問，什麼纔是一份好的產品文檔？我認爲只要可以把要開發的內容說清楚的文檔就是好文檔，文檔的形式並不重要。文檔的做用就在於減小開發過程開發團隊和產品團隊的溝通，不用針對其中的細節反覆確認。咱們考慮一個場景，產品經理就坐在技術人員邊上，一遍開發一遍告訴技術人員下一步作什麼，時刻保持溝通，這個實際上也是沒有問題的，可是效率過低了，產品文檔就是解決這個問題而生的。

咱們日常用的產品文檔常以「原型圖 + 註解」的方式呈現，而不是通篇累牘的文檔。在一段時間的磨合後，產品經理明白什麼內容須要額外註解，什麼內容不須要註解，已經達成共識，這對提高開發效率十分有幫助。

產品文檔不重形式，甚至不少時候，一句話就能把需求說清楚的話，連原型圖都不是必要的。固然這一切創建在產品和開發有必定程度的磨合上，已經創建了必定的默契。若是當開發團隊人數到達100人以上，那隻能寫那種又臭又長的99%都是廢話的PRD了。

**第五章 交互和視覺設計** 交互反映了用戶操做產品的流程。在設計交互環節，要考慮的兩個問題是：如何組織各環節的頁面，如何組織各頁面中的元素？這些在設計功能環節就已經決定的。在作toB類產品的時候，面對B端（一般是後臺部分），一般不會去作花裏胡哨的交互效果，只要遵循基本的用戶體驗原則去作就能夠了，關於常見的用戶體驗原則能夠見上一篇文章。

在交互設計環節，我認爲最重要的有亮點：一是符合用戶預期，二是別讓用戶思考。

「符合用戶預期」的意思是，當他作完某一步操做時，他預期這時候應該出現一個提示，可是實際並無出現，這個用戶體驗就很差了。作到這一點並不能，只要剋制住本身的「小點子」的想法，不要去搞「瞎創新」就能夠了，不少現有的成熟產品早已提供了一整套的交互邏輯，不要爲了創新而創新，在這裏用戶「習慣成天然」的環節因循守舊就能夠了。對於這些，個人態度是，不拘泥於傳統，同時也不會爲了避免同而搞不一樣。

「別讓用戶思考」的意思是，用戶不須要被引導就知道怎麼操做，一個頁面上的「說明」越多，就說明這個功能越難用，但實際上這是很難避免的。將「別讓用戶思考」這一點作到極致的產品就是iPhone的「滑動解鎖」了。

**第六章 後續** 實際上，到了這一步，產品設計部分工做就已經結束了。後面就會開始產品開發和後續的迭代。

寫完才發現，這篇文章有種頭重腳輕的感受，本想結合實例來說解的，結果最後又沒有用到實例。終究仍是我的行業積累不夠，不少東西內心明白殊不知道怎麼表達出來。但終歸仍是在進步的。這就像打怪升級的過程，每一次進步，看待問題的方式都會不一樣，只能說「只緣身在此山中」。

最後，歡迎打賞。

轉載自十二贊官方【原文連接】