敏捷項目管理會把 Feature 分為「Epic」和「Story」兩種級別，Epic 是多個 Story 的集合，來描述一個非常大的功能。作者從實際工作中的方案設(shè)計出發(fā)，講述了是如何完成一項Epic級別功能設(shè)計的過程。

當我們決定要做某個功能時，就進入到產(chǎn)品經(jīng)理基于對需求的理解從而進行功能方案設(shè)計的環(huán)節(jié)。

場景和需求方面的不再在本文贅述，本文只講講功能方案設(shè)計的過程。

01 Epic？

如大家所知，敏捷項目管理會把 Feature 分為「Epic」和「Story」兩種級別。

Epic 是多個 Story 的集合，來描述一個非常大的功能。比如甘特圖、地址字段等。這些 Epic 都至少可以拆分為一個 MVP 版本的大 Story 和后續(xù)修修補補的小的 Story 則單獨進行發(fā)布。

繼續(xù)用甘特圖這個例子來講，我們在 Phase1 的 MVP 階段只需要通過“起始日期”、“結(jié)束日期”來生成甘特圖以展示項目在時間軸的進度情況。

而對于像是“甘特圖可以按照某個字段進行上色”、“甘特圖中可以對任務(wù)進行分組顯示”、“可以拖拽完成起止日期的設(shè)置”等需求都被拆分成了后續(xù)的 Story 單獨進行發(fā)布。

這樣做的好處是，盡量縮短一個大功能的發(fā)布周期，避免花費資源做了對用戶價值不大的功能。

敏捷和瀑布的優(yōu)劣勢這些太基礎(chǔ)的也不多講了，直奔重點聊聊當我拿到一個 Epic 功能時如何應(yīng)對。

依然求生欲滿滿地再聲明一下，本文僅代表我個人主張，不代表公司立場。

02 階段說明

我會從四個階段開始推進一個 Epic：思路整理、初步方案、Phase1 整體方案、驗收用例和交互細節(jié)。

這四個階段結(jié)合了產(chǎn)品經(jīng)理和交互設(shè)計師常用的英國設(shè)計協(xié)會的「雙鉆模型（Double Diamond）」和 d.school的 IDEO設(shè)計思維，梳理成更加符合黑帕云產(chǎn)品功能設(shè)計節(jié)奏的方法。

雙鉆模型

IDEO設(shè)計思維

不難看出，上面兩個思維的方法都是先發(fā)散再收斂，再發(fā)散再收斂，最終到推進功能的開發(fā)階段。

從每周的發(fā)布功能數(shù)量上就可以清楚地了解到，黑帕云是一個高效的產(chǎn)品型公司。我們有三位產(chǎn)品經(jīng)理，兩位設(shè)計師，雖然大家所負責(zé)的都是不同的產(chǎn)品線，但是每周還是需要定時定點碰頭開個討論會，會上由負責(zé)人講解需求的背景和功能設(shè)計的方案。

在 CEO 陳金洲先生（公眾號：米高說）的多次強調(diào)下，為了保證產(chǎn)品討論會的高效性，很多過程產(chǎn)物都不會在這個會上進行宣講和討論。（比如各種腦圖、流程圖……）

在進行產(chǎn)品設(shè)計之前，都屬于「響應(yīng)用戶需求」的階段，具體從「提出需求」到「采納需求」的分析見之前寫過的這篇如何響應(yīng)客戶的需求。

1. 分析研究

拿到 CSM 給到資料后，就開始進行一些分析研究的工作了，這個階段是發(fā)散的階段，需要盡可能去挖掘清楚用戶的問題是什么，業(yè)務(wù)上有哪些上下文，競品的動作等等，最終會有一些零碎的、非結(jié)構(gòu)化的研究結(jié)果。

但在這個階段，我一般不會形成書面的材料，只會丟進 eagle 或者語雀小記這種便簽，隨手記下來。方便快速記，也便于快速找到并翻看。

2. 思路整理

分析研究的差不多之后，大腦中已經(jīng)開始形成問題的雛形。接下來要做的事情就是把這些想法開始聚焦到問題上，定義出對用戶最有價值的，技術(shù)成本相對不高的核心要解決的問題。主要在宏觀上進行需求分析，大體思路整理。不過也會形成一些快速的想法，但還是主要整理當前的問題、現(xiàn)在的限制。再根據(jù)這些問題快速嘗試解決方法，不會考慮細節(jié)，也不會在這個階段思考交互和呈現(xiàn)，也不會思考 phase1 階段計劃做哪些。

到了這個階段之后，就會有一些低保真的圖可以來表示思路了，也可以在會上討論了。在討論時，需要關(guān)注解決方向是否合理，是否技術(shù)受限，是否可行。

3. 初步方案

在思路整理結(jié)果的基礎(chǔ)上，我會開始做一些設(shè)計的探索，開始發(fā)散不同角色視角的界面呈現(xiàn)。

這個階段會框定方案范圍，會寫寫功能邏輯，并以真實場景模擬的中高保真程度界面展示（輔助描述功能，表意組件之間的層級結(jié)構(gòu)，但不代表界面設(shè)計方案）。在這個階段不關(guān)注界面設(shè)計是否合理、文案是否優(yōu)雅，而是要圍繞需求層面以及功能的方案設(shè)計，通過兩三次的討論，吸收會上大家的反饋，再去突破和審視，并且避免遺漏業(yè)務(wù)場景，從而做出設(shè)計方案的最優(yōu)解。

4. Phase1 整體方案

在初步方案討論后，將以一個最小最簡單的業(yè)務(wù)場景進行收斂，并且框定 Phase1 的整體方案?？蚨ㄒ罁?jù)是會模擬一個真實場景，去走一遍這個場景下的業(yè)務(wù)，看看初步方案是否能夠符合，再從上一階段的方案中進行功能裁剪，將范圍縮減至最小。再將其他功能拆分出來，安排到后續(xù)的版本迭代中。

栗子：比如“地址字段”功能 MVP 在訂單場景下，滿足填寫收貨人地址、篩選收貨人地址即可。分組和統(tǒng)計需求則可以拆分到后續(xù)的迭代中。這個階段的重點將不再是多場景，而是要評估所選場景是否合適，以及功能設(shè)計和 Phase1 的范圍是否能滿足所選場景。

5. 驗收用例和交互

最后的階段主要是 Story 的拆分和細節(jié)的驗收標準（Acceptance Criteria，簡稱AC） 書寫，我們一般這個階段就不會在產(chǎn)品討論會上和大家同步了，一來細節(jié)太多，二來沒有必要討論，第三浪費大家的時間，所以討論價值不高。

一般一個 Story 的顆粒度是以可以交付到客戶手中的價值（也可描述為可進入完整測試）作為標準。拆分 Story 的過程中，需要將 AC 描述清楚，開發(fā)在 Show Case 時，會按照 AC 逐條展示。

AC 需要描述用戶的使用路徑，什么角色看到什么入口，點擊之后會發(fā)生什么。除了正常的邏輯，還需要包含一些異常邏輯的處理，比如數(shù)據(jù)量超出 X 條時，不允許復(fù)制數(shù)據(jù)。除了期望功能外，還需考慮其他相關(guān)的影響。

例子：比如成員字段開啟「允許使用多個成員」，功能期望為在填寫成員字段時，可以添加多個成員。相關(guān)的影響有：篩選條件中的如何篩選多成員字段、增量導(dǎo)入數(shù)據(jù)如何識別多成員、分組時能否分組、能否按多個成員生成圖表等相關(guān)處理。

在這個階段會盡量避免有遺漏的場景，并且要仔細檢查交互是否合理。

接下來會以一個黑帕云在 2021 年 06 月 04 日發(fā)布了一個“篩選關(guān)聯(lián)”的功能為例，講解整個功能設(shè)計的過程。

03 需求背景

最早是做汽車后市場的小特科技提出的這個需求。小特科技使用黑帕云來管理他們門店的訂單數(shù)據(jù)。

在之前文章找到數(shù)據(jù)表中最新的一條關(guān)聯(lián)記錄中講到「關(guān)聯(lián)」，同樣的，在訂單數(shù)據(jù)中有這樣幾張表之間是關(guān)聯(lián)關(guān)系：

所以在創(chuàng)建一個訂單時，需要填寫“下單門店”、購買的“商品類型”最后填寫購買的“商品”（庫存表），像是這樣：

但是選擇“購買商品”是展示了庫存表中所有的數(shù)據(jù)。

在 Airtable 中，會把所有門店、所有類型的庫存商品都展示出來，也無論是否這個商品是否有庫存，全靠人工甄別：

小特科技就提出說，能不能直接按照剛剛訂單中所選擇的“門店”和“商品類型”然后把有庫存的商品篩選出來，這樣就不用每次肉眼來找了。

04 思路整理

在研究階段，必不可少的是競品調(diào)研，很遺憾，Airtable 當時還沒有這樣的能力，所以也沒有什么能夠參考的方案。

