最近從之前的項目出來做國際版，和之前項目的設計負責同學嘮嗑，最多的感慨是有關“背鍋”的問題。
啥鍋呢？
估計不少鐵汁也遇到過的，由于設計交付時缺少了一些狀態、頁面和切圖時被有心人拿來放大說事兒甚至打小報告的事情。老實說，在繁忙的研發交付中，無論是產品還是設計甚至開發都會有缺漏的時候，不然要 QA 來做啥子，所以其實這是一件挺難以避免的事情。
但有時候你遇到的合作隊友并不是很 nice 的時候，大家除了忙著撕逼，其實更有效的是細致化預判自己的設計交付，而至于一個 niubility 的設計師可以從視覺和交互的層面細致預判到什么程度，咱們來一探究竟。
我們以 1 個設計流程細節為例，分不同細致級別來看處理的結果：
當我們拿到一個這樣的原型，一個社交類的私聊頁面，在先不做底下功能 tab 的情況下，康康對話面板的設計如何兌現細節。
拋除雜念，直接上手開始設計。產品/交互給原型里畫了幾種狀態就設計幾種狀態，不用懷疑。
速度快到驚人，設計稿分分鐘就出來了，看著還挺高級挺美膩的，是吧。
設計細節都按照良好的視覺舒適度進行設計了，底下的輸入操作區還用心的根據國外產品的設計習慣換成了小麥克風和紙飛機圖標。但是設計稿可能還沒有交付到開發那邊，在嚴格的組內過稿和產品經理那邊就會被攔截下來，什么原因呢？
根據產品的訴求，這是一款相親類的社交產品，私聊的頁面不能過于樸實無華，這樣會缺少了火熱的氣氛。
同時預判界面的唯一商業化功能要稍突出表達一些（上一篇剛寫過一篇有關商業化的文章：歡迎回顧）。
這個顛覆 1 級設計方案的新方案，你可以用來做 AB 方案在組內和產品經理進行過稿，基本很難再挑出你什么視覺體驗上的毛病。拿 2 個相差稍微大一丟丟的方案做 AB 去過稿是一個相對容易過稿的“銷售”小技巧。
但過了前兩關到了技術交付這邊就會發現真正的麻煩事兒才剛剛開始...
開始在設計稿里進行細節拆解，將更多設計規則溫馨備注給開發鐵汁們，減少后期走查時的扯不清及他們的各種細節忽略。
這里備注的細節包含不限于：布局、元素的使用規則、動效提前提示預留、交互規則說明、復雜設計（疊層）拆解等等。
從 3 級開始往上，設計稿的交付越來越復雜，要考慮的內容越來越多，也越來越能體現一個設計師除了畫個圖以外扎實的綜合專業能力。設計交付細節做得越好，研發的進度也會越快，這是最實在的提效。但單單只是如此，我們在實際開發中仍然還是會遇到不停讓你補充設計和切圖的情況，雖然漏細節這個問題無法完全避免，但是可以把缺漏降到最低...
拿到原型后把前前后后相關的的原型全刷一遍，歸納出這個原型私聊面板上出現的所有狀態和交互，在設計完主視覺后，再依據所有狀態交互進行細節設計。這個時候原來只有 1 頁的原型，到 ux 這里就會拓展成大大小小 N 個畫面。
做到這個程度很多鐵汁覺得已經差不多夠意思了，但實際上大部分產品都不會很細致的羅列所有產品中的細節交互狀態，如果團隊有細分的交互設計師，他們也不一定就想的是全的，所以一個 niubility 的 UX 你的細節可以比他們的更全、預判更多。
在和產品商量后，我們補充了 3 種在競品體驗中發現的交互細節（產品原型遺漏）：輸入中、新消息、圖片加載狀態。
另外在功能基礎上優化了一些原來的固有樣式：
- 在原交互基礎上升級禮物彈窗為彈幕形式，增強氣氛渲染感受同時不遮擋屏幕中央聊天區域。
- 優化且補充音視頻最小化狀態的交互邏輯（僅應用內最小化不支持全局最小化，減少應用跳出率）。
- 定制化 toast 控件，做全局 toast 控件區分，避免與對話框視覺感受重疊導致用戶對 toast 的識別問題。
最后的完整輸出如上，雖然有丟丟可怕，但這個也不代表就是私聊這個設計的細節這樣就到極限了，細節這種東西永遠是沒有最好只有更好，沒有最全只有更全。不過細節照顧到這個份上，可能有的人會覺得是在浪費時間，或者實際操作中并沒有那么多時間讓大家考慮這么多細節的問題。
這里我想說 2 方面：
- 一方面是顧全細節是一件磨刀不誤砍柴工的事情，因為只有考慮到細枝末節才能提升整體中下游的配合效率，最后也保障用戶的每一個體驗細節。同時也是線上事后扯皮時的一些取證之地（設計評審都沒法留證據）。
- 另一方面，當熟悉精細化預判設計后，習慣養成、經驗積累是可以不斷使你的產出效率提升的，所以并不要因為它看上去要做很多工作就放棄鍛煉自己的細節思考能力。
雖說現在大家都在關注 PPT 該如何寫，黑話該如何講，但以上個人認為才是作為 UX 始終最實在該提升的東西，也是作為設計師會對業務造成最本分的直接影響。
最后愿大家的明天都是一個超 5 級指數的“超細”設計師。
歡迎關注作者的微信公眾號：「Nana的設計錦囊」
復制本文鏈接 文章為作者獨立觀點不代表優設網立場，未經允許不得轉載。
熱評 鋪地錦