產品經理 PM 第 3 講:如何開始一個改版專案

0

文/ Iris Chen

在我數位產品經理 PM 職涯中,少說帶過數十個數位產品開發專案,其中九成都是網站平台改版。

打造一個全新數位產品和針對既有產品進行改版,專案的啟動(project kick-off)方式有所不同。

一個全新的數位產品規劃,需要更往前思考,分析目標的市場/競爭者/使用者等不確定因素,思考全新的商業模式的各種可能性,會花較多的前期評估企劃。當然也可能採取精實創業 lean startup 模式:直接做就是了,上線撞牆後再來調整。

改版專案通常有較明確的方向以及待解決的問題。原因可能是系統老舊、UX 使用者體驗設計不良、公司業務調整擴張或打造新功能整合等。

以目前產品設計潮流以及因應技術更新快速,約略 3~5 年就會進行翻修大改。當然市面上也有許多知名網站已經存活 10 多年未曾改版,往往是因為系統架構過於龐大、程式邏輯複雜、加上開發的工程團隊已經不知道換過幾輪,改版茲事體大、牽一髮而動全身所以沒人敢動(我曾接過這種案子),所以就還是繼續撐著疊床架屋吧。

在剛接改版專案時,我所做的第一件事情,便是依照 產品經理 PM 第 2 講:從頁面拆解練習 IA 資訊架構(Information Architecture),把既有網站平台拆解後列出資訊架構與主要功能。有些客戶會提供數年前的規劃文件參考,但通常既有版本上線後,數年間也會不斷進行功能調整,許多功能已經和原本的規劃設計不符,因此我通常不會參考這些文件。

列出既有網站的資訊架構後,會對網站全貌有清楚的認識。在同時以外部人員視同一般使用者的身份來看,過頁面時也會發現許多 UX 上的問題。此時可以一一記錄下來。

接下來,進行需求訪談。通常會有幾種狀況:

A:解決既有問題類型

有些客戶非常熟悉數位產品經營,能有條理的列出改版目標與所需修改的問題。但這種客戶可遇不可求,大部分是客戶敘述的非常模糊或者只有概念性的問題。這時候產品經理需要一些技巧來引導發掘問題。我通常把它稱為「聊天」階段:

「我們使用者反應網站很難用,會迷路 」

「是那邊難用呢?可以示範一下嗎?」

「搜尋找資料都找不到… 」

「通常是輸入哪些關鍵字呢?你期待的搜尋結果是什麼呢?」

這其實是基本的用戶訪談技巧,目的是把許多抽象的描述轉化成具體的問題/流程/邏輯敘述。這個概念有點類似敏捷式開發裡的 User Story 自然語言敘述:

身為一個家長,我想要找住家附近的學校,這樣我可以瀏覽這些學校的評價。

(但我們這篇不談敏捷式等開發流程)

因為時間關係通常不會寫這麼多字,而且如果可能,我會嘗試把模糊字詞當場討論確認,例如:「什麼叫做附近的學校?」也許程式邏輯是 GPS 定位住家附近 20 公里,或者輸入設定同一行政區。只是這樣直接列出解法通常有風險,所以只當筆記附註參考。因為對使用者而言,所謂的「附近」往往只是一種感覺,有人的附近是希望走路可到、有人覺得開車可到、有些人要比較學區限制…等。如果有需要,還要做進一步的用戶訪談或測試釐清,這些可列為後續的「待辦事項:釐清住家附近學校的定義」。

而由於先前已經先把資訊結構列出,所以很容易依序引導客戶提出並立刻歸類各種需求描述。這樣的訪談過程約 1 小時至半天不等。

B:目標導向類型

除了上述直指需求問題外,有的改版專案會清楚列出欲達到的目標。例如我遇過這幾種:

「增加新會員註冊 2 倍成長 」
「推出讓 SaaS 客戶覺得 WOW(驚艷)的功能 」

這些目標往往意指新功能的推出或者既有功能優化,需要廣泛創新思考各種作法可能性。