在足夠了解需求和業(yè)務(wù)之后，我就開始了一些快速想法的整理。

1. 場景模擬

首先是找了相對真實的幾個場景：

（1）如圖所示，訂單中有“門店”、“商品類型”字段，希望選擇商品時，可以按照“門店”、“商品類型”并且“庫存”大于 0 的篩選條件過濾出符合的商品：

（2）培訓(xùn)機構(gòu)的財務(wù)在給在校學(xué)生錄入繳費記錄，希望關(guān)聯(lián)的學(xué)生列表可以過濾出“在?！钡膶W(xué)生。

（3）在一個生產(chǎn)工單中，已經(jīng)選擇了這個工單的工序，在選擇設(shè)備時，希望能直接過濾出工序的設(shè)備。如已選擇工序是“表面處理”，那么希望在選擇設(shè)備時，只出現(xiàn)做“表面處理”的設(shè)備。如“熱處理”、“退火”等工序的設(shè)備就可以過濾出去。

這些場景的共通點是，篩選可能是固定的某個值（比如可以設(shè)置員工的狀態(tài)是“在職”），但也有可能是個動態(tài)的依賴訂單或工單中填寫的某個值。

所以我們收斂到業(yè)務(wù)價值上，就是“通過設(shè)置固定值或動態(tài)值，對關(guān)聯(lián)數(shù)據(jù)進行篩選，從而快速選擇到用戶需要的數(shù)據(jù)?！?/p>

接下來再去定義問題。篩選很容易做，但是我們提供這樣的能力，這是一個權(quán)限問題還是輔助的問題？

2. 定義問題

（1）如果是權(quán)限問題

意味著下單店員、財務(wù)、生產(chǎn)工單派單員他們只能選擇篩選條件過濾之后的數(shù)據(jù)。比如說所選商品必須是所選門店的并且?guī)齑嬉笥?0，所選的學(xué)生必須是在校，所選的設(shè)備必須是之前工序?qū)?yīng)的設(shè)備。比如這樣設(shè)置：

（2）如果是輔助篩選問題

既然不是權(quán)限問題，那就只是一個快捷的過濾功能。意味著選擇篩選數(shù)據(jù)時，可以選擇篩選條件過濾后的，但是也可以使用不符合篩選條件的數(shù)據(jù)。比如可以選擇庫存小于 0、不在所選門店的商品，可以選擇已經(jīng)退學(xué)的學(xué)生，可以選擇和所選工序不匹配的設(shè)備。

乍聽之下確實是個權(quán)限問題？別太快下結(jié)論，先來思考這樣兩個問題：

如果你要限制能選擇商品必須是訂單中所選門店的，如果訂單中門店選擇了“鐘樓店”，選擇了鐘樓店的商品后，此時去修改訂單中的門店是“大明宮店”，如何避免這樣的情況？

是不是想到提交數(shù)據(jù)時候去判斷所選商品是否符合篩選條件？

考驗?zāi)阍诘谝粋€階段做研究程度的考試來了。雖然你的用戶只提到了他在創(chuàng)建訂單、創(chuàng)建工單時的場景，但你需要再深入挖掘整個業(yè)務(wù)流程。直到你挖掘出“客人的訂單是有狀態(tài)的，這些狀態(tài)都是在倉庫那邊修改的，比方說出庫人操作完出庫后要改狀態(tài)，還要把快遞單號填上去?！薄@就是需求的 B 面。用戶不會主動說他認為沒有關(guān)系的信息，這些都需要你有需要看到事情全貌的感知力，然后繼續(xù)去探索和挖掘。

在給在校學(xué)生繳費時也是如此，A 面是正常為在校學(xué)生錄入繳費記錄，B 面是為已退學(xué)學(xué)生補繳費用。

所以，如果這是一個權(quán)限問題，你得到的答案是要么是權(quán)限不嚴謹，要么是用戶覺得功能做了不如不做。

05 初步方案

在上個階段最終定位了問題后，下一步我們就開始探索功能的設(shè)計方案。

你可能會疑惑，功能的設(shè)計方案也要產(chǎn)品經(jīng)理來做嗎？在一個高效的產(chǎn)品設(shè)計團隊，大家的職責(zé)范圍的邊界已經(jīng)不是那么清晰了。我們沒有一個人在做螺絲釘工作，所有的工作都是為了更好地設(shè)計出一個有價值的、用戶喜歡的功能。

