AAA教育

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


 

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

在我看來至少要滿足以下條件：

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

如果是一個經(jīng)驗老道的產(chǎn)品經(jīng)理或者交互設(shè)計師，上述情況出現(xiàn)的紕漏會比較少。如果是經(jīng)驗非豐富的PM或者交互設(shè)計，那么很容易出現(xiàn)各種情況的紕漏，如何避免呢？

 

1. 明確主場景和使用人群

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

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

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

適用人群：熱衷于唱歌/K歌的用戶，以及渴望得到展示的舞臺。

痛點：喜歡唱歌，但只在KTV有機會唱。喜歡唱歌，但周邊朋友喜歡唱歌的不多。KTV唱歌水平太差，但苦于沒地方?jīng)]時間練習(xí)。唱的很優(yōu)秀，但是找不到得到PK展示的舞臺。

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

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

 

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

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

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

3. 流程設(shè)計簡單合理化

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

流程設(shè)計如果要簡單合理化，通常有以下幾種方式：

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

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

 

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

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

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

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

5. 交互邏輯無缺失

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

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

是否可以左右滑動切換二級導(dǎo)航？如何可以左右滑動，一直朝一個方向滑動，導(dǎo)航是否可以循環(huán)切換？

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

唱過的人是用萬展示，如果推薦的歌曲只有5個人唱過那么是用「0.0005萬人唱過」，還是就是「5人唱過」？

以上的疑問在交互稿里面都沒有體現(xiàn)，所以在設(shè)計過程中要盡量保證交互邏輯無缺失

 

6. 異常場景不遺漏

異常場景不遺漏，這個里面包含很多情況，依舊以K歌的交互稿為例。

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

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

下載失敗的情況下用戶停留在當(dāng)前界面如何提示，不在當(dāng)前下次在進入時候是否要提示，如果提示，如何提示？

弱網(wǎng)情況下，頁面如何加載，全屏加載？分步加載？

以上的疑問在交互稿里面都沒有體現(xiàn)，所以在設(shè)計過程中要盡量保證異常場景不遺漏。

 

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

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

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

 

8. 極限情況有定義

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

• 常見的是字段的長度定義，例如如果用戶名，標(biāo)題，文本內(nèi)容超長的情況，打點表示還是折行顯示？
• 一次非常多數(shù)據(jù)需要加載或展示時，應(yīng)該如何處理？
• 時間沒有年份時，如果在跨年期間，時間如何展示等等。

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

不同產(chǎn)品都會涉及到多種角色，不同角色是否存在不同的權(quán)限，不同的使用場景？所以設(shè)計過程要通過角色和場景做設(shè)計。

 

10. 全局組件有說明

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

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

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

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