談UX設計師評估資訊架構時內容的影響力、維護成本與可用性

Published in

AAPD — As A Product Designer

9 min readJul 27, 2018

當UX們在參與一個新的軟體專案時，前期會花費大量的時間研究資訊架構的三要素：情境、內容、用戶。這篇文章我們預計要盤點一次「內容」相關的要素，以及針對資訊架構入門有興趣的朋友，提供一個練習分析內容格式的方法。

內容的格式，決定資訊的影響力

在資訊、軟體、網路的世界中，內容格式的影響力往往被一般人低估，因此在談資訊架構的內容要素時，我認為第一點必須先說明「資訊的內容格式」造成的差異。

以各種服務常見的「電話號碼」為例，在網頁中可以直接使用「tel」的語法，當用戶使用可以撥打電話的行動裝置瀏覽你的網頁時，能夠直接點擊連結撥出電話。

<a href="tel:+886-935123123">0935-123-123</a>

這個規格流程能夠順利運作，源自於電信商清楚的規範電話號碼格式、瀏覽器APP與硬體裝置之間有約定好的API 可以呼叫硬體功能、HTML5的語法增加了電話的語意標籤等等一連串事先約定好「溝通格式」的機制。

上面這段話聽起來有點枯燥，我們換個場景再看一次。

這幾年運動風氣比較夯，許多應用服務都希望提供健康相關的應用資訊，在 iOS 的「健康」APP中，預設透過你手機內的感應器偵測你的活動量，如果你是負責規劃「活動量」相關資訊的人，你認為應該用哪些資訊格式作為基本規格呢？

內容格式的定義影響範圍很抽象，從應用的角度來看，遵循通俗的格式或者大型服務的格式能讓我們的服務站在巨人的肩膀上，不用重複發明輪子。

例如你希望你的內容很便利在社群傳播，那就要研究 FB 的 Open Graph格式，想要將你的房源串接到大流量的訂房平台就要準備好對應的內容格式，商店的POS機必須遵循當地法律要求的格式開立收據發票或者明細。

如果有一天你要規劃的應用服務沒有前人的通用格式解法可以參考，你就必須從零開始思考，要用什麼樣的資訊格式來描述你的內容。

本篇文章的最後面附錄一個練習資訊的內容格式分析的方法，主要是透過練習分析 Metadata 來培養對於格式的直覺反應。

Metadata 是個很難翻譯的詞彙，最有名的解釋是「data about data」，用來描述資料的資料（很饒舌），譯名包括：原資料、後設資料、中介資料、中繼資料。

內容的範圍，決定專案維護的規模與成本

除非你所規劃的平台立志搜羅天下網頁與資訊作另一個 Google，否則你所參與的軟體專案通常可以描述出內容的範圍，拿食物外送網站來舉個例子：

A. 單一間餐廳的外送網站
B. 同一品牌連鎖餐廳的外送網站
C. 聯合許多合作餐廳提供統一服務的外送網站
D. 任何餐廳都可以自行刊登資訊的外送網站

上述四個網站都需要提供餐廳、菜單、外送服務的資訊內容，但他們的規模顯然不同，在專案越早期越明確定義資訊內容的應用範圍越好。

關於貪心的小故事：我曾遇過一個專案，初期老闆說是A，但他有B的野心，因此我們用B的規模幫他規劃。結果到了專案上線前老闆野心膨脹認為反正都有 B 的規格了，為何不能做成C呢？對於不想理解產品架構的老闆來說，抽象的名詞聽起來都像是可以通用似的。

規劃一個內容量大的網站，要規劃足夠豐富的輔助系統，包括後台的內容上架流程、內容分類、聚合內容的規則、選單結構、站內推薦機制等等，範圍影響甚大。在此隨便舉幾個例子，也請各位對號入座想想看您手上的專案：

想像一個租房、尋找餐廳、尋找音樂之類的網站，上面累積了一百萬筆資料。1. 要花多少的時間、人力建立這些資料？（專案第三年突然要加入 GPS 資料怎麼辦？）
2. 這些大量資料的內容格式如果不符合後續改版怎麼調整？（例如要從食譜網頁變成提供智慧冰箱食譜的合作）
3. 這些資料需要多國語言翻譯時怎麼進行校正？本國的分類標籤要怎麼進行他國在地化？
4. 一百萬筆資料要提供哪些分類、篩選的方式給用戶？這些分類方式會持續變化嗎？
5. 舊的資料會過期嗎？需要人力維護嗎？（例如餐廳倒閉、歌曲的授權期限結束）