雖然衡量業(yè)務(wù)價值、定義功能才是產(chǎn)品同學(xué)的核心工作。但是在一些非常邏輯化并且業(yè)務(wù)相對復(fù)雜深入的功能上，如果把這些信息傳遞給下游的設(shè)計師去做，肯定會在中間損耗一些信息。如果你能多做一點，就盡量不要把信息流轉(zhuǎn)到下游。

到了下游交互設(shè)計師或者 UI 設(shè)計師的環(huán)節(jié)，他們的目標不是只上個色，整理一下間距，而是站在產(chǎn)品同學(xué)設(shè)計好的功能方案基礎(chǔ)上，重新站在用戶的角度思考，這個功能哪些是重要信息、哪些是次要信息，如何在使用過程中用戶更清楚、更容易達到他的目的，這才是設(shè)計價值的體現(xiàn)。

不過要注意的是（也是我曾經(jīng)犯過的錯誤），不能只把需求描述和功能設(shè)計方案直接丟給設(shè)計師，然后問他們要最終 UI 設(shè)計圖。

因為如果這么做，要么你會得到一個把功能改的面目全非的、你看來漏洞百出的設(shè)計圖，要么你會得到一個只是沒有任何設(shè)計加分的、只是整齊的設(shè)計圖。

后來我才意識到，需求和功能設(shè)計方案對于設(shè)計師是不夠的。設(shè)計師也需要我給研發(fā)開卡那樣，講清楚需要設(shè)計師幫忙做什么，需求背景是什么，為什么有這個需求，我拿到這個需求后整個思考過程是什么。確保我和設(shè)計師的目的是一樣的，也就是所謂的“拉通、對齊”。

這么做的目的是讓產(chǎn)品經(jīng)理和設(shè)計師的價值最大化，效率最大化，各自發(fā)揮自己擅長的部分，短板部分讓對方補齊。

最后，要如何衡量功能和 UI 設(shè)計方案是否達標，可以用基本的 GSM 模型，快速評估：

說到方法論，突然想講點題外話。

這兩年似乎大家都對方法論嗤之以鼻，認為就是生搬硬套，尤其是我們這種非科班出身的產(chǎn)品經(jīng)理和一些自己靠經(jīng)驗和天賦成長起來的設(shè)計師。

慚愧地說，我本人在兩年前也是方法論初學(xué)者，學(xué)到什么就套什么。比如常見的用戶體驗旅程（User Journey）、電梯宣言（Elevator Speech）、利益相關(guān)者地圖（Stakeholder Map）、同理心地圖（Empathy Map）、海盜模型（AAARR）等等。為了顯得設(shè)計方案“高級”一點，就把這些內(nèi)容套在已有的方案上進行包裝。

這顯然違背了方法論的初衷。方法論是前人根據(jù)經(jīng)驗的總結(jié)，形成的一套認識和指導(dǎo)理論。為了讓我們站在他們知識的肩膀上更好更高效地做設(shè)計。

在這兩年產(chǎn)研節(jié)奏緊張的實踐之后，忽然發(fā)現(xiàn)很多方法論都是無感知地被自己使用了（比如上述的 GSM 模型）。這是熟悉了方法論之后，思考方式和設(shè)計策略都被影響了，即便只是用到了其中某個小點并被自己加以“本土化”，最終得到了經(jīng)得起用戶推敲評估的方案。我想這才是方法論被人們學(xué)習(xí)的目的吧。

回到正題。

再來重申下問題：在選擇關(guān)聯(lián)時，如何輔助篩選，從而讓用戶快速找到目的數(shù)據(jù)？

首先要思考，誰能做這個篩選，篩選入口在哪里放比較合適。第二個問題有一個顯然易見的答案，因為題干已經(jīng)告訴我了：在選擇關(guān)聯(lián)時。

那么可以直接將范圍縮小到選擇關(guān)聯(lián)數(shù)據(jù)的彈框中。然后再考慮誰能做這個篩選。

我想到在一些場景中，能看到這個彈框，通常都是經(jīng)常操作的一線業(yè)務(wù)人員，比如模擬場景中的店員、財務(wù)、生產(chǎn)工單派單員。他們往往不是應(yīng)用管理員。

那會不會有人不注意改設(shè)置，影響別人？管理員能不能把權(quán)限放心交給應(yīng)用成員？還是需要管理這個篩選的權(quán)限？

這些都是需要發(fā)散去探索的。

這一步在這個案例中，其實我當時沒有做的很好。現(xiàn)在反過頭來再整理復(fù)盤時，發(fā)現(xiàn)自己當時發(fā)散的還不夠，也沒有做深入的調(diào)研，只是憑直覺認為它的權(quán)限應(yīng)該被管理員控制，然后就匆忙把問題丟到討論會上。

