SaaS 產(chǎn)品設(shè)計的原則

SaaS 全稱是 Software as a service火诸,軟件即服務(wù) 平项,當用戶需要這個產(chǎn)品時疟呐,可以在網(wǎng)絡(luò)環(huán)境下隨時租用,而不需要承擔更多的開發(fā)成本和人力成本等翼馆。這就是初期 SaaS 產(chǎn)品帶給用戶的工具屬性的價值哨啃。

做事有原則的人,更容易被人信任写妥;做產(chǎn)品有原則,更容易減少部門內(nèi)耗审姓,超脫情緒和環(huán)境的影響珍特,自覺選擇最佳方案。 我們來看一看 SaaS 軟件設(shè)計時的原則魔吐。

1

我們先看看看產(chǎn)品需求階段的原則扎筒。

原則一,產(chǎn)品需求階段首先要考慮到產(chǎn)品使用場景酬姆, 滿足用戶需求嗜桌。

B端產(chǎn)品基本上是將「線下已有需求」系統(tǒng)化,回歸場景是一切的基礎(chǔ)辞色。 「不以用戶場景為基礎(chǔ)的設(shè)計都是耍流氓」骨宠,深以為然,產(chǎn)品經(jīng)理在設(shè)計原型時,要考慮的重要因素之一就是「用戶場景」层亿,甚至在拿到一個需求的第一時間桦卒,就需要在腦海中思考用戶在不同場景下的需求能否被滿足,該如何滿足匿又,以此來進行需求的初步篩選方灾,「場景思維」的重要性可見一斑。

現(xiàn)在我們部門溝通交流的過程中碌更,除「需求」外裕偿,高頻出現(xiàn)的另一個詞就是「場景」了,在平時工作中痛单,產(chǎn)品與研發(fā)伙伴對接需求時嘿棘,也常常會被抓耳撓腮的研發(fā)大哥問到:你這個需求的場景是什么?

對「場景」這個詞來做解釋的話桦他,其實就是什么「人」在什么「時候」在什么「地方」出于什么「目的」做了「什么事」蔫巩。
場景是設(shè)計和驗證原型時最重要的依據(jù),也是減少產(chǎn)品和開發(fā)矛盾的潤滑劑快压。

我們來想象一個畫面圆仔,一個上班快遲到的人在到達公司的時候打卡,這時候他一定不希望遲到蔫劣,打卡操作越簡單越好坪郭。 這個畫面就是場景,也是在設(shè)計產(chǎn)品或驗證產(chǎn)品可用性時的重要參考依據(jù)脉幢,從整個產(chǎn)品宏觀來講是這樣歪沃,具體到單個的頁面也是這樣。



再來看看「完美工事」這款打卡的app嫌松,驗證這個產(chǎn)品設(shè)計就可以得到比較符合這個場景沪曙,打開程序直接就是打卡頁面,用戶操作非常簡單萎羔。

原則二液走,好的產(chǎn)品滿足用戶價值并帶來商業(yè)價值

你首先要知道你的用戶是誰,如果你不知道用戶是誰贾陷,就好像你是一個籃球運動員缘眶,你不知道籃筐在哪,你不知道要面向誰去做你的產(chǎn)品髓废。

然后再思考能給用戶創(chuàng)造了什么價值巷懈。B端軟件思考用戶價值的時候一定要從兩方面考慮,首先是給企業(yè)帶來什么價值慌洪,比如提高效率顶燕,降低成本等等凑保,還要考慮為決策人帶來什么價值,比如是否能提升 KPI割岛、話語權(quán)或者掌控力愉适。

大家常說的用戶體驗并不是用戶價值,提升用戶體驗固然好癣漆,但是B端軟件核心是解決問題维咸,是否能創(chuàng)造用戶價值,只有這樣才能帶來商業(yè)價值惠爽。

商業(yè)價值的判斷癌蓖,第一個是盈利,第二個是持續(xù)的盈利婚肆,第三個是持續(xù)的更多的盈利租副,所以產(chǎn)品模式必須是持續(xù)正向增長的,需求理解->解決方案->客戶成功->客戶數(shù)量增長形成正循環(huán)较性。

