如何用科學(xué)的方法做出專業(yè)的原型圖?

UX
2 評(píng)論 25177 瀏覽 182 收藏 15 分鐘

本文作者將以酷狗K歌ios版(虛構(gòu))為載體舉例說(shuō)明,什么樣的原型圖才能算得上專業(yè)而細(xì)致?希望各位可以很清晰地感知這套方法。

什么樣的原型圖才能算得上專業(yè)而細(xì)致?

在我看來(lái)至少要滿足以下條件:

  1. 明確主場(chǎng)景和使用人群
  2. 信息結(jié)構(gòu)合理化
  3. 流程設(shè)計(jì)簡(jiǎn)單合理化
  4. 設(shè)計(jì)符合大部分用戶認(rèn)知模型
  5. 交互邏輯無(wú)缺失
  6. 異常場(chǎng)景不遺漏
  7. 關(guān)鍵字段有規(guī)則定義
  8. 極限情況有定義
  9. 是否涉及到多種角色和權(quán)限
  10. 全局組件有說(shuō)明

如果是一個(gè)經(jīng)驗(yàn)老道的產(chǎn)品經(jīng)理或者交互設(shè)計(jì)師,上述情況出現(xiàn)的紕漏會(huì)比較少。如果是經(jīng)驗(yàn)非豐富的PM或者交互設(shè)計(jì),那么很容易出現(xiàn)各種情況的紕漏,如何避免呢?本人通過(guò)酷狗K歌ios版(虛構(gòu))為載體舉例說(shuō)明,讓讀者可以很清晰的感知和了解上述的一套方法。

1. 明確主場(chǎng)景和使用人群

移動(dòng)互聯(lián)網(wǎng)的快速發(fā)展帶來(lái)了傳統(tǒng)業(yè)務(wù)形態(tài)的變革,滿足人們不同需求的移動(dòng)應(yīng)用應(yīng)運(yùn)而生。K歌類移動(dòng)應(yīng)用以滿足用戶的K歌需求為核心,精準(zhǔn)的K歌工具屬性贏得眾多唱歌愛(ài)好者的追捧。憑借手機(jī)K歌便利性以及豐富的擴(kuò)展功能,移動(dòng)K歌應(yīng)用的業(yè)務(wù)形態(tài)及商業(yè)模式已愈加成熟。

用戶人群在進(jìn)行K歌的時(shí),也希望得到別人的認(rèn)可和pk。所以移動(dòng)K歌應(yīng)用已經(jīng)成為以K歌為核心的泛娛樂(lè)平臺(tái),在集成原有K歌工具性能的基礎(chǔ)上,移動(dòng)K歌平臺(tái)已開(kāi)拓出道具打賞、游戲聯(lián)運(yùn)、智能硬件以及線下KTV經(jīng)營(yíng)等多元變現(xiàn)路徑。

從中國(guó)主流移動(dòng)K歌應(yīng)用的人均行為分析數(shù)據(jù)來(lái)看,唱吧、全民K歌和愛(ài)唱三款應(yīng)用的人均單日使用次數(shù)均超過(guò)6次,其中唱吧最多,達(dá)到7.4次。人均單日使用時(shí)長(zhǎng)方面數(shù)據(jù)集中度較高,全民K歌、演唱匯、酷我K歌、移動(dòng)練歌房四款應(yīng)用均在30到40分鐘之間。其中,愛(ài)唱和唱吧的人均單日使用時(shí)長(zhǎng)最為突出,分別高達(dá)53.84和50.77分鐘。在豐富曲庫(kù)、及時(shí)更新、專注打造K歌工具的基礎(chǔ)上,各移動(dòng)K歌應(yīng)用均通過(guò)新增歌會(huì)友、視頻直播、視頻合唱等社交功能的方式提升用戶粘性,現(xiàn)階段,K歌、直播、交友已成移動(dòng)K歌平臺(tái)標(biāo)配。

適用人群:熱衷于唱歌/K歌的用戶,以及渴望得到展示的舞臺(tái)。

