在我看來至少要滿足以下條件：
- 明確主場景和使用人群
- 信息結構合理化
- 流程設計簡單合理化
- 設計符合大部分用戶認知模型
- 交互邏輯無缺失
- 異常場景不遺漏
- 關鍵字段有規則定義
- 極限情況有定義
- 是否涉及到多種角色和權限
- 全局組件有說明
如果是一個經驗老道的產品經理或者交互設計師，上述情況出現的紕漏會比較少。如果是經驗非豐富的PM或者交互設計，那么很容易出現各種情況的紕漏，如何避免呢？本人以酷狗K歌ios版（虛構）為載體舉例說明，讓讀者可以很清晰的感知和了解上述的一套方法。
1.明確主場景和使用人群移動互聯網的快速發展帶來了傳統業務形態的變革,滿足人們不同需求的移動應用應運而生。K歌類移動應用以滿足用戶的K歌需求為核心,精準的K歌工具屬性贏得眾多唱歌愛好者的追捧。憑借手機K歌便利性以及豐富的擴展功能,移動K歌應用的業務形態及商業模式已愈加成熟。
用戶人群在進行K歌的時，也希望得到別人的認可和pk。所以移動K歌應用已經成為以K歌為核心的泛娛樂平臺，在集成原有K歌工具性能的基礎上，移動K歌平臺已開拓出道具打賞、游戲聯運、智能硬件以及線下KTV經營等多元變現路徑。
從中國主流移動K歌應用的人均行為分析數據來看，唱吧、全民K歌和愛唱三款應用的人均單日使用次數均超過6次，其中唱吧最多，達到7.4次。人均單日使用時長方面數據集中度較高，全民K歌、演唱匯、酷我K歌、移動練歌房四款應用均在30到40分鐘之間。其中，愛唱和唱吧的人均單日使用時長最為突出，分別高達53.84和50.77分鐘。在豐富曲庫、及時更新、專注打造K歌工具的基礎上，各移動K歌應用均通過新增歌會友、視頻直播、視頻合唱等社交功能的方式提升用戶粘性，現階段，K歌、直播、交友已成移動K歌平臺標配。
適用人群：熱衷于唱歌/K歌的用戶，以及渴望得到展示的舞臺。
痛點：喜歡唱歌，但只在KTV有機會唱；喜歡唱歌，但周邊朋友喜歡唱歌的不多；KTV唱歌水平太差，但苦于沒地方沒時間練習；唱的很優秀但是找不到得到PK展示的舞臺。
解決方案：是從工具層面切入。給用戶提供K歌練習和錄制工具。但也不單純是工具，用戶通過工具錄制作品時，通過合唱等方式與其他用戶互動。錄制完成后上傳分享作品，獲得其他用戶的贊賞和獎勵。和別的K歌者同場競技從而提高唱歌水平。最后高質量的大量作品又給用戶提供內容。產品也從工具層面轉向社交層面。從用戶內容輸入到輸出形成一個完美的閉環。
定位：所以酷狗K歌可以認為是一個垂直興趣（唱歌）的UGC社區。用戶生產內容、用戶進行內容的消費，獲得更多的認可和贊賞。提供更好的工具給用戶，讓用戶在平臺玩的更愉快！
2.信息結構合理化通過明確主場景和適用人群、痛點、解決方案和定位。同時基于酷狗K歌現有業務可以形成一套完整的產品架構。
比賽、動態、K歌、發現、我的，五個大tab從K歌到發現推薦到社交形成一套完整的閉環。
盡量用最簡單合理的交互方式達到業務需求。這樣的話用戶更容易上手使用。
流程設計如果要簡單合理化，通常有以下幾種方式：
- 操作路徑簡化，簡化不必要的步驟或操作干擾
- 一個界面盡量只做一件事情
- 操作邏輯和主流app一致或和生活中認知習慣保持一致
例如做評委界面，一組比賽，通過卡片左右滑動的形式換組，這樣的設計高度模擬了現實中的卡片的實際場景，使得切換起來簡單有趣。同時擔心用戶不知道此隱蔽操作，也提供文字按鈕進行切換；整個界面基本就做一件事，做評委。不存在其他功能操作的干擾；操作路徑簡單，不需要跳轉頁面。
4.設計符合大部分用戶認知模型認知模型又稱3M認知模型，是人類對真實世界進行認知的過程模型。所謂認知，通常包括感知與注意、知識表示、記憶與學習、語言、問題求解和推理等方面，建立認知模型的技術常稱為認知建模。
這里說到的認知模型，通常就是說對于設計的認知。比如常見的是結構分組，相同屬性結構的在一起；操作邏輯遵從從哪里來到哪去；信息通過大小顏色去區分重要度；
例如在K歌模塊第一模塊為導航入口的聚合，第二個模塊為推薦歌曲和排行榜單。導航入口的聚合符合主流APP的交互設計。同時將推薦歌曲和排行榜單通過二級導航的的方式呈現。
【K歌】作為按鈕也比較符合用戶的認知，點擊就可以K歌了。同時界面所處的tab就是K歌。整個tab所以的一件事就是K歌了。由于整個產品所定義的是K歌比賽和社交，所以比賽和動態分別位于第一和第二tab。
5.交互邏輯無缺失在設計中很容易出現交互邏輯的缺失。出現這種原因是因為設計師首先做了最常見的設計布局從而忽略了其他情況，依舊以上一張交互稿為例。
推薦歌曲和排行榜單的二級導航，是否固定懸浮？
是否可以左右滑動切換二級導航？如何可以左右滑動，一直朝一個方向滑動，導航是否可以循環切換？
推薦歌曲下的列表最多出現多少列？
唱過的人是用萬展示，如果推薦的歌曲只有5個人唱過那么是用“0.0005萬人唱過”，還是就是“5人唱過”？
6.異常場景不遺漏異常場景不遺漏，這個里面包含很多情況，依舊以K歌的交互稿為例：
下載過程中無網絡如何提示用戶？WiFi切換為2/3/4G如何提示用戶？
用戶第一次進入，沒有唱歌記錄，沒有口味和風格的標簽，如何推薦歌曲，這種情況下如何提示和引導用戶？
下載失敗的情況下用戶停留在當前界面如何提示，不在當前界面下次在進入時候是否要提示，如果提示，如何提示？
弱網情況下，頁面如何加載，全屏加載？分步加載？
7.關鍵字段有規則定義關鍵字段有規則定義，這里指的是，字段需要連接數據庫，對于這樣的字段需要明確的定義，不然最后開發時候，開發要么找設計師溝通要么他們自己去按照自己的理解去定義并做出來。
例如動態里面，關于時間的定義，就需要一個明確的定義，如果不寫的話最后的結果可能就千變萬化。交互稿里面，當天的時間顯示 時：分；昨天就顯示昨天；昨天以前顯示 月-日。
由于交互稿是動態主界面，所以涉及到送禮、評價、轉發的交互沒有體現出來。
極限情況有定義這里有很多種情況：
- 字段的長度定義，例如用戶名，標題，文本內容超長的情況，打點表示還是折行顯示？
- 一次非常多數據需要加載或展示時，應該如何處理？
- 時間沒有年份時，如果在跨年期間，時間如何展示等等
產品都會涉及到多種角色，不同角色存在不同的權限和不同的使用場景。所以設計過程要重視角色、場景和權限。
10.全局組件有說明全局組件指的是整個產品通用的組件，例如全局斷網，操作成功、操作失敗、加載、空數據界面，404等
全局斷網：一般是在首頁使用tips提示。用戶在其他界面點擊操作時，也會出現toast反饋提示用戶。也有一些app在用戶進入出現對話框提示用戶網絡異常。相對于對話框，使用tips對用戶的干擾更小。
操作成功：一般操作成功都是根據具體的使用場景對出對應的提示。
操作失敗：異常情況導致操作失敗，這時需要統一的提示，通常使用toast，也有一些使用對話框強提示用戶。
加載：涉及到全局加載和局部加載，全局加載在設計中要統一說明，例如上一個界面點擊進入下一個界面，使用的全局加載就需要說明。如果是一些小場景的加載，那么需要特殊說明。例如上拉加載，下拉加載，局部小區域加載等。
空數據類型一共有三類：- 初始狀態的定義：初始化狀態，沒有任何內容，需要用戶進行某種操作才能產生內容的界面。
- 清空狀態的定義：通過刪除或其他用戶操作，清空當前的頁面內容，產生了空界面，這時候需要有明確的提示，且告知用戶該如何處理。
- 出錯狀態的定義：由于網絡、服務器或者沒有找他其他結果等原因導致無法加載內容，產生了空界面，這時候需要有明確的提示，且告知用戶該如何處理。用戶操作反饋的無結果界面也可以用這樣的思路來設計。
