產品設計:離用戶那么近,業務系統該如何設計?
相比C端產品,B端的業務系統對很多人來說都很陌生。在爬過無數的坡、踩過無數的坑過后,以在線教育業務系統為例,系統分析整理了業務系統產品的相關內容,分享給感興趣的你,希望你可以少走一些彎路、繞開一些坑。
業務系統,通常為:內部產品,與c端產品供廣大普通用戶使用不同,業務系統的使用者通常是公司內部的銷售、客服、技術支持人員或者是一些合作伙伴或商業客戶。
業務系統的一大特點,就是:距離使用用戶足夠“近”。你可能在茶水間或者去洗手間的路上碰到你的用戶,可以隨時展開需求調研與問題反饋(接受吐槽),獲得系統優化的一些點或是一些“靈感”。
“埋雷”與“排雷”
埋雷
做用戶調研,千萬別忘了用戶是會“撒謊”的。如果完全按照用戶反饋的內容進行開發,一顆巨大的雷就悄悄的埋下了。
為什么這么說呢?下面讓我們來逐層分析,逐步排雷。
排雷
1)確定影響范圍
一套完整的業務流程需要不同部門、不同職能屬性的用戶(角色)一起來完成。如果完全采納一方的建議,站在當前用戶的角色角度是可行的,但對于其他用戶角色來說可能是一種負擔,對總體流程來說可能也沒有很大的優化或提升。
2)確定具體問題
其次,業務部門有需求或反饋,說明他們在實際工作中遇到了一些問題或者使用不便捷的地方。
但我們不能把他們反饋的“功能”或提升的建議作為產品方案,反而需要深度調研業務使用過程中遇到了哪些問題,想要達到什么樣的效果,收益是什么,如何衡量相關數據指標。而不是把業務的產品“建議”當做我們的產品“方案”,把我們自己變成了業務部門的“傳話筒”。
3)確定產品方案
最后,需要思考當前功能在現有產品功能架構中的定位。從做功能后做模塊到做系統,最終主動思考、建立產品架構思維,是一個逐漸成長與沉淀的過程。
將整個業務相關的流程、功能、模塊、系統視為一個整體,并以“上帝視角”對它進行剖析、完善,優化總體業務流程,提升辦公效率,提高用戶體驗。
所以,業務產品經理需要傾聽用戶而不盡信用戶,以公司整體業務為目標,培養產品架構思維,深挖用戶的每一個訴求,并最終完成較為合格的產品方案。
用戶
大家都知道,從一個idea到最終產品落地實現的過程中,做用戶調研、用戶畫像來明確我們的用戶目標群體是必不可少的,我們需要了解用戶目標群體的年齡、性別、教育程度、地區、職業、等等信息。
但是,業務系統的用戶調研與用戶確認相比to C類產品更加具象。因為使用的用戶可能就是你單位的同事或合作伙伴,你可以隨時找他們溝通發起用戶調研并收集反饋,就不用費力思考“我的用戶在哪里?”這樣令人頭疼的問題啦。
那么,具體對于業務系統的目標用戶該如何確認呢?
1. 深入了解總體的業務流程
也許有的小伙伴會好奇,不是確認目標用戶么,怎么扯到業務流程去了?
深入了解業務流程的過程中(業務流程抽象后面文章會講到),會對業務整體流程有個總體的了解——清楚都有哪些部門哪些人(角色)在哪些節點做哪些事?彼此的互動及反饋是怎樣的?這些內容對于后續業務系統的規劃與設計尤其重要。
還記得我最初做在線教育業務系統產品經理的時候,前半個月基本都是泡在業務部門,領導還以為我出去浪了(給你個眼神自己體會)。
2. 了解公司的組織機構及各部門職能
了解公司的組織機構及部門職能有助于將視角開闊的足夠廣,廣到可以去清晰的定位邊界。
業務的職能邊界,往往是業務流程挖坑最多的地方,也是業務本身糾纏不清的地方。打個比方:A部門負責賣蔬菜,B部門負責賣水果,但是西紅柿這個產品A、B部門都有售賣。
那么,具體的銷量及推廣流量的轉化率該怎么計算呢?
此外,每個公司的組織機構及部門職能可能會有一些差別,例如:客服,有的公司客服只管投訴建議與反饋,而有的公司客服可能還負責售賣產品。
3. 了解業務系統主要角色的工作內容
說了這么多,終于將話題扯回業務系統。
了解及確認:業務系統都有哪些部門使用?主要需要什么樣的功能?部門內部有哪些角色?需要什么樣的權限?搞清楚用戶對于后續開展業務系統的功能模塊設計具有重要的意義。
感興趣的小伙伴可以去看一下RBAC(Role-Based Access Control——基于角色的訪問控制)的相關內容,或許你對于用戶角色及系統權限會有不一樣的理解。
本文由@齊小新 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash, 基于CC0協議。
寫得很基礎,有一個小瑕疵,用戶那部分排序,排錯了
感謝 ?? 已經更正
催更催更,等著后續的文章 ??