痛點(diǎn):喜歡唱歌,但只在KTV有機(jī)會(huì)唱;喜歡唱歌,但周邊朋友喜歡唱歌的不多;KTV唱歌水平太差,但苦于沒(méi)地方?jīng)]時(shí)間練習(xí);唱的很優(yōu)秀但是找不到得到PK展示的舞臺(tái)。

解決方案:是從工具層面切入。給用戶提供K歌練習(xí)和錄制工具。但也不單純是工具,用戶通過(guò)工具錄制作品時(shí),通過(guò)合唱等方式與其他用戶互動(dòng)。錄制完成后上傳分享作品,獲得其他用戶的贊賞和獎(jiǎng)勵(lì)。和別的K歌者同場(chǎng)競(jìng)技從而提高唱歌水平。最后高質(zhì)量的大量作品又給用戶提供內(nèi)容。產(chǎn)品也從工具層面轉(zhuǎn)向社交層面。從用戶內(nèi)容輸入到輸出形成一個(gè)完美的閉環(huán)。

定位:所以酷狗K歌可以認(rèn)為是一個(gè)垂直興趣(唱歌)的UGC社區(qū)。用戶生產(chǎn)內(nèi)容、用戶進(jìn)行內(nèi)容的消費(fèi),獲得更多的認(rèn)可和贊賞。提供更好的工具給用戶,讓用戶在平臺(tái)玩的更愉快!

2. 信息結(jié)構(gòu)合理化

通過(guò)明確主場(chǎng)景和適用人群、痛點(diǎn)、解決方案和定位。同時(shí)基于酷狗K歌現(xiàn)有業(yè)務(wù)可以形成一套完整的產(chǎn)品架構(gòu)。

比賽、動(dòng)態(tài)、K歌、發(fā)現(xiàn)、我的,五個(gè)大tab從K歌到發(fā)現(xiàn)推薦到社交形成一套完整的閉環(huán)。

3. 流程設(shè)計(jì)簡(jiǎn)單合理化

盡量用最簡(jiǎn)單合理的交互方式達(dá)到業(yè)務(wù)需求。這樣的話用戶更容易上手使用提升產(chǎn)品的用戶體驗(yàn)。

流程設(shè)計(jì)如果要簡(jiǎn)單合理化,通常有以下幾種方式:

  1. 操作路徑簡(jiǎn)化,簡(jiǎn)化不必要的步驟或操作干擾;
  2. 一個(gè)界面盡量只做一件事情;
  3. 操作邏輯和主流app一致或和生活中認(rèn)知習(xí)慣保持一致。

例如做評(píng)委界面,一組比賽,通過(guò)卡片左右滑動(dòng)的形式換組,這樣的設(shè)計(jì)高度模擬了現(xiàn)實(shí)中的卡片的實(shí)際使用場(chǎng)景,使得切換起來(lái)簡(jiǎn)單有趣。同時(shí)也提供文字按鈕進(jìn)行切換,防止用戶不知道此隱蔽操作。整個(gè)界面基本就做一件事,做評(píng)委。不存在其他功能操作的干擾;操作路徑簡(jiǎn)單,不需要跳轉(zhuǎn)頁(yè)面。

4. 設(shè)計(jì)符合大部分用戶認(rèn)知模型

認(rèn)知模型又稱3M認(rèn)知模型,是人類對(duì)真實(shí)世界進(jìn)行認(rèn)知的過(guò)程模型。所謂認(rèn)知,通常包括感知與注意、知識(shí)表示、記憶與學(xué)習(xí)、語(yǔ)言、問(wèn)題求解和推理等方面,建立認(rèn)知模型的技術(shù)常稱為認(rèn)知建模。

這里說(shuō)到的認(rèn)知模型,通常就是說(shuō)對(duì)于設(shè)計(jì)的認(rèn)知。比如常見(jiàn)的是結(jié)構(gòu)分組,相同屬性結(jié)構(gòu)的在一起;操作邏輯遵從從哪里來(lái)到哪去;信息通過(guò)大小顏色去區(qū)分重要度;

