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

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

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

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

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

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

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

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

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

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 的範例

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

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

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

協助建立網站內容 Metadata 的結構化資料標記工具

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

使用 Google 結構化資料標記協助工具,練習拆解 Metadata

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

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