2

產(chǎn)品設(shè)計階段有以下幾個原則

1. 功能需要滿足所有角色核心場景下的需求

SaaS 產(chǎn)品要確保業(yè)務(wù)鏈路每個角色的核心場景都能跑通用僧,如果有一個角色無法正常使用,那該功能就不算完整赞咙,會導(dǎo)致整個鏈路上的每個角色都沒法正常使用责循。

以「完美訪客」小程序舉例, 來訪用戶可以掃碼登記攀操,管理員可以生成訪客碼院仿,還可以添加子管理員協(xié)助來訪統(tǒng)計分析。 麻雀雖小速和,五臟俱全歹垫,雖然是一個簡單的程序,但是能滿足所有角色的使用颠放。

2. 每個客戶都應(yīng)該都獨立排惨、個性化的

傳統(tǒng)軟件流程是把軟件賣給客戶,客戶自己要出錢部署碰凶,買服務(wù)器存儲暮芭,搭建網(wǎng)絡(luò)環(huán)境,還要用運維的人員痒留。而 SaaS 軟件現(xiàn)這些都不用了,硬件由供應(yīng)商自己出蠢沿,放在公有云上伸头,以服務(wù)的方式租給客戶,所以叫賣服務(wù)舷蟀。SaaS 本質(zhì)上是由賣軟件改成賣服務(wù)恤磷,幫助用戶降低成本面哼。

但是客戶的使用的方式還應(yīng)該是一樣的,每個客戶之間不應(yīng)該有交集扫步,還要適當?shù)臐M足企業(yè)個性化配置魔策,對于大客戶可能還需要定制化開發(fā)。不過盡量的降低定制化開發(fā)比例河胎,如何降低定制開發(fā)的比例闯袒,我認為還是取決于產(chǎn)品對行業(yè)的理解深度,產(chǎn)品本身的成熟度游岳。

「完美工事」從開始就設(shè)立了微服務(wù)的軟件架構(gòu)政敢,把企業(yè)的個性化需求在微服務(wù)上實現(xiàn),內(nèi)部多用API的方式互通胚迫,不影響主產(chǎn)品的升級迭代喷户。給一個企業(yè)做的定制化的功能,有時候還能同時提供給其他企業(yè)使用访锻。

3. 低耦合褪尝,高內(nèi)聚

低耦合:指產(chǎn)品結(jié)構(gòu)內(nèi)不同模塊間的聯(lián)系弱,關(guān)系簡單期犬。修改一個模塊不會影響到另一個模塊河哑。

高內(nèi)聚:指產(chǎn)品結(jié)構(gòu)中單個模塊內(nèi)各個元素聯(lián)系緊密。簡單來說哭懈,就是一個模塊內(nèi)的代碼只完成一個任務(wù)灾馒,即單一責任原則。

低耦合遣总,高內(nèi)聚會給產(chǎn)品帶來什么好處呢睬罗?從短期來看,并不會給產(chǎn)品帶來明顯的好處旭斥,甚至會使開發(fā)周期變得更長容达。但隨著產(chǎn)品迭代,你會遇到更多復(fù)雜的需求垂券。如果產(chǎn)品耦合度高花盐,則牽一發(fā)而動全身,輕易不能改動功能菇爪,因為會牽涉到產(chǎn)品架構(gòu)層面的問題算芯。

Saas是把賣軟件變?yōu)橘u服務(wù),放棄一次性收入凳宙,按照客戶是否使用來收費熙揍,就必須把軟件產(chǎn)品真正做到客戶喜歡,持續(xù)滿足絕大數(shù)客戶需求氏涩,SaaS 產(chǎn)品結(jié)構(gòu)及呈現(xiàn)方式必須可延續(xù)届囚、可擴展有梆。而低耦合,高內(nèi)聚會給產(chǎn)品帶來更好的擴展性意系,靈活性泥耀,復(fù)用性,可維護性蛔添。建議在產(chǎn)品開始設(shè)計時考慮好產(chǎn)品未來的長期規(guī)劃痰催,避免后期產(chǎn)品難以迭代,需要重構(gòu)作郭。多和架構(gòu)師溝通陨囊,防患于未然的同時,留給未來更多可能夹攒。

4. 權(quán)限控制盡量細致

SaaS的產(chǎn)品業(yè)務(wù)相對復(fù)雜蜘醋,面對的企業(yè)客戶規(guī)模和業(yè)務(wù)方向都不同,權(quán)限訴求也不一樣咏尝,根據(jù)不同公司業(yè)務(wù)權(quán)限設(shè)計需要設(shè)計的盡量細致压语。

處理權(quán)限是一個比較麻煩的事,設(shè)計階段如果沒有考慮好后期再改成本是非常大的编检。一個賬號在一個系統(tǒng)可能對應(yīng)多個角色胎食,部分產(chǎn)品可能還涉及到不同地區(qū)不同分公司。那么根據(jù)業(yè)務(wù)需要在角色定義層或權(quán)限分配層允懂,先確定好集團厕怜、地區(qū)屬性,再確定數(shù)據(jù)權(quán)限蕾总、菜單權(quán)限粥航、功能權(quán)限等等。

權(quán)限控制方面可以參考一下RABC模型:基于角色的訪問控制生百。

RABC是Role-BasedAccess Control的英文縮寫递雀,意思是基于角色的訪問控制。模型認為權(quán)限控制的過程可以抽象概括為:判斷Who是否可以對What進行How的訪問操作蚀浆,即將權(quán)限問題轉(zhuǎn)換為Who缀程、What、How的問題市俊。Who杨凑、What、How構(gòu)成了訪問權(quán)限三元組摆昧,Who撩满,What,How分別對應(yīng)著用戶,資源鹦牛,操作。RABC的核心在于通過為用戶分配對應(yīng)的角色進而將用戶與對應(yīng)的操作聯(lián)系起來勇吊,已實現(xiàn)用戶對資源的操作曼追。

5. 產(chǎn)品要保持一致性,拒絕設(shè)置專業(yè)門檻

一致性包括視覺一致性汉规、交互一致性礼殊、文案一致性、跨平臺一致性针史。

對用戶來說晶伦,一致性可以降低用戶學(xué)習成本,用戶在不同頁面之間不會感到陌生啄枕,提升用戶體驗婚陪,更容易展現(xiàn)獨特的品牌感、品質(zhì)感频祝。
對團隊來講泌参,利用一套風格統(tǒng)一的視覺、交互組件能提升設(shè)計作品的一致性常空,團隊之間溝通對接也會更有效率沽一,不會出現(xiàn)風格不統(tǒng)一的情況。

不要設(shè)置一些專業(yè)門檻漓糙,以文案舉例铣缠,之前看到過我們開發(fā)的產(chǎn)品有一處提示信息「企業(yè)id不能為null」,雖然開發(fā)能看懂昆禽,但是我相信很多用戶都會不理解蝗蛙,這句話可以改成「企業(yè)不能為空」或者 「需要加入企業(yè)」等等。 類似的專業(yè)文案有很多为狸,比如 PV 改成瀏覽量歼郭,UV改成用戶訪問量等等。

6. 按照優(yōu)先級順序去迭代

