每日干货分享

B端零售門店服務App-信息架構


經歷過幾家創業公司,但卻很少參與產品信息架構的設計,不管有沒有產品經理,產品的信息架構大部分都由創業者來定。不是所有的創業者都有信息架構搭建意識,他們多從短期的業務邏輯和商業價值兩個維度出發,簡單定義信息內容和產品架構,而忘記了實現商業價值應以滿足用戶需求為基礎。從長期的產品發展來看,信息架構對產品發展的影響會越來越明顯。對to C產品而言,用戶核心使用場景較少,用戶群體相對集中,使用流程相對簡短,所以大都屬於輕架構。而對to B產品而言,屬於功能繁多,流程複雜,角色許可權多樣,場景靈活可配置的重架構產品。隨著to B產品用戶群體增大,覆蓋場景增多,越來越多的想象不到的問題暴露出來,這個時候信息架構的設計經不經得住推敲就一目了然了。

一、剖析和復盤信息架構

在之前經歷了近兩年的一款to B產品中,迭代更新了大量的功能,結合用戶使用場景設計並優化了好幾個複雜的的操作流程,給用戶帶來功能完整和流程簡單的產品體驗。可是隨著時間的驗證,用戶給我們提出了一些我們並沒有考慮到的問題。

以下是從應用市場和用戶交流群收集的2017年3月到2017年9月的用戶提問和反饋,我將這些內容分為已上線功能存在使用問題和功能不全導致使用不便兩部分來展示:

B端零售門店服務App-信息架構

B端零售門店服務App-信息架構

從用戶反饋看,很多現有的功能可以滿足他們的需求,可用戶卻找不到也不會用。與不會用的功能數相比,功能設計不完整佔少數。面對重複關於找功能入口、獲取內容等問題高頻出現在用戶交流群中,團隊需要花大量的時間去告知用戶如何使用。這對於人力資源不足的創業團隊而言是奢侈的。面對這麼多高頻率的重複問題,你可以說是沒有客服團隊,沒有用戶幫助系統等原因造成。卻容易忽略最重要的原因:產品設計師沒有將信息按照易於人們理解接收的方式來整理和排列,導致用戶無法自然感知、接收和預測信息。所以在解決交互視覺問題之前,需將信息架構這個產品骨架優先完成。本文選擇逆向分析方式來複盤產品信息構架和從理論上去學習信息構架的重要性。

1、還原產品A信息架構

產品A是一款為個體商戶、零售批發、連鎖便利店等提供移動門店管理服務的企業服務軟體。包括以下功能點:1.店鋪管理(店鋪信息,店鋪營銷,多店管理)2.訂單管理(線上接單,線下開單,訂單查詢,退換貨)3.庫存管理(商品移庫,商品拆裝,商品拼裝,商品組裝,商品盤點)4.店員管理(店員入店,店員許可權管理,店員角色設置)5.賬本管理(手動記賬,自動記賬,多賬戶管理,供應商賬戶管理)6.會員管理(會員辦理,會員積分,會員充值)7.店鋪分析(進貨分析,出貨分析,店員分析,會員分析,毛利分析,庫存分析,賬本分析)8.店鋪營銷等。以下是產品A目前的信息架構圖:

B端零售門店服務App-信息架構

從線上版的信息架構可以看出,整個產品的架構寬且深。整個功能架構出現了嚴重的不平衡。導航共五個模塊:首頁、訂單、庫存、分析、管店。首頁和管店功能佔比最大,將這兩個模塊單獨提取:

1.1 首頁:個人中心、店鋪切換、部分統計、經營指數圖、進貨、出貨。首頁做這種功能模塊排版是為了讓用戶第一印象就可以認識這個產品。想傳達給用戶這個產品的兩大特點:一是這個產品是為建立數據化智能門店服務的,二是這個產品的主要應用場景是出貨進貨。

B端零售門店服務App-信息架構

1.1.1 導航區

在右上方的「+」用於同步,快速添加賬目等服務;掃碼按鈕用戶快捷結算,快捷開單。

個人中心

  • 功能描述:賬號個人信息設置;
  • 交互方式:點擊進入個人中心模塊可編輯個人信息;
  • 實際場景:修改賬戶信息,退出賬戶登錄,提交反饋等;
  • 體驗疑問:內容簡單,層級處理太複雜,是否可以減少跳轉合併成一個頁面?

店鋪切換

  • 功能描述:滿足多店管理情況下切換店鋪;
  • 交互方式:下拉或者點擊切換店鋪其他tab數據全部轉變;
  • 實際場景:大量店主只有一個店,並不需要切換店鋪;
  • 體驗疑問:從功能優先順序和隱藏需激活的設計方式上看,這種設計安排是否合理?

1.1.2 內容區

部分統計

  • 功能描述:展示今日進貨、本月毛利、今日出貨;
  • 交互方式:無;
  • 實際場景:店主需要關注的數據是動態變化的,顯示當日的經營情況,如:訂單數、入賬、新增辦卡等;
  • 體驗疑問:是否是店主想要看到的關鍵營業數據?

