數位產品幕後:從 header 改版開始的《報導者》網站開發之路 2.0

Ivory Chia
報導者開放實驗室
12 min readOct 29, 2021

--

你有發現《報導者》網站的 header 好像不太一樣了嗎?

《報導者》的產品開發團隊在 2021/10/12 進行了 header 改版。這篇文章想跟大家聊聊新版與舊版的 header 到底差在哪裡、在眾多項目之中我們為什麼選擇從 header 開始,以及作為《報導者》第一個產品經理,在開發過程中的心路歷程。

💡註:2021/10/27 品牌重塑專案相關的調整也上線了!《報導者》的 logo、字形都有了很大的變動,未來也會在報導者開放實驗室 medium 分享,敬請期待~

新的團隊組成:《報導者》的第一個產品經理

2021 的下半年,《報導者》數位產品開發團隊迎來了巨大的變動 — — 成立 6 年後,組織內部首次出現了「產品經理(Product Manager)」這個角色。

過去的《報導者》是其實存在「PM」的,但 PM 角色的核心內涵對應到的是數位專題的專案經理(Project Manager),守備範圍落在瞭解記者目前正在做的新聞內容、規劃數位專題時程、幫助記者發想搭配的數位形式、以及規劃後續的專題行銷方式。

然而隨著《報導者》成立的時間越久,組織成員對於數位專題也出現了不同的反思。的確,某些特定議題以數位專題作為敘事形式會更為生動活潑,也能夠帶給讀者更為沈浸且具有臨場感的閱讀體驗,但站在組織願景的角度思考,單純著重報導內容與敘事形式已經遠遠不足。

做為深度報導內容載體的「《報導者》網站」,必須承擔更多責任、並更為宏觀的以「打造與讀者之間的長期關係」為目標前進才行。

我在上述的時空背景下以「產品經理」的身份加入了《報導者》,《報導者》的數位產品開發團隊正式補齊了軟體開發需要的金三角:產品經理、工程師與設計師,各個角色的專業分工也變得更清楚,由產品經理規劃產品發展策略、重新梳理開發流程,並承擔對組織其他利害關係人溝通產品推進方向的責任。