我有個朋友恰巧是某音樂平台早期成立的核心研發工程師，據說他們一開始在建立音樂資料庫時吃盡了苦頭。一開始很天真的想說可以透過版權商取得最基本的歌曲清單來建立資料庫，萬萬想不到版權商寄來一堆又一堆的音樂光碟，讓他們自行 keyin，數以萬計的音樂專輯資訊。

這些數以萬筆計算的大量內容影響系統資訊架構的例子，在網站改版的專案中通常是惡夢一場，尤其是先天規劃不良用許多違章建築的方法偷吃步的網站，通常要花數倍力氣應對這些問題。

舉個例子，許多新聞網站的 CMS 所提供的文章編輯器通常開放讓編輯修改文章的原始碼，所以有許多文章會嵌入各式各樣第三方的嵌入碼，常見的例如 Youtube、Google Map、投票、簡報等等。

這些嵌入的第三方服務在新聞媒體的內容要整理成 APP 可以吃的格式時往往死一片，特別是喜歡在文章編輯器裡面讓標題忽大忽小內文五顏六色的文章內容，對於將內容格式轉移到其他應用服務上來說都是嚴重干擾的雜訊。

想想看，新一代內容平台例如 Medium，是怎麼改變文章編輯的方式呢？

所以，身為一位 UX，在進行資訊架構的階段，很重要的任務就是釐清內容的範圍，包括為了滿足商業目標的情境需要什麼必要內容？（例如根據卡號辨認本國卡、外國卡或者發卡單位），用戶對於內容有什麼基本的期待與習慣？（例如衣服鞋子等商品要能提供不同尺碼選擇）等等。

提醒，如果你所規劃服務的內容範圍無法定義，是一個嚴重的警訊，代表專案還有很大的模糊空間。（模糊空間代表需求沒有凍結，但通常專案死線都擺在眼前，猜猜看，沒辦法凍結需求的專案會發生什麼事情呢？）

內容的來源，決定專案規格的可用性

許多野心勃勃的專案只憑著介面設計稿就開工，程式寫完才發現介面上有許多內容根本不知道要怎麼樣才能弄到手，或者需要耗費極大的成本才能建置內容。

例如漂亮的介面稿上面每個商品都是乾淨去背的樣子，但實際上電商營運的人員只有小畫家可用，供應商根本不提供照片，怎麼辦呢？

又舉個例子，假設今天要做一個C2C的二手書交易平台，但網站上如果弄不到歷年出版的書目資料，是不是要仰賴程度不一的使用者自行填寫書籍資料內容？這樣一來光是在各個首頁、目錄頁，可能就會造成圖片殘缺、標題不一，甚至同一本書但是超多筆不同版本的資訊等等。

再舉地址資訊為例，有些網站在用戶收件地址的填寫上將用戶的行政區做獨立的下拉選單，因此用戶只需要填寫城市、行政區，就會自動產生郵遞區號。郵遞區號的資訊是通用規格的內容，因此查詢郵政網站的公開資訊就可以整理出明確對應的表單。

上述例子，一是營運團隊沒有足夠品質的素材資源與產出能力，一個是開放用戶自行填寫造成大量不確定性的困擾，一個是蒐集萬年不變的公開資料作為服務的應用。內容的來源影響品質，也影響一個規格的成敗。

以下列舉幾個容易想到的內容來源管道：

1. 內容團隊產生：養一批人自己建立資料，常見於 PGC 類型網站，例如新聞媒體、氣象資訊、影視品牌等，或者較封閉的 B2B 平台。2. 合作單位：透過合作取得內容，例如 LINE Today 或雅虎新聞跟許多媒體簽約取得合作內容，或者網站嵌入 Google Map 資料也是一種引用合作單位內容的概念。3. 外部公開資料：任何人都可以查到的資料，最有名的案例就是 Google 蒐集大家的網頁，也有許多行銷平台專門蒐集媒體、臉書的資料作為產品內容提供分析後的數據。4. 用戶產生：俗稱UGC，社群網站、蝦皮拍賣、Medium都是用戶產生內容的服務。5. 資訊產生過程描述自己的資料（Metadata）：例如文章發佈的時候會有"發佈時間"這個資料、臉書貼文出去之後會吸引其他用戶按讚留言分享的數據、影片也會有時間長短等等。