這篇文章筆者將通過一個日常工作中具體需求，重新梳理一遍從接到需求到功能上線的全過程，以及在實現這個需求的過程中遇到的一系列問題以及解決方案。

首先說下我們的團隊配置：2個運營、1個產品兼測試兼部分交互、1個前端1個后端、1個設計兼部分交互。這個配置在一個以運營主導的公司里也算正常，而且需求方和技術方不在一起，溝通也不是很方便。但是，作為一個產品狗，搞好和技術部小伙伴之間的關系是必備技能，這可不能馬虎。

我們按照常規套路來從頭到尾講一下這個需求的實現過程，大體就分以下幾步：

公司不一樣流程也有小差別，比如豪氣正規的公司可能還會有灰度發布階段，當然這也得看發布的需求值不值得這樣做，其中涉及的細節步驟暫未列出，只是寫了個大體框架，（你在原型出圖后到需求評審過程中，會有多次低保真模型流程測試，根據需求評審會其他小伙伴的意見進行原型修改等過程）并且由于本次只是針對單個需求的制作過程，所以這個流程根據實際情況也會有些許不同。

收集需求

當運營的BOSS首先跟我提這個需求的時候，他是這樣說的：

“我需要咱們這個站做一個加價購功能，大概就是買產品達到一定條件后可以用少量價格換購另外的產品，類似與這個網站的功能（于是便掏出一個臺灣的網站給我看）?！?/p>

顯然當他這樣跟我們說的需求我們是不可能回一聲“哦”然后屁顛屁顛跑去開始搞加價購，我們需要問清需求背景，需求目的，期望運用到的需求場景，以及是否有后續計劃（考慮到功能拓展性）。

理解并分析需求

由于目標客戶群體以及歐美文化因素等原因，面向這類用戶的跨境電商服裝垂直站點一直保持著簡約，低調的風格，即使賣幾美金的貨，網站逼格也必須看起來跟國際大牌站點風格沒什么兩樣，正是因為這個原因，大部分這類網站并沒有多少促銷活動，最多的兩種促銷手段是Coupon贈送和直減打折，剩下的打折手段實在是少之又少，相比于我們國內琳瑯滿目的促銷手段，跨境垂直B2C站點這塊儼然荒蕪之地。

經過我一番窮追猛打的追問后，并且由于以前自己做過一段時間運營的背景，便了解到了以下情況：

• 現階段網站庫存積壓較多，常規清倉打折活動效果并不明顯，并且推廣入口單一（推廣人員只單純的推清倉集合頁，量也不大），清倉產品在很多流量入口沒有曝光，需要與關聯性熱賣品進行搭配銷售，并且順便利用熱賣品的流量曝光清倉產品，加快清倉速度；
• 運營這邊希望在有限的流量情況下提高客單價，由于加價購的門檻條件，當活動功能覆蓋的流量范圍大并且功能運用合理的情況下，是會對網站整體客單價產生一定影響；
• 當前運營活動手段單一，常規活動功能效果不明顯，運營手段有限，需要新增活動功能；
• 未來運營還希望能增加積分功能，滿贈功能等等其他活動功能（涉及后續功能擴展，不屬于這次需求之內，但是也要考慮）。

至此我們明白了運營提加價購的背景，原因以及目的，這個需求的運營真實需求是：以加價購為基礎，搭建一個活動功能體系，能夠有效的進行商品清倉，并且可以用運營手段影響客單價，增加運營的活動運營手段。

在理解了運營的需求后，我們需要對用戶需求進行分析，如何平衡用戶需求以及商業需求？這個是需要我們考慮的，我們希望用戶接受并且順暢使用我們的功能，那么從用戶角度來說，我們需要注意什么？

我們站的定位是年齡段在20-35歲的年輕女性，目標國家則是主要集中的歐美國家，商品價格偏低，物美價廉，以服裝類目為主摻雜其他附屬品類。

