談談過度設計

07-12

談談過度設計

來自專欄鯨魚事務所

在設計產品的過程中，經常會遇到過度設計的情況。過度設計往往和設計不足同時出現，表示在設計產品時過於關注不大可能出現或與核心問題關係不大的場景。

我們在與需求方或開發談論需求時，會大概率遇到兩種情況。第一是大家糾結於一個極小場景的需求，認為非要設計某個功能。最後演變為這裡需要XX功能，那裡也需要，恨不得將所有的功能在每一個頁面上都體現出來。比如在設計某公眾號時，底部主體已經有對賬功能了，在個人中心還是加上了對賬功能，而其實對賬在個人中心是用戶不會使用的功能。這導致個人中心頁需要滿足對賬及對賬相關的其他功能，增加了許多內容。第二是想要將一個與產品無關的需求加入進來，這時候需求有場景支撐但卻是不適合產品，不能在產品中立足的。如果最後需求沒有控制住，最終的結果會是整個系統的信息架構混亂、功能主次不明、信息臃腫。當你詢問為什麼需要這個功能時，需求方往往會說用戶有可能在這裡使用XX功能。如果按這種思路，為什麼不把所有功能做在一起呢，畢竟任何時候用戶都會有概率想到要使用某個功能，即便這個概率可能是百萬分之一。

如果遇到這種情況，我們需要怎麼做呢？其實就是講道理、擺事實，判定需不需要做再判定怎麼做。

講道理

首先我們在自己充分了解用戶的基礎上，判定這個需求是一個極低或不適用我們產品的需求。這是基礎，我們需要有自己的判斷和依舊。然後與需求方復盤整個場景，將這個場景詳細拆解一遍。這個時候很可能我們在復盤這個場景的時候，需求方會發現問題的所在和合適的解決方案。需求存在嗎？梳理的過程可以很好的解釋這個問題。如果存在，雖然是極低的需求，那需要做嗎？這時候需要考慮投入產出比，現在開發資源的情況是怎樣？為一個極低且不可能出現的需求去佔用開發資源是否值得？這樣下來，大部分明事理的需求方都會選擇放棄這個需求。

擺事實

如果這時候還是無法說服需求方，那麼你需要快速找來相應的數據和用戶反饋來幫你佐證。調取後台記錄，看是否會有這個場景的數據，將數據的多少量級和整體進行對比。如果沒有數據，在可以快速和用戶溝通的情況下，可以直接快速訪談用戶，驗證相應場景和頻率。這樣有直接的數據佐證，大部分需求方會認可你的提議。

如果做，怎麼做？

最壞的結果是講完道理，你還沒有相應的數據佐證你，需求方覺得場景還是需要做，那如何處理？如果是在一定需要做的情況下，那就需要做好兩件事。第一是合理的設計，將這一功能弱化到盡量合理的位置。這裡的位置是指架構和頁面的位置。信息架構上合理的層級；頁面上不喧賓奪主，突出主要功能，遵循「奧卡姆剃刀原則」。第二是埋點數據，看後面數據的反饋情況。如果這是一個完全無有，數據表現很差的功能，同時影響到主體功能，那就必須在有數據印證後砍掉。

過度設計存在於我們大部分項目中，究其原因無非是對用戶理解不夠，對產品定位不明確，對體驗做不好拿捏。花更多的時間去理解場景，解析需求，很多問題可以迎刃而解。我們都希望自己的產品是極簡實用的，但真正需要做到真的很難。但作為產品的設計師，你必須定義好你的孩子是怎樣的，這是你的責任。