【 設計理論】詳細解析交互設計師怎樣理解信息架構




詳細解析交互設計師怎樣理解信息架構

這一次的教學是屬於設計理論領域中的設計理論的相關教學。

文章出處是來自優設的設計理論類文章,寫教學的作者是EDC尤原慶,感謝EDC尤原慶提供設計理論的實作教學。

教學大綱:

今天分享一篇交互設計高級教程,關於產品信息架構的思考,這方面是交互設計師成長的一個關鍵點,也是交互設計大局觀的錘鍊基石,文章很有深度,值得用心學習。


設計理論教學開始

今天分享一篇交互設計高級教程,關於產品信息架構的思考,這方面是交互設計師成長的一個關鍵點,也是交互設計大局觀的錘鍊基石,文章很有深度,值得用心學習。

這篇適合交互設計或者對交互設計感興趣的小夥伴們看。所以我就不解釋信息架構是什麼了。今天寫一下產品信息架構的思考。

任何產品都有信息架構,或繁雜或簡單。在文中討論的時候,我大致把信息架構分為兩種來例證。一種是比較簡單的信息架構,例如大多ToC產品,微信、QQ音樂、騰訊視頻等;一種是比較複雜的信息架構,例如大多ToB產品,運維類產品、客戶關係管理系統、業務支撐系統等。我把第一種稱為“輕架構”產品,第二種稱為“重架構”產品。

輕架構產品,需要提供給用戶一個簡單明了的信息架構,讓用戶使用方便、體驗流暢。輕架構產品不能讓用戶迷路,不能帶來太多的學習成本,面對海量普通用戶要做到可用且效率高。輕架構產品可以通過做減法來聚焦。

重架構產品,需要提供功能完備、結構嚴謹的信息架構,讓用戶能通過操作流程以使用各個功能。這樣的架構會帶來一定的學習成本,有些重架構產品甚至需要對使用人員進行培訓。重架構產品的用戶群體一般比較聚焦。重架構產品很難通過做減法來聚焦,而是需要對海量功能進行合理整合、靈活布局來聚焦核心用戶場景。所以對重架構產品,信息框架更難,且更重要。

我在華為的設計工作包括輕架構產品和重架構產品。

設計輕架構產品的好處是輕鬆、愉快,用戶一般容易共感感知,甚至用戶就是你自己。難點在於突破和創新。

設計重架構產品的好處是對交互設計師是一次磨練交互技能的好機會,信息架構越複雜,對交互設計的要求就越高,鍛煉效果越好。難點在於,重架構產品需要對業務的理解透徹,業務理解門檻高,海量功能不能做精簡,用戶是陌生群體, 需要用戶研究的支持才能理解用戶,信息結構複雜導致交互設計難度高、錯誤率高、費力。設計重架構產品對全局觀的要求非常高。

下面我會根據Jesse James Garrett在“用戶體驗要素:以用戶為中心的產品設計”書中關於信息結構的分類為維度,講述一下這些結構在用戶體驗設計的信息架構設計中的作用,並會舉一些真實案例來討論如何使用這些結構以幫助思考。

一、層級結構(hierarchical structure)

詳細解析交互設計師怎樣理解信息架構

“在層級結構中,節點與其他相關節點之間存在父級/子級的關係。子節點代表着更狹義的概念,從屬於代表着更廣義類別的父節點。不是每個節點都有子節點,但是每個節點都有一個父節點,一直往上直到整個結構的父節點。層級關係的概念對於用戶來說非常容易理解,同時軟件也是傾向於層級的工作方式,因此這種類型的結構是最常見的。”

這是最常見的一種方式,樹狀圖、家族圖譜等,都是這個路線。這個路線蠻符合大自然的。這個結構相信大部分設計師都使用過,所以普通場景不做過多討論。這裡我想重點講的是層級結構的一種平衡式使用方式。

什麼是平衡式使用方式呢?

這個也是我最近想出來……首先我們知道,層級結構可以帶來兩種設計思路。

第一種,從上到下。從產品主要願景,一步一步細分到每個功能特性。

第二種,從下到上。從對用戶有價值的功能特性開始,一步一步往上倒推到產品靈魂。

如果你讀了我上一篇關於設計流程的思考,這兩種方式就是戰略層、範圍層雙向的方式。