所以這要是想做面對面的用戶調研是十分困難的，但是根據以往的數據分析以及行業經驗，我們可以知道這個客戶群是對打折促銷非常感興趣的群體，也就是對價格敏感，更直白的從人性來說就是愛占小便宜。那么用戶的使用場景又是如何呢？

我們需要從：

• 用戶設備；
• 用戶使用時段；
• 用戶著陸頁頁面場景；

這幾點進行分析，最終得出契合用戶使用場景的解決方案。所以我們需要在功能制作中需要注意在合適的場景下凸顯價格差異，滿足用戶對價格敏感的特點，刺激下單。當然了，你還可以根據其他的分析模型去更加具體的分析一下，常用的分析模型有馬斯諾，人性7宗罪，從用戶動機出發，模擬用戶對需求進行驗證等。

需求篩選及優先級排序

好不容易接到個需求咱就別給他在篩選和排序了。（PS：這樣做是不對的！這里我們要區別需求優先級排序和需求功能點優先級排序，兩者所處的階段不一樣）

制定迭代計劃

此需求暫不涉及大的版本迭代計劃，但是對于此需求的小版本迭代計劃，則需要在第一次評審后根據技術，運營等小伙伴的建議，評估具體功能點的實現難度，實現周期以及模擬運營方案后進行排期迭代。

轉化需求

在轉化需求前我們首先要知道我們首先面臨的幾個問題：

• 類似加價購活動在國外站點基本沒有，至少在我調查的近40個無論大型綜合類電商還是小型垂直電商站基本沒有發現（暫時發現臺灣的兩個網站有，但是不是我們的目標客戶群），所以，我們面臨著比較高的用戶教育成本，并且需要選用適當的文案讓用戶理解并且參加活動；
• 此類活動即使在國內也沒有哪家網站是讓服裝類商品參與的，基本只有小零食，快消品等通用性較強的商品。服裝類商品涉及到尺碼，顏色，款式等個性化較高的屬性，用戶不太會草率加購這類產品，并且服裝類商品如果尺碼，款式問題涉及的退換貨較多，如果主商品退貨，加購商品退不退就很尷尬，類似這種情況涉及的糾紛也相對較多；
• 由于公司業務原因，GA頁面事件埋點暫時不可用，也就是說具體的頁面點擊事件數據暫時不可用，我們只能根據粗糙的用戶行為數據,業務指標數據以及用戶反饋來盡量合理的評估活動功能效果；

了解面臨的問題后我們開始轉化需求。

明確需求的關鍵節點：

我們根據用戶使用場景來明確這個需求的前臺關鍵節點：

競品分析

確定關鍵節點后，我們有針對性的進行競品分析，調研主流網站對于關鍵節點的處理的優劣，由于國外沒有網站可以參考，在經過多方篩選后，選取了國內站點兩個綜合類并且流量較大，活動體系完備的網站，京東和1號店；（在此我只是闡述下競品分析的一些套路，具體分析內容由于篇幅以及本文主題就不闡述了）

一般我們競品分析分為兩種，一種是完整的競品分析，我們需要進入一個新市場，或者開一條新產品線，那么我們要完完整整的從戰略，產品架構，產品功能點，產品界面設計等等層面去解構，這也就是我們在各大網站上最常見的競品分析報告；然而從實際工作中來看，這種分析報告確實不怎么常用（但是這種分析一般用來鍛煉一下自己的產品思維是有幫助的）；我們常用的是針對功能點或者模塊的針對性競品分析，而這種分析又分為兩種：

• 帶著目的去拆解，優化自己產品已有的功能；
• 功能總體分析評價，新增或者借(chao)鑒(xi)相應的模塊或者功能。

而我們這次應當采用第二種方法，對競品的功能進行總體分析評價，從而新增我們的活動體系。

競品分析過程中….（此處省略幾千字和N張圖）

根據我們對京東和1號店的活動體系進行分析，得出以下關鍵結論：

一般的加購類活動類型包括以下幾個：

