如何設計復雜信息架構產品？

 　　最近忙於一個技術平台類項目，信息架構非常復雜，所以想寫一些關於設計復雜信息架構產品的想法和經驗。

　　我們做產品設計的設計師日常工作粗略分一下，可以分為兩類，一類是ToC產品，面向消費者的產品，一類是ToB產品，面向企業或者特定用戶群體的面商類產品。平常大家討論比較多的是ToC類產品，因為大家都在使用，且設計師很多在從事ToC類產品的設計工作。

　　在知乎、微信、微博等平台，有不少設計師朋友來問我，做ToB類產品，信息架構復雜，功能繁多，流程很繞，怎麼才能設計好呢?正好最近在做一個很復雜很繞的產品設計，這裡正好一並總結回答。

　　為了方便描述，我這裡極端一點，描述ToC類產品為信息架構相對簡單的產品，例如微信，核心故事為聊天、朋友圈、支付等，因人而異，每個用戶的核心場景不算多。而ToB類產品動辄就是上百個核心故事，各種功能模塊繁雜且對用戶的親切性低，使用起來學習成本高，例如銀行交易系統、電信客服系統等。

　　簡單類比一下，信息架構復雜程度的感覺由弱到強是這樣的。

　　設計或者操控以下交通工具：

　　自行車。

　　汽車。

　　飛機。

　　火箭。

　　宇宙飛船……

　　現在基本了解了信息架構復雜產品的樣子，咱們一起來看一下一些設計這類產品需要注意的點。

　　一、邏輯清晰

　　設計復雜信息架構產品，第一要素，就是設計師邏輯要非常清晰。這類產品伴隨的海量功能、大量模塊、錯綜復雜的交互流程、難以理解的業務技術背景，都是對設計師達到邏輯清晰的挑戰。

　　如果極端簡化一個ToC類產品的任務流程，可能是這樣的：

　　一個機智的用戶來使用是這樣：

　　一個不太機智的用戶來使用是這樣：

　　然後看一個ToB類產品，信息架構復雜的時候，如果設計師沒有達到邏輯清晰，那設計出來的任務流程可能是這樣的：

　　這時，

　　萌萌的用戶會：-_-””

　　默默的用戶會：呵呵……

　　凶狠的用戶會：設計師你過來我保證不砍你……

　　所以做ToB類產品設計，一定不能像寫散文一樣，隨心而至，隨時下筆，得像寫議論文那樣，做足功課，想清楚重點和邏輯，腦中成圖，再動手畫稿。

　　二、角色與場景

　　雖然ToC和ToB設計的特性差異明顯，但是基本的設計方法還是通用的。角色與場景設計依然是復雜信息架構產品設計的法寶。有著1000個功能的產品，先分角色，降低每個角色模塊需要思考的信息量和業務邏輯量，然後再根據真實用戶的使用情況，來劃分場景進行場景設計。把一大塊任務有邏輯地細分到小任務，才有逐步實現的可能。

　　切記，最好不要僅僅依靠業務功能來劃分模塊，不然體驗設計會亂得一塌糊塗。

　　角色設計需要對用戶群體有清晰的了解和劃分，能做到業務使用的共感。

　　場景設計需要設計師有足夠的全局觀，不然分開了場景，完成了設計，合不起來，就麻煩了。

　　一個復雜信息架構產品，分角色，劃場景，可以讓設計師對產品目的了解更深刻，全局把握更強，另外在頁面層級上，會把之前需要10層的功能任務流打薄到2-3層，大大提升用戶的使用效率和舒適度。

　　三、學習成本

　　做產品設計的一個基本要求，就是要保證用戶學習成本足夠低，低到沒有最好。做ToC產品這個目標很明確，也很容易靠攏，而做ToB產品很難。

　　我見過一個中國電信客服的界面，一個PC界面密密麻麻上百個功能，業務員完全憑借自己的記憶力和習慣來進行操作，沒有太多的任務流清晰度可言。這樣的產品使用，是需要一定時間的學習才能達到基本使用，學習成本肯定不低。

　　還有不少ToB產品，需要有專門的培訓和講解，才能勉強讓新用戶開始使用。

　　這個時候，如果單純以學習成本低到沒有來要求ToB類產品，非常難。信息架構復雜起來，是很難通過認知設計、視覺設計、交互流程簡化來解決學習成本高的問題。

　　有幾個點可以幫助到，一是靈活有效的提示(生僻專業術語提示、關鍵操作提示、報警監控提示等)，二是充足有價值的用戶測試，保證不出現設計師以為很好用，用戶學到哭的情況，三是深刻理解業務，設計師的業務理解水平接近架構師和產品經理的水平，才能從體驗側做一定范圍的有效改動，來幫助產品的可用性得到提升。

