資訊架構入門#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的野心，因此我們用2的規模幫他規劃；結果到了專案臨上線前，老闆野心膨脹，認為反正都有2的規格了，為何不能做成3呢？
對於不想理解產品架構的老闆來說，抽象名詞聽起來都像是可以通用似的，但其實不然、而且甚至天差地遠。
規劃一個內容量大的網站，要規劃足夠豐富的輔助系統；包括後台的內容上架流程、內容分類、聚合內容的規則、選單結構、站內推薦機制等等，範圍影響甚大。在此隨便舉幾個例子，各位也不妨對號入座，看看自己手上的專案。
想像一個租房、尋找餐廳、尋找音樂之類的網站，假設上面已經累積了100萬筆資料。
- 要花多少時間、人力建立這些資料？（如果業主在專案的第三年，忽然靈機一動，想加入GPS資料怎麼辦？）
- 這些大量資料的內容格式，如果不符合後續改版的需求怎麼調整？（例如要從「食譜網頁」變成提「供智慧冰箱食譜」的合作）
- 這些資料需要多國語言翻譯時怎麼進行校正？本國的分類標籤要怎麼進行他國在地化？
- 100萬筆資料要提供哪些分類、篩選的方式給用戶？這些分類方式會持續變化嗎？
- 舊的資料會過期嗎？需要人力維護嗎？（例如餐廳倒閉、歌曲的授權期限結束等等）
我有個朋友，恰巧是某音樂平台早期成立的核心研發工程師。據說他們一開始在建立音樂資料庫時，就吃盡了苦頭。
一開始時，他們很天真的想，可以透過版權商取得最基本的歌曲清單來建立資料庫；萬萬想不到的是，版權商卻寄來一堆又一堆的音樂光碟，讓他們自行人工輸入數以萬計的音樂專輯資訊。
用「違章建築」硬解資訊架構問題的網站，日後通常都得花好幾倍力氣來彌補。
這些數以萬筆計算的大量內容，影響到系統資訊架構的例子，在網站改版的專案中通常是惡夢一場；尤其是先天規劃不良、用許多「違章建築」的方法硬解的網站，日後通常必須要花好幾倍的力氣來應對這些問題。
舉個例子：許多新聞網站的內容管理系統（CMS）所提供的文章編輯器，通常都可以讓編輯修改文章原始碼，所以許多文章都會嵌入各式各樣的第三方嵌入碼，常見的包括Youtube、Google Map、投票、簡報等等。
當新聞媒體想做自己的手機app時，這些嵌入內容的第三方服務如果要整理成app可以接受的格式，往往災情慘重；特別是如果編輯又喜歡讓標題忽大忽小、內文五顏六色，在將內容轉移到其他應用服務上時，都是嚴重干擾的雜訊。
想想看，如Medium之類的新一代內容平台，又是怎麼改變文章編輯方式的呢？
所以，身為一位UX設計師，在資訊架構階段很重要的任務，就是「釐清內容的範圍」，包括：為了滿足商業目標的情境，需要什麼必要內容（例如根據信用卡號辨認本國卡、外國卡或者發卡單位），用戶對於內容有什麼基本的期待與習慣（例如衣服鞋子等商品，要能提供不同尺碼的選擇）等等。
提醒一下，如果你所規劃的服務，是無法定義內容範圍的，這會是一個非常嚴重的警訊：代表專案還有很大的模糊空間；模糊空間代表需求沒有凍結，但通常專案的完成期限就擺在眼前。
猜猜看，沒辦法凍結需求的專案會發生什麼事情呢？
內容的來源，決定專案規格的可用性
有許多野心勃勃的專案，設計師往往只憑著介面設計稿就開工，結果程式寫完才發現，有許多介面上需要的內容根本不知道怎麼弄到手、或者需要耗費極大的成本才能建置。
例如在漂亮的介面稿上，每個商品影像都是乾淨、去好背的樣子，但實際上電商營運的人員只有「小畫家」可以用，供應商根本不提供照片，怎麼辦呢？
再舉個例子，假設今天要做一個C2C（用戶對用戶）的二手書交易平台，但網站上如果弄不到歷年出版的書目資料，是不是要仰賴程度不一的使用者自行填寫書籍資料內容？
這樣一來，在各個資料頁面上就可能發生圖片殘缺、標題不一，甚至同一本書有超多筆不同版本的資訊等問題。
再舉地址資訊為例。有些網站在用戶收件地址的填寫上，將用戶所在的「行政區」做成獨立的下拉選單，因此用戶只需要填寫城市、行政區，就會自動產生郵遞區號。
因為郵遞區號資訊是通用規格的內容，因此查詢郵政網站的公開資訊，就可以整理出明確對應的表單。
上述例子，一是營運團隊沒有足夠品質的素材資源與產出能力，一個是開放用戶自行填寫造成大量不確定性的困擾；另一個是蒐集萬年不變的公開資料，作為服務的應用。
內容的來源影響品質，也影響了一個規格的成敗。
以下列舉幾個容易想到的內容來源管道：
- 內容團隊產生：養一批人自己建立資料，常見於PGC（專家產生內容）類型網站，例如新聞媒體、氣象資訊、影視品牌等，或者較為封閉的B2B（商家對商家）平台。
- 合作單位：透過合作取得內容，例如LINE Today或雅虎新聞跟許多媒體簽約取得合作內容，或者網站嵌入Google Map資料，也是一種引用合作單位內容的概念。
- 外部公開資料：任何人都可以查到的資料；最有名的案例就是Google蒐集大家的網頁。也有許多行銷平台專門蒐集媒體、Facebook的資料作為產品內容，提供分析後的數據。
- 用戶產生：俗稱UGC，社群網站、蝦皮拍賣、Medium都是用戶產生內容的服務。
- 資訊產生過程描述自己的資料（Metadata）：例如文章發佈的時候會有「發佈時間」這個資料、Facebook貼文之後吸引其他用戶按讚／留言／分享的數據、影片也會有觀看時間長短等資訊。
補記：關於metadata的補充案例
本文初稿完成之後，筆者與朋友聊到metadata的概念，覺得文中的說明還是有些模糊。剛好打開桌面上的截圖檔案，用滑鼠右鍵可以點選「取得資訊」，打開之後看到的內容，就是關於這個檔案的metadata：
練習時間：分析你感興趣的網頁，標記出適合的metadata
運用Google所提供的工具，依照下圖內提供的網站類型，從中挑選一種（例如徵才、文章、餐廳、電影等等）來練習資料的標記方式；並請同時思考，這些標記出來的資料是從哪裡產生的？
以下就是筆者拿自己的Medium文章練習的結果。建議您多換幾種不同的網頁來嘗試看看：
如果你想多了解資料結構化，可以參考Schema.org這個網站，或者這個與產品有關的格式說明網頁。
關於metadata的規劃，也可以向認識的後端工程師請益，討論專案中的內容有哪些資料屬於metadata的範圍，應該會更有所收穫，也讓你未來所設計的資訊架構更加事半功倍、未來改版更加無痛。
- 「資訊架構設計」系列文章
為什麼會看到廣告
留言0
查看全部
吐納商業評論的沙龍 的其他內容
你可能也想看
資訊安全警報：陳彥博臉書專頁遭綁架事件分析陳彥博在四月十號發布一篇貼文表示，他手上三十六萬追蹤的臉書專頁遭到綁架。根據報導指出，從去年底開始，勒索集團開始採用假的視訊連結來進行綁架，報導還提出防範措施。
2024-04-10
臺灣價值高息ETF 00940資訊整理，不懂選股邏輯就瘋狂買？00940元大高股息臺灣ETF重點分析，含元大臺灣價值高息指數的追蹤股票高股息 股息率 配息頻率 等資訊。搶市場初級市場申購的打破發行價10元的現象，值不值得投資存在爭議。未來的股息表現需要時間檢驗。股息率不等於報酬率。
2024-04-01
用實價登錄資訊的“均價”買房？!「實價登錄」是政府在民國100年推出的一項政策，主要是希望藉由房價成交資訊透明化，讓大家在買價房地時，可以知道過往的類似案例大約賣多少錢一坪，讓大家有個底，也減少因房僳資訊不對稱所衍生的交易糾紛。然而，您確定可以直接確定房價嗎
買房常這樣出價
小張想買房，想說用實價登錄上的資訊，找想買的地點附近
2023-11-05
瑞士格林德瓦必去景點-菲斯特(FIRST)纜車、懸崖天空步道、冒險活動(含2023票價資訊)「格林德瓦」海拔 1,034 公尺的山中小鎮，是登上瑞士少女峰的絕佳前哨站，不過如果想來點刺激的話，絕對要安排一趟「菲斯特 FIRST 」，可以去走懸崖天空步道 First Cliff Walk 保證美到你目不暇給、高山湖泊 Bachalpsee 健行、以及乘坐刺激的遊樂設施。
2023-10-12
UX 設計領域的新人殺手：資訊架構設計最近我在帶實習生開始接手資訊架構的工作，相對於用戶研究的工作，資訊架構的設計規劃工作可以說是新人殺手。
我聽過剛入行的設計師困惑的跟我說：「wireframe 不就是沒上色的介面設計嗎？」
殊不知，許多剛入行設計師規劃的介面與流程被工程師刁難、被 PM 亂改、魔改了十幾個版本之後才發現沒辦法開發，原
2023-01-11
資訊與價值分不清，銷售註定會失利與人溝通這件事情，往往最大的難題在於「我們很難快速得知客戶在想些什麼」，唯有透過「提問」才有可能逐步的了解眼前這位客戶。
而如何讓提問有效，我們一定要嘗試站在客戶的角度思考，他今天前來諮詢「最想要獲得什麼」。
如果你常困擾銷售的問題，納悶自己明明都有把資訊，正確的傳遞給客戶，但為何最後總無法將商品順
2022-09-26
【ISO 45001系列】 制度架構-溝通制度與文件化資訊的保存制度有了上到下的教育訓練，自然少不了下到上或是水平單位、對外單位的溝通制度，本文提供了內部溝通方式的具體做法與建議。而做得這麼辛苦的管理系統，一定要把成果以及面臨到的問題保存下來，之後這些文件化的資訊肯定可以派上很大的用場，本文這邊也整理出來整個ISO 45001條文裡面有對應要求文件化資訊的內容。
2022-04-19
Web3.0是什麼？從「資訊和價值交換」的角度來觀察從2021年開始就很頻繁地聽到「Web3.0」這個詞，也看了不少大佬和媒體的解釋，大概的說法是這樣：
Web 1.0的時代，網路大體上使用來讀的，一個一個網站像佈告欄一樣單向提供資訊給大家。
Web 2.0的時代，大家可以輕易的互動交流，但是必須依附在某個平台上，平台越來越大漸漸侵蝕到個人權益。
2022-03-23