第一種很容易理解,戰略定了一個大方向,管理層傳達並指導,執行層輸出,一步一步分解任務直到任務量清晰、執行后得到產品結果。

第二種在重架構產品中使用的不少,例如一個給中國電信客服做的ToB產品,得先了解客服人員每天工作的任務流、操作流、所需模塊集合,然後倒推規整為一個一個功能模塊,再倒推形成一個系統。

最近我做重架構產品,第二種方法用的蠻多。是有點費腦子,但是嘿嘿,我研究生博弈論這門課是A+呢不怕不怕。lol

這兩種方式都有缺陷。

我舉一個近期的設計例子,是一個重架構產品,首先,產品的戰略層已經確認,換言之,從上到下是合理的思路;但是,產品過於複雜且功能特性多、合作部門跨度大,這時看上去從下到上才是正解。

問題就出現了。如果從上到下分解,到了底層功能特性太多且不合使用邏輯,就紊亂了。如果從下到上倒推,功能特性有組合邏輯,但是到了頂層,產品靈魂又很難對上最開始戰略層制定的方向。

怎麼辦呢?再看一下這個圖:

詳細解析交互設計師怎樣理解信息架構

我把戰略層的第一點,最高父節點,稱為大將;把底層眾多的功能特性稱為小兵。現在的問題是,大將下達指令,小兵凌亂;小兵自行組合,大將不能接受結果。所以我想,應該使用最高父節點和底層節點中間的那些點,我稱為隊長。隊長整理小兵,形成合力的隊伍,隊長對大將負責,在隊長層合力融合,最終完成軍隊的戰鬥力合成。

這就是我對平衡式使用方式的思考過程。從上到下不行,從下到上也不行,就從中間動手。我們把海量的功能特性與系統架構師確認好,然後通過用戶訪談對我們針對的目標用戶進行測試,讓他們對海量功能特性進行認知並分組。這時候,一個經過系統架構師和目標用戶驗證的中層結構就定好了。這時候“隊長”已經產生。此時,再思考戰略層對產品特質、靈魂的定位,順推合理的中層結構,這時,另一群“隊長”也產生了,他們是能實現戰略層(父節點)要求的。然後兩組“隊長”開始融合,從中間出發,對上對下各做調整和妥協,最後得到一個統一信息架構。這個結果的重點是中層結構“隊長”。這個中層結構向上能滿足戰略層的要求,向下能滿足底層海量特性功能的實現。

問題解決了。

交互設計需要精進的一個點,就是解決複雜信息結構。解決複雜信息結構的過程和結果,會直接影響交互設計師的設計執行力和設計影響力。

二、自然結構(organic structures)

詳細解析交互設計師怎樣理解信息架構

“自然結構不會遵循任何一致的模式。節點是逐一被連接起來的,同時這種結構沒有太強烈的分類概念。自然結構對於探索一系列關係不明確或一直在演變的主題是很合適的。但是自然結構沒有給用戶提供一個清晰的指示,從而讓用戶能感覺他們在結構中的哪個部分。如果你想要鼓勵自由探險的感覺,比如某些娛樂或教育網站,那自然結構可能會是個好的選擇;但是,如果你的用戶下次還需要依靠同樣的路徑,去找到同樣的內容,那麼這種結構就可能會把用戶的經歷變成一次挑戰。”

這樣的模式在現在的ToC產品越來越多(特別是遊戲娛樂產品)。它符合輕架構產品的瀏覽式形態。

有一種經典的區分用戶場景的維度是:任務式、瀏覽式。

任務式的特點:完成任務、快、準確、效率,例如查詢某個航班到達的時間。

瀏覽式的特點:碎片、時間充裕、逛、發散、不聚焦、注意力吸引式,例如漫無目的地刷微博、看知乎。

自然結構很適合輕架構產品的瀏覽式形式。因為第一,重架構產品,ToB產品,如果用戶需要靠瀏覽靠猜來使用產品特性完成任務,那肯定結果是不好的,用戶會崩潰;第二,ToC產品一般就有兩種形態,如果不是任務式,那很有可能就是用戶在無聊,需要進入瀏覽式。

當然,完全自然結構的設計方式很少(不知道最近很火的秘密算不算)。

大部分ToC產品應該是任務式和瀏覽式并行的。所以自然結構,應該是綁定其他信息結構來思考。

例如騰訊視頻。自然結構肯定是應該考慮綁定層級結構來思考。用戶進入視頻產品,可能的一種使用方式是,用戶心裡已經有一個明確的思路,找2014年美國電影看,所以用戶進入種類選擇,選擇電影,選擇美國電影,選擇2014年,然後進行瀏覽。這個可以算是先層級結構思考、后自然結構思考。

如果用戶是在家裡喝茶,想看看視頻,但是沒有任何目的,打開了視頻產品,那他們就是進行瀏覽式操作,這個時候自然架構就產生價值。用戶在首頁進行無邏輯瀏覽,從首頁某個電視劇點入,看看詳情,不感興趣,從該電視劇的推薦點擊到下一個電視劇,然後不感興趣,然後從這個電視劇的主演想到他正在演出的一個電視真人秀,又跑去綜藝里瀏覽。

每個產品對層級結構和自然結構的偏重是不同的。例如電商類產品,大部分人去天貓是有明確購買目的的,這個時候任務類操作會更重要;但是有沒有完全沒有購買目的,就是想去天貓花點錢或者找點折扣產品呢?肯定有,但是可能不如第一種用戶多。

所以在信息架構設計中,我認為自然結構會是一個重要思考點,因為我們設計師要時刻記得,用戶不是理性的,他們很多時候的操作和想法會呈現隨機狀態。但是自然結構不是唯一的,必須有層級結構、線性結構、矩陣結構等其他信息框架來配合和約束,才能讓這個產品的整體信息架構完整、可用、有效。

三、線性結構(sequential structures)

“線性結構來自於你最熟悉的線下媒體。連貫的語言流程是最基本的信息結構類型,而且處理它的裝置早已被深深地植入我們的大腦中了。書、文章、音像和錄像全部都被設計成一種線性的體驗。在互聯網中線性結構經常被用於小規模的結構,例如單篇的文章或單個專題;大規模的線性結構則被用於限制那些需要呈現的內容順序對於符合用戶需求非常關鍵的應用程序,比如教學資料。”

線性結構比較容易理解。更多呈現在幫助文檔、產品故事講述等場景。就不多描述了。

這裡我想重點提一下就是線性結構是另外一種練習交互設計邏輯的方法。一個極端是複雜信息架構(層級、自然、矩陣等),另一個極端就是線性結構。如何用連貫的語言方式講述一個故事,但是不能進行跳轉和穿插,要一條線把思路講清楚,反而不是一件簡單的事情。

所以交互設計需要鍛煉兩個極端的信息架構描述方式。一個是複雜信息架構,充滿了層級、跳轉、補充、交叉;一種是極簡的線性架構,一根主線講清楚一個故事,甚至是複雜的故事。

四、矩陣結構(matrix structure)

詳細解析交互設計師怎樣理解信息架構

“矩陣結構允許用戶在節點與節點之間沿着兩個或更多的“維度”移動。由於每一個用戶的需求都可以和矩陣中的一個“軸”聯繫在一起,因此矩陣結構通常能幫助那些“帶着不同需求而來”的用戶,使他們能在相同內容中尋找各自想要的東西。舉個例子來說,如果你的某些用戶確實很想通過顏色來瀏覽產品,而其他人偏偏希望能通過產品的尺寸來瀏覽,那麼矩陣結構就可以同時容納這兩種不同的用戶。然而,如果你期望用戶把這個當成主要的導航工具,那麼超過三個維度的矩陣可能就會出現問題。在四個或更多維度的空間下,人腦基本上不可能很好地可視化這些移動。”

這個結構非常好理解。這裡想講的是,現在大部分設計團隊的KPI評估方式,就是矩陣結構。一方面,向業務線負責,以設計支撐產品商業成功;一方面,向設計線負責,以設計專業經驗支撐團隊專業影響力建設和技能成長建設。

設計師如何平衡這個矩陣結構管理方式,是設計師成長的關鍵點之一。

設計師做完一個產品,一定要回頭從信息架構層開始往下想,這個產品信息架構你做了什麼樣的創新、調整,產生了什麼價值。不要僅僅拘泥於做界面元素的規範、設計細節問題解決沉澱等。因為信息架構,是交互設計大局觀的最好錘鍊基石。

— —

文章永久連結為: 詳細解析交互設計師怎樣理解信息架構