而這么多活動規則如何有序的在購物車進行聚合展示呢？除了每個網站固有的分級策略外，一般的活動優先級展示是這樣的：

至于為什么是這么個順序，有興趣可以自行去研究下，筆者在此就暫不闡述啦，除了以上關鍵路徑外，我們還對關鍵節點頁面的活動展示，交互方式，規則說明等做了詳細的研究和參考。在分析的過程中我們發現一個很嚴重的問題，這么復雜的活動，翻譯成英語的話，還真沒幾個人能懂。。。打個比方，”加價購”怎么翻譯？我專程問過好幾個國外同事，也沒人能簡潔的描述出來的，沒有一個詞來形容這個詞，他們甚至沒有聽過這種活動。

所以，如果直接按照國內的加價購，完完整整的展示出來的話，那么我的1版本草稿業務邏輯方案是這樣事兒的：

這僅僅只是一個滿額減的完整的流程，里面還涉及到階梯滿減的概念，那么除了滿額減，還有滿額贈，滿量增，滿量減，滿額折，滿量折，每一個都這么來一遍？中國人都繞暈了吧，何況還得翻譯成英文，還得通俗易懂短小精悍，即使不考慮技術成本，如果這個作為第一個版本就這么個推出，基本就GG了。

所以，在功能框架一定的情況下，如果照搬國內的設計并且直接推出全套版本顯然不能滿足我們的需求，我們要另辟蹊徑，站在國外友人的腦海里去考慮問題，去考慮他們的思考方式和語言特點，雖然我們要重新教育用戶，但是要盡可能的將用戶理解成本降至最低。

因此最終此功能的第一版大致方案框架是這樣事兒的：

暫時舍去階梯概念，舍去滿折方式，以一個Icon為節點，囊括滿額，滿量兩種活動方式，我們需要教育客戶一看到這個Icon就知道這是類似于加價購的活動，不再在標識上區分滿額，滿量概念，在用戶的購物動線上，從Icon，文案一步步引導用戶，完成對活動的理解和參與，整個過程是個很自然的引導過程，不用再去讓用戶糾結規則，也不再去設置長篇大論的活動引導頁。

到了這里，我們就不再出現加價購這個名詞了，我們稱之為APA活動體系，去養成用戶對于APA活動的認知和使用習慣。

原型出圖

前臺原型出圖

這個需求在原型制作環節整個頁面展示雖然簡單，但是涉及到多規則，后臺設計多流程。前端頁面動態數據較多，尤其注意規則說明以及異常說明詳細無遺漏，否則到時候做完了測試的時候就不可避免的開懟。并且與用戶的交互也比較多，所以我采取了低保真交互原型，并且把交互方式錄成GIF放在原型包里面，（必須要特意去提醒開發和設計某些按鈕是可以點的?。。。┚唧w的原型這里就不放了（不要打我，我一般做低保真交互模型的原則是做出特定的交互方式，對于界面元素只是標注下信息層級關系，不會去加色彩以及按鈕樣式誘導設計師，每個人都有每個人的原型寫法，如果有感興趣的同學可以跟筆者交流下），在跟設計和開發反復溝通交流以及后兩次評審會之后，我們的第一版前端成品是這樣的：

商品列表頁Icon展示：

由于以前設計規范的缺失，在商品列表頁我們補充并且制定了活動功能的Icon規范，采用紅底白字的Icon方式展示活動，這為后續的其他活動功能留下擴展空間，鼠標移入會有簡短說明。

商品詳情頁活動規則以及選購商品展示：

商品詳情頁首先展示的是一段引導性文案，我們不會上來就告訴用戶活動詳細規則，因為第一英文解釋起來實在太麻煩，二來過于繁瑣的文案也會造成頁面混亂。我們把既定的規則放入展開模塊當中。這個頁面涉及到的程序規則就是頁面展示的相應文案，根據后臺配置的活動類型不同而變化，比如滿減活動，這里就會提示 “You have a chance to get this following fashion items in a low price:”