在會上，經(jīng)驗老到的 CEO 的觀點指出，建議先放開權(quán)限給所有用戶。理由是我們現(xiàn)在的目的是讓這個功能被更多人發(fā)現(xiàn)，更快被使用，更快傳遞價值，所以應(yīng)該讓它的受眾范圍不僅局限在管理員，而且即便非管理員是做了篩選，這也沒什么大不了的。

回過頭復(fù)盤時，也對功能有了更深刻的體會：管理員并不關(guān)心其他人關(guān)聯(lián)了什么數(shù)據(jù)，因為這不是一個權(quán)限控制的問題，這是快速幫助使用中篩選目標數(shù)據(jù)的問題。如果關(guān)聯(lián)了沒有權(quán)限的，那也應(yīng)該在角色和權(quán)限中設(shè)置這個角色對關(guān)聯(lián)表數(shù)據(jù)的可見權(quán)限。

確定了以上兩個問題之后，推導(dǎo)出來以下設(shè)計目標：

• 有關(guān)聯(lián)字段編輯權(quán)限的用戶可以容易地發(fā)現(xiàn)這個新功能，順利設(shè)置篩選條件，并且設(shè)置能夠保存
• 為了讓其他人接收到“數(shù)據(jù)已經(jīng)是篩選過的”這一信息，需要有相對明顯的標記，防止用戶產(chǎn)生“為什么數(shù)據(jù)不全”的疑惑

下一步就是具體方案的探索。

如下圖所見，我的第一個方案是把入口放在對話框 Header 的右邊，關(guān)閉按鈕的左邊。（因為這里本身有一個按鈕，點擊后的 Drop Down 中可以對關(guān)聯(lián)表的字段進行排序和顯隱）

點擊后看到這樣的設(shè)置說明：

這個方案收到的反饋是“把簡單功能復(fù)雜化，可能是你現(xiàn)在最得心應(yīng)手的能力”。

就，真·沒必要讓用戶閱讀這么一長串功能說明，帶來的結(jié)果很大概率是“讓用戶快速用上功能”這一 Signal 的評分在及格線之下。

再來看方案二：

這個方案已經(jīng)很接近設(shè)計目標了。通過開關(guān)來控制是否使用已經(jīng)設(shè)置好的篩選條件，這完全取決個人。點擊右側(cè)“展開篩選條件”，可以展開查看現(xiàn)在有哪些篩選條件。

不過 CEO 又對設(shè)計方案進行了一些用戶感知上的優(yōu)化建議，也就是線上我們看到的版本。

沒有篩選條件時，會看到“篩選”按鈕，用戶也能快速 get 到這里的信息是可以篩選的。

點擊篩選后，同樣會展開設(shè)置篩選條件：

保存后，會清楚看到這些數(shù)據(jù)是經(jīng)過篩選后的：

06 Phase1 方案

這個 Epic 拆解起來非常容易，因為在上一個階段已經(jīng)把整體的設(shè)計方案定下來了。

所以在定 Phase1 場景時候也跳不開整個設(shè)計方案的框架。

前面在 「04 思路整理」階段的「場景模擬」這一小結(jié)提到：

這些場景的共通點是，篩選可能是固定的某個值（比如可以設(shè)置員工的狀態(tài)是“在職”），但也有可能是個動態(tài)的依賴訂單或工單中填寫的某個值。

所以就很好拆出 Phase1 滿足的是那些需要篩選“固定值”的場景。設(shè)計方案也完美覆蓋這一場景。

之后在今年 9 月 9 日發(fā)布了動態(tài)值的篩選。收到了用戶的“篩選苦他們久矣”的表揚。

07 寫在最后

在寫這篇文章時，發(fā)現(xiàn) Airtable 已經(jīng)發(fā)布了類似的功能。

不過它的入口是在這個關(guān)聯(lián)字段的設(shè)置上，也就是一開始我們討論的“權(quán)限問題還是輔助篩選問題”。不能說是因為 Airtable 對業(yè)務(wù)理解不夠深入，而是他們這樣做是因為和黑帕云的產(chǎn)品受眾和定位的不同。

相信國內(nèi)的競品們很快也會有類似的功能，很期待看到他們是如何定義這個功能。

個人猜測還是會像 Airtable 一樣，因為他們定位更加相像一些，都是團隊協(xié)作類的結(jié)構(gòu)化電子表格。拭目以待~