例如在K歌模塊第一模塊為導(dǎo)航入口的聚合,第二個(gè)模塊為推薦歌曲和排行榜單。導(dǎo)航入口的聚合符合主流APP的交互設(shè)計(jì)(主流app已經(jīng)將用戶的認(rèn)知培養(yǎng)起來(lái)了)。同時(shí)將推薦歌曲和排行榜單通過(guò)二級(jí)導(dǎo)航的的方式呈現(xiàn)?!綤歌】作為按鈕也比較符合用戶的認(rèn)知,點(diǎn)擊就可以進(jìn)行K歌。同時(shí)界面所處的tab就是K歌。整個(gè)tab所以的一件事就是K歌了。由于整個(gè)產(chǎn)品所定義的是K歌比賽和社交,所以比賽和動(dòng)態(tài)分別位于第一和第二tab。

5. 交互邏輯無(wú)缺失

在設(shè)計(jì)中很容易出現(xiàn)交互邏輯的缺失。出現(xiàn)這種原因是因?yàn)樵O(shè)計(jì)師首先做了最常見(jiàn)的設(shè)計(jì)布局從而忽略了其他情況,依舊以上一張交互稿為例。

推薦歌曲和排行榜單的二級(jí)導(dǎo)航,是否固定懸浮?

是否可以左右滑動(dòng)切換二級(jí)導(dǎo)航?如何可以左右滑動(dòng),一直朝一個(gè)方向滑動(dòng),導(dǎo)航是否可以循環(huán)切換?

推薦歌曲下的列表最多出現(xiàn)多少列?

唱過(guò)的人是用萬(wàn)展示,如果推薦的歌曲只有5個(gè)人唱過(guò)那么是用“0.0005萬(wàn)人唱過(guò)”,還是就是“5人唱過(guò)”?

以上的疑問(wèn)在交互稿里面都沒(méi)有體現(xiàn),所以在設(shè)計(jì)過(guò)程中要盡量保證交互邏輯無(wú)缺失

6. 異常場(chǎng)景不遺漏

異常場(chǎng)景不遺漏,這個(gè)里面包含很多情況,依舊以K歌的交互稿為例:

下載過(guò)程中無(wú)網(wǎng)絡(luò)如何提示用戶?WiFi切換為2/3/4G如何提示用戶?

用戶第一次進(jìn)入,沒(méi)有唱歌記錄,沒(méi)有口味和風(fēng)格的標(biāo)簽,如何推薦歌曲,這種情況下如何提示和引導(dǎo)用戶?

下載失敗的情況下用戶停留在當(dāng)前界面如何提示,不在當(dāng)前下次在進(jìn)入時(shí)候是否要提示,如果提示,如何提示?

弱網(wǎng)情況下,頁(yè)面如何加載,全屏加載?分步加載?

以上的疑問(wèn)在交互稿里面都沒(méi)有體現(xiàn),所以在設(shè)計(jì)過(guò)程中要盡量保證異常場(chǎng)景不遺漏

7. 關(guān)鍵字段有規(guī)則定義

關(guān)鍵字段有規(guī)則定義,這里指的是,字段需要連接數(shù)據(jù)庫(kù),對(duì)于這樣的字段需要明確的定義,不然最后開(kāi)發(fā)時(shí)候,開(kāi)發(fā)要么找設(shè)計(jì)師溝通要么他們自己去按照自己的理解去定義并做出來(lái)。

例如動(dòng)態(tài)里面,關(guān)于時(shí)間的定義,就需要一個(gè)明確的定義,如果不寫(xiě)的話最后的結(jié)果可能就千變?nèi)f化。交互稿里面,當(dāng)天的時(shí)間顯示 時(shí):分;昨天就顯示昨天;昨天以前顯示 月-日。定義明確。由于交互稿是動(dòng)態(tài)主界面,所以涉及到送禮、評(píng)價(jià)、轉(zhuǎn)發(fā)的交互沒(méi)有體驗(yàn)出來(lái)。

8. 極限情況有定義

極限情況有定義這里有很多種情況:

(1)常見(jiàn)的是字段的長(zhǎng)度定義,例如如果用戶名,標(biāo)題,文本內(nèi)容超長(zhǎng)的情況,打點(diǎn)表示還是折行顯示?

(2)一次非常多數(shù)據(jù)需要加載或展示時(shí),應(yīng)該如何處理?

(3)時(shí)間沒(méi)有年份時(shí),如果在跨年期間,時(shí)間如何展示等等

9. 是否涉及到多種角色和權(quán)限

不同產(chǎn)品都會(huì)涉及到多種角色,不同角色是否存在不同的權(quán)限,不同的使用場(chǎng)景。

所以設(shè)計(jì)過(guò)程要通過(guò)角色和場(chǎng)景做設(shè)計(jì)

10. 全局組件有說(shuō)明

全局組件,指的是整個(gè)產(chǎn)品通用的組件,例如全局?jǐn)嗑W(wǎng),操作成功、操作失敗、加載、空數(shù)據(jù)界面,404等

  • 全局?jǐn)嗑W(wǎng):一般是在首頁(yè)使用tips提示。用戶在其他界面點(diǎn)擊操作時(shí),出現(xiàn)toast反饋提示用戶。也有一些app在用戶進(jìn)入出現(xiàn)對(duì)話框提示用戶網(wǎng)絡(luò)異常。相對(duì)于對(duì)話框,使用tips對(duì)用戶的干擾更小。
  • 操作成功:一般操作成功都是根據(jù)具體的使用場(chǎng)景對(duì)出對(duì)應(yīng)的提示。
  • 操作失?。?/strong>異常情況導(dǎo)致操作失敗,這時(shí)需要統(tǒng)一的提示,通常使用toast。
  • 加載:涉及到全局加載和局部加載,全局加載在設(shè)計(jì)中要統(tǒng)一說(shuō)明,例如上一個(gè)界面點(diǎn)擊進(jìn)入下一個(gè)界面,使用的全局加載就需要說(shuō)明。如果是一些小場(chǎng)景的加載,那么需要特殊說(shuō)明。例如上拉加載,下拉加載,局部小區(qū)域加載等。

空數(shù)據(jù)類型一共有三類:

  1. 初始狀態(tài)的定義:初始化狀態(tài),沒(méi)有任何內(nèi)容,需要用戶進(jìn)行某種操作才能產(chǎn)生內(nèi)容的界面。
  2. 清空狀態(tài)的定義:通過(guò)刪除或其他用戶操作,清空當(dāng)前的頁(yè)面內(nèi)容,產(chǎn)生了空界面,這時(shí)候需要有明確的提示,且告知用戶該如何處理。
  3. 出錯(cuò)狀態(tài)的定義:由于網(wǎng)絡(luò)、服務(wù)器或者沒(méi)有找他其他結(jié)果等原因?qū)е聼o(wú)法加載內(nèi)容,產(chǎn)生了空界面,這時(shí)候需要有明確的提示,且告知用戶該如何處理。用戶操作反饋的無(wú)結(jié)果界面也可以用這樣的思路來(lái)設(shè)計(jì)。

相關(guān)閱讀

設(shè)計(jì)規(guī)范 | 詳解組件控件結(jié)構(gòu)體系:空數(shù)據(jù)類

設(shè)計(jì)規(guī)范 | 詳解組件控件結(jié)構(gòu)體系:網(wǎng)絡(luò)異常類

設(shè)計(jì)規(guī)范 | 詳解組件控件結(jié)構(gòu)體系:加載類

#專欄作家#

UX,微信公眾號(hào):UEDC,人人都是產(chǎn)品經(jīng)理專欄作家。前華為ITUX交互組組長(zhǎng),現(xiàn)美團(tuán)點(diǎn)評(píng)高級(jí)交互設(shè)計(jì)師。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來(lái)自 Unsplash,基于 CC0 協(xié)議

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 很棒,這教會(huì)了我會(huì)多東西。但實(shí)際上要用到那些東西,還是要根據(jù)自己的項(xiàng)目來(lái)。對(duì)這些東西做個(gè)“需求評(píng)審”。

    回復(fù)