如果后臺配置的是滿贈活動，這里就會提示”You have a chance to get this items for free”,同時按鈕文案也會變成 “See the free?items”,里面的規則說明也會相應變化。

這個鏈接會引導客戶去一個專門為APA活動定做的專題落地頁當中，可供用戶選擇更多APA商品，當然這個專題落地頁模板的制作也又是一個比較好玩的事情了，直接上部分設計稿吧（Low-price items里面的圖標文案超出圖標范圍是因為我在截圖的時候只是縮小了頁面，但是文案是用html寫的，不是圖片，所以字體縮小不了）

商品專題頁頁面截圖（部分）

購物車頁展示：

示例截圖1

示例截圖2

購物車里面我們參考了部分競品的分欄方式，并且轉化成我們自己的分欄方式，這里尤其要提的是購物車里面的邏輯較為復雜，除了文案、提示語的變化，以及達到目標值之后的商品狀態變化，按鈕樣式變化以外，比較無語的是在和技術溝通的過程中，發現了很多歷史遺留的邏輯問題，以及與其他系統對接留下來的未解決問題。

在這個需求中，我們的購物車無法同時存在兩條相同的商品數據，并且無法存在多個免費商品數據，這些購物車規則牽扯到的方面較多，優化成本很高，這就導致了我們必須想出一些折中方案，盡量讓用戶體驗不那么糟糕或者造成相當大的困惑，(事實證明在對國外同事做體驗測試的時候在極端情況下是存在一些困惑問題，不過這些問題出現頻次較少，可以交代客服人員在客戶詢問的時候進行解釋。)

后臺原型出圖

后臺制作中首先要注意在活動功能管理板塊下預留其他活動的擴展空間，并且注意前后端的數據交互標注清晰，提前設計好表結構和字段方便開發建表，理清楚業務操作邏輯后，便可出圖啦,這里我就貼操作邏輯以及最后的成品展示，后臺操作邏輯以及關鍵節點解釋如下：

表單部分截圖如下：(部分字段)

添加加購商品如下：(部分字段)

如何判斷我們的功能達到目的？

我們回過頭看看我們之前的需求分析，運營希望加快清倉產品的清倉速度，提高清倉產品的曝光，那這只是業務場景，對于我們這個功能來說，清倉產品只是一種產品類型，那么如何判斷我們這個功能是否有效？我們根據實際條件下(我們無法拿到頁面點擊數據)可以取到的數據制訂以下實驗：

我們采取獨立樣本T檢驗對功能效果進行評測，總共10個清倉產品，產品轉化率近似，20個熱銷產品，轉化率同樣近似。

分三組制作三個專題：

• 第一個專題為普通專題，將10個清倉產品與20個熱銷產品混合放置即可；
• 第二個專題為加價購專屬專題，設定活動方式為滿減，將10個清倉產品作為20個熱銷產品的加購商品；
• 第三個專題也為加價購專屬專題，設定活動方式為滿贈，將10個清倉產品作為20個熱銷產品的贈品；

然后針對三個專題每一個專題抽取30個獨立用戶分組，用戶群的用戶基數近似相等，用戶群轉化率相似，采用相同的推廣渠道，由于無法精確確定用戶數量，我們只需告知推廣保證每日每個專題劃分的每一個群組的流量保證在一個特定數量XXXX左右，持續兩周，最終得出每個用戶分組的以下數據：從這個專題頁落地的用戶所下的訂單中，同時包含清倉產品與熱銷產品的訂單數/所有訂單數，我們給它起個名字叫近似加購率（因為即使在加價購專題里清倉產品和熱銷產品在一起也不一定就是參加加購活動加購的）。用圖表展現就是這樣：

得出數據后做兩兩獨立樣本T檢驗，最終判斷實驗結果，這個網站可以根據你的數據樣本輔助你完成此類實驗：http://www.evanmiller.org/ab-testing/t-test.html

（對于T檢驗的方法和適用范圍感興趣的讀者可以回顧下大學知識或者谷歌一下，這里筆者就暫不列出實驗具體步驟了，后期筆者會計劃專門寫一篇這類實驗的完整過程，這篇文章就只講一下筆者的實驗思路。）

需求評審

這一環節其實并不一定只在這一階段做一次，就像我上面說的，筆者出了第一版方案后拉幾個團隊成員進行初稿評審，理出許多問題，然后再進行修改，針對一些短期無法實現或者成本較高的功能點進行排期或者刪減，有時候也可能會出現二審，三審的可能性咯~如果到三審還有很多問題那就相當的揪心了，所以一般都是團隊中過兩遍，然后拉上BOSS們再終審一遍基本就OK了。終審是最需要用心的時候，一定要注意自己的表達能力和情緒感染力，讓Boss能明白并且認同你們的方案。在會議上面對別人的提問要及時給出有理有據的答復，這一點在終審上是要尤其注意的，良好的演說能力也能為你的需求過審少很多麻煩。

設計開發

設計開發中要隨時與團隊成員保持聯系，尤其是與設計溝通更加頻繁，你們要商議具體的交互細節以及頁面細節，切記不可用特定的言語干擾設計思路。

比如說，有些產品會要求設計某個按鈕用什么什么顏色，某個元素大一點，小一點，這都是不可取的。你只需要確定好信息層級，告知設計師由于業務需求，哪些元素需要強調，哪些需要弱化即可，設計師會根據設計規范以及自己的設計思路進行設計，否則就會和設計師懟的沒完沒了了；至于與開發的溝通，主要是在邏輯層面的交流會更多些，而且筆者認為最好能懂些技術知識，即使一點不懂你也要分清楚哪個開發是做哪一塊的，遇到問題找誰，跟他應該怎樣溝通，如果存在溝通障礙，那么程序員一般的反應都是—>生悶氣，不理你，哈哈，你要知道，大部分程序員還是很可愛的。當你的需求提上去后，什么時候測試，什么時候上線，這塊的進度一般都由項目經理掌控，當然，自己的心里也要有譜，有自己的項目進度表。

測試

測試確實是個心累的活兒，如果你們公司的測試人員較為專業，會為你省下不少麻煩和時間，你只需要負責上線前每一個階段的驗收即可。否則，你就得自己寫測試用例，測試反饋，直到上線，這里每個公司的流程不一樣，這里也就不過多闡述，免得產生誤導。

上線觀察，數據反饋

在此之前需要跟運營人員以及推廣人員打好招呼按照事先設計的實驗方案進行實驗，在上線之后每日監控數據變動情況，每組數據的流量是否有異常，專題商品庫存情況，下架情況，等等，總之需要控制變量，確保實驗按照時間順利完成，最后拉取實驗數據進行數據分析，根據分析結果確定此功能的可用性，得出分析報告反饋給團隊成員和BOSS。

版本迭代

這一部我并沒有寫到最開始的那個流程圖當中，對于一個完整的產品有大的版本迭代，對于一個功能同樣也會有相應的版本迭代。在這個需求中，我們前面根據一二期需求評審之后以及后續根據運營人員的實際情況進行功能擴展，針對此功能大致得出以下迭代計劃：

當然，這個迭代計劃只是作為產品人員自己的計劃。具體每一階段是否上線還需要根據每一階段的數據反饋以及公司具體的運營需求和運營策略的變化（在一個運營主導的公司就是這樣咯~）進行調整，總之，用心對待自己做出來的東西，不僅僅是生孩子，養孩子的責任你同樣也逃不了。

至此，這個需求從初始到上線的一個流程就基本結束了。雖然僅僅只是通過一個需求來回顧了一下需求從開始到結束的整個框架，不知不覺也有了近7000字，對于里面的細節部分請原諒我沒有在本文中全部寫出來，文中還有許多的不足請各位讀者給予指正，私信評論都可，哈哈，歡迎拍磚。

本文由 @白子 原創發布于人人都是產品經理。未經許可，禁止轉載。