一個宏大的功能,是如何被設計出來的

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

一個宏大的功能,是如何被設計出來的

當我們決定要做某個功能時,就進入到產品經理基於對需求的理解從而進行功能方案設計的環節。

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

01 Epic?

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

Epic 是多個 Story 的集合,來描述一個非常大的功能。比如

甘特圖、地址欄位

等。這些 Epic 都至少可以拆分為一個 MVP 版本的大 Story 和後續修修補補的小的 Story 則單獨進行釋出。

繼續用甘特圖這個例子來講,我們在 Phase1 的 MVP 階段只需要透過“起始日期”、“結束日期”來生成甘特圖以展示專案在時間軸的進度情況。

而對於像是“甘特圖可以按照某個欄位進行上色”、“甘特圖中可以對任務進行分組顯示”、“可以拖拽完成起止日期的設定”等需求都被拆分成了後續的 Story 單獨進行釋出。

這樣做的好處是,

儘量縮短一個大功能的釋出週期,避免花費資源做了對使用者價值不大的功能

敏捷和瀑布的優劣勢這些太基礎的也不多講了,直奔重點聊聊當我拿到一個 Epic 功能時如何應對。

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

02 階段說明

我會從四個階段開始推進一個 Epic:

思路整理

初步方案

Phase1 整體方案

驗收用例和互動細節

這四個階段結合了產品經理和互動設計師常用的英國設計協會的「雙鑽模型(Double Diamond)」和 d。school的 IDEO設計思維,梳理成更加符合黑帕雲產品功能設計節奏的方法。

一個宏大的功能,是如何被設計出來的

雙鑽模型

一個宏大的功能,是如何被設計出來的

IDEO設計思維

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

從每週的釋出功能數量上就可以清楚地瞭解到,黑帕雲是一個高效的產品型公司

。我們有三位產品經理,兩位設計師,雖然大家所負責的都是不同的產品線,但是每週還是需要定時定點碰頭開個討論會,會上由負責人講解需求的背景和功能設計的方案。

在 CEO 陳金洲先生(公眾號:米高說)的多次強調下,

為了保證產品討論會的高效性

,很多過程產物都不會在這個會上進行宣講和討論。(比如各種腦圖、流程圖……)

一個宏大的功能,是如何被設計出來的

在進行產品設計之前,都屬於「響應使用者需求」的階段,具體從「提出需求」到「採納需求」的分析見之前寫過的這篇如何響應客戶的需求。

1. 分析研究

拿到 CSM 給到資料後,就開始進行一些分析研究的工作了,這個階段是發散的階段,需要儘可能去挖掘清楚使用者的問題是什麼,業務上有哪些上下文,競品的動作等等,最終會有一些零碎的、非結構化的研究結果。

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

2. 思路整理

分析研究的差不多之後,大腦中已經開始形成問題的雛形。接下來要做的事情就是把這些想法開始聚焦到問題上,定義出

對使用者最有價值的,技術成本相對不高

的核心要解決的問題。主要在宏觀上進行需求分析,大體思路整理。不過也會形成一些快速的想法,但還是主要整理當前的問題、現在的限制。再根據這些問題快速嘗試解決方法,不會考慮細節,也不會在這個階段思考互動和呈現,也不會思考 phase1 階段計劃做哪些。

到了這個階段之後,就會有一些低保真的圖可以來表示思路了,也可以在會上討論了。在討論時,需要關注

解決方向

是否合理,是否技術受限,是否可行。

3. 初步方案

在思路整理結果的基礎上,我會開始做一些設計的探索,開始發散不同角色視角的介面呈現。

這個階段會框定方案範圍,會寫寫功能邏輯,並以真實場景模擬的中高保真程度介面展示(輔助描述功能,表意元件之間的層級結構,但不代表介面設計方案)。在這個階段不關注介面設計是否合理、文案是否優雅,而是要圍繞需求層面以及功能的方案設計,透過兩三次的討論,

吸收會上大家的反饋,再去突破和審視,並且避免遺漏業務場景,從而做出設計方案的最優解

