產(chǎn)品設(shè)計:沒有完美的方案,只有更好的方案

3 評論 11694 瀏覽 24 收藏 12 分鐘

前段時間發(fā)了一篇文章:兩個真實產(chǎn)品案例所引發(fā)的思考。主要對兩個切身經(jīng)歷的產(chǎn)品案例,進行了一些分析和思考。有讀者評論說可以多分享一些案例形式的人講解,正好最近又遇到一個比較“有意思”的案例,可以拿出來說道說道。

背景說明

作為一個電商平臺,前不久我們上線了申請開發(fā)票功能,用戶可以選擇“普通發(fā)票-個人”、“普通發(fā)票-單位”、“專用發(fā)票”三種類型,其中“專用發(fā)票”類型需要填寫的信息比較多,在該功能上線一期,出于精簡考慮,系統(tǒng)沒有保存專票信息。

在后邊的版本迭代中,我們緊接著把專用發(fā)票的模塊功能提上了日程,在做具體設(shè)計的時候,身為產(chǎn)品同學(xué)我和交互同學(xué)產(chǎn)生了比較大的分歧,主要的問題點有如下三個:

一、專用發(fā)票的模板數(shù)量提供一個還是多個?

交互同學(xué)的想法是可維護多個,給用戶提供更多的自主性。我堅持的是初期只維護一套模板即可,我又有哪些考慮呢?

首先,多套專票模板的用戶需求量到底能有多少?根據(jù)以往數(shù)據(jù)統(tǒng)計,開票的用戶本身就是一小部分,并且開專票的比例也很少,其中又同時需要多個專票模板的用戶肯定更是少之又少。并且單純的從主觀性上考慮,開具的專票內(nèi)容相對是固定的,而不像網(wǎng)購的收貨地址,可能有家庭地址、公司地址、女朋友的地址等等。所以,多套模板的需求是否存在,或者說需求量有多少目前還是存疑的。

然后,在看一下多套模板帶來的成本有哪些?最顯而易見的就是開發(fā)成本,因為需要支持多套模板,用戶任意添加,其開發(fā)維護成本勢必會增加。還有隱性的用戶使用成本,尤其是那些基本上都是使用一套專用發(fā)票的用戶,無論是在申請開發(fā)票填寫信息時,還是維護過程中,交互的邏輯相對也會更復(fù)雜一些,后邊的第二點也會具體說明到這塊內(nèi)容。

綜上兩點,多套專用發(fā)票模板的需求量還是存疑的,并且也會帶來額外的成本,所以我傾向選擇一期僅提供一套專票信息模板即可。當(dāng)然,后面的版本迭代中,完全可以再根據(jù)實際情況進行調(diào)整。這也算是在踐行著MVP的設(shè)計思路。

二、申請發(fā)票過程中專票信息模板的處理方式

前面說明了,發(fā)票的類型一共有三種供選擇:“普通發(fā)票-個人”、“普通發(fā)票-單位”、“專用發(fā)票”,具體的交互邏輯如下,選擇好類型之后則需要填寫對應(yīng)的信息,其中前兩種類型信息很少,只需考慮給專票信息提供模板即可。

假定確定只維護一套專票信息模板,申請開票的過程中用戶若選擇了“專用發(fā)票”,此時專票模板中的信息該如何體現(xiàn)出來呢?

常見的一種處理方式,就是當(dāng)用戶選中“專票類型”后,直接把專票信息模板中的信息顯示出來供用戶查看,確定無誤的話則直接提交,如果有問題的話可以點擊編輯按鈕,進入二級頁面進行修改。同時交互上也要考慮,用戶第一次申請開專票,沒有維護模板的情況下的處理方式。

這種處理方式有一個問題,如果選擇“普通發(fā)票-個人”、“普通發(fā)票-單位”類型,則是表單項需要填寫,而選擇“公司專用發(fā)票”后卻是展示專票模板,并可以進入修改的二級頁面,這使得在同一個路徑中,分成了不同的交互邏輯,本身會有點怪異;并且這種專票模板的處理方式,在已上線的一期方案基礎(chǔ)上,無論是交互邏輯和技術(shù)實現(xiàn)上都會變得更加復(fù)雜,實際的用戶體驗也是個未知數(shù)。

以上是交互提出的方案,而在我最腦海中最初設(shè)想的另外一種處理方式:當(dāng)用戶選中“專用發(fā)票”類型后,頁面下方仍然是需要填寫的表單項,此時系統(tǒng)做判斷,分為兩種情況:

  1. 如果是第一次申請專票,沒有記錄任何專票信息,則為正常的空表單需用戶填寫;
  2. 如果系統(tǒng)已經(jīng)記錄了專票信息,則表單把模板信息做默認(rèn)填充,用戶檢查無誤的話,直接提交;如果發(fā)現(xiàn)有信息需要修改,直接在默認(rèn)填充的信息上進行修改后提交,并且此時系統(tǒng)會更新專票模板的信息。