產品開發金三角(自製,改編自 How to develop strong Engineering, Product and Design partnerships

關於 header 改版,我們做了什麼?

《報導者》網站的 header(aka 整個網站最頂部的部分)改版在 2021/10/12 上線,這也是我加入《報導者》以後和團隊一起進行的第一個產品開發。先來幫大家對照一下改版前與改版後的 header 差在哪裡:

從靜態的狀態來看,最顯而易見的地方是我們加入了「贊助」與「訂閱」 2 個行動呼籲的按鈕,同時也使用了簡單的 3 個關鍵字傳達《報導者》的理念 — — 深度 x 開放 x 非營利。

更大的差異發生在使用者在網站當中上下滾動頁面時,header 的互動效果。在電腦上的呈現是最明顯的:改版前的 header 只有單一一列,也只有使用者回到網站最頂端時才會出現;改版之後,當使用者往下滑動網頁,header 會轉為較不影響使用者閱讀的較窄的版本,並會隨著使用者的持續下滑行為完全消失。

而當使用者往上滑動網頁(也就是顯露「想要離開此刻所在的位置」的明顯傾向的時候)窄版的 header 會立刻出現,直到使用者持續上滑到頁面最頂部時,才會出現最完整的的 header。

除此之外,我們也調整了平板和手機的漢堡選單

下圖左邊是舊版的漢堡選單,點擊後選單會從頁面上方掉出。回顧當時的時空背景,設計的考量點在於「兼容讀者操作選單與文章頁的彈性」,因此即使展開漢堡選單,使用者依然能夠看到文章頁的內容,也可以使用索引、回到專題頁等文章相關功能。然而現在看來,這樣的設計其實存在明顯的問題:

  • 和主流的漢堡選單行為(從螢幕左側/右側出現,或直接蓋滿全螢幕)差異過大,讀者很容易有被突襲的錯愕感,反而不曉得該如何行動
  • 選單內容的資訊和行為類型很雜亂,沒有依據屬性分類

因此這次我們將新版的漢堡選單改為下圖右邊的樣子:點擊後召喚出的是全螢幕選單,以按鈕樣式呈現最主要的行動呼籲,並以網站的內容分類為選單核心,同時使用者也可以直接在選單當中展開議題的細部分類,更清楚地掌握《報導者》的網站內容。

由於《報導者》網站當中有不同文章版型,header 也有不同的設計!攝影分類的 header 是以深藍色為底色,至於其他使用到滿版照片的版型,則是為了兼顧影像佔滿全螢幕的視覺效果以及 header 的操作,特別將 header 調整為半透明的。

總之這次真的,設計細節很多啊(暈)

為什麼從 header 著手?

header 改版乍看之下並不是很了不起的巨大功能,為什麼選擇從這個項目開始著手呢?背後的考量有 3 個原因:

1. 舊版 header 未能成為網站使用者的「引路人」

不曉得大家在《報導者》的網站閱讀文章時,有沒有經歷過這種困擾:

文章滑到一半,想要到網站的其他地方看看其他報導,頓時發現自己找、不、到、出、去、的、地、方!必須得耐著性子滑到頁面的最上方,才會出現文章分類與選單等「出口」,有時甚至會因為文章長度太長了,還沒滑到頂端就忍不住直接關掉瀏覽器視窗。

網站的導覽體系是由不同的基本元素與子系統組成的,其中,出現在網站中所有網頁上方的 header 屬於全域導覽系統(Global Navigation Systems),在整體環境裡面扮演著「提供脈絡線索(Context)與移動選擇的彈性(Flexibility),幫助使用者了解身處何處,以及能往何處去」的重要角色。然而在原本的設計當中,header 並未扮演良好的「引路人」,這也直接影響了《報導者》網站內部動線的流暢度。

2. 《報導者》的品牌價值與行動呼籲(Call-to-action)在網站當中不夠明顯

《報導者》是什麼樣的媒體、依賴什麼樣的模式在媒體寒冬持續生存,對於長期關注我們的讀者而言已經相當熟悉,但這些問題的答案,對於初次進入《報導者》網站的新使用者而言是相當陌生的。在網路時代,注意力是最稀缺的資源,我們無法期待新的使用者會留給《報導者》網站足夠的時間,願意進一步進入「關於我們」的頁面嘗試更瞭解我們;而 header 作為整個網站曝光度最高的區域,如果能夠讓讀者進入網站之後,就能接收到 header 傳達的訊息、建立對《報導者》的第一印象,是更為理想的狀態。

3. 開發規格相對明確、成本也較低,適合作為新團隊的 trial run

最後一個原因則是基於團隊磨合的實際考量。如同前面提到的,組織中原先並不存在產品經理的角色,而我甫到職就進入 COVID-19 疫情的三級警戒🤯

在全體遠距工作,同時又存在新角色、新流程、新工具(是的,我們也在這段期間更換了新工具,從原本的 kanbanflow 搬移至 JIRA)的多重挑戰之下,我認為最重要的事情是先建立起產品經理、工程師、設計師三種角色之間的協作默契,並且透過實際快速踩過一次新的產品開發流程,找出下一步調整與修正的方式

否則如果首次開發時間拖太長,很有可能一不小心就會陷入互相傷害的窘境,也會讓新進產品經理處於很不利的開局當中。

上線之後認真 retro 了一波,很棒!

如何劃定 header 的開發範圍:那些做與不做

基於上述考量,在設計開始之初,我們就已經定義了很明確的設計方向:

  • 加入《報導者》的價值主張,以及非營利媒體最重要的兩個行動呼籲:贊助、訂閱(電子報)
  • 讓使用者能夠更容易找到前往其他頁面的「出口」,提升網站的易用性
  • 將對使用者閱讀體驗的干擾盡可能降到最低(雖然希望大家更認識、甚至進一步贊助《報導者》,但閱讀時的舒適度仍是我們最在意的核心)

這次的設計方向,其實是刻意限縮後的結果。《報導者》網站當中,還存在著一個最巨大、也最根本性的問題,不論是原本的工程師與設計師,或是新加入的產品經理,都有著高度共識認為需要被解決 — — 也就是網站整體的資訊架構

資訊空間如何規劃,才能夠使得可尋性(findability)與可理解性(understandability)達到最佳化,是資訊架構學這門學問在探討的問題;而從更具體的層次來說,前面提到的「導覽體系」只是構築資訊架構的其中一環,同時還會與其他 3 個體系搭配,共同組建出整個資訊空間,包括 (1) 將網站的資訊以各種不同方式呈現的組織體系(Organization systems)、描述每個類別、(2) 選項和連結的名稱的命名體系(Labeling systems)和 (3) 讓使用者在內容中尋找所需資訊的搜尋體系(Search systems)。

隨著《報導者》網站乘載的報導數量、類型越來越豐富,甚至在 2020 年打造出了新的聲音產品 podcast《The Real Story》,在成立之初所定義的資訊架構已經變得不敷使用,因此除了 header 坐落的導覽體系之外,組織體系、命名體系與搜尋體系都是我們心心念念想要重新設計的項目。

傳說中的資訊架構三本柱(自製,改編自《資訊架構學》

但為什麼這次只處理 header 改版,其他部分徹底不碰呢?

除了團隊磨合 trial run 的實際考量,也因為《報導者》的產品開發團隊人力有限,掌握小增量、多迭代的敏捷精神極為關鍵,一方面可以達成「有效運用有限資源」的效益,另一方面也才能夠持續提供給讀者有價值的交付。(當然,對於組織內部過往並不存在產品經理角色的《報導者》而言,敏捷開發還需要歷經多次實戰操演,才能夠穩定落地。)

不過正如同設計師有時無法克制追求使用體驗極致完美的心情,產品經理有時也難以壓抑「想做大事」的衝動。這次 header 改版的過程中,我所用來框定自己的方式,是設定 non-goals

產品經理必須先定義清楚的目標,再進一步進入解決方案的思考,這點對於熟悉軟體開發文化與流程的人而言並不是新鮮事;但值得強調的是,在定義 goal 之外,設定 non-goals 也同樣重要 Facebook 的 COO 雪莉・桑德伯格(Sheryl Sandberg)對於 non-goals 的定義是:「只有在主要目標達成之後,員工才應該關注的次要目標」,而為了框定 non-goals,Facebook 內部會使用非常無情的方式進行優先級排序,進而讓員工判斷在有限的資源之下應該先被放置在一旁的項目。Facebook 尚且如此,對於《報導者》這樣的小團隊來說,non-goals 的存在就顯得更加重要了。

此外,在《報導者》內部,設定 non-goals 也是一種提升溝通透明度、管理利害關係人期待值的做法。組織裡面匯集文字工作者與軟體開發者兩種不論工作型態、思維模式都截然不同的專業,是所有數位原生媒體都會遭遇的狀況,由於前者對軟體開發並不理解,產品經理、UI/UX與工程師很容易被視為無所不能的魔術師,產品開發過程也時常乘載超量的期待,因此在一開始就明確點出什麼是目標、什麼不是目標,會更有效地讓利害關係人理解開發範圍的侷限,並進一步拉齊利害關係人的認知,提升組織內部不同職能之間的溝通順暢度。

判斷做與不做在軟體開發中是一門藝術。對於產品經理來說,最困難的不是打造完美的產品,而是如何在反覆的溝通與取捨之中,打造出「剛剛好的產品」。

《報導者》網站的下一步:資訊架構大改造

完成 header 改版之後,接下來就要朝著那些還沒做到的事情繼續前進了!

下一個目標會著重在資訊架構當中的「組織體系」、「命名體系」,希望透過重新定義《報導者》網站的內容分類,回應絕大部分讀者進入網站之後以議題類型為核心的資訊需求,幫助讀者更容易找到自己感興趣的內容,同時達成讓記者們嘔心瀝血產出的報導更容易出現在讀者眼前的效果。

在組織內部推動已經行之有年的資訊架構改造是困難的,我個人認為這件事的難度甚至超越開發一個獨立的新產品。這裡所談到的困難並不是指工程層面(當然在開發上可能需要翻掉許多既有架構,工程師大概也會因此滿崩潰的…😶),而是組織內部的溝通與共識建立。

畢竟編輯、記者、攝影、行銷,乃至於產品經理、設計師、工程師,都有著自己的立場和角度。在 UX 領域有許多輔助資訊架構的設計的方式,最典型的做法是藉由 Card Sorting 和 Tree Testing,在過程中觀察使用者理解和組織資訊的邏輯,尋找當前設計的可能解決空間,並驗證網站設計者所假想的資訊分類是否真的與使用者的認知相符。

等到下一個階段完成後,再寫 Medium 跟大家分享囉!

給點意見回饋吧!

如果你喜歡這次的《報導者》 header 改版,請幫我們拍拍手 👏 也歡迎在下方留言回饋。

能夠真正解決大家使用《報導者》網站時的痛點,就是對《報導者》產品開發團隊最棒的打氣了。

產品開發小團隊 ♥
📣有你,才有《報導者》

《報導者》秉持深度、開放、非營利的精神,透過讀者的贊助支持來營運,不仰賴商業廣告置入。如果您認同我們的理念,歡迎與我們一起前進,共同推動這場媒體小革命。

贊助我們:https://bit.ly/3ylK401

官方網站:https://bit.ly/3rTeR1V
粉絲專頁:https://bit.ly/37jjGYD
Instagram:https://bit.ly/3rWFQJV

--

--