最近做了不少設計評論相關的功能，圖書詳情頁評論，書評區，書評廣場，書單評論，名家評論等等，牽一髮而動全身。尤其是中途請了個長假，是的該優化的圖書優化了，該上線的也上線了，但是，當初你提的那些優化點，開發一句做不了，產品就妥協了，對無關流程呀。好，達成協議，上線後看反饋，上線後看效果。。這些常掛在嘴邊的藉口說服了他們。此刻強烈的使命感油然而生：爲用戶體驗負責是交互最基本的職責。然已有很多文章，大俠們從各個方面告訴我們該如何去設計一個體驗好的產品。而我從設計以外，交互設計還會做哪些雜事，來確保產品的優質體驗。
1）考慮現實因素，設計不要太理想化
設計時，一定要考慮所有的現實因素。比如我們的視覺設計師喜歡用出版類圖書封面作爲提案，在做毛玻璃效果時，同樣採用偏文藝類的封面來做效果。而實際場景用戶看到的是網文類圖書。最終實現的效果它就不夠英俊了。此時交互設計師要記得提醒設計師們。
2）認識自己平臺的能力
對平臺能力有一定的瞭解，比如互動站點一直以來加載就會慢很多，那在設計互動站點的時候，需要注意避免一次加載過多內容，多用分佈加載，局部刷新，提早預加載，提早開始數據交互，等等這些加載的小細節先拋給開發，讓開發提早評估提早預估；再比如咪咕閱讀互動站點與圖書站點的交互能力，評論（圖書站點）中嵌入道具功能（互動站點），他們之間的交互事先沒有預先拋出來，開發也就沒有考慮進去，最後連流程都是走不通的。然這部分的能力是需要長期與開發磨合學習，慢慢積累才能提升的。一個建議：遇到開發做不了的問題，試着去了解爲什麼做不到，去刨根問底，再不懂自己去學習涉及到的內容。其他別無他法
3）跟進視覺
首先對接視覺時，交互有必要跟視覺設計師表達清楚項目背景，設計目標，用戶背景等，如果是大項目這部分會要求視覺設計師提早參與，而小需求，可以通過交互來表達，最後是否達到效果交互要好好把控。
跟進視覺的過程其實很大一部分是對自己畫的交互再驗證的過程，不要簡單對待。認真細緻，不放過每個細節，跟着視覺稿來回反覆多走幾次流程，有時間可以做個demo。然自己卻常常只是簡單帶過。到後面視覺很多狀態會忽略，畢竟視覺設計師對業務的熟悉度有限。。另外對於好看不好，有意見提出來，由視覺設計師來定，術業有專攻，這樣也便於更好的合作，互相提升。
最後交互呀 你也要有一定的審美，人家好看的你非要說不好看，那慘爆了
4）跟進開發是大頭
前兩天真的很生氣，開發信誓旦旦的說我們從來不看交互稿，只看產品文檔與視覺稿，那交互存在的意義何在呀，弱爆了。一些細小的微交互都由產品經理在產品文檔中來傳達，或者到後期的體驗環節來補救，這樣真的好嗎？經過與前端頭頭的一番溝通，終於交互文檔可以在整個流程轉起來了。同時增加了交互參與技術需求評審環節。又給自己攤活了。。。
來說說體驗吧 ，一般的流程我們都會去點點，有問題的話測試一般也都能測出來，交互主要還要關注1.加載速度，比如頁面加載的速度有沒有超過最大值，2.頁面跳轉過程是否順暢是否合理：比如用戶從列表進到詳情頁，再次出來有沒有保留在進入後的頁面，尤其是B測頁面，通常會從新加載頁面，所以頁面會回到頂端；3.響應是否及時：用戶觸發一個觸點，會有兩處甚至三處應該有相關響應，是否都同時做出了響應；比如用戶點贊後當時會有顏色 相關的反饋，因爲只做了本地緩存，傳到服務器的過程失敗了，再次刷新後，這些數據又倒回來了；4.頁面刷新效果，響應流暢度，異常情況（0 太少 太多 中途離開。。。）等微交互都是測試人員會忽略的點。
在開發過程中，我們會被告知什麼效果實現不了，因爲什麼什麼原因。這個時候一定要把持住底線，不能退讓太多；比如之前在做閱歷時涉及到一個曲線圖，對於座標軸的顯示問題，開發只能按照平臺輸出的分段顯示，而在用戶側不會關注到很細微的具體時間點，那我們希望座標軸的顯示跨度大一點，後來從我們的角度我們提出通過遮罩的方式，我們不希望顯示的分段透明化 ；所以愉快的解決了所謂開發說做不到的問題。
今天就先寫這些。後續再補充；打雜的過程雖然沒有任何產出，卻是保證產品有良好體驗必不可少的環節。 恩，吭哧吭哧把腿跑。。。。。