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

　　電商網(wǎng)站制作流程

　　一、收集需求

　　當(dāng)運(yùn)營的BOSS首先跟我提這個(gè)需求的時(shí)候，他是這樣說的：

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

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

　　二、理解并分析需求

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

　　正是因?yàn)檫@個(gè)原因，大部分這類網(wǎng)站并沒有多少促銷活動(dòng)，最多的兩種促銷手段是Coupon贈(zèng)送和直減打折，剩下的打折手段實(shí)在是少之又少;相比于我們國內(nèi)琳瑯滿目的促銷手段，跨境垂直B2C站點(diǎn)這塊儼然荒蕪之地。

　　經(jīng)過我一番窮追猛打的追問后，并且由于以前自己做過一段時(shí)間運(yùn)營的背景，便了解到了以下情況：

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

　　運(yùn)營這邊希望在有限的流量情況下提高客單價(jià)，由于加價(jià)購的門檻條件，當(dāng)活動(dòng)功能覆蓋的流量范圍大并且功能運(yùn)用合理的情況下，是會(huì)對網(wǎng)站整體客單價(jià)產(chǎn)生一定影響;

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

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

　　至此我們明白了運(yùn)營提加價(jià)購的背景，原因以及目的，這個(gè)需求的運(yùn)營真實(shí)需求是：

　　以加價(jià)購為基礎(chǔ)，搭建一個(gè)活動(dòng)功能體系，能夠有效的進(jìn)行商品清倉，并且可以用運(yùn)營手段影響客單價(jià)，增加運(yùn)營的活動(dòng)運(yùn)營手段。

　　在理解了運(yùn)營的需求后，我們需要對用戶需求進(jìn)行分析。

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

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

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

　　我們需要從：

　　用戶設(shè)備

　　用戶使用時(shí)段

　　用戶著陸頁頁面場景

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

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

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

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

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

　　四、制定迭代計(jì)劃

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

　　五、轉(zhuǎn)化需求

　　在轉(zhuǎn)化需求前我們首先要知道我們首先面臨的幾個(gè)問題：

　　類似加價(jià)購活動(dòng)在國外站點(diǎn)基本沒有，至少在我調(diào)查的近40個(gè)無論大型綜合類電商還是小型垂直電商站基本沒有發(fā)現(xiàn)(暫時(shí)發(fā)現(xiàn)臺(tái)灣的兩個(gè)網(wǎng)站有，但是不是我們的目標(biāo)客戶群)。所以，我們面臨著比較高的用戶教育成本，并且需要選用適當(dāng)?shù)奈陌缸層脩衾斫獠⑶覅⒓踊顒?dòng);

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

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

　　了解面臨的問題后我們開始轉(zhuǎn)化需求。

　　六、原型出圖

　　前臺(tái)原型出圖

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

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

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

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

　　后臺(tái)原型出圖

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

　　如何判斷我們的功能達(dá)到目的?

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

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

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

　　我們采取獨(dú)立樣本T檢驗(yàn)對功能效果進(jìn)行評測，總共10個(gè)清倉產(chǎn)品，產(chǎn)品轉(zhuǎn)化率近似，20個(gè)熱銷產(chǎn)品，轉(zhuǎn)化率同樣近似。

　　分三組制作三個(gè)專題：

　　第一個(gè)專題為普通專題，將10個(gè)清倉產(chǎn)品與20個(gè)熱銷產(chǎn)品混合放置即可;

　　第二個(gè)專題為加價(jià)購專屬專題，設(shè)定活動(dòng)方式為滿減，將10個(gè)清倉產(chǎn)品作為20個(gè)熱銷產(chǎn)品的加購商品;

　　第三個(gè)專題也為加價(jià)購專屬專題，設(shè)定活動(dòng)方式為滿贈(zèng)，將10個(gè)清倉產(chǎn)品作為20個(gè)熱銷產(chǎn)品的贈(zèng)品;

　　然后針對三個(gè)專題，每一個(gè)專題抽取30個(gè)獨(dú)立用戶分組。

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

　　七、需求評審

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

　　針對一些短期無法實(shí)現(xiàn)或者成本較高的功能點(diǎn)進(jìn)行排期或者刪減，有時(shí)候也可能會(huì)出現(xiàn)二審，三審的可能性咯~如果到三審還有很多問題那就相當(dāng)?shù)木拘牧?，所以一般都是團(tuán)隊(duì)中過兩遍，然后拉上BOSS們再終審一遍基本就OK了。

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

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

　　八、設(shè)計(jì)開發(fā)

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

　　比如說：

　　有些產(chǎn)品會(huì)要求設(shè)計(jì)某個(gè)按鈕用什么什么顏色，某個(gè)元素大一點(diǎn)，小一點(diǎn)，這都是不可取的。

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

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

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

　　當(dāng)你的需求提上去后，什么時(shí)候測試，什么時(shí)候上線，這塊的進(jìn)度一般都由項(xiàng)目經(jīng)理掌控，當(dāng)然，自己的心里也要有譜，有自己的項(xiàng)目進(jìn)度表。

　　九、測試

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

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

　　十、上線觀察，數(shù)據(jù)反饋

　　在此之前，需要跟運(yùn)營人員以及推廣人員打好招呼，按照事先設(shè)計(jì)的實(shí)驗(yàn)方案進(jìn)行實(shí)驗(yàn)。

　　在上線之后每日監(jiān)控?cái)?shù)據(jù)變動(dòng)情況，每組數(shù)據(jù)的流量是否有異常，專題商品庫存情況，下架情況，等等?？傊枰刂谱兞浚_保實(shí)驗(yàn)按照時(shí)間順利完成。

　　最后拉取實(shí)驗(yàn)數(shù)據(jù)進(jìn)行數(shù)據(jù)分析，根據(jù)分析結(jié)果確定此功能的可用性，得出分析報(bào)告反饋給團(tuán)隊(duì)成員和BOSS。