最近债鸡，也不能說最近吧江滨，總之就是大四這段時間，寫論文之余閑得無聊厌均，和朋友接了一個設(shè)計外包項目唬滑。我們?nèi)齻€人，我是交互設(shè)計師棺弊，其他兩個負責視覺設(shè)計晶密，第一次組隊就接了一個項目，團隊算是一邊磨合一邊進行工作模她，而我們團隊和公司那邊也是一邊磨合一邊進行工作稻艰，其實工作進行得不是很順利，不過總歸做完了侈净∽鹞穑回顧這次項目經(jīng)驗，有幾點想跟大家分享一下畜侦。
一元扔、項目需要一張數(shù)據(jù)表
這次算是一個全新的項目，從零開始旋膳，但是實際上第一版出來的功能已經(jīng)非常多了澎语。產(chǎn)品那邊沒有一個完整的功能列表給我，需求也是時不時進行改動。所以咏连，在做設(shè)計的時候盯孙，總感覺會遺漏某些狀態(tài)的變化，所以祟滴，針對這一點振惰，我覺得可以有一張數(shù)據(jù)表。這張表就是工程師后臺的數(shù)據(jù)記錄垄懂，產(chǎn)品在規(guī)劃功能的時候就需要把這張表格給羅列出來骑晶，然后在設(shè)計交互流程的時候，每進行一個步驟草慧，都需要考慮這個步驟對于這個數(shù)據(jù)表格的影響桶蛔，然后把這些變化完整地寫進交互文檔里面。
舉個例子漫谷，由于我們的平臺是一個優(yōu)惠券發(fā)放的平臺仔雷，那么這個時候涉及到兩個主體：優(yōu)惠券和領(lǐng)券的人，優(yōu)惠券的數(shù)據(jù)就是一個數(shù)量的問題舔示。不過對于領(lǐng)券人碟婆，數(shù)據(jù)表有如下：1、未使用的券惕稻；2竖共、已使用的券；3俺祠、已過期的券公给；4、待付款的訂單蜘渣；5淌铐、已付款的訂單；6蔫缸、已退款的訂單腿准；7、積分捂龄；8、返利加叁。羅列了一下倦沧，這些是最主要的數(shù)據(jù)，然后比如說訂單的數(shù)據(jù)它匕，因為訂單是進行購買優(yōu)惠券的活動的展融，所以訂單的數(shù)據(jù)也會影響優(yōu)惠券的數(shù)據(jù)。優(yōu)惠券消費會有返積分或者返利豫柬，所以告希，優(yōu)惠券的狀態(tài)也會影響積分或者返利的數(shù)據(jù)扑浸。那么也就是說訂單的變化也會影響積分或者返利。這些數(shù)據(jù)之間關(guān)系錯綜復雜燕偶，如果有一張詳細的表格喝噪，可以把這些變化寫進交互設(shè)計文檔里面，我覺得邏輯會更加完整指么，對于開發(fā)人員來說也比較便捷酝惧。只是可惜，這些都是做完了才發(fā)現(xiàn)的伯诬，所以當時就沒有做晚唇。
二、將功能模塊化
這次的項目是我有史以來接到的最大的項目盗似，項目功能比較多也比較雜亂哩陕，特別是后期加入了一個支付功能，導致整個交互邏輯的復雜度大大增加了赫舒。復雜度變大的壞處有三個：①難以梳理邏輯悍及；②容易遺忘一些邏輯；③難以恰當?shù)仃U述設(shè)計号阿。針對這三個缺點并鸵，我在做的過程中嘗試將功能進行模塊化。模塊化的意思是將一些功能進行打包扔涧，然后只梳理這些功能之間的關(guān)系园担。梳理完之后枯夜，這些功能就形成了一個整體弯汰，然后其他功能只和這個整體進行交互而不和其中的功能進行交互。
這么說有點不形象湖雹，舉個例子吧咏闪，就說電腦吧，電腦可以看成是由顯示器摔吏、CPU鸽嫂、內(nèi)存、硬盤等部件構(gòu)成的征讲，而其實顯示器里面又是由各種零件構(gòu)成的据某，顯示器里面的零件就相當于我的功能，我所做的就是先把一部分打包成“顯示器”诗箍，一部分打包成“CPU”癣籽，然后把他們當成一個整體來考慮。
顯而易見就是，這么做首先每次處理都只是一部分問題筷狼，邏輯比較容易梳理瓶籽，也不容易遺忘邏輯。當然埂材，更重要的就是表達的問題塑顺。如果不進行模塊化的話，我真的不知道該如何在一張畫布上把這些邏輯流程表達出來楞遏，所以茬暇，模塊化之后，我可以在每張畫布只表達其中一個模塊寡喝，當我把所有模塊都闡述清楚了糙俗，整個項目也就清楚了。
當然预鬓，除了以上的種種優(yōu)點之外巧骚，模塊化還有一個優(yōu)點就是方便復用。一些常見的模塊格二，比如注冊登錄模塊劈彪，消息通知模塊，個人中心模塊顶猜，這些模塊在當今的APP里基本都存在沧奴，也就是說他們的復用率都比較高。如果在設(shè)計的過程中就已經(jīng)將這些功能進行模塊化了长窄，之后如果需要設(shè)計新產(chǎn)品的功能時滔吠，這些模塊就可以直接拿過來復用，省時省力挠日。這個省時省力節(jié)約的是功能規(guī)劃疮绷、界面設(shè)計、邏輯推演等等這些時間和精力嚣潜，所以還是相當可觀的冬骚。
先寫這兩點，后面還有公共交互和團隊溝通的問題懂算，后面再補只冻。
