如何將業務轉化為產品設計(上)
怎樣將一個之前未接觸過的新業務,轉化為研發可以具體開發的詳細產品方案呢?本文作者對此進行了分析,一起來看一下吧。
一、構建業務模型
怎么樣將一個idea,商業模式拆解為業務模型,這個在之前的文章中已經有詳細的說明,可以點擊看相關文章:
總體思路是:
1)有一個ideal之后,運用商業運作模型(商業畫布,商業模式運作圖,價值鏈分析)、業務運作模型、財務運作模型能夠將以一個項目的各方面做一個整體的評估;
2)我們進一步運用業務模型的拆解方法,可以拆分出這個事情的核心業務及支撐系統,明白這個事情是如何運作的,關鍵節點是哪些,并據此搭建一個整體性的產品概覽。
但這個產品框架是一個比較粗略的方案,比如之前其它文章畫的同城配送系統的產品整體概覽(已經做過這個系統,然后來寫這篇文章,帶有天然的理解在里面)。
那怎樣將一個之前未接觸過的新業務轉化為研發可以具體開發的詳細產品方案呢,這其實不是一件簡單的事情,特別是針對復雜系統,平臺類產品的時候。
本文不涉及戰略層面的東西,這部分在之前的業務模型拆解中有涉及一部分,另外怎么樣去找到一個好的需求點,并評估是否可行也不涉及。
我們將文章限定范圍為:產品方向已經確定,業務模式等已確定,我們只需要把這個業務調研清楚,做產品拆解。這樣將讓我們的精力集中于業務向產品詳細方案的轉化,業務方向一定要確定,然后才去啟動正式的產品詳細方案設計工作,要不然產品方案會無止境地變化,無謂地增加各種成本和打擊團隊的士氣。
二、業務轉化為產品的難點
業務是依托于用戶存在的,這個用戶可能是購買商品的客戶,也可能是公司內部的管理運營人員。
業務就是由用戶發起并執行后有一個結果的活動,這個活動可能是由系統執行,可能由其他人完成,也可能人與系統配合完成。
互聯網和信息技術出現之前,業務基本都是在線下進行,現在越來越多業務實現線上化,有些業務整體都是線上(比如抖音、微信、資訊),O2O業務,傳統行業,制造業等行業還有很多業務是在線下。
無論是怎樣的業務,我們大多以用戶為中心進行設計產品,產品在滿足用戶需求同時,還要讓用戶在使用過程中感到足夠方便和舒適。但另一個方面,滿足用戶的需求不僅僅只是跟用戶打交道,還面臨著其他一切為滿足用戶需求而提供服務的人員和企業,對于這些衍生需求,也是需要滿足。
這項工作面臨著很多挑戰:
1)沒考慮到非用戶接觸的內部業務產品設計:以用戶為中心的設計,從用戶角度出發的,目標是要讓用戶的體驗好,但可能忽略一些基礎支撐性的業務如何設計。
2)沒考慮業務流程設計:一項業務需要設計流程。比如,一個訂單需要設計用戶下單、確認發貨、物流送貨和用戶簽收等流程。但以用戶為中心的設計,對流程強調得并不多,更多地強調了頁面設計和簡單的交互設計。
3)遺漏大量邏輯:當系統復雜度很大的時候,只使用流程進行考慮將會很復雜,這將導致會遺漏很多邏輯,特別是多系統之間的交互。
4)缺乏系統性:平臺類型的業務產品設計,需要考慮到各系統之間的交互,比如平臺類型的訂單,會涉及用戶、商戶、平臺,一筆訂單中由包含商品、優惠、快遞、支付、退款等。很容易對系統考慮不全,導致架構存在問題。
5)未考慮系統的延展性:只關注當時當下的問題,沒有考慮到業務發展之后,產品需要怎么來支持,使得產品系統隨著業務發展而需要不斷的重構。
6)如果有多人協作同一個系統,很容易由于各自的設計思路不一致,繪制原型標準不一致而造成各自閉門造車而最終組裝不上的問題。
那需要怎么來應對這些問題呢:
1)梳理流程的時候,采取端到端的方法——也即是從一個活動的開始直到最終結果的整個過程,形成閉環,可以跨越多端(用戶端、商家端、平臺管理端)、多部門、多操作者,打破產品系統的隔閡和封閉。
2)采用統一的語言體系和標準(如UML,各端口原型及設計標準統一),保證各方的底層設計邏輯、標準、語言統一,這樣設計出的東西才統一。
3)從面向過程的設計轉為面向對象的設計,應對復雜性、平臺型項目設計,更系統全面的考慮問題,就需要把UML,DDD思想運用到從業務到產品設計的過程中,讓整個的過程更系統絲滑,實現面向對象,模塊化、模型化的產品設計。
三、以業務為中心的設計
1. 整體思路
下圖為用戶體驗要素的5層框架結構:
- 戰略層——確定商業目標,產品目標,用戶群體,怎么賺錢等
- 范圍層——為產品功能劃定范圍,做哪些功能
- 結構層——思考產品怎么做,包括怎么跟用戶交互,怎么組織內容(信息架構)
- 框架層——思考產品怎么設計,界面設計,導航設計,信息設計
- 表現層——風格統一,色彩搭配,排版,利用用戶的視覺,聽覺,觸覺,味覺來刺激用戶
普通產品經理做得就是范圍層,結構層,框架層的東西,表現層一般是UI設計師來。
范圍層對應搭產品的框架(功能框架、非功能框架);
結構層對應做細節(業務流程、業務操作、信息結構);
框架層對應畫界面(交互設計及更詳細的信息設計,信息設計來源于信息結構),可以表示為如下圖所示:
2. 產品常用的UML圖
我們學習的英語、漢語可以被稱為語言,這個是顯而易見的。我們學習的各種數學符號,也是一種語言,叫數學語言。
怎么理解數學符號也是一種語言呢?比如,我們可以用漢語說“一加一等于二”,但是在實際做計算的時候,我們還是習慣用“1+1=2”來表達。
兩者的意思是相同的,但用數字表達更高效、更簡潔。
統一建模語言也是語言,該語言可以代替我們的文字描述來表達一項業務,可以對業務進行抽象建模。
建模是對事物的一種抽象表述,其目的是簡化現實。也就是將紛繁復雜的業務,進行抽象,讓業務更清晰,系統的進行呈現,便于理解。通過建模的方式,我們進一步將業務轉化為產品方案。
語言都有語法(使用規則),如英語、漢語等都有語法。數學符號也有語法,如規定加、減、乘、除和括號的用法。UML既然也是語言,那么就有相應的語法,如規定流程圖的開始和結束怎么畫、判斷條件怎么畫等。
在所有的UML圖中,產品經理需要掌握的是用例圖、流程圖、狀態圖、類圖這四種圖。
挑選一個適合的繪制UML圖的工具,將有助于提高工作效率,并展現出專業度。
Microsoft Visio、ProcessOn、億圖圖示等軟件都能繪制UML圖。使用Axure RP軟件既能繪制原型圖,又能繪制UML圖,不用再將UML圖進行轉移。用Axure RP軟件繪制UML圖能節省時間,建議使用該軟件繪制UML圖。
下一篇將介紹具體怎樣將業務轉化為產品的做法。
專欄作家
Markzou,8年產品經驗,人人都是產品經理專欄作家。主要專注于本地生活、O2O、到家服務、新零售領域;曾任職于多家本地生活垂直領域頭部公司,具有豐富的本地生活行業經驗。
本文原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自 Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
如果有不明白的地方,可以加markzou1988
設計工具現在遍地都是,想要學會的成本比較低,但產品設計卻是產品方面不能缺少的,必須掌握。