無論在哪家公司辐棒,我相信技術(shù)資源都是非常緊張的病曾,所以在進行需求排期時的溝通就非常重要了,可以按照下面的優(yōu)先級去迭代漾根。

  1. 我們先保證有穩(wěn)定的功能泰涂,滿足所有角色使用,如果功能不能正常用了辐怕,其他任何都是扯淡逼蒙;
  2. 是否有競品打動決策者的功能,能讓客戶轉(zhuǎn)用另一家產(chǎn)品的功能必然是好功能寄疏,就是很好的買單功能是牢;
  3. 跟客戶收入直接掛鉤僵井,客戶能用來增加營收、縮減成本的功能驳棱。哪怕別的地方做的一般批什,能給客戶省錢,客戶也是接受的社搅;
  4. 是否提升軟件使用者的工作效率驻债,用戶每天都在頻繁使用的產(chǎn)品功能,需要能高效操作形葬,能少一步操作是一步合呐;
  5. 是否易用,易用指的是別讓我思考笙以,我看一眼就知道該怎么操作淌实,這一點利于商務(wù)對使用人培訓(xùn)。這一點有時候不太好評判猖腕,開發(fā)難度可能也比較大翩伪,優(yōu)先級排在后面了;
  6. 最后是好看谈息,當你做了前面所有的缘屹, 如果有資源,盡量讓頁面好看侠仇,而不是一味追求好看轻姿。

3

產(chǎn)品研發(fā)階段也需要注意幾點原則。

1 .首先保證系統(tǒng)的穩(wěn)定性新逻炊,增或定制功能互亮,要最大程度避免系統(tǒng)改造和重構(gòu),能夠穩(wěn)定迭代

對SaaS服務(wù)商來說余素,系統(tǒng)穩(wěn)定性的保障一直是一個非常復(fù)雜的命題豹休。通常情況下,業(yè)界比較優(yōu)秀的服務(wù)商桨吊,系統(tǒng)穩(wěn)定性一般能做到99.9%威根,相當于全年無休。系統(tǒng)不穩(wěn)定對品牌口碑影響很大视乐,還會直接帶來經(jīng)濟損失洛搀。比如某盟就2020年2月23日出現(xiàn)刪庫事件導(dǎo)致系統(tǒng)幾乎癱瘓,數(shù)據(jù)到月底才逐步恢復(fù)佑淀,對客戶造成了很大的損失留美,對公司也造成了很大的影響。

這里的關(guān)鍵是業(yè)務(wù)和技術(shù)層面,需要產(chǎn)品和技術(shù)共同努力谎砾。產(chǎn)品經(jīng)理要有對業(yè)務(wù)邏輯的深入理解和未來業(yè)務(wù)的預(yù)判性逢倍,并且對業(yè)務(wù)產(chǎn)品的各個維度組成有抽象化能力【巴迹可以從用戶維度瓶堕、商業(yè)維度、需求場景症歇、功能服務(wù)維度多去考慮;用戶上把 SaaS系統(tǒng)的幾類角色好好分析下谭梗,商業(yè)上把付費模式忘晤、增值模塊好好構(gòu)思下,凡事多想一步激捏,讓團隊各成員心里有數(shù)设塔,落地執(zhí)行時多做少做心里也有底,在把產(chǎn)品方案傳遞給技術(shù)研發(fā)時远舅,整體架構(gòu)上也便于預(yù)留擴展闰蛔,做到系統(tǒng)的耦合或內(nèi)聚的決策更加精確,業(yè)務(wù)模塊的復(fù)用性更好图柏。

2. 技術(shù)架構(gòu)上要考慮服務(wù)化序六、分層化、可配置化蚤吹、自動化例诀。還要要考慮架構(gòu)高可用性、伸縮性裁着、可維護性等繁涂。

  • 高可用性即系統(tǒng)不依賴單點(一臺服務(wù)器掛了不至于影響業(yè)務(wù)系統(tǒng),一臺數(shù)據(jù)庫宕機了不至于數(shù)據(jù)丟失二驰,被非法攻擊了能很好地轉(zhuǎn)移)扔罪;
  • 伸縮性,好的架構(gòu)在用戶1萬時你能支撐業(yè)務(wù)桶雀,用戶突增至100萬時能否簡單加機器來解決等矿酵;
  • 可維護性,隨著你業(yè)務(wù)的增加矗积,技術(shù)復(fù)雜性增加坏瘩,系統(tǒng)的自動化運維能否跟上,系統(tǒng)的發(fā)布回滾漠魏,運行時的監(jiān)控倔矾、日志系統(tǒng)是否完善,自動預(yù)警和恢復(fù),而不能簡單堆人維護哪自。

4

