2023年產(chǎn)品設計：如何讓功能既靈活又簡單

產(chǎn)品設計：如何讓功能既靈活又簡單？一、為什么這是個問題？

功能設計是產(chǎn)品經(jīng)理最基本的技能，也是產(chǎn)品最基本的組成部分和價值所在。

所以，不管是在工作中，還是在面試中，一個功能設計得太簡單或者太雞肋，都會直接拉低別人對你的印象分！?。?/p>

但在產(chǎn)品設計中，敏捷與簡潔這兩個特性的確經(jīng)常是沖突的。

尤其是在工具型產(chǎn)品中，我們想把功能設計得很敏捷，就經(jīng)常會用起來很簡單；假如想設計得很簡潔，又會削減功能性，顯得很雞肋。

當然還有個方法，就是在簡潔的功能中加入機器學習模型；不過假如團隊自身積累不足，這個方法的投入就太高而價值又太小，不是個好方法。

舉個例子：在當今的產(chǎn)品中，包含的信息越來越多、越來越簡單，所以搜尋功能就越來越重要了。

在搜尋功能上，我們既盼望能夠足夠敏捷（比如支持各種條件組合，支持“與或非”等等），又盼望足夠簡潔（像一般文字輸入一樣）。

怎么辦呢？

這是一個比較典型的逆境，我們來看看百度、Google等通用搜尋引擎是怎么做的。

它們在“簡潔”上做得很精彩，當需要多個關鍵詞時，只需要用空格隔開就可以了。

還不錯對吧？但是，再看看它們應對“敏捷”的高級搜尋功能……

這里的確供應了足夠的敏捷性，但整個設計就倒塌了；由于從1個輸入框變成了10項配置，太簡單了?。。?/p>

那么假如加入機器學習模型呢？就這樣：

這類推舉看似簡潔，但假如要仔細做，需要投入不少人力和時間才能實現(xiàn)。

所以，百度這是個失敗的設計嗎？

其實不然——假如你是百度搜尋引擎的深度用戶，那么你應當知道這樣一組搜尋指令：

用減號“-”代表排解關鍵字；用“intitle:”代表關鍵字只消失在標題中；用“inurl:”代表關鍵字只消失在URL中；用“filetype:”代表只想看某些文件類型，比如docx、pdf；用“site:”代表只想搜尋某個站點中的內(nèi)容；以上這些指令都可以直接在搜尋框中輸入，既滿意了高級用戶的需求，又不會影響初級用戶的使用體驗。這就實現(xiàn)了既敏捷又簡潔。

那么，假如你想在設計自己的產(chǎn)品時也做到敏捷而簡潔，應當怎么做呢？

二、原來的設計問題出在哪？

首先，我們定義問題的范疇。

敏捷與簡潔的取舍，不是一個純粹的交互設計的問題，它還涉及到前端頁面交互與后端系統(tǒng)的協(xié)作；所以單從交互設計的角度很難找到答案。

這里必需說一點：要想提升對于產(chǎn)品的理解，需要練習自己的抽象思索力量。

在這里，我們就需要把詳細的產(chǎn)品交互做一次抽象和提煉，找到其中的規(guī)律；有技術背景的同學在這方面會有優(yōu)勢。

為什么？由于技術語言本身就是對事物的抽象。

其次，我們要打破一種思維定式：“一個功能是一體的，不再可分”；其實并不是這樣的，就用上面的搜尋引擎舉例，它與用戶相關的部分大致可以拆成兩個子模塊：

收集用戶輸入搜尋條件；系統(tǒng)解析用戶輸入的內(nèi)容；所以，正是這兩部分造成了敏捷與簡潔很難取舍——用戶隨便輸入的內(nèi)容系統(tǒng)很難解析；而系統(tǒng)便利解析的內(nèi)容對用戶來說太簡單了。

最終，我們可以借鑒技術領域的MVC設計理念，來考慮我們的產(chǎn)品功能設計。