4. Phase1 整體方案

在初步方案討論後,將以一個最小最簡單的業務場景進行收斂,並且框定 Phase1 的整體方案。框定依據是會模擬一個真實場景,去走一遍這個場景下的業務,看看初步方案是否能夠符合,再從上一階段的方案中進行功能裁剪,將範圍縮減至最小。再將其他功能拆分出來,安排到後續的版本迭代中。

栗子:比如“地址欄位”功能 MVP 在訂單場景下,滿足填寫收貨人地址、篩選收貨人地址即可。分組和統計需求則可以拆分到後續的迭代中。這個階段的重點將不再是多場景,而是要評估所選場景是否合適,以及功能設計和 Phase1 的範圍是否能滿足所選場景。

5. 驗收用例和互動

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

一般

一個 Story 的顆粒度是

以可以交付到客戶手中的價值(也可描述為可進入完整測試)作為標準

。拆分 Story 的過程中,需要將 AC 描述清楚,開發在 Show Case 時,會按照 AC 逐條展示。

AC 需要描述使用者的使用路徑,什麼角色看到什麼入口,點選之後會發生什麼。除了正常的邏輯,還需要包含一些異常邏輯的處理,比如資料量超出 X 條時,不允許複製資料。除了期望功能外,還需考慮其他相關的影響。

例子:比如成員欄位開啟「允許使用多個成員」,功能期望為在填寫成員欄位時,可以新增多個成員。相關的影響有:篩選條件中的如何篩選多成員欄位、增量匯入資料如何識別多成員、分組時能否分組、能否按多個成員生成圖表等相關處理。

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

接下來會以一個黑帕雲在 2021 年 06 月 04 日釋出了一個“篩選關聯”的功能為例,講解整個功能設計的過程。

03 需求背景

最早是做汽車後市場的小特科技提出的這個需求。小特科技使用黑帕雲來管理他們門店的訂單資料。

在之前文章找到資料表中最新的一條關聯記錄中講到「關聯」,同樣的,在訂單資料中有這樣幾張表之間是關聯關係:

一個宏大的功能,是如何被設計出來的

所以在建立一個訂單時,需要填寫“下單門店”、購買的“商品型別”最後填寫購買的“商品”(庫存表),像是這樣:

一個宏大的功能,是如何被設計出來的

但是選擇“購買商品”是展示了庫存表中所有的資料。

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

一個宏大的功能,是如何被設計出來的

小特科技就提出說,能不能直接按照剛剛訂單中

所選擇的“門店”和“商品型別”然後把有庫存的商品篩選出來

,這樣就不用每次肉眼來找了。

04 思路整理

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

在足夠了解需求和業務之後,我就開始了一些快速想法的整理。

1. 場景模擬

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

(1)如圖所示,訂單中有“門店”、“商品型別”欄位,希望選擇商品時,可以按照“門店”、“商品型別”並且“庫存”大於 0 的篩選條件過濾出符合的商品:

一個宏大的功能,是如何被設計出來的

(2)培訓機構的財務在給在校學生錄入繳費記錄,希望關聯的學生列表可以過濾出“在校”的學生。

(3)在一個生產工單中,已經選擇了這個工單的工序,在選擇裝置時,希望能直接過濾出工序的裝置。如已選擇工序是“表面處理”,那麼希望在選擇裝置時,只出現做“表面處理”的裝置。如“熱處理”、“退火”等工序的裝置就可以過濾出去。

一個宏大的功能,是如何被設計出來的

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

所以我們收斂到業務價值上,就是“透過設定固定值或動態值,對關聯資料進行篩選,從而快速選擇到使用者需要的資料。”

接下來再去

定義問題

。篩選很容易做,但是我們提供這樣的能力,這是一個許可權問題還是輔助的問題?

2. 定義問題

(1)如果是許可權問題

意味著下單店員、財務、生產工單派單員他們

只能

選擇篩選條件過濾之後的資料。比如說所選商品

必須

是所選門店的並且庫存要大於 0,所選的學生

必須