最后總結(jié)下丰包,本篇文章從需求、設(shè)計壤巷、開發(fā)三個階段闡述SaaS的幾個原則:
需求階段要多思考邑彪,注意使用場景和滿足用戶價值和商業(yè)價值。
設(shè)計階段要考慮不同角色的場景和需求胧华;注意客戶之間是獨立的個性的寄症;產(chǎn)品功能模塊要低耦合、高內(nèi)聚矩动;權(quán)限控制盡量細致有巧,產(chǎn)品要保持一致性,不要有專業(yè)門檻悲没;按照優(yōu)先級順序迭代篮迎;
研發(fā)階段要和開發(fā)配合,保證系統(tǒng)穩(wěn)定性和可擴展性示姿。

一點小經(jīng)驗分享給大家甜橱,祝愿彼此都能打造成功的SaaS產(chǎn)品。歡迎關(guān)注栈戳,共同交流岂傲。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市子檀,隨后出現(xiàn)的幾起案子譬胎,更是在濱河造成了極大的恐慌,老刑警劉巖命锄,帶你破解...
    沈念sama閱讀 212,816評論 6 492
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件堰乔,死亡現(xiàn)場離奇詭異,居然都是意外死亡脐恩,警方通過查閱死者的電腦和手機镐侯,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,729評論 3 385
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來驶冒,“玉大人苟翻,你說我怎么就攤上這事∑郏” “怎么了崇猫?”我有些...
    開封第一講書人閱讀 158,300評論 0 348
  • 文/不壞的土叔 我叫張陵,是天一觀的道長需忿。 經(jīng)常有香客問我诅炉,道長蜡歹,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 56,780評論 1 285
  • 正文 為了忘掉前任涕烧,我火速辦了婚禮月而,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘议纯。我一直安慰自己父款,他們只是感情好,可當我...
    茶點故事閱讀 65,890評論 6 385
  • 文/花漫 我一把揭開白布瞻凤。 她就那樣靜靜地躺著憨攒,像睡著了一般。 火紅的嫁衣襯著肌膚如雪阀参。 梳的紋絲不亂的頭發(fā)上肝集,一...
    開封第一講書人閱讀 50,084評論 1 291
  • 那天,我揣著相機與錄音结笨,去河邊找鬼。 笑死湿镀,一個胖子當著我的面吹牛炕吸,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播勉痴,決...
    沈念sama閱讀 39,151評論 3 410
  • 文/蒼蘭香墨 我猛地睜開眼赫模,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了蒸矛?” 一聲冷哼從身側(cè)響起瀑罗,我...
    開封第一講書人閱讀 37,912評論 0 268
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎雏掠,沒想到半個月后斩祭,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 44,355評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡乡话,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,666評論 2 327
  • 正文 我和宋清朗相戀三年摧玫,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片绑青。...
    茶點故事閱讀 38,809評論 1 341
  • 序言:一個原本活蹦亂跳的男人離奇死亡诬像,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出闸婴,到底是詐尸還是另有隱情坏挠,我是刑警寧澤,帶...
    沈念sama閱讀 34,504評論 4 334
  • 正文 年R本政府宣布邪乍,位于F島的核電站降狠,受9級特大地震影響对竣,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜喊熟,卻給世界環(huán)境...
    茶點故事閱讀 40,150評論 3 317
  • 文/蒙蒙 一柏肪、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧芥牌,春花似錦烦味、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,882評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至弃理,卻和暖如春溃论,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背痘昌。 一陣腳步聲響...
    開封第一講書人閱讀 32,121評論 1 267
  • 我被黑心中介騙來泰國打工钥勋, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人辆苔。 一個月前我還...
    沈念sama閱讀 46,628評論 2 362
  • 正文 我出身青樓算灸,卻偏偏與公主長得像,于是被迫代替她去往敵國和親驻啤。 傳聞我的和親對象是個殘疾皇子菲驴,可洞房花燭夜當晚...
    茶點故事閱讀 43,724評論 2 351

推薦閱讀更多精彩內(nèi)容