這篇文章筆者將通過一個日常工作中具體需求， 重新梳理一遍從接到需求到功能上線的全過程， 以及在實現這個需求的過程中遇到的一系列問題以及解決方案。
首先說下我們的團隊配置：2個運營、1個產品兼測試兼部分交互、1個前端1個後端、1個設計兼部分交互。 這個配置在一個以運營主導的公司裡也算正常， 而且需求方和技術方不在一起， 溝通也不是很方便。 但是， 作為一個產品狗， 搞好和技術部小夥伴之間的關係是必備技能， 這可不能馬虎。
我們按照常規套路來從頭到尾講一下這個需求的實現過程， 大體就分以下幾步：
公司不一樣流程也有小差別， 比如豪氣正規的公司可能還會有灰度發佈階段， 當然這也得看發佈的需求值不值得這樣做， 其中涉及的細節步驟暫未列出， 只是寫了個大體框架， （你在原型出圖後到需求評審過程中， 會有多次低保真模型流程測試， 根據需求評審會其他小夥伴的意見進行原型修改等過程）並且由於本次只是針對單個需求的製作過程， 所以這個流程根據實際情況也會有些許不同。
收集需求
當運營的BOSS首先跟我提這個需求的時候， 他是這樣說的：
“我需要咱們這個站做一個加價購功能， 大概就是買產品達到一定條件後可以用少量價格換購另外的產品， 類似與這個網站的功能（於是便掏出一個臺灣的網站給我看）。 ”
顯然當他這樣跟我們說的需求我們是不可能回一聲“哦”然後屁顛屁顛跑去開始搞加價購， 我們需要問清需求背景， 需求目的， 期望運用到的需求場景， 以及是否有後續計畫（考慮到功能拓展性）。
理解並分析需求
由於目標客戶群體以及歐美文化因素等原因， 面向這類用戶的跨境電商服裝垂直網站一直保持著簡約， 低調的風格， 即使賣幾美金的貨， 網站逼格也必須看起來跟國際大牌網站風格沒什麼兩樣， 正是因為這個原因， 大部分這類網站並沒有多少促銷活動，
經過我一番窮追猛打的追問後， 並且由於以前自己做過一段時間運營的背景， 便瞭解到了以下情況：
現階段網站庫存積壓較多， 常規清倉打折活動效果並不明顯， 並且推廣入口單一（推廣人員只單純的推清倉集合頁， 量也不大）， 清倉產品在很多流量入口沒有曝光， 需要與關聯性熱賣品進行搭配銷售， 並且順便利用熱賣品的流量曝光清倉產品， 加快清倉速度；運營這邊希望在有限的流量情況下提高客單價， 由於加價購的門檻條件， 當活動功能覆蓋的流量範圍大並且功能運用合理的情況下，至此我們明白了運營提加價購的背景， 原因以及目的， 這個需求的運營真實需求是：以加價購為基礎， 搭建一個活動功能體系， 能夠有效的進行商品清倉， 並且可以用運營手段影響客單價， 增加運營的活動運營手段。
在理解了運營的需求後， 我們需要對使用者需求進行分析， 如何平衡用戶需求以及商業需求？這個是需要我們考慮的， 我們希望用戶接受並且順暢使用我們的功能，那麼從使用者角度來說，我們需要注意什麼？
我們站的定位是年齡段在20-35歲的年輕女性，目標國家則是主要集中的歐美國家，商品價格偏低，物美價廉，以服裝類目為主摻雜其他附屬品類。
所以這要是想做面對面的用戶調研是十分困難的，但是根據以往的資料分析以及行業經驗，我們可以知道這個客戶群是對打折促銷非常感興趣的群體，也就是對價格敏感，更直白的從人性來說就是愛占小便宜。那麼用戶的使用場景又是如何呢？
我們需要從：
使用者設備；用戶使用時段；使用者著陸頁頁面場景；這幾點進行分析，最終得出契合用戶使用場景的解決方案。所以我們需要在功能製作中需要注意在合適的場景下凸顯價格差異，滿足用戶對價格敏感的特點，刺激下單。當然了，你還可以根據其他的分析模型去更加具體的分析一下，常用的分析模型有馬斯諾，人性7宗罪，從用戶動機出發，模擬用戶對需求進行驗證等。
需求篩選及優先順序排序
好不容易接到個需求咱就別給他在篩選和排序了。（PS：這樣做是不對的！這裡我們要區別需求優先順序排序和需求功能點優先順序排序，兩者所處的階段不一樣）
制定反覆運算計畫
此需求暫不涉及大的版本反覆運算計畫，但是對於此需求的小版本反覆運算計畫，則需要在第一次評審後根據技術，運營等小夥伴的建議，評估具體功能點的實現難度，實現週期以及模擬運營方案後進行排期反覆運算。
轉化需求
在轉化需求前我們首先要知道我們首先面臨的幾個問題：
類似加價購活動在國外網站基本沒有，至少在我調查的近40個無論大型綜合類電商還是小型垂直電商站基本沒有發現（暫時發現臺灣的兩個網站有，但是不是我們的目標客戶群），所以，我們面臨著比較高的使用者教育成本，並且需要選用適當的文案讓用戶理解並且參加活動；此類活動即使在國內也沒有哪家網站是讓服裝類商品參與的，基本只有小零食，快消品等通用性較強的商品。服裝類商品涉及到尺碼，顏色，款式等個性化較高的屬性，使用者不太會草率加購這類產品，並且服裝類商品如果尺碼，款式問題涉及的退換貨較多，如果主商品退貨，加購商品退不退就很尷尬，類似這種情況涉及的糾紛也相對較多；由於公司業務原因，GA頁面事件埋點暫時不可用，也就是說具體的頁面點擊事件資料暫時不可用，我們只能根據粗糙的使用者行為資料,業務指標資料以及使用者回饋來儘量合理的評估活動功能效果；瞭解面臨的問題後我們開始轉化需求。
明確需求的關鍵節點：
我們根據使用者使用場景來明確這個需求的前臺關鍵節點：
競品分析
確定關鍵節點後，我們有針對性的進行競品分析，調研主流網站對於關鍵節點的處理的優劣，由於國外沒有網站可以參考，在經過多方篩選後，選取了國內網站兩個綜合類並且流量較大，活動體系完備的網站，京東和1號店；（在此我只是闡述下競品分析的一些套路，具體分析內容由於篇幅以及本文主題就不闡述了）
一般我們競品分析分為兩種，一種是完整的競品分析，我們需要進入一個新市場，或者開一條新產品線，那麼我們要完完整整的從戰略，產品架構，產品功能點，產品介面設計等等層面去解構，這也就是我們在各大網站上最常見的競品分析報告；然而從實際工作中來看，這種分析報告確實不怎麼常用（但是這種分析一般用來鍛煉一下自己的產品思維是有説明的）；我們常用的是針對功能點或者模組的針對性競品分析，而這種分析又分為兩種：
帶著目的去拆解，優化自己產品已有的功能；功能總體分析評價，新增或者借(chao)鑒(xi)相應的模組或者功能。而我們這次應當採用第二種方法，對競品的功能進行總體分析評價，從而新增我們的活動體系。
競品分析過程中….（此處省略幾千字和N張圖）
根據我們對京東和1號店的活動體系進行分析，得出以下關鍵結論：
一般的加購類活動類型包括以下幾個：
而這麼多活動規則如何有序的在購物車進行聚合展示呢？除了每個網站固有的分級策略外，一般的活動優先順序展示是這樣的：
至於為什麼是這麼個順序，有興趣可以自行去研究下，筆者在此就暫不闡述啦，除了以上關鍵路徑外，我們還對關鍵節點頁面的活動展示，對話模式，規則說明等做了詳細的研究和參考。在分析的過程中我們發現一個很嚴重的問題，這麼複雜的活動，翻譯成英語的話，還真沒幾個人能懂。。。打個比方，”加價購”怎麼翻譯？我專程問過好幾個國外同事，也沒人能簡潔的描述出來的，沒有一個詞來形容這個詞，他們甚至沒有聽過這種活動。
所以，如果直接按照國內的加價購，完完整整的展示出來的話，那麼我的1版本草稿業務邏輯方案是這樣事兒的：
這僅僅只是一個滿額減的完整的流程，裡面還涉及到階梯滿減的概念，那麼除了滿額減，還有滿額贈，滿量增，滿量減，滿額折，滿量折，每一個都這麼來一遍？中國人都繞暈了吧，何況還得翻譯成英文，還得通俗易懂短小精悍，即使不考慮技術成本，如果這個作為第一個版本就這麼個推出，基本就GG了。
所以，在功能框架一定的情況下，如果照搬國內的設計並且直接推出全套版本顯然不能滿足我們的需求，我們要另闢蹊徑，站在國外友人的腦海裡去考慮問題，去考慮他們的思考方式和語言特點，雖然我們要重新教育用戶，但是要盡可能的將用戶理解成本降至最低。
因此最終此功能的第一版大致方案框架是這樣事兒的：
暫時舍去階梯概念，舍去滿折方式，以一個Icon為節點，囊括滿額，滿量兩種活動方式，我們需要教育客戶一看到這個Icon就知道這是類似於加價購的活動，不再在標識上區分滿額，滿量概念，在用戶的購物動線上，從Icon，文案一步步引導用戶，完成對活動的理解和參與，整個過程是個很自然的引導過程，不用再去讓使用者糾結規則，也不再去設置長篇大論的活動引導頁。
到了這裡，我們就不再出現加價購這個名詞了，我們稱之為APA活動體系，去養成用戶對於APA活動的認知和使用習慣。
原型出圖前臺原型出圖
這個需求在原型製作環節整個頁面展示雖然簡單，但是涉及到多規則，後臺設計多流程。前端頁面動態資料較多，尤其注意規則說明以及異常說明詳細無遺漏，否則到時候做完了測試的時候就不可避免的開懟。並且與用戶的交互也比較多，所以我採取了低保真交互原型，並且把對話模式錄成GIF放在原型包裡面，（必須要特意去提醒開發和設計某些按鈕是可以點的！！！）具體的原型這裡就不放了（不要打我，我一般做低保真交互模型的原則是做出特定的對話模式，對於介面元素只是標注下資訊層級關係，不會去加色彩以及按鈕樣式誘導設計師，每個人都有每個人的原型寫法，如果有感興趣的同學可以跟筆者交流下），在跟設計和開發反復溝通交流以及後兩次評審會之後，我們的第一版前端成品是這樣的：
商品列表頁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字，對於裡面的細節部分請原諒我沒有在本文中全部寫出來，文中還有許多的不足請各位讀者給予指正，私信評論都可，哈哈，歡迎拍磚。
本文由 @白子 原創發佈于人人都是產品經理。未經許可，禁止轉載。
我們希望用戶接受並且順暢使用我們的功能，那麼從使用者角度來說，我們需要注意什麼？我們站的定位是年齡段在20-35歲的年輕女性，目標國家則是主要集中的歐美國家，商品價格偏低，物美價廉，以服裝類目為主摻雜其他附屬品類。
所以這要是想做面對面的用戶調研是十分困難的，但是根據以往的資料分析以及行業經驗，我們可以知道這個客戶群是對打折促銷非常感興趣的群體，也就是對價格敏感，更直白的從人性來說就是愛占小便宜。那麼用戶的使用場景又是如何呢？
我們需要從：
使用者設備；用戶使用時段；使用者著陸頁頁面場景；這幾點進行分析，最終得出契合用戶使用場景的解決方案。所以我們需要在功能製作中需要注意在合適的場景下凸顯價格差異，滿足用戶對價格敏感的特點，刺激下單。當然了，你還可以根據其他的分析模型去更加具體的分析一下，常用的分析模型有馬斯諾，人性7宗罪，從用戶動機出發，模擬用戶對需求進行驗證等。
需求篩選及優先順序排序
好不容易接到個需求咱就別給他在篩選和排序了。（PS：這樣做是不對的！這裡我們要區別需求優先順序排序和需求功能點優先順序排序，兩者所處的階段不一樣）
制定反覆運算計畫
此需求暫不涉及大的版本反覆運算計畫，但是對於此需求的小版本反覆運算計畫，則需要在第一次評審後根據技術，運營等小夥伴的建議，評估具體功能點的實現難度，實現週期以及模擬運營方案後進行排期反覆運算。
轉化需求
在轉化需求前我們首先要知道我們首先面臨的幾個問題：
類似加價購活動在國外網站基本沒有，至少在我調查的近40個無論大型綜合類電商還是小型垂直電商站基本沒有發現（暫時發現臺灣的兩個網站有，但是不是我們的目標客戶群），所以，我們面臨著比較高的使用者教育成本，並且需要選用適當的文案讓用戶理解並且參加活動；此類活動即使在國內也沒有哪家網站是讓服裝類商品參與的，基本只有小零食，快消品等通用性較強的商品。服裝類商品涉及到尺碼，顏色，款式等個性化較高的屬性，使用者不太會草率加購這類產品，並且服裝類商品如果尺碼，款式問題涉及的退換貨較多，如果主商品退貨，加購商品退不退就很尷尬，類似這種情況涉及的糾紛也相對較多；由於公司業務原因，GA頁面事件埋點暫時不可用，也就是說具體的頁面點擊事件資料暫時不可用，我們只能根據粗糙的使用者行為資料,業務指標資料以及使用者回饋來儘量合理的評估活動功能效果；瞭解面臨的問題後我們開始轉化需求。
明確需求的關鍵節點：
我們根據使用者使用場景來明確這個需求的前臺關鍵節點：
競品分析
確定關鍵節點後，我們有針對性的進行競品分析，調研主流網站對於關鍵節點的處理的優劣，由於國外沒有網站可以參考，在經過多方篩選後，選取了國內網站兩個綜合類並且流量較大，活動體系完備的網站，京東和1號店；（在此我只是闡述下競品分析的一些套路，具體分析內容由於篇幅以及本文主題就不闡述了）
一般我們競品分析分為兩種，一種是完整的競品分析，我們需要進入一個新市場，或者開一條新產品線，那麼我們要完完整整的從戰略，產品架構，產品功能點，產品介面設計等等層面去解構，這也就是我們在各大網站上最常見的競品分析報告；然而從實際工作中來看，這種分析報告確實不怎麼常用（但是這種分析一般用來鍛煉一下自己的產品思維是有説明的）；我們常用的是針對功能點或者模組的針對性競品分析，而這種分析又分為兩種：
帶著目的去拆解，優化自己產品已有的功能；功能總體分析評價，新增或者借(chao)鑒(xi)相應的模組或者功能。而我們這次應當採用第二種方法，對競品的功能進行總體分析評價，從而新增我們的活動體系。
競品分析過程中….（此處省略幾千字和N張圖）
根據我們對京東和1號店的活動體系進行分析，得出以下關鍵結論：
一般的加購類活動類型包括以下幾個：
而這麼多活動規則如何有序的在購物車進行聚合展示呢？除了每個網站固有的分級策略外，一般的活動優先順序展示是這樣的：
至於為什麼是這麼個順序，有興趣可以自行去研究下，筆者在此就暫不闡述啦，除了以上關鍵路徑外，我們還對關鍵節點頁面的活動展示，對話模式，規則說明等做了詳細的研究和參考。在分析的過程中我們發現一個很嚴重的問題，這麼複雜的活動，翻譯成英語的話，還真沒幾個人能懂。。。打個比方，”加價購”怎麼翻譯？我專程問過好幾個國外同事，也沒人能簡潔的描述出來的，沒有一個詞來形容這個詞，他們甚至沒有聽過這種活動。
所以，如果直接按照國內的加價購，完完整整的展示出來的話，那麼我的1版本草稿業務邏輯方案是這樣事兒的：
這僅僅只是一個滿額減的完整的流程，裡面還涉及到階梯滿減的概念，那麼除了滿額減，還有滿額贈，滿量增，滿量減，滿額折，滿量折，每一個都這麼來一遍？中國人都繞暈了吧，何況還得翻譯成英文，還得通俗易懂短小精悍，即使不考慮技術成本，如果這個作為第一個版本就這麼個推出，基本就GG了。
所以，在功能框架一定的情況下，如果照搬國內的設計並且直接推出全套版本顯然不能滿足我們的需求，我們要另闢蹊徑，站在國外友人的腦海裡去考慮問題，去考慮他們的思考方式和語言特點，雖然我們要重新教育用戶，但是要盡可能的將用戶理解成本降至最低。
因此最終此功能的第一版大致方案框架是這樣事兒的：
暫時舍去階梯概念，舍去滿折方式，以一個Icon為節點，囊括滿額，滿量兩種活動方式，我們需要教育客戶一看到這個Icon就知道這是類似於加價購的活動，不再在標識上區分滿額，滿量概念，在用戶的購物動線上，從Icon，文案一步步引導用戶，完成對活動的理解和參與，整個過程是個很自然的引導過程，不用再去讓使用者糾結規則，也不再去設置長篇大論的活動引導頁。
到了這裡，我們就不再出現加價購這個名詞了，我們稱之為APA活動體系，去養成用戶對於APA活動的認知和使用習慣。
原型出圖前臺原型出圖
這個需求在原型製作環節整個頁面展示雖然簡單，但是涉及到多規則，後臺設計多流程。前端頁面動態資料較多，尤其注意規則說明以及異常說明詳細無遺漏，否則到時候做完了測試的時候就不可避免的開懟。並且與用戶的交互也比較多，所以我採取了低保真交互原型，並且把對話模式錄成GIF放在原型包裡面，（必須要特意去提醒開發和設計某些按鈕是可以點的！！！）具體的原型這裡就不放了（不要打我，我一般做低保真交互模型的原則是做出特定的對話模式，對於介面元素只是標注下資訊層級關係，不會去加色彩以及按鈕樣式誘導設計師，每個人都有每個人的原型寫法，如果有感興趣的同學可以跟筆者交流下），在跟設計和開發反復溝通交流以及後兩次評審會之後，我們的第一版前端成品是這樣的：
商品列表頁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字，對於裡面的細節部分請原諒我沒有在本文中全部寫出來，文中還有許多的不足請各位讀者給予指正，私信評論都可，哈哈，歡迎拍磚。
本文由 @白子 原創發佈于人人都是產品經理。未經許可，禁止轉載。