功能設計:將需求轉化成實際的功能列表

3 評論 36744 瀏覽 167 收藏 9 分鐘

圍繞功能框架去設計,不要去迎合領導,不要去討好用戶,不要去取悅自己。產(chǎn)品經(jīng)理在做功能設計的時候,要能保持平和中立的心態(tài),才能確保核心主線功能不出現(xiàn)任何偏差。

概念設計階段是需求從抽象到具體、從模糊到清晰的過程,確立了產(chǎn)品的功能模型和信息架構。而功能設計則需要將信息架構進一步落地,是從框架結構到詳細設計的過程。以分析后的需求為依據(jù),在概念設計的基礎上,設計產(chǎn)品的功能,經(jīng)過功能的成本核算后,再進行產(chǎn)品設計。

功能設計主要是確定產(chǎn)品的功能列表,產(chǎn)品初始的核心功能基本上在這個階段就定下來了。實際上,我們在做需求分析的時候,做加法和減法的核心思考也是保證產(chǎn)品的核心主線功能,只是功能設計階段出來的功能列表更細化,甚至是到任務級。我現(xiàn)在給產(chǎn)品團隊分配任務的時候,基本上都是這個層級的,功能列表細化到只差設計落地了。

在做功能設計的過程中,要注意三點:

一是要對功能列表進行分類。產(chǎn)品經(jīng)理在確定產(chǎn)品主要功能列表之后,應該考慮為用戶去做的事情就是分類。分類可能無助于降低產(chǎn)品使用的難度,但是可以幫助用戶更快速的認知產(chǎn)品和周邊的世界。主要就是降低用戶的認知和學習成本,讓用戶更容易接受。

有些產(chǎn)品的核心功能實現(xiàn)之后可以應用的場景很多,比如在線視頻類的功能,可以做直播、錄微課、開視頻會議、做遠程協(xié)作等等,雖然功能的操作難度是一樣的,但不同的場景下操作步驟或者環(huán)節(jié)是不太一樣的,這時若要達到用戶快速上手的目的,就需要依照應用的場景對相應的功能列表進行劃分,進而達到不同場景下的不同功能列表組裝。

二是要堅持圍繞功能框架來設計功能列表。千萬不要反過來做,概念設計階段確定的功能框架實際上就是產(chǎn)品整體功能的核心組成部分,在此基礎上去細化功能列表。也不要迎合任何人,功能加多了并不是什么好事。

不要倒過來去做,很多時候依照功能列表去反推功能框架,往往會把產(chǎn)品規(guī)劃變得面目全非,你對功能列表的取舍就變得沒有依據(jù),覺得每個功能點都挺好的,都對產(chǎn)品有幫助,到最后發(fā)現(xiàn)組裝出來的已經(jīng)完全不是原來的設想了,這樣也會導致功能設計偏離需求分析的結論。

圍繞功能框架去設計,不要去迎合領導,不要去討好用戶,不要去取悅自己。產(chǎn)品經(jīng)理在做功能設計的時候,要能保持平和中立的心態(tài),才能確保核心主線功能不出現(xiàn)任何偏差。

三是想清楚再確認加入列表。任何一個功能點,只要還沒有想清楚,寧愿先不做。不要為了功能的豐滿度,刻意的加上一些待確認的功能點。

這樣做的危害是比較大的,既有可能影響項目的進度,又可能會造成大概率的返工。我們在需求分析階段就要做需求的可行性分析,到功能設計階段,也要做功能點的可行性分析,確保功能列表都是明確可實施的。

以營銷短信管理模塊為例,這是CRM系統(tǒng)里很常見的一個功能,要實現(xiàn)營銷短信對用戶的針對性發(fā)送,一般都需要給運營人員做一個發(fā)送管理的系統(tǒng),常見的功能框架為發(fā)送短信和查看結果,基于此的功能列表如下:

短信發(fā)送結果明細列表查詢,可查看接收方手機號、發(fā)送時間、發(fā)送內(nèi)容、發(fā)送狀態(tài);

  1. 按接收方手機號查詢發(fā)送結果;
  2. 發(fā)送內(nèi)容模板的自定義管理;
  3. 接收方手機號信息的批量導入;
  4. 單一接收方疲勞度控制;
  5. 發(fā)送內(nèi)容支持鏈接;
  6. 短鏈接轉化生成功能。

可以看出在圍繞發(fā)送和結果查看這兩件事上,需要做不少的功能點。而第5點和第7點看似和功能框架沒什么關系,卻是比較關鍵又是可以取舍的功能。

疲勞度控制主要是考慮接收方體驗的,一般是單個手機號單天收到3條以內(nèi),也已經(jīng)很多了,現(xiàn)在1天收1條都會覺得多,有些產(chǎn)品甚至控制3天收1條,這取決于受眾群體的接收能力。如果發(fā)送比較頻繁,這個功能點是很有必要的,如果發(fā)送不那么頻繁,這個功能也就可做可不做的,因為不頻繁的情況下完全可以人為控制。

短鏈接生成是考慮短信發(fā)送字符限制的問題,正常的鏈接都是字符數(shù)很多的,現(xiàn)在市面上有很多短鏈接生成的第三方工具,這時還需要分析可行性,考慮需不需要調(diào)用第三方的API,還是人為的去做短鏈接的轉化。

從這個例子可以看出, 我們在圍繞功能框架設計的時候,產(chǎn)品經(jīng)理除了要將常規(guī)的功能點設計出來以外,還要考慮業(yè)務本身的場景要求和用戶使用的場景要求。

例子只是針對一個功能模塊的,若是整個產(chǎn)品,首先功能模塊的數(shù)量就會比較多,其次設計的原則都是差不多的,比如常見的注冊登錄功能,該有的功能點都要有,另外就是結合目標用戶群體的使用場景,看需不需要增減功能點。就拿修改密碼這個功能點來說,在直接使用手機號碼注冊越來越常見的今天,修改密碼和找回密碼這兩個功能點的取舍是可以好好考慮一下的。

功能設計就好比蓋房子過程中的房間使用場景設計,在確認了房子里有廚房、衛(wèi)生間、客廳、臥室等主要框架結構后,比如要確認廚房的場景列表,要支持燒飯、油煙處理、水池等等,就是廚房常見的使用場景,如果你還要支持燒烤、烘焙,你就要考慮一下廚房空間布局是否合理和夠用了,而一旦確認了廚房使用場景,就進入了廚房布局設計,有點像產(chǎn)品里的原型設計。

很多小伙伴在做產(chǎn)品的過程中可能都沒有功能設計這一步,所以出來的原型很多情況下結構條理性上就差一些,甚至出現(xiàn)做著做著跑偏了的情況,建議大家還是按部就班地做,等你熟練掌握了,胸有成竹就行了,沒必要一步步的畫出來寫下來,但在前期,還是規(guī)范一點更有助于產(chǎn)品基礎能力的鍛煉。

#專欄作家#

華仔,微信公眾號:zeropm,人人都是產(chǎn)品經(jīng)理專欄作家。歷任阿里巴巴、1號店、盛大網(wǎng)絡資深產(chǎn)品經(jīng)理,現(xiàn)任美平米電商產(chǎn)品產(chǎn)品總監(jiān),合著有《運營前線》、《產(chǎn)品前線》、《互聯(lián)網(wǎng)產(chǎn)品之美》,譯著有《人人點贊:讓APP瞬間瘋轉的絕妙文案》。11年產(chǎn)品經(jīng)理工作經(jīng)驗,專注于在線教育和電商產(chǎn)品方向。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉載。

題圖來自 unsplash,基于 CC0 協(xié)議

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 數(shù)據(jù)中臺

    回復
  2. 寫得好

    回復