最近，也不能說最近吧，總之就是大四這段時間，寫論文之餘閒得無聊，和朋友接了一個設計外包項目。我們三個人，我是交互設計師，其他兩個負責視覺設計，第一次組隊就接了一個項目，團隊算是一邊磨合一邊進行工作，而我們團隊和公司那邊也是一邊磨合一邊進行工作，其實工作進行得不是很順利，不過總歸做完了。回顧這次項目經驗，有幾點想跟大家分享一下。
一、項目需要一張數據表
這次算是一個全新的項目，從零開始，但是實際上第一版出來的功能已經非常多了。產品那邊沒有一個完整的功能列表給我，需求也是時不時進行改動。所以，在做設計的時候，總感覺會遺漏某些狀態的變化，所以，針對這一點，我覺得可以有一張數據表。這張表就是工程師後臺的數據記錄，產品在規劃功能的時候就需要把這張表格給羅列出來，然後在設計交互流程的時候，每進行一個步驟，都需要考慮這個步驟對於這個數據表格的影響，然後把這些變化完整地寫進交互文檔裏面。
舉個例子，由於我們的平臺是一個優惠券發放的平臺，那麼這個時候涉及到兩個主體：優惠券和領券的人，優惠券的數據就是一個數量的問題。不過對於領券人，數據表有如下：1、未使用的券；2、已使用的券；3、已過期的券；4、待付款的訂單；5、已付款的訂單；6、已退款的訂單；7、積分；8、返利。羅列了一下，這些是最主要的數據，然後比如說訂單的數據，因爲訂單是進行購買優惠券的活動的，所以訂單的數據也會影響優惠券的數據。優惠券消費會有返積分或者返利，所以，優惠券的狀態也會影響積分或者返利的數據。那麼也就是說訂單的變化也會影響積分或者返利。這些數據之間關係錯綜複雜，如果有一張詳細的表格，可以把這些變化寫進交互設計文檔裏面，我覺得邏輯會更加完整，對於開發人員來說也比較便捷。只是可惜，這些都是做完了才發現的，所以當時就沒有做。
二、將功能模塊化
這次的項目是我有史以來接到的最大的項目，項目功能比較多也比較雜亂，特別是後期加入了一個支付功能，導致整個交互邏輯的複雜度大大增加了。複雜度變大的壞處有三個：①難以梳理邏輯；②容易遺忘一些邏輯；③難以恰當地闡述設計。針對這三個缺點，我在做的過程中嘗試將功能進行模塊化。模塊化的意思是將一些功能進行打包，然後只梳理這些功能之間的關係。梳理完之後，這些功能就形成了一個整體，然後其他功能只和這個整體進行交互而不和其中的功能進行交互。
這麼說有點不形象，舉個例子吧，就說電腦吧，電腦可以看成是由顯示器、CPU、內存、硬盤等部件構成的，而其實顯示器裏面又是由各種零件構成的，顯示器裏面的零件就相當於我的功能，我所做的就是先把一部分打包成“顯示器”，一部分打包成“CPU”，然後把他們當成一個整體來考慮。
顯而易見就是，這麼做首先每次處理都只是一部分問題，邏輯比較容易梳理，也不容易遺忘邏輯。當然，更重要的就是表達的問題。如果不進行模塊化的話，我真的不知道該如何在一張畫布上把這些邏輯流程表達出來，所以，模塊化之後，我可以在每張畫布只表達其中一個模塊，當我把所有模塊都闡述清楚了，整個項目也就清楚了。
當然，除了以上的種種優點之外，模塊化還有一個優點就是方便複用。一些常見的模塊，比如註冊登錄模塊，消息通知模塊，個人中心模塊，這些模塊在當今的APP裏基本都存在，也就是說他們的複用率都比較高。如果在設計的過程中就已經將這些功能進行模塊化了，之後如果需要設計新產品的功能時，這些模塊就可以直接拿過來複用，省時省力。這個省時省力節約的是功能規劃、界面設計、邏輯推演等等這些時間和精力，所以還是相當可觀的。
先寫這兩點，後面還有公共交互和團隊溝通的問題，後面再補。