經營指數

  • 功能描述:多維度數據匯總成經營指數;
  • 交互方式:點擊統計圖,tab切換至分析;
  • 實際場景:經營指數適合店鋪階段性經營狀態展示,並配合具體的數據分析和換算規則;
  • 體驗提問:沒有告知用戶經營指數的統計標準,數據內容不直觀。由於某種原因,暫已停止更新;

進貨

  • 功能描述:進貨記賬;
  • 交互方式:交互和出貨一致;
  • 實際場景:進貨后錄入貨物信息、供應商信息和進貨金額;
  • 體驗疑問:進貨此處進貨按鈕給用戶造成兩方面的困擾:平台是否可以給用戶提供產品?進貨和產品入庫有什麼區別?

出貨

  • 功能描述:滿足店主實時出貨選擇商品和收銀流程;
  • 交互方式:跳轉頁面錄入商品選購信息、會員信息和完成收銀流程;
  • 實際場景:客人選購好商品到收銀台付款;
  • 體驗疑問:暫無。

從上述分析可得:除了出貨入口操作頻次高,其他功能存在設計不完整和定義不準確不清晰等問題!導致整個頁面的場景感很弱,華而不實。

1.2 管店:店鋪基本信息、購買服務入口、店鋪成員、基礎設置模塊、店鋪運營模塊

和首頁比,管店tab顯得複雜很多。隨著產品的功能越來越細化,管店模塊內容越來越豐富。但一直都在基礎設置和店鋪運營兩個模塊內添加。基礎設置是啟動店鋪數據化的開端,店鋪的數據化運營需要全面的基礎數據來支撐。店鋪運營是為商家獲取客戶和管理客戶服務的。商家通過開通運營服務和設置運營規則吸引更多新客戶和老客戶回購。

B端零售門店服務App-信息架構

背景圖模塊:店鋪二維碼、設置(包括店鋪信息)、服務購買;

店鋪成員:店鋪成員展示、添加店員;

基礎設置:商品、印表機、結算、角色、(隱藏部分:儲值卡、規格、類型、單位、收銀設備、倉庫、個性化);

店鋪運營:賬本、通訊錄、小麥鋪。

在功能較少的時候,這種四大塊的方式分割頁面並不會突兀。隨著功能增多,涉及的用戶場景細化,兩個簡單的基礎設置和店鋪運營模塊已經不能很好的支撐服務項歸類。導致新增功能不直觀,入口安排不合理,用戶搜索困難等問題。

2、產品A信息架構剖析版

通過對最複雜的首頁和管店頁面剖析可得出功能入口安排沒有從長期的產品定位出發,導致產品骨架無法合理支撐功能特性。為了全面理解問題,我選擇對全盤功能特性打散重組。由於是復盤階段,身邊沒有同事等相關工作人員和用戶,無法使用封閉式卡片分析法,所以從用戶反饋、使用場景和功能邏輯關聯性的角度使用色塊歸類法來進行功能分類,使閱讀更清晰,剖析更直觀:

B端零售門店服務App-信息架構

B端零售門店服務App-信息架構

通過剖析,將整個產品歸類為7塊,每塊代表特定的功能區,用7個顏色將其標出來。從標的色塊可看出各個色塊分佈相當分散,這說明整個產品功能模塊間並沒有保持獨立性,功能特性穿插混亂。混亂的功能特性入口使用戶迷路,通過信息構架場景化歸類來改變現狀。被分散的最嚴重的是設置類的功能。賬戶信息設置、店鋪信息設置、店鋪數據規則設置和個性化設置等。

3、產品A信息架構復盤版

為了打造一個寬且淺的信息架構,減少層次達到功能展示扁平化,實現用戶可以輕易的發現功能入口。首先通過色塊歸類法快速找出相關功能特性進行模塊重組。然後使用場景歸類法定義場景,將重組后的各個模塊分發到場景中。最後總結為由六個大模塊均衡組成的信息架構。

模塊一:首頁。店鋪基本數據錄入和運營活動設置。便於錄入基本數據和設置數據運營規律;

模塊二:訂單。實時的出貨訂單管理,分為門店訂單操作和線上訂單操作。將記賬類的進貨和倉庫調整功能都歸到庫存模塊;

模塊三:庫存。全新整個庫存管理模塊。新增進貨入庫功能以及將所有的倉庫操作記錄整合為倉庫日誌;

模塊四:統計。全新的使用店鋪數據統計功能,錢、貨、人多維度的數據統計和分析;

模塊五:設置(抽屜)。將分散的互不相干的各種設置功能統一為一個開放性模塊,便於高效查找和靈活使用;

模塊六:開單。將開單收銀設置為單一模塊,這個模塊是基於其他模塊設置成果的唯一呈現模塊。

經過多次的歸類整合,全新的信息構架復盤版如下:

B端零售門店服務App-信息架構

總結:

以上是我對信息架構復盤的思路整理。整個過程通過線上反饋,模塊分組封閉完成。不代表專業立場,只是我個人的分析思維和沉澱。復盤后的信息架構也無法運用到市場中驗證。但通過這次信息架構的復盤,我加深了對信息架構設計的理解和運用。

在產品設計初期,產品設計團隊可以慢一點,不僅僅站在業務邏輯和商業價值的角度去設定產品的信息架構,而應該全面站在用戶使用場景中去考慮問題。

在產品設計中期,信息架構需要隨著產品定位的變化而優化,便於更好更快速的支撐新功能。用戶引導不僅僅停留在視覺表現層,應該深入的追求引導失誤的根本原因,最低成本提升產品的貼心程度和判斷能力,讓用戶使用更貼心快捷。

二、信息架構相關理論知識

1、什麼是信息架構?

信息架構是指在對某一特定內容里的信息集合進行統籌、分類,從而幫助用戶更好的檢索和瀏覽信息。

比如當我們去醫院看病時,從進入醫院大門那一刻就進入了一個完整的信息架構中。這些信息都安排在住院部、門診部的樓房裡。當我們挂號后就會去找到對應的科室就診。就診后醫生會讓我們做檢查、治療、買葯。我們都需要去對應的房間。整個看病流程我們都離不開醫院複雜的信息架構。

B端零售門店服務App-信息架構

其實我們使用App和瀏覽網頁也是相同的道理,總是可以通過頂部或者底部的導航欄找到我們想要的功能。由此可得:

從用戶層:信息架構是幫助用戶在特定的複雜的信息中快速找到自己想要的;

從產品層:信息架構是建立在以產品目標為出發點通過滿足用戶需求實現業務需求來設計的。

2、怎麼做信息架構?

產品的工作流、行為和組織把一個大信息集合根據特定的規律拆分為多個小信息集合,這裡的特定規律需遵循用戶的目標和需求,並保持簡單和穩定。由於這些信息各自承擔著具體任務,因此信息分組的目的在於更好地在任務中和任務間疏通用戶的使用流程。這時,要考慮的主要問題如下(此處內容引用自《About Face 交互設計精髓4》):

  • 哪些信息能夠容納其他信息;
  • 如何組織才能優化工作流;
  • 哪些信息需捆綁使用?哪些不是?
  • 哪些數據有利於用戶做出分析和決策?
  • 相關聯的元素是如何排序?
  • 哪些信息需大片展示?
  • 用戶的心理模型如何影響信息組織?

簡言之有以下三個步驟:

  • 首先定義清楚有哪些工作流、行為和組織,儘可能將所有信息歸類清楚,寧可分細也不能太粗放;
  • 然後簡單的確定一級導航,將細分的相關類別進行整合,這一步可以嘗試多種組合方式,但需要保證每個導航模塊的獨立性;
  • 最後需確定導航之間的相互聯繫,給主導航進行排序並解決複雜的數據邏輯關係。

3、什麼是好的信息構架?

隨著時間的積累,現在大多數產品的信息架構都有很多相似之處,驗證了好的信息架構有一定的普適性。譬如我們都知道一種最為常見的模式,當我們沿著信息架構深入導航時,我們總會傾向於從寬泛的「信息面」逐步定位到特定的「信息點」。這種探索信息架構的行為通常被稱為「鑽取」。所以好的信息架構應有以下共同點

3.1 符合「產品目標」和「用戶需求」

B端產品通過提高客戶對服務的滿意度和存留率獲取收益。然而B端產品對應的用戶角色較多,各個角色需求差異。要滿足全鏈路的效率提升,需要對各個角色的工作環節進行詳細了解。

3.2 層級關係清晰,突出重點信息

產品特性複雜繁多的情況下,通過對比將信息進行分組和分類,根據使用頻率,突出重要信息,滿足用戶高效的操作體驗。

3.3 相關信息歸類,保持分類獨立

通過使用場景將信息歸類,防止信息零散分佈在其他場景中,而同一層級中的各個信息都應該保持獨立便於用戶準確預測內容。

3.4 結構平衡穩固,便於快速擴展

從縱向來看,功能特性層級深會讓用戶操作路徑過長。從橫向來看,入口太多導致查找困難。這些都會降低用戶效率。同時,新功能特性的加入如果能很好的融入到已有信息架構中,會減少產品團隊的決策成本。如更新內容過多,已有信息架構無法支撐,可在分支內優化調整保持產品的易用性。

3.5 描述清晰易懂,避免用語不當

產品設計師在設計過程中,文字描述除了貼合場景和功能特性外,還需滿足簡單易懂。特別是做一些行業的工具類軟體,需考慮到用戶群體的專業化程度,如面向很多缺少專業知識的全新用戶,專業辭彙不僅加大了用戶的理解難度,還會降低使用效率,也會給產品團隊帶來想象不到的教育成本。

以上是我通過對各個平台和書本搜索的關於信息架構設計的整理,不放過每一個有問題的機會去學習和沉澱為的是在以後的工作中能更加職業化的高效的專業的解決問題和提出問題。