假設我們的目標為「增加註冊 2 倍成長」,從產品經理角度來看,我們會先把新會員獲得(acquisition)等行銷宣傳策略放一旁,而專注於產品設計本身,此時可使用 HMW 發問技巧來思考:(How might we)我們如何將導入的流量轉化成新會員註冊?

在數年前規劃親子天下改版時,我們就設定了媒體網站上幾個會員轉換門檻:投票、測驗、文章兌換,以及觸發動機:遊戲化機制 Gamification 親子幣點數累積。從這樣的想法出發再延續到完整的互動流程動線、CTA(call-to-action)UI設計,會員數據定義與收集、點數換算與後台管理等一連串的機制設計。

C:不知道問題在哪裡的類型

這樣的改版出發點也滿有趣的。客戶覺得好像應該要改版、隱約覺得應該有問題要解決、應該可以做得更好,但又不知道要改什麼、或者怎麼做比較好。

這時候會有比較全面性的訪談。包含公司各相關部門(stakeholders)、外部使用者訪談等,從中彙整出需求列表,設定改版目標,並配合公司策略方向排定優先次序等。

數據分析以及使用者訪談

在改版專案進行前後,也需檢視既有數據資料、並視需要安排各種使用者研究。而在進行大改版之前,如果時間充裕狀況下,有時我會建議幾個重要頁面或使用流程先做幾輪小優化、將數據調至滿意後,再以此為基礎進行大改版。

有時既有版本的數據追蹤碼埋設不夠完整,能提供的分析資訊不夠,會建議先將既有版本的埋碼補上,等有清楚的數據資料再進行改版。

當然如果既有網站問題非常明顯,例如有些功能流程使用者早已抱怨連連,就直接對症下藥進行,簡化數據分析以及使用者訪談階段。

特別一提的是,既有數據分析僅能分析既有使用行為、從中發掘目前遭遇的問題。如果新改版的目標在於擴大市場或是創造新使用行為,既有數據較難以反映出此方向。

專案 Kick-off meeting簡報項目

有些公司會從 BRD(Business Requirement Document)、PRD(Product Requirement Document)、Business plan 著手一步步進行,但我個人覺得如果目標方向已經很清楚,可以儘量精實簡單處理,不要為了製作文件而努力去產出一堆文件。

▲ 圖片來源:Imaniuk on Wikimedia

當前述分析都取得初步共識後,通常會召集專案相關人員舉行 Kick-off meeting,產品經理簡報以下訊息:

  1. 既有版本的問題
  2. 改版目標
  3. 改版重點功能介紹
  4. (長程)Product Roadmap
  5. (近程)專案時程
  6. 專案成員 R&R(Role & Responsibility 角色與權責)
  7. 風險與問題分析(Risk management & Issues)
  8. 其他待議問題

當然有時還會視狀況附上以下分析:

  1. 市場分析
  2. 競爭者分析
  3. 使用者分析
  4. 數據分析
  5. 商業模式描述
  6. 成本與收益分析

接下來就進入專案規劃開發流程。

§ 產品經理系列文章

產品經理 PM 第 1 講:專業能力
產品經理 PM 第 2 講:從頁面拆解練習 IA 資訊架構(Information Architecture)
產品經理 PM 第 3 講:如何開始一個改版專案
數位產品經理的一天 — 在雲端管理跨國產品開發團隊
數位產品經理的一天 — 以美國大型證券商交易網站為例(奶爸老喬的矽谷觀察 Silicon Valley Old Joe)

§ 如果您對數位產品經理相關內容有興趣,歡迎加入Facebook【數位產品經理不想公開的秘密 】私密社團

※ 與作者面對面交流討論,歡迎參加 2018/08/31 產品經理實務研討:
http://edu.userxper.com/pm2018/

授權來源:產品經理 PM 第 3 講:如何開始一個改版專案

Share.

About Author

vide 編輯群

Leave A Reply