是在校,所選的裝置

必須

是之前工序對應的裝置。比如這樣設定:

一個宏大的功能,是如何被設計出來的

(2)如果是輔助篩選問題

既然不是許可權問題,那就只是一個快捷的過濾功能。意味著選擇篩選資料時,可以選擇篩選條件過濾後的,但是也可以使用不符合篩選條件的資料。比如可以選擇庫存小於 0、不在所選門店的商品,可以選擇已經退學的學生,可以選擇和所選工序不匹配的裝置。

乍聽之下確實是個許可權問題?別太快下結論,先來思考這樣兩個問題:

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

是不是想到提交資料時候去判斷所選商品是否符合篩選條件?

考驗你在第一個階段做研究程度的考試來了。雖然你的使用者只提到了他在建立訂單、建立工單時的場景,但你需要再深入挖掘整個業務流程。直到你挖掘出“客人的訂單是有狀態的,這些狀態都是在倉庫那邊修改的,比方說出庫人操作完出庫後要改狀態,還要把快遞單號填上去。”——這就是需求的 B 面。

使用者不會主動說他認為沒有關係的資訊,這些都需要你有需要看到事情全貌的感知力,然後繼續去探索和挖掘。

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

所以,如果這是一個許可權問題,你得到的答案是要麼是許可權不嚴謹,要麼是使用者覺得功能做了不如不做。

05 初步方案

在上個階段最終定位了問題後,下一步我們就開始探索功能的設計方案。

你可能會疑惑,功能的設計方案也要產品經理來做嗎?在一個高效的產品設計團隊,大家的職責範圍的邊界已經不是那麼清晰了。我們沒有一個人在做螺絲釘工作,所有的工作都是為了更好地設計出一個有價值的、使用者喜歡的功能。

雖然衡量業務價值、定義功能才是產品同學的核心工作。但是在一些非常邏輯化並且業務相對複雜深入的功能上,如果把這些資訊傳遞給下游的設計師去做,肯定會在中間損耗一些資訊。如果你能多做一點,就儘量不要把資訊流轉到下游。

到了下游互動設計師或者 UI 設計師的環節,他們的目標不是隻上個色,整理一下間距,而是站在產品同學設計好的功能方案基礎上,重新站在使用者的角度思考,這個功能哪些是重要資訊、哪些是次要資訊,如何在使用過程中使用者更清楚、更容易達到他的目的,這才是設計價值的體現。

不過要注意的是(也是我曾經犯過的錯誤),不能只把需求描述和功能設計方案直接丟給設計師,然後問他們要最終 UI 設計圖。

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

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

這麼做的目的是讓產品經理和設計師的價值最大化,效率最大化,各自發揮自己擅長的部分,短板部分讓對方補齊。

最後,要如何衡量功能和 UI 設計方案是否達標,可以用基本的 GSM 模型,快速評估:

一個宏大的功能,是如何被設計出來的

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

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

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

這顯然違背了方法論的初衷。方法論是前人根據經驗的總結,形成的一套認識和指導理論。

為了讓我們站在他們知識的肩膀上更好更高效地做設計。

在這兩年產研節奏緊張的實踐之後,忽然發現很多方法論都是

無感知

地被自己使用了(比如上述的 GSM 模型)。這是熟悉了方法論之後,思考方式和設計策略都被影響了,即便只是用到了其中某個小點並被自己加以“本土化”,最終得到了經得起使用者推敲評估的方案。我想這才是方法論被人們學習的目的吧。

回到正題。

再來重申下問題:在選擇關聯時,如何輔助篩選,從而讓使用者快速找到目的資料?

首先要思考,誰能做這個篩選,篩選入口在哪裡放比較合適。第二個問題有一個顯然易見的答案,因為題幹已經告訴我了:

在選擇關聯時

那麼可以直接將範圍縮小到選擇關聯資料的彈框中。然後再考慮誰能做這個篩選。

我想到在一些場景中,能看到這個彈框,通常都是經常操作的一線業務人員,比如模擬場景中的店員、財務、生產工單派單員。他們往往不是應用管理員。

