如果您想訂閱本博客內容，每天自動發(fā)到您的郵箱中， 請點這里
咚咚咚：前段時間參與設計一個較大的線上活動，包含十個奧運相關小游戲及一些相關界面，前后歷時幾個月。奧運后活動下線，設計工作完結后，我整理了這過程中的收獲及工作方式，和大家分享下。
立項前信息收集與準備
有些大型項目是很早就規(guī)劃了要做的，只是具體哪天立項發(fā)郵件或哪些人參與還沒確定，如果知道要自己要參與這件事，可以做些準備工作，提前了解一些信息：
-
項目人員。了解各個職能的接口人是誰，運營、產(chǎn)品、視覺、前端、后端、測試等有誰參與，有些人可能之前都不認識，大家的工作方式和性格也不一樣，提前了解認識下，對后期合作和方案推進會有幫助。
-
信息。保證自己了解到的信息是一手資料很重要。和各方溝通過程中收集下項目的背景、目標、投入的資源、方案的思路及活動體量、以及可能的用戶利益點、項目時間點（通常deadline是確定的）等等等等。這些信息可以通過產(chǎn)品和運營了解到。如果是公司的例行活動，能夠拿到以往活動的數(shù)據(jù)和資料當然是最好，如果沒有的話也盡量找到以前做過類似活動的人員了解一些前人的方法和經(jīng)驗。
-
別人的想法。項目組人員總會有自己的想法和方案，有時候甚至方案是比較確定的。盡早的了解到產(chǎn)品或者運營的想法可以預估個大概的時間節(jié)點和需求，做到心中有數(shù)。如果有好的想法這個時候提出來也最容易被采納，畢竟時間上一切來得及。
立項時信息確認
從接觸到正式立項這段時間免不了會有些因素變動，當然也有確定下來的，確定的東西越多對設計做規(guī)劃也就更有幫助。
控制節(jié)奏
項目啟動后是不可能立馬有方案的，但是項目的目標和方向通常是有的?；诋斚碌哪繕?、方向和資源是可以安排工作節(jié)奏。
-
拆分任務。拿這次奧運活動來說，項目立項后知道的是要做大概十個游戲獨立售賣，然后整個活動期間要為客戶端拉新。所以思路是先總后分，先將活動架子搭建起來，考慮如何整體包裝這十個游戲，然后再分別設計每個游戲。
-
排優(yōu)先級。根據(jù)拆分的各個任務模塊考慮設計的先后順序。大項目不可能同時設計，一次性輸出全部的設計方案，時間上一般是來不及的，所以只能分批次設計輸出。這樣還有一個好處是，在一部分設計確定輸出后，項目的其他人員也能夠盡早的展開工作，不用等全部設計輸出就可以動起來，項目時間上更加充裕。
-
時間預估。設計任務安排好后需要給自己設定個大概時間點，到什么節(jié)點輸出哪一部分內容有個規(guī)劃。一是督促自己快速思考有效產(chǎn)出，二是保證項目整體時間可控，減少風險。
方案設計
具體的方案設計是個比較長的過程，可以用的方法也很多，每個人通常也都有自己的方法。這個過程中會出現(xiàn)很多的爭執(zhí)，有一點很重要，在圍繞著某個細節(jié)爭執(zhí)不休的時候，要記得跳出來想想項目的目標是什么，很多爭執(zhí)點在放回項目目標這個點的時候，答案往往就清晰了。此外還有以下幾點體會：
-
方案共建。想法誰提出的不重要，有好想法才重要。當沒有好想法的時候可以拉上項目組其他成員一起腦爆，大家坐下來一起討論出來的方案往往推進起來異常容易。
-
更好的方案。時刻提醒自己，除了眼前這個方案一定還存在一個更好的方案，時間允許的情況下不妨再逼自己一把，這個過程很痛苦但是結果往往也很令人滿意。
-
統(tǒng)一布局。雖然這個活動包含十個游戲，但是可以根據(jù)每個游戲的特點抽離出一些共性統(tǒng)一來設計。比如我的做法是將頁面分為了三塊，頂部統(tǒng)一放成績相關的元素，中間為游戲主畫面，底部防止操作相關元素。然后在這樣的布局原則下針對每個游戲設計。這樣一是可以給用戶樹立較為統(tǒng)一的認識，體驗一致；二是可以提高設計效率，同時也沒有對某個做出細致的限制，不影響單個游戲的創(chuàng)新空間。
方案輸出與跟進
交互評審完畢并不表示設計工作就結束了，后續(xù)的跟進與走查仍然屬于設計的一部分，而且很重要。
-
查漏補缺。即使再有經(jīng)驗的設計師也不可能把所有的情況都考慮到，所以開發(fā)過程中補充一些細節(jié)是正常的，但是這種情況越少越好。前期考慮清楚規(guī)劃好和臨時打補丁效果肯定不一樣。心態(tài)很重要，態(tài)度也很重要。
-
保證設計還原度。交互評審后仍然需要不斷的跟進視覺設計和后續(xù)的開發(fā)，除了了解項目進度外，還有一個重要的原因是通過不斷的溝通保證你的設計方案是被充分理解并被嚴格執(zhí)行，否則難免會出現(xiàn)因為誤解方案而造成上線效果打折情況。關鍵詞，推動方案落地。
數(shù)據(jù)埋點與測試
做完一個項目如果只是增長了一些項目經(jīng)驗是不夠的，我們還需要知道我們的經(jīng)驗是對還是錯。所以對方案的驗證和數(shù)據(jù)收集就非常重要了。
-
真實的用戶測試。并不是每個項目都有時間和資源進行用戶測試的。但是如果有時間的話，能夠進行一次真實的可用性測試絕對是值得的。這也是解決方案爭議的一個有效辦法。我們不可能完全了解我們的用戶，而且設計過程中與其他人的pk也不會每次都勝出。在我做的這十個小游戲中，上線前用了一周時間借助用研找了十幾個真實的用戶進行了測試，結果發(fā)現(xiàn)對其中兩個競猜的游戲用戶比較方案，而且會影響到對整個活動滿意度。最后經(jīng)過慎重考慮還是忍痛砍掉了一個，并對整個活動其他部分做了一次優(yōu)化。
-
數(shù)據(jù)埋點。數(shù)據(jù)能很大程度上反映一個活動的效果，通常運營和產(chǎn)品也都會督促前端的同學進行埋點。但是不同的角色看的數(shù)據(jù)指標和范圍不一樣，如果要檢驗設計的好壞最好是設計將需要埋點的地方單獨標記出來輸出給前端，以便后續(xù)的整理和總結。
活動總結
活動結束后及時的收集數(shù)據(jù)，并分析總結。趁著對活動還有印象，通過數(shù)據(jù)分析自己設計中哪些地方做的合適，哪些地方做的不合適，總結經(jīng)驗和教訓。至此一項比較完整的活動設計算是結束了。
