日常工作中具體需求，重新梳理一遍從接到需求到功能上線的全過程，以及在實現這個需求的過程中遇到的一系列問題以及解決方案。下面由學習啦小編為大家整理的電商網站制作流程，希望大家喜歡!

　　電商網站制作流程

　　一、收集需求

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

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

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

　　二、理解并分析需求

　　由于目標客戶群體以及歐美文化因素等原因，面向這類用戶的跨境電商服裝垂直站點一直保持著簡約，低調的風格，即使賣幾美金的貨，網站逼格也必須看起來跟國際大牌站點風格沒什么兩樣。

　　正是因為這個原因，大部分這類網站并沒有多少促銷活動，最多的兩種促銷手段是Coupon贈送和直減打折，剩下的打折手段實在是少之又少;相比于我們國內琳瑯滿目的促銷手段，跨境垂直B2C站點這塊儼然荒蕪之地。

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

　　現階段網站庫存積壓較多，常規(guī)清倉打折活動效果并不明顯，并且推廣入口單一(推廣人員只單純的推清倉集合頁，量也不大)，清倉產品在很多流量入口沒有曝光，需要與關聯性熱賣品進行搭配銷售，并且順便利用熱賣品的流量曝光清倉產品，加快清倉速度;

　　運營這邊希望在有限的流量情況下提高客單價，由于加價購的門檻條件，當活動功能覆蓋的流量范圍大并且功能運用合理的情況下，是會對網站整體客單價產生一定影響;

　　當前運營活動手段單一，常規(guī)活動功能效果不明顯，運營手段有限，需要新增活動功能;

　　未來運營還希望能增加積分功能，滿贈功能等等其他活動功能(涉及后續(xù)功能擴展，不屬于這次需求之內，但是也要考慮)。

　　至此我們明白了運營提加價購的背景，原因以及目的，這個需求的運營真實需求是：

　　以加價購為基礎，搭建一個活動功能體系，能夠有效的進行商品清倉，并且可以用運營手段影響客單價，增加運營的活動運營手段。

　　在理解了運營的需求后，我們需要對用戶需求進行分析。

　　如何平衡用戶需求以及商業(yè)需求?這個是需要我們考慮的，我們希望用戶接受并且順暢使用我們的功能，從用戶角度來說，我們需要注意什么?

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

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

　　我們需要從：

　　用戶設備

　　用戶使用時段

　　用戶著陸頁頁面場景

　　這幾點進行分析，最終得出契合用戶使用場景的解決方案。所以我們需要在功能制作中需要注意在合適的場景下凸顯價格差異，滿足用戶對價格敏感的特點，刺激下單。

　　當然了，你還可以根據其他的分析模型去更加具體的分析一下。常用的分析模型有馬斯諾、人性7宗罪、從用戶動機出發(fā)、模擬用戶對需求進行驗證等。

　　三、需求篩選及優(yōu)先級排序

　　好不容易接到個需求咱就別給他在篩選和排序了。

　　PS：這樣做是不對的!這里我們要區(qū)別需求優(yōu)先級排序和需求功能點優(yōu)先級排序，兩者所處的階段不一樣。

　　四、制定迭代計劃

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

　　五、轉化需求

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

　　類似加價購活動在國外站點基本沒有，至少在我調查的近40個無論大型綜合類電商還是小型垂直電商站基本沒有發(fā)現(暫時發(fā)現臺灣的兩個網站有，但是不是我們的目標客戶群)。所以，我們面臨著比較高的用戶教育成本，并且需要選用適當的文案讓用戶理解并且參加活動;

　　此類活動即使在國內也沒有哪家網站是讓服裝類商品參與的，基本只有小零食，快消品等通用性較強的商品。服裝類商品涉及到尺碼，顏色，款式等個性化較高的屬性，用戶不太會草率加購這類產品，并且服裝類商品如果尺碼，款式問題涉及的退換貨較多，如果主商品退貨，加購商品退不退就很尷尬，類似這種情況涉及的糾紛也相對較多;

　　由于公司業(yè)務原因，GA頁面事件埋點暫時不可用，也就是說具體的頁面點擊事件數據暫時不可用，我們只能根據粗糙的用戶行為數據,業(yè)務指標數據以及用戶反饋來盡量合理的評估活動功能效果;

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

　　六、原型出圖

　　前臺原型出圖

　　這個需求在原型制作環(huán)節(jié)整個頁面展示雖然簡單，但是涉及到多規(guī)則，后臺設計多流程。

　　前端頁面動態(tài)數據較多，尤其注意規(guī)則說明以及異常說明詳細無遺漏，否則到時候做完了測試的時候就不可避免的開懟。

