To B產品經理如何設計接口類產品?

人人都是產品經理 發佈 2020-01-07T06:28:25+00:00

本文以被動請求接口為主,討論如何進行對外系統接口的產品設計。

本文以被動請求接口為主,討論如何進行對外系統接口的產品設計。一起來看看~

常見的To B產品有四類:

  • 第一類為管理系統類產品,如CRM、ERP、BOSS平台等;
  • 第二類為辦公系統類產品,如OA;
  • 第三類為商家端系統類產品,如給小B端用的商戶系統;
  • 第四類為接口服務類產品,如聚合支付接口、人臉識別接口。

從產品形態上來說,前三類To B產品都具有用戶操作介面,其設計原則和C端產品的設計方法有很大的重合,可以借鑑C端產品的設計方法進行產品設計,例如尼爾森十大可用性原則、簡約設計方法等UE、UI設計方法就同樣適用於前三類產品的頁面設計。但第四類接口服務型產品沒有操作介面,產品形態是以API接口存在,所以設計的方式與C端產品就會有很大的不同。

一、產品經理需要關注哪些種類的系統接口

系統接口分為內部系統接口(公司內部系統與系統間的接口,例如數據中台和業務系統的接口)和對外系統接口(提供給第三方調用的接口,一般都是基於HTTP/SOAP的協議接口,例如微信開放平台提供給小程序開發者的接口),內部系統接口對於產品經理來說無需過多關注,例如伺服器端都會面向APP提供調用接口,產品經理只需定義好APP的功能即可,具體APP和伺服器的傳輸交互會由開發工程師來定義。

對外系統接口包含:主動推送接口(主動給第三方發送信息)、被動推動接口(被第三方推送信息)、主動請求接口(主動請求第三方獲取信息)和被動請求接口(被第三方請求獲取信息)。

其中普遍的主動請求接口產品經理只需要能看懂就可以,不需要花費太多的精力提此類接口的需求,例如:自己公司採購了第三方的人臉識別接口用於業務中的身份驗證,產品經理只需要提出在某某業務環節需要調用人臉識別功能即可,無須過多關注如何調用人臉識別接口。因此主動請求接口本文不做討論,本文以被動請求接口為主,討論如何進行對外系統接口的產品設計。

二、如何設計接口類產品

系統接口類的產品設計需要定義如下內容:輸入內容、輸出內容、業務異常處理方式、計費邏輯、響應速度、並發量、易用性等。

1. 輸入內容

即第三方發送給我們的業務請求參數。產品經需要關注業務請求參數,同時明確參數是否可空,無需定義公共請求參數。例如數字證書在線生成接口(一般由CA公司提供的服務,應用調用該接口請求CA公司生成個人用戶數字證書或企業用戶數字證書),名稱、證件號碼、證件類別等信息屬於業務請求參數中不可空的參數,沒有此部分數據無法完成證書的生成;電子郵件、手機號等屬於業務請求參數中的可空的參數,預設此部分參數也可完成業務;應用ID、加密因子、加密算法等參數屬於公共請求參數,公共請求參數內容無需產品經理設計,無需體現在需求文檔中。

2. 輸出內容

即接收第三方的請求後,經由系統處理後的業務返回參數。產品經需要關注業務返回參數,同時明確參數是否可空,無需定義公共返回參數。例如數字證書在線生成接口,第三方調用該接口後,系統需要返回cer格式的數字證書給第三方,cer格式的數字證書就是業務返回參數。輸出內容同樣需要明確參數是否可空,同時還需要明確是同步返回還是異步返回。

3. 業務異常處理方式

異常部分產品經理只需定義業務異常的處理方式,即產品經理對業務規則的要求。例如為保障圖片質量,要求第三方通過接口上傳的圖片需要大於100K,則需要產品經理明確指出在此要進行圖片大小檢查,若不符合規則即拋出異常。系統異常(如參數錯誤、參數缺失等)無需產品經理來定義。

4. 計費邏輯

即接口如何向第三方計費。

計費邏輯常包含兩部分:

  • 第一部分是哪些情況下需要計費,哪些情況可以不計費,例如簡項比對接口(通過接口上傳用戶的姓名和身份證號碼,系統根據公安系統人口庫判斷輸入的信息是否一致,接口輸出比對一致、比對不一致、庫中無此號碼等結果),比對一致、比對不一致可以設置成計費,庫中無此號碼則可以設置成不計費。如果產品做得比較成熟的話,計費與否可以從後台管理系統中通過返回結果碼自由配置。
  • 計費邏輯第二部分是需要明確計費方式,計費方式大致分為按次計費(調用一次接口收取一次費用)、階梯計費(調用一次接口收取一次費用,但達到了一定使用量後單價有所下降)、按時間計費(包月或包年收費方式)。

5. 響應時間

即第三方從發出請求報文後,經歷多久可以收到返回報文。通常接口的響應時間都是毫秒級的,但系統需要進行較大運算量的業務,響應時間可能會稍微長一些,例如OCR文字識別和音頻識別接口,響應時間可能要達到幾秒或幾十秒,因為系統需要提取照片或音頻中的文字內容。

6. 並發量

即系統支持同時請求接口的最大用戶數量。通常並發量需求描述中會包含用戶數量、響應時間、持續時長。例如聚合支付接口,請求高峰出現在中午12點到1點午餐時間,持續時長大概1個小時,對並發量的需求描述就可以按照500用戶並發數,持續1小時,事務平均響應時間小於1秒來寫。

7. 易用性

即接口對第三方來說容易讀懂、容易使用,有基礎開發背景知識的開發工程師就可以很方便的調用成功。通常接口類產品的易用性都是通過SDK(軟體開發工具包,把接口封裝成JAVA或PHP等語言的調用函數)和調用DEMO(示例代碼)來實現,產品經理可以提出接口需要提供配套SDK(JAVA版本或PHP版本等)及調用DEMO的需求描述。

8. 其他

除了上述需求,還有一些不常用的業務需求產品經理可以關注,根據實際情況來判斷是否需要寫,例如系統每秒鐘能夠處理的事務數量(即TPS,系統吞吐量)需求;穩定性需求,即長時間運行一個比較大的並發量,觀察系統是否穩定不宕機。

對外系統接口中產品經理還會關注主動推送接口(主動給第三方發送信息)和被動推送接口(被第三方推送信息),這兩種接口的設計方法和上面所提的方法大體相同,但上面提到的都是非批量模式,這兩種接口的需求需要體現推送是批量方式還是單次方式,例如給監管機構上報數據的接口就採用了主動推送、批量上報的模式,產品經理需要定義清楚上報內容,上報頻次,上報異常處理方式。

本文由 @產品工具箱 原創發布於人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基於CC0協議。

關鍵字: