想問一下前輩們,怎樣去分析一個APP的信息架構?

自己也看過幾本書,但是對「信息架構」「信息結構」「功能結構」「功能框架」這些概念有些模糊,在網上搜,看別人分析的功能框架還能明白,但是「信息架構」不是很懂,該怎樣分析呢?


使用逆向推演的方法整理了微信的某一個界面的信息架構

文章鏈接如下

[逆向工程]信息架構推演&<微信消息列表


所謂分析,其實就是再現app創作時的過程

信息架構說到底就是用於app製作時進行合理歸類的

按照你自己設想的分類規則和邏輯,將app里的功能東西進行歸類整理,方便自己接下來的工作,也方便了下游的開發工作


題主你好,剛剛好我們完成了個課程是研究兩款應用以及從它們的情感化設計中分析他們的信息架構,希望能對你有幫助哦~

我們主要研究了《墨跡天氣》和《我的天氣》這兩款天氣應用,所以呢,分析APP前需要認真仔細地列出信息架構的框架圖,需要每一個層級涉及的操作一個不漏的列出來,這樣我們會更好分析它可能存在的操作,以及分析他們的信息架構層級之間的關係和它們的信息價架構和它們的定位作出一個詳盡的分析,所以我們需要以下幾個圖:

1.兩款應用的信息架構

2.信息架構情感化的可視化圖

3.情感化的流程及走勢

4.兩款應用情感化的總體波動圖

然後我們得出下面的分析以及解讀:

首先產品的信息架構設計屬於整個產品設計的結構層,信息架構就是將用戶需求中所有包含的信息內容呈現給用戶。

附圖(墨跡天氣信息架構和我的天氣信息架構)(因太長所以沒有放上來)

因此抽了第一層級部來分析

解讀:

上圖列出的是兩款應用的第一層級的框架,根據框架圖筆者認為可以解讀出來以下的信息,《我的天氣》的五個第一層級中,有3個功能與天氣相關,其優先的為天氣信息內容,其中只有更多這一個主項對用戶本身進行挖掘,根據這款APP的定位為純天氣應用,所以這些設定本身大多符合定位,但是這容易被同類工具應用同質化,在經濟上的性質也屬於「賣方市場」;

相反對比《墨跡天氣》,注重對用戶屬性和信息設計,更多關注用戶以及用戶之間的互動,對用戶的挖掘比較多,其中時景和我都屬於關注用戶本身的,這很好地論證了《墨跡天氣》是款系統集成天氣應用。

信息架構的可視化圖 (可能視覺效果上一般般)

解讀:

由信息架構可視化圖可知,《我的天氣》層級相對淺,優先順序別為天氣,其中有情感化體驗;《墨跡天氣》的層級深,但容易造成混亂感以及一些不必要的麻煩,但是在功能設計上更多偏向用戶,講時景放在第一層級上更加尊重用戶的體驗價值,滿足了用戶情感上的內在需要。

信息架構的情感化流程

圖一是《墨跡天氣》圖二是《我的天氣》

上面兩幅圖是根據信息架構的可視化中特別具有情感化的部分勾勒出來的一個情感走向流程圖,這兩幅圖也主要從微觀的角度,典型突出兩個產品的功能特色以及各個功能之間的信息流向是否符合用戶的行為和情感趨向。我們的表現形式為第一層級的圓點是最大的,從第一層級到第七層級的圓點大小遞減,而圓點的顏色深淺表達情感化聚集的程度。

1.《墨跡天氣》中的情感化最突出的情感化主線是時景這一塊。其特徵是用戶群體大,鐵杆粉絲多。情感化主要聚集在時景這一塊,《墨跡天氣》的團隊非常注重通過這一自主開發的功能彰顯自己特色、帶給用戶情感化的體驗以幫助用戶表達思鄉之情還通過了社交來增加與用戶的互動功能,目的是提高用戶的活躍度,因此,在時景這一項功能上,先把它放在第一層級上並用感知層面刺激用戶點擊,他們並沒有止步於這一個層級,抓住用戶的情感後乘勝追擊進一步加強情感聚集度,因此在這一點上《墨跡天氣》的情感化攻略是做得非常成功的。

2.《我的天氣》定位又與《墨跡天氣》不同,其原因是用戶群體少還在上升階段大力去俘獲用戶群體,因此他們主要在APP的「顏值」上取得認同,這是把重心放在本能層面。作為工具類應用在使用的流程圖中, 《我的天氣》最聚集體現情感化地方在「今日」這一塊,回想信息架構圖,今日在《我的天氣》這個應用中處於第一層級的最主要的功能項,並且在這一項上面聚集了整款應用的大部分情感走勢。這樣目的很清晰 ,在最主要、最顯眼的功能上面一開始就集中精力發動情感,為留住用戶增加喜愛度,然後在後面的層級上面呼應用戶的情感避免斷層。

從宏觀上面的情感化比對

上圖是從宏觀上分析兩個應用的情感情緒波動圖,以順時針為方向,從起點到終點層級依次遞增。於是我們得出以下信息及解讀:

1.《我的天氣》表現的情緒波動少,相對來說比較平緩,但是其情感的體驗值都一直處於中高水平,筆者可以理解為作為一款基礎工具應用,《我的天氣》為求在用戶整個使用過程中一直保持一個愉悅的心情;《墨跡天氣》相對來說情緒的高低起伏較大,用戶的情緒波動比較大,但是為什麼作為一個擁有眾多用戶群體的應用要這麼「任性」呢,筆者發現了其中緣由,我發現每一次低谷後都會急劇上升情感,第一是給眾多「鐵杆粉」帶來驚喜,來增強新鮮感,第二是為下一層級的操作埋下伏筆,「欲擒故縱」的策略。

2.以交點為分界,內圓中標註的是表現情感化高的一方及其功能項。我們會發現兩個應用的情感化表現應該是平分秋色的,這就解釋了我們一開始為什麼選擇兩個市場份額差別如此大的兩款應用作為比較,在別人看來這並沒有什麼可比性,畢竟《墨跡天氣》從綜合競爭力上面就足以「吊打」《我的天氣》了。首先得出解讀上面筆者發現《我的天氣》的優勝點在於基礎天氣信息指數這方面,《墨跡天氣》則在特色、主推項目前更勝一籌,加上前面所說的落差感就是為了令用戶更加喜愛他們的功能項。

以上就是我結合了兩個應用做出的分析以及解讀,希望可以幫助到你,具體問題具體分析。覺得有幫助給我點個讚唄,第一次回答問題~


Hi 題主,我也是新人,看了這問題才知道還有「信息架構」「信息結構」「功能結構」「功能框架」這些專業辭彙。

我也不懂這些。

我接到一個任務時,我是這麼做的:

1.問清楚別人想要做什麼事兒

2.開始分析做這些事兒必須有哪些步驟

3.分層級分類型,各種分,從上往下梳理,然後想想怎樣讓一個用戶在完成這些操作時,步驟更少,界面更易懂。

估計你說的信息架構,可能就是:梳理一個用戶在這款產品上滿足自己需求時的流程。

還是用實例說明好點:

拍照-看拍照效果-如果構圖滿意,也不模糊,那麼就進入到下一步:處理(處理又分了很多種功能比如裁剪,濾鏡,調色等)-處理完之後大概分兩種:保存/分享-分享又分很多種:社交軟體分享或者軟體自帶的分享功能-分享完之後別人看到可能會轉發或者留言點贊,這時候產品會告訴你:要讓用戶知道自己的圖片被人點贊了,於是必須設計一個通知...就這樣像個無底洞一直挖下去。

Keep digging~

我的基礎知識幾乎為零,很肯能完全是錯的。警惕!!!!!

歡迎指正,期待其他答案,一起學習進步。

呵呵,容許我推薦一個自己常用的網站:

歡迎訪問 祝快樂

:)


信息架構分為兩類,前者是前期PM依據分析得到的PRD進行的功能梳理。後者是產品規劃期,交互設計師從用戶行為角度考慮產品信息的內部流動(一般提到的信息架構多指後者)。

如果要分析一個產品的信息架構,可以從以下維度考慮:1).當前產品定位是什麼(判斷基準);2)當前產品有哪些功能,這些功能是否符合產品定位;3)各個功能之間的信息流向是否符合用戶行為(用戶行為重於理性邏輯)

-----------------------------------------------------

希望能幫到你


用這個方法,可以有條不紊的設計一個產品的信息架構

原文鏈接:信息架構分析表——十個步驟打造產品骨架 - 陳尋楓的文章 - 知乎專欄

信息架構等於是產品的骨架,需要資深的經驗沉澱才能分析準確。為了讓產品設計過程更加快速和制定一些規範,我製作了一份《信息架構分析表》,可以由交互設計師牽頭,團隊共同協作完成。《分析表》本身也不是完美的,在運用過程中會不斷迭代優化。

產品設計初期,需要對產品結構做全面的梳理,這個行為稱為信息架構。信息架構不僅僅是對內容的梳理,需要從用戶行為、內容結構、數據關係等多個角度進行分析,最終交付一份信息架構分析表。

我將信息架構設計方法分為10個步驟:

  1. 頭腦風暴
  2. 用戶和行為
  3. 系統行為
  4. 子系統和客戶端
  5. 界面分布
  6. 數據關係
  7. 數據模型
  8. 關鍵元素
  9. 術語表
  10. 介面定義

最終交付的信息架構分表,可以從全局引導交互設計、界面設計、資料庫設計、後端開發、前端開發的推進。就像骨骼之於肌肉和器官的關係。

信息架構分析表並不是一次性寫成的,每個步驟都需要反覆和相關的人員溝通,從大綱到細節不斷完善。下面將簡要描述每個步驟的設計分析方法。

一、頭腦風暴

用思維導圖的方式,記錄需求方對於產品的需求和思路。沒有固定的格式遵循,不必考慮對錯。記錄後再經過兩三次的重新梳理,力求讓自己充分理解產品定位和核心需求,以及未來的發展方向。重新梳理的思維導圖,將進行深度分解,應用到之後的9個步驟中。

二、用戶和行為

對用戶進行分類,並且羅列用戶的主要行為,適當描述行為的流程。

用戶的分類方法設定兩個層級,第一級為用戶分組,我們稱之為「陣營」。例如:產品運營方陣營,做的是對內容、業務的管理維護;消費者陣營,做的是查詢、下單、社交、分享;供應商陣營,做的是訂單管理、商品維護、售後服務等。多個陣營最終組成產品的生態體系。

每個陣營有不同的許可權需求,衍生出對應的角色。例如:管理員、客服、普通會員、VIP會員、供應商、配送員等。

詳細列出每個角色在使用產品時的操作行為,例如:購買商品、充值/提現、創建新商品、分享照片、領取任務、邀請註冊。其中一定有某些行為,與團隊經歷和市場常見的需求不同,需要指出其中的特殊流程。

通過對特殊流程的描述,將有助於指導業務邏輯和資料庫的設計。

三、系統行為

除了人為操作的行為之外,有一些行為屬於系統自動執行。例如:自動統計訂單、自動結算賬單、自動發送信息等。這類行為往往需要伺服器端運行定時策略,執行後會產生或改變數據。相比由用戶操作的被動執行程序,也被稱為主動執行的程序。

四、子系統和客戶端

分析了用戶分類和各種行為之後,便可以規劃系統劃分為幾個子系統和依託幾個客戶端。

例如:運營方使用的運營管理系統,是一個PCWeb端子系統;消費者購物用的子系統包含4個客戶端,PCWeb端、iOS端、Android端、微信H5端;本文撰寫工具有道筆記,有Windows客戶端、Mac客戶端。

羅列所有子系統和客戶端,並對每個客戶端做階段性開發的排序,產品生命周期往往是先抓住種子用戶,針對這個人群退出合適客戶端。

五、界面分布

每個子系統和客戶端擁有多少個界面,每個界面如何命名(中文和英文)。

首先需要劃分子系統和客戶端,再劃分內容模塊,最後羅列每個界面的名稱。例如:運營管理系統/PCWeb端/商品管理/商品列表。

我將界面區分了三種類別:page / tab / dialog,區分它們的顯示狀態和層級關係。

界面的命名規範,每個團隊有自己的習慣,我的習慣是「內容+形式」,例如:goodsList / articleDetail / orderForm / cartGoodsList,僅供參考。

在信息架構分析表中,我加入少量項目管理的元素。界面分布表中,我加入UIMock、靜態樣式和介面集成的開發進度,描述界面設計和前端開發是否完成。

六、數據關係

該步驟分析數據和數據之間的關聯,將指導設計資料庫結構。有特殊需求的地方,可以註明欄位類型、長度、枚舉等細節。

一個訂單表,關係著多個表:商品明細表、用戶表、商品表、收貨地址表、地區表、優惠券表,我們需要描述它們之間的關聯欄位是什麼。尤其是複雜業務或團隊缺乏經驗的領域,前期更要規劃好表之間的關聯關係,盡量考慮未來可能的變化和發展。

七、數據模型

這份數據模型所描述的是核心內容展示給用戶看的信息,用表格型結構的方式呈現,不必描述所有數據表。

當核心的數據關係梳理清楚,我們需要提供一份數據模型,分別給需求方、交互設計和開發人員進行溝通。需求方需要明確回復,展示給用戶看的數據是否足夠;交互設計需要根據模型設計原型圖上展現的信息;開發人員需要圍繞數據模型考慮擴展、冗餘、條件判斷等需求,設計更詳細的資料庫結構。

八、關鍵元素

系統中可能需要設計一些與眾不同的效果和功能,被稱為關鍵元素,必要時繪製出的wireframe。關鍵元素往往是產品的賣點,前期溝通的時候一定會深入討論;也往往是一個對設計和開發略有挑戰的需求,也必須前期思考實現方式。

關鍵元素舉例:

  • 用個十百千萬的格式輸入金額(像會計帳本上的填寫方式),與常規的輸入方式不同;
  • 搜索結果排序規則,需要給每個內容設計一個「權重」欄位,至於權重值如何產生,後續再設計具體演算法;

九、術語表

系統中一定有一些專業術語,需要將術語的中文、英文和說明描述清晰。

十、介面定義

這個部分很重要,對於指導開發、評估工作量、進度跟蹤,有很大幫助。前面的界面分布,是針對設計和前端開發人員的。這個部分則是針對後端開發人員。

首先自己羅列一些主要的介面,再與後端開發人員溝通,定義出每一個內容和行為所要調用的後端介面。

經過這十個步驟的設計和分析,最終的信息架構分析表,將是整個產品的骨架。這也是高級產品經理的必修武功。分析信息架構的過程,也是一個貫穿需求、體驗、設計、開發、數據和管理的過程。

《信息架構分析表》模板下載地址http://note.youdao.com/groupshare/?token=62EEF7361A024F828A6D8AD92D02FB65gid=25491471


「自己也看過幾本書,但是對「信息架構」「信息結構」「功能結構」「功能框架」這些概念有些模糊…」

不知道題主所謂的看過幾本書,是翻翻的意思,還是真的讀過…

互聯網業務中,建議可以認真讀一讀(讀懂會使用,不在讀的多)《Web信息架構》,先了解信息架構的一些基本概念和基礎架構模型,再根據架構理論去分析你關注對象的信息結構。


推薦閱讀:

目前交互設計有沒有一些成型的規範?
想學習交互設計,選擇報班培訓還是自己看書學習?有哪些專業書籍值得推薦?

TAG:交互設計 | 信息架構 | 交互設計入門 |