　　設計復雜信息架構產品時，想做到學習成本低到沒有，這時的設計方法應該是，雖不能至，心向往之。

　　四、業務理解度

　　做復雜信息架構產品，最難的就是業務理解入門。例如做微信、QQ音樂等產品，設計師相對好入手，因為設計師本身也是用戶群體。而復雜信息架構產品一般不是給普通用戶使用的，是給一個特定群體的用戶使用的，大部分情況，設計師與這個特定群體是沒有交集的。

　　例如設計師接到一個任務，做銀行交易系統，首先，設計師沒有在銀行工作過，對銀行交易流程基本不了解，第二，設計師完全不知道使用這個交易系統的用戶的心理模型、工作狀態、用戶場景、喜怒哀樂。如果這個銀行交易系統是給尼日利亞的某個銀行做的，可能設計師連當面和用戶交流的機會都沒有。

　　所以做這類產品時，動工前，設計師大部分時候業務理解度無限趨近於0……

　　最好的方式，我是建議設計師能自己跑去真實使用場景做做自己的用戶訪談，例如到用戶群體做一天的跟蹤訪談、用戶深訪、任務流程記錄、用戶痛點記錄等，這些真實的感受和體驗帶來的價值遠遠大於架構師或者產品經理給設計師描述帶來的價值。

　　自我經驗的比較也是一個好方法。沒有設計師能站出來說，我做過任何類型的產品設計，但是優秀的設計師可以找到一些讓以前自己成功的設計經驗適用到現有產品的方法。

　　做一個雲平台的服務購買場景，雖然設計師可能沒有接觸過雲平台，但是能否類比到去京東淘寶買零食的流程，來看看有沒有共性可以利用。其實是有的，因為人性是相通的。

　　五、拉通

　　做復雜信息架構產品，最難的一點是拉通。

　　做一個ToC類產品，可能一個設計討論會，來4-5位產品與開發的同事就能啟動討論，且很快會有結論和執行項。做一個復雜信息架構的ToB類產品，一個模塊拉通會輕輕松松就是來30多人，一個討論就能引發2個小時的混戰。

　　這個時候對設計師的全局觀和項目把控能力的要求是非常高的。不然就會出現一個情況，拉30多人討論10個設計點，討論到第2個設計點的時候，大家爭起來了，很快就爭論到商業、業務、技術、平台等非設計的論題，吵了3個小時然後大家都崩潰了就散會了。這個時候設計師才想起來，還有9個設計點沒有討論……

　　拉通需要設計師有掌握全場討論的能力，控制時間，控制爭論方向，避免沒有結果的討論，主動提出並控制設計的執行項。

　　六、做減法

　　有很多ToC類的設計黃金准則，在ToB類設計不一定適用。例如做減法。一個頁面，產品經理提出了20個功能，設計師說，簡潔!減法!砍成3個!產品經理說，不行，10個!設計師說，好了，5個，趕緊的我還要出圖呢。這個減法討論就結束了。(當然，簡單信息架構產品做減法也是需要技巧和思考的)

　　而ToB類產品，一個模塊100個功能可能來自20個不同的業務需求群體，這個時候砍任何功能，都會造成整個大功能模塊閉環的缺失。所以單純的砍功能做減法不一定在ToB類產品設計上適用。

　　七、設計師的成就感

　　很多設計師在網上給我抱怨，說做的產品是ToB的，密密麻麻的功能、表格、篩選、流程圖，一點美感都沒有，不像做一個音樂、聊天、工具的ToC產品那麼有成就感。

　　的確，做一款好的ToC產品，首先，樣子足夠好看(能放棄一些次級功能追求簡潔和美觀)，第二，大眾使用，App Store有人誇，家人朋友可以點贊。

　　做ToB產品，先不說好不好看，一般來說ToB產品的交互價值遠遠大於視覺暫時，而且主要是沒人誇。設計師花半年給南美一個運營商做一個大數據分析系統，做的再好，南美那邊也不會有用戶跑來贊你啊，要是真有一天有個用戶高興的不行，給你打一個電話，你也聽不懂啊…… 哈哈哈

　　我覺得換一個角度來想。

　　找到樂趣。

　　做什麼設計都是有樂趣的。做ToC產品，把一個首頁做的漂亮精致，肯定是有成就感的。做ToB產品，把一個需要10步的流程通過打散、整合、聚集等方式減少到3步，也是一種樂趣。

　　設計復雜信息架構的時候，設計師千萬不要放棄自己對專業的美好理想，讓自己完全受制於業務和技術來出稿，而是時刻記得自己的專業能否幫助整個系統得到提升，這