酷播亮新聞
產品設計中常存在著各種矛盾和不明確的地界。
最近總在不同的設計文章裡遇見vague一詞，我不禁杜撰出了一個設計名詞——Vague Design。 這緣起於我在日常設計中的一些執念。
對我個人而言，近些年接觸的設計對象全是企業產品，它們龐大又復雜，常使我陷入對邏輯的執念中。 這種執念有時候讓人有一往無前的勇氣，有時候又讓人困惑——這個世界確乎是可以被邏輯完整解釋的嗎？
事實給我的回答通常是否定的。 我們總是需要面對（或產出？）一些無法用良好邏輯解釋的設計，或是不符合某種依據，或是挑戰某種既有結構。 這是否意味著我們可以坦然接受這樣的模糊設計呢？ 在此我稍稍整理了曾經遇到的模糊情景，希望對理清這一標準有所幫助。
產品模糊
產品設計中常存在著各種矛盾和不明確的地界。 作為設計師，我們希望產品規劃完整而富有遠見，而實際情況是每一個新迭代都可能帶來“戰略性”調整。
在如此敏捷的環境下，設計邏輯偶爾需要作出一些退讓。 這當然不意味著放棄使用規則來組織界面，但某些跳出常規邏輯框架的設計可以幫助產品獲得更好的使用體驗。
舉個栗子。
圖中的三個圖形代表三個產品模塊。 若遵從嚴格的歸類邏輯，後兩者在性狀上可認為屬於同一類別，在層級上理應收攏為一個模塊。 但在某些場景下我們很可能會將其進行平鋪展示，如這兩個功能正巧十分重要以至於需要界面對其進行更多曝光，又或者在某些產品階段通過並列展示達到ABtest的效果 。
真實案例來自macOS App Store 的主導航。 其中“更新”在邏輯上明顯依附於“已購項目”，但此處處理成了兩個tab。 或許蘋果的設計師是為了保持已購項目穩定的時間排序，同時對更新進行更強勢的推薦。 這些靈活處理增加了設計陳述的模糊性，但在特殊情境下可能會為產品帶來幫助。 或許我們下次在作出一個挑戰歸類邏輯的設計方案時可以更加理直氣壯。
用戶心理模糊
這可能是一個更加常見的情況。 繼續舉個栗子。
仍然是若干個功能的排布問題。 這一次，我決定將前兩個模塊進行合併。 程序員在面對設計時可能會感到困惑，因為從他們的視角，前兩者的實現機製完全不同。 這里便涉及到所謂用戶心理模型的概念——相較於技術層面的邏輯，設計師更在意用戶對界面建立的認知——而用戶心理認知又常常和技術邏輯不甚相近。
這個案例中，“本地搜索”和“查找QQ號”是兩套不同的開發邏輯，但在分析用戶行為動機後可以發現，這兩種行為往往發生在同一目標之下，故我們將其放置在 統一入口中。
類似的案例其實隨時可見，開發邏輯條理明確，常常帶來先入為主的影響，讓我們感覺設計良好。 所以更需要時常警醒自己，跳出實現框架，從使用者角度重新梳理，可能會發現故事可以有更友善的敘述方式。
邊角模糊
邊角模糊和前兩種情況略有不同，它其實並不是一種設計傾向，而更多的是對流程上的反思。 我曾經參加這樣一個關於刷新機制的討論。 在枚舉了所有刷新情景之後，工程師拋出了一個話題：
“刷新過程中可能出現超長的加載時間。這個體驗會很差。”
“技術能改進嗎？”
“這個沒辦法，這關係到技術框架改動了。”
“那設計看看有什麼方式可以優化下？”
…
某些辣手的技術漏洞往往出現在產品的邊角場景中(核心場景的通常實現得比較完善)，誠然設計的一個重要功用是幫助修飾技術的不完美，但我發現當花費了太多時間討論 如何處理加載問題，針對核心的前置操作的設計考慮便會減少。 在類似複雜場景的討論中，設計師更需要去把握主次，而不是讓自己陷入對無止境的問題的修復中。
最後，我們對剛剛的案例採取瞭如下解決方案：
“上線後觀察一下發生頻率，如果反饋很多再做特殊設計優化。”
對於這種預想中的低概率事件，我們選擇不在前期花費過多精力。 這種模糊化的處理傾向在產品的一定階段內會產生很高的性價比。 當然也可以加一句：
“你這個問題提得還是挺好的。”
我自然不希望模糊概念成為設計途中一個逃避思考的庇護所——它反而應該是一個普適而人化的設計起點。 在提出每一個設計建議和方案之前，我們也許可以考慮避免沉溺於某些精準概念，進而推導出對用戶心理和產品價值最優的設計方案。
Sometimes vague，always sensible. 希望對你的思考也有所幫助：）
作者： Shuya，一個常常懷疑的設計師，一個比較堅定的理想主義者。 人比文字大概只活潑十倍而已。 一起進步，謝謝大家。
來源：微信公眾號：Beforweb（ID：beforweb）
題圖來自，基於CC0協議