　　并且與用戶的交互也比較多，所以我采取了低保真交互原型，并且把交互方式錄成GIF放在原型包里面(必須要特意去提醒開發(fā)和設計某些按鈕是可以點的!!!)。

　　不要打我，我一般做低保真交互模型的原則是做出特定的交互方式，對于界面元素只是標注下信息層級關系，不會去加色彩以及按鈕樣式誘導設計師，每個人都有每個人的原型寫法，如果有感興趣的同學可以跟筆者交流下。

　　后臺原型出圖

　　后臺制作中首先要注意：在活動功能管理板塊下，預留其他活動的擴展空間，并且注意前后端的數據交互標注清晰;提前設計好表結構和字段方便開發(fā)建表，理清楚業(yè)務操作邏輯后，便可出圖啦。

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

　　我們回過頭看看我們之前的需求分析：

　　運營希望加快清倉產品的清倉速度，提高清倉產品的曝光——那這只是業(yè)務場景。

　　對于我們這個功能來說，清倉產品只是一種產品類型。那么如何判斷我們這個功能是否有效?我們根據實際條件下(我們無法拿到頁面點擊數據)可以取到的數據制訂以下實驗：

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

　　分三組制作三個專題：

　　第一個專題為普通專題，將10個清倉產品與20個熱銷產品混合放置即可;

　　第二個專題為加價購專屬專題，設定活動方式為滿減，將10個清倉產品作為20個熱銷產品的加購商品;

　　第三個專題也為加價購專屬專題，設定活動方式為滿贈，將10個清倉產品作為20個熱銷產品的贈品;

　　然后針對三個專題，每一個專題抽取30個獨立用戶分組。

　　用戶群的用戶基數近似相等，用戶群轉化率相似，采用相同的推廣渠道——由于無法精確確定用戶數量，我們只需告知推廣保證每日每個專題劃分的每一個群組的流量保證在一個特定數量XXXX左右。

　　七、需求評審

　　這一環(huán)節(jié)其實并不一定只在這一階段做一次，就像我上面說的，筆者出了第一版方案后拉幾個團隊成員進行初稿評審，理出許多問題，然后再進行修改。

　　針對一些短期無法實現或者成本較高的功能點進行排期或者刪減，有時候也可能會出現二審，三審的可能性咯~如果到三審還有很多問題那就相當的揪心了，所以一般都是團隊中過兩遍，然后拉上BOSS們再終審一遍基本就OK了。

　　終審是最需要用心的時候，一定要注意自己的表達能力和情緒感染力，讓Boss能明白并且認同你們的方案。

　　在會議上面對別人的提問要及時給出有理有據的答復，這一點在終審上是要尤其注意的，良好的演說能力也能為你的需求過審少很多麻煩。

　　八、設計開發(fā)

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

　　比如說：

　　有些產品會要求設計某個按鈕用什么什么顏色，某個元素大一點，小一點，這都是不可取的。

　　你只需要確定好信息層級，告知設計師由于業(yè)務需求，哪些元素需要強調，哪些需要弱化即可，設計師會根據設計規(guī)范以及自己的設計思路進行設計，否則就會和設計師懟的沒完沒了了。

　　至于與開發(fā)的溝通，主要是在邏輯層面的交流會更多些，而且筆者認為最好能懂些技術知識，即使一點不懂你也要分清楚哪個開發(fā)是做哪一塊的，遇到問題找誰，跟他應該怎樣溝通。

　　如果存在溝通障礙，那么程序員一般的反應都是—>生悶氣，不理你——哈哈，你要知道，大部分程序員還是很可愛的。

　　當你的需求提上去后，什么時候測試，什么時候上線，這塊的進度一般都由項目經理掌控，當然，自己的心里也要有譜，有自己的項目進度表。

　　九、測試

　　測試確實是個心累的活兒，如果你們公司的測試人員較為專業(yè)，會為你省下不少麻煩和時間，你只需要負責上線前每一個階段的驗收即可。

　　否則，你就得自己寫測試用例，測試反饋，直到上線，這里每個公司的流程不一樣，這里也就不過多闡述，免得產生誤導。

　　十、上線觀察，數據反饋

　　在此之前，需要跟運營人員以及推廣人員打好招呼，按照事先設計的實驗方案進行實驗。

　　在上線之后每日監(jiān)控數據變動情況，每組數據的流量是否有異常，專題商品庫存情況，下架情況，等等。總之需要控制變量，確保實驗按照時間順利完成。

　　最后拉取實驗數據進行數據分析，根據分析結果確定此功能的可用性，得出分析報告反饋給團隊成員和BOSS。