這系列文章的命題是：當把產品做完後，不管是已改版多次還是 MVP，只要是產品，永遠有變得更好、持續進步的空間，但要如何改善呢？該從哪裡下手呢？
以下整理了一個概略的產品優化流程，會在接下來的文章中細講每個步驟。
什麼是 mockup？
如果說 wireframe 是寫生時的鉛筆草稿，mockup 就是上完顏色後的完稿。在產品開發的流程中，通常都是「需求凍結」後，UI 設計師才會依照 wireframe 去繪製 mockup。更多資訊可以參考這篇文章〈初學者的 Mockup〉。
如果處在 UX 設計師和 UI 設計師有明確分工的組織，可能會發現這兩者乍看分工明確（UX 負責邏輯、UI 負責畫面），但其實又難以完全拆開。
比如 UX 今天想用呈現一個「選擇題」的功能，wireframe 上面會有題目、題目敘述與選項，那選項應該要是單選還是複選？有沒有限制只能選幾個？如果有限制，那超過限制時，會跳出什麼警告文字？
UX 想好這些邏輯後，會作出對應的 wireframe，而 UI 的工作之一，就是要把 wireframe 變成高擬真的 mockup。但在製作的過程中，通常設計師們會有一套 design system，這其中包含字型、字體大小、顏色、各種元件樣式等，有些公司甚至會規範到文案規則與模板（UX 的 microcopy）。
有時因為有些元件不在原有的 design system 裡，或者長相略有差異，或者 UI 設計師有其他想法（畢竟「基本上」UX 負責邏輯、UI 負責畫面，美感部分通常由後者決定），這會使得 UX 設計師準備的 wireframe 不一定能 100% 直接做成 mockup，所以等 mockup 完成後，一來是讓 UX 設計師對照哪些地方和 wireframe 不同，二來也讓 UI 設計師能和 UX 設計師說明改動的原因。
但基本上，wireframe 已是第一層把關，到了 mockup 通常不會有太大修改。尤其如果是 UX 和 UI 徹底分開的話，很有可能 UI 設計師就是照著 UX 給的 wireframe 去出 mockup，落差通常不會太大；但無論如何，在設計流程中，仍然需要 UI+UX+PM 三方的密切合作與溝通。
為什麼需要 mockup？
可能有人會問，既然上一段說 wireframe 和 mockup 不會落差太大，那為什麼還需要 mockup？以下試著用 2 種面向來說明：
- （對內）確保產品介面是團隊做得出來且易於維護的
一般來說，wireframe 比較像是草稿，另外加上一些使用邏輯或操作案例的處理；mockup 則是已經近似於完稿了（幾乎只差在不能點擊使用而已）。
也就是說，等產品真的做出來後，大家也會用 mockup 去對照，確保當初規劃的 vs. 實際做出來的長得一樣，小至字體顏色是否一致、置中置左置右是否一致，大至頁面排版是否有遵照 mockup 示意圖、視窗縮放時是否有依照流變規則等。關於這些細節，都是在工程師實際開發前需要確認的。
此外，對開發與產品團隊而言，mockup 上面的任何元素都要是「技術上可行的」。不過，就像上面說的，wireframe 已是第一層把關，設計師通常在這個關卡，就會先跟工程師確認各種技術可行性，所以到了 mockup 時，通常不會有太大修改。
但當然偶有例外，以我自己遇過的案例來說，之前碰過有些網站要做 RWD，但 UX 設計師在準備 wireframe 時，不太會去仔細定義這些 responsive 規則，而是留給 UI 設計師在 mockup 仔細定義各種規則，所以mockup 在這裡就是「讓 UI 設計師和工程師更方便討論各種技術可行性」的關鍵。
- （對外）確保產品介面能提供良好且一致的使用者體驗
若要粗淺定義「設計」的必要性，一是得好用（易用性高），二是得好看（美感佳）。
然而「是否好看」很主觀，但「一般情況」下，如果公司有由專業設計師定義一個 design system，規定 logo 怎麼用、相關色票、哪些情況該用哪種字體、字級的各種應用情境等，「通常」成果應該不會太差，畢竟 design system 通常不會由一人去建立，而是一群設計師集體完成與維護，集眾人智慧（且這個「眾人」是「設計師們」）的結晶，應該不會太糟糕。
退一萬步說，即使真的有點糟糕，但 design system 至少能確保一個產品在不同頁面或區塊上，仍能給人同一種風格、樣式和感覺。比如 logo 有個固定大小，不會從首頁跑到下一頁後，logo 就突然變色或變超大；超連結有固定的樣式，比如固定都是藍色搭配底線，不會突然變成鮮紅色加粗體。
design system 的目的，對內是減少工程師與設計師做重工，對外是讓產品有一致性，甚至進而塑造一種「品牌感」。比如當你在使用 Google 旗下的 gmail, chrome, google calendar, google map 時，應該會發現他們的 app icon 都有類似的顏色，而 web/app 介面本身也有類似的風格，比如字體或按鈕長得一樣等。
PM 拿到 mockup 後，要注意些什麼？
上面介紹了 mockup 和它的用途，最後講一下作為 PM，在拿到 mockup 之後，可以做哪些事。
如果是和設計師有比較「正式」的合作關係或流程，通常在 UI 設計師完成 mockup 之後，PM + 設計師（UI & UX）會有個 UI design review。目的是確認 UI 給出來的 mockup 跟 UX 準備的 wireframe 沒有太大落差，以及如果真的有不一致的地方，雙方該怎麼解決。
在 design review 時，除此之外，PM 需要注意的部分有：
- mockup vs. wireframe 有沒有地方不一致
- mockup vs. 目前正式環境的畫面有哪些不一致、是否符合當初所溝通的範圍
- mockup 裡面有無跑版或錯字
- mockup 有無缺漏任何細節，如：空狀態、錯誤處理（比如用戶在寫意見回饋時，沒有填寫必填欄位，那當用戶按「送出」的時候，系統要怎麼處理？）、極端案例等。
結語
老實說，轉職當 PM 以來，看過的 mockup 應該不算少，但儘管每次都覺得自己很仔細了、想過很多操作可能性了，最後都還是會有漏掉的部分……經過這些經歷，覺得「細心」跟「經驗」還是最重要的，真的是沒有捷徑。
「細心」能讓 PM 在宏觀大局之餘，也可以兼顧每個小細節 — — 每個按鈕、文案、操作邏輯等，「經驗」則是讓 PM 能從較普遍的用戶行為中，抓出一些極端的特殊案例，並作出對應的處理（看是要補畫面，還是不處理，或者用其他方式解決）。
