前言
原本想用「重構 (revamp)」這個詞，但查了一下，發現前端畫面的重新設計叫做 “redesgin”、後端程式碼的重新編寫叫做 “refactor”，不曉得如果是整個系統前端後端都大改，應該怎麼稱呼才合適。
但先不管，先來看看比較基礎的名詞解釋：
“Redesign” is…
a process of reinventing and rebuilding a product. It significantly changes the user experience — the way it looks works and makes the user feel.
re-creating a product or making significant changes to it that changes the user experience.
“Refactor” is…
a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.
a process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.
我在每間公司聽到大家對於「產品大改版」的稱呼都不一樣，雖然 chatgpt 說可以用 “revamp”（或者 ”rebuild”）、雖然現職公司的大家都是用 “revamp” 稱呼大改版，但在網路上沒有查到很多文章會用 “revamp”，所以標題與接下來的內文就先用比較白話的「大改版」來統稱「畫面重新設計+程式碼重構」的大專案。
為什麼要改版？
1. 業務考量 (Business concern)
比如業務成果不太好 — — 整體點擊率太低或轉換率不高、產品想要拓展到新市場等，進而需要產品做個整體的大升級或大改造（所以通常會搭配 2. 一起），以便給人耳目一新的感覺。
2. 美觀 / 設計 / 視覺考量 (Aesthetics concern)
比如品牌調性大變、想要傳達不一樣的視覺形象等，有時相對簡單的做法是更換文案、logo 和視覺主色，但也可能會因為整體品牌形象考量而改變整個畫面排版，甚至拿掉某些功能，所以這也可能牽涉到後端邏輯的一些改動。
3. 功能性 / 實用性考量 (Functionality / usability concern)
比如希望提升整體的使用者體驗、想根據使用者意見而進行改版或增刪某些功能等。
4. 技術考量 (Technical concern)
比如想提升載入速度、擴展產品彈性等，以便未來容納更大的容量或更多延伸需求和功能。
產品大改版的步驟有哪些、流程是什麼？
借用這張設計過程的圖。其實產品大改版的過程中，會用到的步驟也差不多是以下四個：
註：下文會把 “explore” 和 “define” 分開寫，並把右半部的橘色區塊統稱為 “execute”，且這區塊在此篇文章不會談太多（後面會解釋原因）。
source: https://www.designingbuildings.co.uk/wiki/Double_diamond_design_process
Discover
每個 PM 大概都知道：沒有 100 分的產品，即使發了幾千幾萬個版本，被人使用的產品就是一個有機體，一定有許多可以改進的地方。
在這個階段，可以先探索有哪些想要改動的東西，陸續把他們找出來並記下來。而在探索過程中，有兩件事可以特別留意：
1. 尋找對應的利益關係人，並畫出利益關係人矩陣 (interest & power)
source: https://www.solitaireconsulting.com/2020/07/stakeholder-management-using-the-power-interest-matrix/
(1) 對產品有高度興趣 + 有高度的干涉權力 (Manage closely)
→ 通常這些人既是使用者，也是最直接的利益關係人。比如頻繁使用該產品且可能會帶來更多使用者、密集使用該產品的某種意見領袖等，他們的意見通常是最需要被納入考量（甚至必須付諸實現）。
(2) 對產品有高度興趣 + 沒有太多干涉權力 (Keep informed)
→ 通常這些人是潛在使用者或已是重度用戶，所以才會對產品有興趣。他們的意見通常會較貼近真實的使用場景，對於產品改版會有蠻大幫助。
(3) 對產品沒有興趣 + 但有高度的干涉權力 (Keep satisfied)
→ 通常這些人很有可能是產品使用者的主管或者 PM 的主管，礙於位階，他們的意見通常會需要納入參考。
(4) 對產品沒有興趣 + 也沒有太多干涉權力 (Monitor)
→ 通常這些人的意見不是太重要，一般來說，可以把它當成參考即可。
2. 列出會被產品改版影響到的人或產品
雖然這件事情也可以放在上線前作，但還是建議越早準備越好！尤其如果要改版的產品跟其他產品或團隊有所牽連，更建議要提早準備，以便在最後關頭才遇到阻力，那就很可能會影響到改版上線的進度！
如果是 to C 產品，通常最直接被影響到的就是使用者本人。
如果是 to B 產品，不只是最終端的使用者，客戶也會被影響到（畢竟客戶不一定是使用者，但他是負責下決策、決定要購買該產品的人或主要窗口）。此外，有些 to B 產品還會再從其他上游產品抓資料，或者提供資料給其他下游產品，所以產品本身的改動，也可能影響到上下游產品。
以我這次做的改版來說，前端的介面重新設計會影響到最終端的使用者，後端的重構則有動到一些要回傳給下游產品的 API，且產品本身也要從上游產品抓取更多使用者資料，所以會涉及到的人與單位很多。
當時我並沒有意識到這件事，是到上線前幾天才開始清點並通知會被影響到的人 / 產品，並給予他們相關的協助（比如先提供用戶引導或新的 API 文件），因此，上線前幾天非常忙碌，每天都在加班收拾自己搞出來的殘局……
Define
1. 確認要改版的範圍與項目＆排序
在整理用戶需求時，可以開一個 google spreadsheet 並填進以下欄位：
- page/section：該功能所在的範圍或區塊。方便到時和設計與工程師討論
- title：這個需求的主題（項目名稱）
- description：列出使用者面對到的痛點和使用情境
- solution：這格不一定要寫。作為 PM，如果當下有很具體的想法就會寫，沒有的話就會先空著，先跟設計師討論再說
- raised by：這格會寫上提出這個痛點的人，以便日後追問細節或回報進度
- priority：剛開始寫的時候，畢竟能比較的對象不多，所以可能還排不出來，這可以等到最後收斂需求時再來寫
- remark：任何註解或補充資訊
2. 不要貪心
承上，列出要改動的範圍後，如果可以，先找設計師和工程師聊聊，聽聽他們的想法和建議。
比如某些地方的 UX 邏輯太複雜、某個要加上的功能要花不少時間測試，那就要評估 CP 值夠不夠高 — — 也就是改動後的成效 vs. 為此改動而付出的時間人力成本，是否有「划得來」的感覺。
以這次做的改版舉例，坦白說，第一個階段其實沒有加上任何新功能！儘管這看起來非常不合理，但團隊經過內部討論後，覺得這是最保險的決定。
原因是，當初之所以想要改版，主因是：
(1) 前端畫面太過老舊，該產品的誕生甚至早於公司的 design system，所以許多元件都是手刻，導致後續要更新或修 bug 都非常困難。這次的改版，想先把介面重新設計一次，並且套上 design system 的元件庫，而光是這個改動就已經很大了。
(2) 後端程式碼也非常老舊，已經超過 3~4 年沒更新，且為了後續的擴充性，工程師也提出想要換不同的語言重寫。
基於以上，第一階段就真的只是介面重新設計＆程式碼重寫，沒有新功能。
儘管我們已經收到超多用戶需求與抱怨，但我們也知道，得先把第一個階段完成，後續要增 / 改功能才會更有效率；而且，如果要完成介面重新設計、程式碼重寫，還要增加新功能，估時會再多出好幾個月。
依照以往經驗，一個專案的時間拉越長，過程與結果就會越不可控，比如半路會殺出新需求、工程師可能做到一半被其他更緊急的專案抓走等，為了不要讓變因增加，最後決定把第一個階段的改動範圍定為 “MVP”，也就是新版產品的功能不會比舊版少，但也不會更多。
Explore
列出要改動的項目後，再來就是開始探索各種可能性，也就是尋找對應的解法。像我就在這次改版中嘗試了三種常見方式：
1. 質化：使用者訪談
有些人的疑問可能是：使用者那麼多，搞不好大家的意見都不一樣呀，那要問幾個才夠？根據個人經驗，儘管使用者的意見真的很多元，但累積到一定樣本後，大家提出的內容還是會有分大宗熱門款 vs. 冷門情境款，也就是說，還是能稍微做出分類的！
至於一定樣本到底是多少？可先根據訪談原因 / 目的把使用者分類，每種類別的用戶建議至少一定要訪 1 位，多則可以 3 位。
比如在前公司（線上學習平台）做訪談時，我們想了解訂閱者的學習習慣，當時就把訂閱者的訂閱主題分成幾類，比如財經、語言等，每類各訪幾位。
在現職公司時，我在去年底接了一個內容翻譯平台的大改版專案，為了更了解使用者的日常操作流程與背景，就根據使用者在平台上的角色（比如有開發人員、內容翻譯人員、內容審核人員等）將他們分類，每類各訪了 2~3 人，總共訪了 10+ 個使用者。
事實證明，後來收集到的資料，對後續的優化和改版也有非常大的幫助，一來是更了解他們的使用背景、最常用哪些功能、意想不到的使用習慣與痛點等，二來則是在做產品決策時，這些使用者的量化或質化數據都能作為很有利的依據。
2. 質化：競品研究
使用者的想法與使用數據對於產品決策有很大的影響，但如果數據不足、想要更「均衡」地參酌更多意見，參考競品也是很好的方式！
有時在看競品時，自己的思考也會隨之被刺激，會想說：為什麼他們（競品公司）要這樣設計、而不是那樣設計？為什麼他們沒有這個功能？為什麼他們要把這個功能放在這麼顯眼的位置……等，是個很有趣的動腦過程，也可能在思考過程中激發出不同的想法。
很多網路文章的標題都會寫「xxx 從模仿開始」，雖然這個句式已被用爛，但不得不說，還真好用，很多時候也確實有其道理……
只是做產品不能只是模仿，還要有個好的理由。總不能每次都說「競品這樣做，一定有他們的理由，人家都可以長成那麼大的公司了，那我們就照抄 / 模仿就好」，而是要在「模仿 / 參考」的過程中，萃取出適合自己公司的產品文化與調性的部分，把它揉合成更適合的形狀。
3. 量化：收集過往使用數據
改版有點像是居家大改造，不只得把不好的動線（不夠直覺的功能或使用者介面）與過時或過醜的裝潢（老舊或不合時宜的介面、排版或文案）打掉，也得斷捨離，把冗餘的傢俱或日用品（太冷門的功能或奇怪的系統邏輯）丟掉。
但到底什麼能改、什麼不能改？哪些功能必須保留、哪些有待商榷、哪些非改不可？
「使用者訪談」可以給出很多答案，但畢竟樣本有限且耗時甚多，所以在此侷限下，有時侯直接撈數據可能會更實用。
延伸前面的例子，我當時在規劃內容翻譯平台的改版時，很不幸地，因為沒有太多使用數據可以參考，所以多半還是仰賴使用者訪談，才能拼湊出整個產品被使用的情形。
但當然！還是有些小地方可以靠數據做判斷，小至畫面上的每個欄位應該要多寬、上限要放多少字，大至每個翻譯專案的使用者數量上限應該要設多少等，至少團隊還是能找到這些基本數據，這就讓設計師在規劃改版時更有參考值。
比如說，數據告訴我們：每個翻譯專案名稱的字數平均為 25 字、中位數為 28 字、最大值 98 字，那這時如果設計師僅是基於美觀考量，而想把翻譯專案名稱的顯示字數改為 15 字，那顯然是不行的，因為一半的用戶都會超過這些數字，影響範圍太大，且這些名稱可能也包含某些重要的參考資訊，如果只是因為「顯示太多字數，會讓版面看起來很擠」這樣的理由，想必使用者會很難被說服，且也不夠貼近他們的使用習慣。
Execute
大改版的一開始得先經過各種迷茫與探索，接著好不容易定義出要改版的範圍與待解決的問題，再來則是透過質化與量化數據找出對應的解法。到了這個階段，終於可以進入設計與技術實作了。
一般來說，在這個階段時，產品經理的主導場合可能沒有前三個來得多。至少以個人經驗來說，這邊比較是設計師與工程師的主場，產品經理屬於「給意見」、「選擇最終解法（給出最終決策）」的角色，所以這一段的篇幅就不會太多，有興趣了解更多的話，可以參考以往這幾篇文章：
〈如何改善產品？功能優化怎麼做？step 5：wireframe〉
〈如何改善產品？功能優化怎麼做？step 6：mockup〉
比較值得一提的時，因為大改版的改動範圍不小，如果怕使用者對於新介面或新功能太不熟悉、不確定這樣改適不適合，可以在設計出 wireframe 或 mockup 之後，多花時間做個 prototype，再去找之前參與訪談的那些使用者實測，也就是做一場 “usability test”（易用性測試）。
關於「易用性測試」，網路上有更多專業文章可以參考，這邊就大概講一下：易用性測試的目的就是找真正的使用者來操作新版的介面，主訪者（設計師與產品經理）可以根據使用者以往的使用情境，出一個對應的任務，請使用者完成對應的動作，而主訪者的職責就是觀察並瞭解使用者在這個過程中說了什麼、遇到什麼困難、有哪些問題、感覺如何，進而再去優化新版介面。
比如要做 ig 的易用性測試，可能就可以請使用者完成「上傳限時動態」、「張貼一則帶有 5 張圖片的貼文，並且標註地點」、「搜尋 Elon musk 的最新一篇貼文，並在下面按讚與留言」等任務，藉此觀察使用者有沒有在哪邊卡關，或者在哪些流程展露了什麼情緒。
其他意想不到的事
上面說的四大步驟就是產品改版的「基本流程」，走完了基本流程，還有很多「進階流程」要留意，但因為這和產品種類有很大關聯，不一定能應用到所有產品，比如：發現很多被其他用戶擅自取用的 API、改版到一半被告知要搬家到其他的雲端去部署、臨時被某個大牌用戶改死線，最後加班把產品趕上線……等，這些都是我在這個大改版專案遇過的突發問題……總之因為這些比較算是個案，也很難以單一通則去解決，所以就不寫太細。
結語
這篇文章寫於 2023 年 5 月，算是記錄了自己在 2022 Q4 到 2023 Q1 在忙的專案（之一……），雖然之前在現職公司也接過大改版的專案，但規模沒有這次大、時間沒有這次長、死線沒有這次緊、利益關係人沒有這次多且龐雜，所以這次做起來又更辛苦了一點，但當然也學到了很多。就以這篇文章做個簡單的紀錄和分享吧。
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
