資訊架構入門#3：如何評估資訊架構的影響力、維護成本、可用性？／Soking

當UX使用體驗設計師們在參與一個新的軟體專案時，前期會花費大量時間研究資訊架構的三要素：情境、內容、用戶。在本文中，讓我們來盤點一下「內容」相關的要素，並提供一個練習分析內容格式的方法，給對資訊架構入門有興趣的朋友。

獸群之心／ Soking 產品設計師，多年新創公司、社群營運以及媒體經驗，經營千綺設計，提供UI/UX設計顧問服務、以及UX教育工作坊。

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

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

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

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

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

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

這幾年運動風氣普及，許多應用服務都希望提供健康相關的應用資訊；在iOS的「健康」app中，則預設透過手機內的感應器，來偵測使用者的活動量。如果你是負責規劃「活動量」相關資訊的人，會希望使用哪些基本的資訊規格呢？

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

舉例來說，如果你希望內容能夠很便利在社群媒體上傳播，那就要研究Facebook的「Open Graph」格式；如果想要將酒店房間資源串接到大流量的訂房平台，就要準備好對應的內容格式。如果是商店的POS結帳機，則必須遵循當地法律要求的格式，開立收據發票或者明細。

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

在本文的最後，附上了一個練習資訊內容格式分析的方法，讓讀者透過練習分析描述metadata，來培養對於格式的直覺反應，稍後再請參考。

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

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

除非你規劃的平台立志搜羅天下網頁與資訊，成為「另一個Google」，否則你所參與的軟體專案，通常都可以描述出內容的範圍。以餐點外送網站為例，基本型態就可以分為這四類：

1. 單一餐廳的外送網站
2. 同一品牌多家連鎖餐廳的外送網站
3. 聯合許多合作餐廳、提供統一服務的外送網站
4. 任何餐廳都可以自行刊登資訊的外送網站

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

關於貪心的小故事：我曾遇過一個專案，初期老闆說是1，但他有2的野心，因此我們用2的規模幫他規劃；結果到了專案臨上線前，老闆野心膨脹，認為反正都有2的規格了，為何不能做成3呢？ 對於不想理解產品架構的老闆來說，抽象名詞聽起來都像是可以通用似的，但其實不然、而且甚至天差地遠。

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

想像一個租房、尋找餐廳、尋找音樂之類的網站，假設上面已經累積了100萬筆資料。

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

我有個朋友，恰巧是某音樂平台早期成立的核心研發工程師。據說他們一開始在建立音樂資料庫時，就吃盡了苦頭。

一開始時，他們很天真的想，可以透過版權商取得最基本的歌曲清單來建立資料庫；萬萬想不到的是，版權商卻寄來一堆又一堆的音樂光碟，讓他們自行人工輸入數以萬計的音樂專輯資訊。

用「違章建築」硬解資訊架構問題的網站，日後通常都得花好幾倍力氣來彌補。

這些數以萬筆計算的大量內容，影響到系統資訊架構的例子，在網站改版的專案中通常是惡夢一場；尤其是先天規劃不良、用許多「違章建築」的方法硬解的網站，日後通常必須要花好幾倍的力氣來應對這些問題。

舉個例子：許多新聞網站的內容管理系統（CMS）所提供的文章編輯器，通常都可以讓編輯修改文章原始碼，所以許多文章都會嵌入各式各樣的第三方嵌入碼，常見的包括Youtube、Google Map、投票、簡報等等。

當新聞媒體想做自己的手機app時，這些嵌入內容的第三方服務如果要整理成app可以接受的格式，往往災情慘重；特別是如果編輯又喜歡讓標題忽大忽小、內文五顏六色，在將內容轉移到其他應用服務上時，都是嚴重干擾的雜訊。

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

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

提醒一下，如果你所規劃的服務，是無法定義內容範圍的，這會是一個非常嚴重的警訊：代表專案還有很大的模糊空間；模糊空間代表需求沒有凍結，但通常專案的完成期限就擺在眼前。

猜猜看，沒辦法凍結需求的專案會發生什麼事情呢？

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

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

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

再舉個例子，假設今天要做一個C2C（用戶對用戶）的二手書交易平台，但網站上如果弄不到歷年出版的書目資料，是不是要仰賴程度不一的使用者自行填寫書籍資料內容？

這樣一來，在各個資料頁面上就可能發生圖片殘缺、標題不一，甚至同一本書有超多筆不同版本的資訊等問題。

再舉地址資訊為例。有些網站在用戶收件地址的填寫上，將用戶所在的「行政區」做成獨立的下拉選單，因此用戶只需要填寫城市、行政區，就會自動產生郵遞區號。

因為郵遞區號資訊是通用規格的內容，因此查詢郵政網站的公開資訊，就可以整理出明確對應的表單。

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

內容的來源影響品質，也影響了一個規格的成敗。

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

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

補記：關於metadata的補充案例

本文初稿完成之後，筆者與朋友聊到metadata的概念，覺得文中的說明還是有些模糊。剛好打開桌面上的截圖檔案，用滑鼠右鍵可以點選「取得資訊」，打開之後看到的內容，就是關於這個檔案的metadata：

練習時間：分析你感興趣的網頁，標記出適合的metadata

運用Google所提供的工具，依照下圖內提供的網站類型，從中挑選一種（例如徵才、文章、餐廳、電影等等）來練習資料的標記方式；並請同時思考，這些標記出來的資料是從哪裡產生的？

網址： https://www.google.com/webmasters/markup-helper/u/0/

以下就是筆者拿自己的Medium文章練習的結果。建議您多換幾種不同的網頁來嘗試看看：

如果你想多了解資料結構化，可以參考Schema.org這個網站，或者這個與產品有關的格式說明網頁。

關於metadata的規劃，也可以向認識的後端工程師請益，討論專案中的內容有哪些資料屬於metadata的範圍，應該會更有所收穫，也讓你未來所設計的資訊架構更加事半功倍、未來改版更加無痛。

• 「資訊架構設計」系列文章