那會不會有人不注意改設定,影響別人?管理員能不能把許可權放心交給應用成員?還是需要管理這個篩選的許可權?

這些都是需要發散去探索的。

這一步在這個案例中,其實我當時沒有做的很好。現在反過頭來再整理覆盤時,發現自己當時發散的還不夠,也沒有做深入的調研,只是憑直覺認為它的許可權應該被管理員控制,然後就匆忙把問題丟到討論會上。

在會上,經驗老到的 CEO 的觀點指出,建議先放開許可權給所有使用者。理由是我們現在的目的是讓這個功能被更多人發現,更快被使用,更快傳遞價值,所以應該讓它的受眾範圍不僅侷限在管理員,而且即便非管理員是做了篩選,這也沒什麼大不了的。

回過頭覆盤時,也對功能有了更深刻的體會:管理員並不關心其他人關聯了什麼資料,因為這不是一個許可權控制的問題,這是快速幫助使用中篩選目標資料的問題。如果關聯了沒有許可權的,那也應該在角色和許可權中設定這個角色對關聯表資料的可見許可權。

確定了以上兩個問題之後,推匯出來以下設計目標:

有關聯欄位編輯許可權的使用者可以容易地發現這個新功能,順利設定篩選條件,並且設定能夠儲存

為了讓其他人接收到“資料已經是篩選過的”這一資訊,需要有相對明顯的標記,防止使用者產生“為什麼資料不全”的疑惑

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

如下圖所見,我的第一個方案是把入口放在對話方塊 Header 的右邊,關閉按鈕的左邊。(因為這裡本身有一個按鈕,點選後的 Drop Down 中可以對關聯表的欄位進行排序和顯隱)

一個宏大的功能,是如何被設計出來的

點選後看到這樣的設定說明:

一個宏大的功能,是如何被設計出來的

這個方案收到的反饋是“把簡單功能複雜化,可能是你現在最得心應手的能力”。

就,真·沒必要讓使用者閱讀這麼一長串功能說明,帶來的結果很大機率是“讓使用者快速用上功能”這一 Signal 的評分在及格線之下。

再來看方案二:

一個宏大的功能,是如何被設計出來的

這個方案已經很接近設計目標了。透過開關來控制是否使用已經設定好的篩選條件,這完全取決個人。點選右側“展開篩選條件”,可以展開檢視現在有哪些篩選條件。

不過 CEO 又對設計方案進行了一些使用者感知上的最佳化建議,也就是線上我們看到的版本。

沒有篩選條件時,會看到“篩選”按鈕,使用者也能快速 get 到這裡的資訊是可以篩選的。

一個宏大的功能,是如何被設計出來的

點選篩選後,同樣會展開設定篩選條件:

一個宏大的功能,是如何被設計出來的

儲存後,會清楚看到這些資料是經過篩選後的:

一個宏大的功能,是如何被設計出來的

06 Phase1 方案

這個 Epic 拆解起來非常容易,因為在上一個階段已經把整體的設計方案定下來了。

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

前面在 「04 思路整理」階段的「場景模擬」這一小結提到:

這些場景的共通點是,篩選可能是

固定的某個值

(比如可以設定員工的狀態是“在職”),但也有可能是個

動態的依賴訂單或工單中填寫的某個值

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

之後在今年 9 月 9 日釋出了動態值的篩選。收到了使用者的“篩選苦他們久矣”的表揚。

07 寫在最後

在寫這篇文章時,發現 Airtable 已經發布了類似的功能。

不過它的入口是在這個關聯欄位的設定上,也就是一開始我們討論的“許可權問題還是輔助篩選問題”。不能說是因為 Airtable 對業務理解不夠深入,而是他們這樣做是因為和黑帕雲的產品受眾和定位的不同。

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

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

作者:範昕茹,編輯:王昕挨踢妹,排版:季嘉穎

本文由人人都是產品經理合作媒體 @IT時報 授權釋出,未經許可,禁止轉載

題圖來自Unsplash,基於 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。

頂部