MVC是三個單詞的首寫字母——M代表Model，是指產(chǎn)品中的數(shù)據(jù)模型；V代表View，是指產(chǎn)品中呈現(xiàn)數(shù)據(jù)的方式，其實就是用戶“看得見摸得著”的產(chǎn)品形態(tài)；C代表Controller，指的是真正用來響應用戶操作的部分。

這種設計理念為我們設計簡單功能打開了思路。

一個產(chǎn)品功能，我們可以從三個方面來思索它的設計：

第一部分是Controller，我們可以理解為“核心功能”。比如，在搜尋引擎中什么是“核心功能”？依據(jù)用戶輸入的條件，返回符合條件的結果，這就是核心功能；所以“查詢”就是一個必不行少的Controller。

其次部分是View，直接理解就是“產(chǎn)品形態(tài)”。比如收縮引擎中的輸入框，搜尋結果列表；這兩個詳細的產(chǎn)品形態(tài)，就是兩個View。

第三部分是Model，這部分就很抽象了；我們在這里不單獨解釋它，結合下面的例子一起說。

我們以“用Excel中的數(shù)據(jù)畫圖表”這個場景為例，來看看MVC的三個部分是怎么協(xié)作工作的。

首先，我們在一個Excel文件中保存的一份數(shù)據(jù)，這份數(shù)據(jù)，就相當于MVC中的Model。

接下來，我們選中這些數(shù)據(jù)，然后使用插入圖表的功能，并選擇一種圖表類型；比如我們選擇了折線圖，這其中“插入圖表”就是一個Controller，而折線圖就是一個View。

這時假設我們不想用折線圖了，想換成柱狀圖；那么，略微對Excel有一些了解的同學都知道，為了把折線圖換成柱狀圖，我們不需要復制一個Excel文件，也不需要再安裝一套Excel軟件，只需要轉(zhuǎn)變一下圖表類型。

為什么這么簡潔？

保存在Excel里的數(shù)據(jù)Model變了嗎？沒有。

“插入圖表”這個功能Controller變了嗎？也沒有。

要做的只是切換一下View。

所以，假設我們想在自己的產(chǎn)品中，增加一個類似“把折線圖換成柱狀圖”的功能，我們實際要增加的只是一個View，而不需要轉(zhuǎn)變已經(jīng)有的Model和Controller。

除非我們把“插入折線圖”和“插入柱狀圖”當做完全不相干的兩個功能來設計；不過這明顯不合理，而且已經(jīng)超綱了，我們不在這里爭論。

三、怎么用MVC設計產(chǎn)品功能？

現(xiàn)在你有體會到MVC在產(chǎn)品設計中的魅力嗎？那我們再舉個例子：

協(xié)作型的產(chǎn)品通常都會增加權限管理模塊。

根據(jù)標準的RBAC（RoleBasedAccessControl，基于角色的訪問掌握），我們需要設計的功能包括：

單個/批量管理用戶和給用戶賦權；單個/批量管理角色和給角色賦權；權限校驗，返回校驗通過或拒絕；聽起來像是個很簡單的功能模塊吧？別慌，假如用MVC的理念怎么設計呢？

這里只考慮了最核心的功能部分，在實際功能落地時，多少還會有其他功能補充進來，比如單點登錄、讀取用戶信息等。

首先我們有3個重要的Controller（不是全部哦），包括：

1個更新用戶與角色關系的Controller，支持批量；1個更新角色與權限關系的Controller，支持批量；1個校驗權限的Controller，支持不支持批量都行；其次，我們只有3個重要的Module，包括：

1個用戶與角色對應關系的Model；1個角色與權限對應關系的Model；1個用戶與權限對應關系的Model；其實，我們也可以把這三個Model合并成1個，這樣我就只需要一個“用戶-角色-權限”的Model了。

最終，我們也只需要1個View了，由于在交互上無非是查詢或者更新“用戶-角色-權限”三者之間的關系。

此時，假如之前我們的確沒有考慮到“批量