這種處理方式在只維護一套專票模板的基礎(chǔ)上,只是做了表單項的默認(rèn)填充,無論是交互邏輯,還是技術(shù)實現(xiàn)上都更加簡潔清晰。并且這種處理方式很好的包含了第一次無專票模板的場景和有專票模板的場景,另外用戶如果在開票過程中需要修改信息,也更加直觀自然。所以最終我還是堅定選擇了這種處理方式。

然后,針對這個點再談一下問題一遺留的那個問題,如果要支持多套模板,那在申請開發(fā)票的流程中,其處理方式必定會更加復(fù)雜;不僅要能夠從多套模板中選擇一個,也要能夠修改某個模板信息,并且還要能在開票過程中直接新增模板。這不僅僅會加大技術(shù)實現(xiàn)的成本,并且在需求不明確的情況下也會增加現(xiàn)有用戶的使用成本。

三、是否在個人中心增加專票信息維護入口

除了在申請開發(fā)票的過程中,可以填寫/修改專票的信息,那在個人中心頁面是否要增加的專票信息維護的入口呢?

交互設(shè)計師最初的設(shè)計方案是不需要,他給出的原因主要有兩點:

  1. 以上已經(jīng)分析過,需要維護專票信息的用戶是一小部分,所以不應(yīng)該為了少部分用戶的需求而在個人中心頁面增加獨立的入口;
  2. 專票信息應(yīng)該出現(xiàn)在被需要的地方就夠了,就是申請開票過程中。

針對第1點,我覺得應(yīng)該要有一個限定的場景,就是在任務(wù)的主流程中,要足夠簡化,不能因為個別用戶的特殊需求而損害了大部分正常用戶利益。可是“個人中心”的定位本身就是個人相關(guān)信息的展現(xiàn),而發(fā)票信息很自然的應(yīng)該被歸為其中的一部分,并且在這里放置發(fā)票信息,并沒有對其他正常用戶造成額外的干擾。所以這個觀點根本無法套用在這個場景中。

針對第2點,如果只考慮大部分的正常使用場景確實如此,可是如果當(dāng)用戶在非開票時想要修改專票信息該怎么辦呢?可能有人也會質(zhì)疑說:這是一種非常低頻的使用場景。的確如此,可同時我們也可以繼續(xù)思考,為了滿足這部分低頻場景下的需求,在個人中心增加了發(fā)票信息的維護入口后,又會帶來什么損害嗎?如果答案是否定的,并且我們也認(rèn)可“專票信息”同屬于“個人信息”中的一類,為何不增加入口維護呢?

其實,對于這個問題,“專票信息”在某種程度上跟“收獲地址”是類似的,而電商平臺通用的做法就是,除了在下單時可以填寫/修改收貨地址,在個人中心也會提供相應(yīng)的維護入口。

總結(jié)

以上,是針對專票信息維護這個產(chǎn)品案例,我在設(shè)計過程中的一些思考,其中主要的思路可以總結(jié)為以下幾點:

  1. 當(dāng)需求不明確時,盡量簡化功能,甚至?xí)簳r不做,即學(xué)會MVP的設(shè)計思路;
  2. 除了考慮功能帶來的收益,也要考慮實現(xiàn)成本,當(dāng)成本過大而收益有限時一定要慎重;
  3. 盡量保證前臺交互方式的一致性和簡潔性,不要讓用戶有過多的思考;
  4. 在保障前臺用戶體驗的前提下,也要考慮系統(tǒng)實現(xiàn)的復(fù)雜性和難易程度,尤其針對迭代功能,設(shè)計方案盡可能在原有基礎(chǔ)上簡化處理;
  5. 除了要支持主流的使用場景,也要考慮是否可以滿足某些特殊的使用場景;
  6. 當(dāng)猶豫是否要支持某些低頻的使用場景時,也可以反向思考如果要支持,需要付出多大的成本,又會帶來哪些損害,當(dāng)收益比足夠大時,就可以考慮;

雖然在討論中,我比較強勢地否定了很多交互設(shè)計師的觀點,但也要坦誠我的設(shè)計思路中也會存在局限,存在有所欠缺的地方,所以也歡迎大家來拍磚,一起討論。做產(chǎn)品設(shè)計往往就是這樣,很多時候不存在完美無瑕的方案,但是通過反復(fù)的思考和討論,能夠不斷得出更好的方案。

 

本文由人人都是產(chǎn)品經(jīng)理專欄作家 @劉鵬(微信公眾號:pengideas ) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?。未經(jīng)許可,禁止轉(zhuǎn)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 單筆訂單開票還是多筆訂單開票

    來自北京 回復(fù)
  2. 我是做電子發(fā)票的產(chǎn)品,能否加個微信 ??

    來自廣東 回復(fù)
  3. 總結(jié)寫的很到位,學(xué)習(xí)了,多謝~!

    來自江蘇 回復(fù)