提交需求
賽事與廣告咨詢合作,請?zhí)顚懶枨蟊韱危覀儠诘谝粫r間與您聯(lián)系!
前言
C端產(chǎn)品可以用發(fā)散的方式挖掘場景,從而將需求轉(zhuǎn)為亮點。而B端產(chǎn)品基本上是將「線下已有需求」系統(tǒng)化,將復(fù)雜的邏輯變?yōu)楹唵慰捎玫模瑢⒄嬲暮诵?,抽離剝出,達(dá)到線上使用標(biāo)準(zhǔn)。所以需要「還原并簡化業(yè)務(wù)」,而非「發(fā)散業(yè)務(wù)」,無法發(fā)散獲取,只能還原場景,回歸場景。
一個故事幫大家快速理解:
什么是回歸場景在一次商品管理系統(tǒng)后臺的建設(shè)項目中,業(yè)務(wù)人員(運營人員)提出了以下需求:我需要更好的管理商品大類及商品規(guī)格,在創(chuàng)建商品活動時候,我能更加的快速完成活動上線時間。
產(chǎn)品經(jīng)理小李子,快速整理好需求,以及分析用戶痛點,以及平臺規(guī)劃,調(diào)動好人員支持項目。完成一系列的操作后,把項目交接到交互設(shè)計師小王手中。交互設(shè)計師,沒有多加思索項目的背后的隱藏的內(nèi)容。找到產(chǎn)品經(jīng)理核對好需求,并進(jìn)行探討--確認(rèn)了,需要設(shè)計商品管理及活動創(chuàng)建。春菜迅速的畫好了原型圖,初步獲得了確認(rèn)。
然而,到了開發(fā)階段,由于開發(fā)日期遠(yuǎn)高于預(yù)估排期,最終實現(xiàn)的方案出現(xiàn)了嚴(yán)重的問題,遠(yuǎn)遠(yuǎn)達(dá)不到當(dāng)初業(yè)務(wù)人員的預(yù)期,引起了大量的投訴不好用,最終產(chǎn)生了很大負(fù)面影響,并且也不愿意去用了。
回歸場景如果從回歸場景來看,相比之下那么這一位交互設(shè)計師無疑是一位老江湖了。
這位老江湖找到當(dāng)初提出的需求的業(yè)務(wù)人員:我這次來找你就是通過您了解,你需要商品管理和創(chuàng)建活動的需求去解決什么問題,以便我回去重新給您構(gòu)思一個更加有效貼切實際的解決方案!
業(yè)務(wù)人員接過話題:因為我想通過商品管理,來規(guī)劃商品上下架的操作及沒貨的情況,還可以根據(jù)市場環(huán)境調(diào)整一下價格。我繼續(xù)問道:你之前是如何解決的呢?
業(yè)務(wù)人員回答:我只能通過微信的方式告訴價格變動或者商品沒貨了。然后我在根據(jù)大量的表格中去找到對應(yīng)的商品,然后進(jìn)行編輯,創(chuàng)建活動。所以我的效率很不高,經(jīng)常挨罵?;顒右膊荒芗皶r的變更,又需要重復(fù)上一步去完成更替。
所以問題并不是一定要完成大模塊商品管理和活動創(chuàng)建,而是幫助他們解決效率問題!
找到了問題之后,我認(rèn)為應(yīng)采用更簡單的解決方案,我快速的畫出了草圖草圖,講解了一番。業(yè)務(wù)人員聽懂我提出的方案后,雙手一拍,對,我就是需要這個功能。你太厲害了!
只有回歸場景,才能找到業(yè)務(wù)中真正的問題,從而給出更高效的解決方案。
確定了核心場景需求,一定確認(rèn)以下四點:
1、場景是否能夠讓業(yè)務(wù)閉環(huán);
2、場景之間是否有有明晰的串聯(lián)邏輯;
3、是否有捷徑的路可以走
4、是否是已經(jīng)是用戶理解的版本。
同理心設(shè)計
這是從一個大層面去講解「回歸場景」,那么接下來,我通過一些細(xì)節(jié)講一下什么是場景化下的同理心設(shè)計。
還是商品模塊的案例:需求確認(rèn)完,核心問題確定完成,接下來輪到線框仔上場了。春菜,表示簡單。
春菜在商品模塊創(chuàng)建的下,設(shè)計好表單后,寫好交互說明,得意洋洋的交給前端,組織會議,還特意強(qiáng)調(diào)了,請后臺同學(xué)一起參與,這一塊的內(nèi)容會牽扯后臺。開發(fā)哥哥也表示,這些簡單,沒問題,可以做。
在實際的場景中:用戶在創(chuàng)建表單中,輸入內(nèi)容,一會一個紅字,一會一個請輸入,表示我還沒輸入,系統(tǒng)就反饋我是錯誤的了,我錯在哪了?并且加大了我的阻礙,就相當(dāng)于,你正在走路,時不時的被拌一下的那種感覺。發(fā)了很大的火,投訴到了老板那里。
聰明的大家也知道了問題!那就是「表單實時校驗」的場景運用問題!
老板也試了一下。單手拍頭,我草,你去幫他解決一下吧。你看一下你就知道了。
老江湖看到這表單創(chuàng)建,微微一笑。寫出了以下問題:
1、這是強(qiáng)業(yè)務(wù)類的表單,實時校驗就太過分了,同時也加強(qiáng)了用戶自我懷疑、不耐煩等的負(fù)面情緒。實時校驗也增大了后臺的負(fù)荷。場景運用不明確。
2、缺少同理心,沒有站在用戶的角度上去設(shè)計,沒能感受到,他創(chuàng)建表單時候的心情。
3、表單太過精細(xì),不必要的字段過多。沒有貼合實際商品的規(guī)格信息。
4、沒有了解業(yè)務(wù)人員(運營人員)的工作量。沒能從底層解決效率問題。
5、表單名稱復(fù)雜,不易懂。導(dǎo)致用戶頻繁理解錯。
6、專業(yè)操作屬性過多。邏輯復(fù)雜
7、表單距離按鈕控件太遠(yuǎn)。用戶操作路徑過長
8、缺少防錯提示。不小心刷新網(wǎng)頁,缺少防錯。手賤點了關(guān)閉網(wǎng)頁,缺少防錯
9、缺少記錄字段。既然是創(chuàng)建商品,肯定會有同類型的字段出現(xiàn),系統(tǒng)需要記憶。幫助用戶減少下一次輸入。缺少友好性。
好的設(shè)計師:是能站在用戶的層次上去思考問題,站在專業(yè)的角度上,幫助他解決問題。
好的設(shè)計師不會甩鍋:是他沒跟我說清楚,諸如此類的話,我們要學(xué)會反思,我為什么不能主動的去跟他探討呢。
總結(jié):根據(jù)場景確定設(shè)計原則,站在場景內(nèi),能真的懂用戶在想什么。
END
原文作者: 交互思維鋪子
原文鏈接: 如何從場景中提取設(shè)計原則
公眾號:CJM Studio
本文由 @CJM Studio 整理發(fā)布于UI中國 ,未經(jīng)作者許可,禁止轉(zhuǎn)載。
Powered by Froala Editor
大牛,別默默的看了,快登錄幫我點評一下吧!:)
登錄 立即注冊