這系列文章的命題是：當把產品做完後，不管是已改版多次還是 MVP，只要是產品，永遠有變得更好、持續進步的空間，但要如何改善呢？該從哪裡下手呢？
以下整理了一個概略的產品優化流程，會在接下來的文章中細講每個步驟。
經過重重關卡，終於到了「繪製 wireframe」這個步驟。前面提的都是如何收集問題，並且把問題「翻譯」成為產品需求和功能，再來就是要將這些需求透過畫面具象化了。
什麼是 wireframe？
“wireframe” 大致上翻譯為「線框圖」，可以把它想像成是一個產品設計的「草稿」，就像小時候班級出去寫生時，會先用鉛筆畫個草稿，再用水彩或其他顏料上色，那個「草稿」就是 wireframe，目的是先勾勒出目標對象「大概的長相」。
更多介紹可以參考這兩篇文章：〈Wireframe是什麼？認識網站UI設計排版草圖與資訊架構〉、〈什麼是 Wireframe ?〉
為什麼要畫 wireframe？
以我自己的實務經驗來說，並非在每次的產品迭代過程中，都一定會準備 wireframe。wireframe 的目的是具象化呈現改動後的介面長相，藉此讓需求端確認是否符合他們期待、讓 UI 設計師依此準備 mockup（更擬真的畫面）、讓工程師知道畫面初步會長怎樣，甚至能依此先做對應的準備或評估，確認其可行性。
這邊一再提到「長相」、「畫面」，就代表 wifreframe 其實是跟前端的操作介面有連動關係的，比如想在 landing page 的 footer 加上「聯絡我們」的連結、想在 app 裡的註冊畫面中，加上「現在註冊就送 $100 購物金」的文案、想改動網站整體的色系等，這些都是和「畫面」或「產品的長相」有關，wireframe 就能扮演著「示意圖」的角色，方便團隊以此作為討論基礎，也能確保大家對產品有共同的想像。
反之，如果產品的優化與畫面無關，而是要更改後端的邏輯 — — 比如想更改使用者的權限、想將某個 IP 加到黑名單、想調整允許用戶上傳的檔案上限……等，這些不一定在前台有對應操作畫面的使用邏輯時，其實就不太需要準備 wireframe，只要跟工程師直接溝通就行了。
PM 也要會畫 wireframe 嗎？
在確認產品需求後，該由 PM 還是設計師繪製 wireframe 呢？
以個人經驗舉例，如果作為 PM 的自己對於畫面有很清楚的期待 ，就會直接先準備 wireframe 跟設計師討論。
比如某次在做後台工具時，我認為這個工具型產品將會隨著未來一次次的優化，包含越來越多功能，所以希望介面是以左右欄方式呈現（如下圖左），左邊是 side bar，右邊是主畫面，這樣 side bar 裡面的功能選單會比較一目了然，擴充性也比較夠；若是用上下方式呈現（如下圖右），上面有一排 navigation bar，下面是主畫面，在選項太多的情況下，就難以一次看到所有選項。
當時有了這些想法後，我就直接先畫一版 wireframe 跟設計師討論，目的是希望成品不要離我的期待太遠，設計師再以此去出 mockup。
但也有時候，我對於畫面雖有大致的想法，但不太有自信，且相信設計師會有更好的解法，所以就不會準備 wireframe，反而怕這樣會限縮他們的想像。
如果組織沒有太明確的分工，PM 通常可以先和設計師聊聊，先了解對方的工作習性與個性後，再決定由誰負責 wireframe。
有些設計師很需要發揮空間，在不受限的情況下，反而可以激盪出更好的點子，那基本上就可以請設計師準備 wireframe 了；有些設計師想先了解 PM 的期待，以免自己想了一堆點子，但最後都被打槍，那 PM 就可以先準備 wireframe，讓設計師知道自己的想法。
像我在前公司時，差不多就是用上述方式決定自己是否要準備 wireframe。不過來到現職公司後，因為設計師另外屬於設計部門（我跟工程師則是屬於是開發部門），且有分 UI 和 UX 工程師，加上內部產品有更多負責的邏輯與動線要先規劃（詳情可見〈負責內部產品（Internal Product）的 PM 都在幹嘛？跟 to B/C 端產品有什麼不同？〉），所以 wireframe 包含的不只是示意圖，更重要的是使用流程、操作邏輯和動線。既然 wireframe 變得如此龐雜又關鍵，自然就得交給專業的來，所以現在都是由 UX designer 畫 wireframe 了。
不過，也不用把「繪製 wireframe」這件事情想得太嚴肅，它只是流程的一部份，目的是讓團隊能更清楚溝通、站在同一個立基點，所以不要拘泥在「誰」畫 wireframe，這並不是重點，wireframe 本身的內容才是最重要的。
常用的 wireframe 工具
wireframe 的呈現有很多種方式，我用過手繪（就真的是拿原子筆畫在 A4 紙的那種）、在 word 裡拉表格、在 ppt 裡用各種圖形工具，甚至用過 windows 的小畫家和 mac 內建的影像編輯工具，也用過 figma 和 whimsical。目前操作下來，最慣用的還是 whimsical 這套免費的線上工具。
最主要是因為 whimsical 有元件庫可用，基本常用的元件還算齊全，比如下拉選單、按鈕、比如下拉選單、按鈕、toggle、radio button 等都有，畫完之後可以直接下載圖檔，也可以直接分享連結，對於處理基本的 wireframe 應該算是蠻夠用了。
不過，就像上一段說的，wireframe 的核心目標是要讓團隊清楚溝通、站在同一個立基點，所以重點並非在與 wireframe 長得多美、多精緻，工具只是其次，團隊都能習慣就好。
畫 wireframe 要注意什麼？
既然這篇的主題都是 wireframe 了，雖然我並非繪圖高手，但還是想拋磚引玉分享幾個繪製 wireframe 時，要特別留意的重點：
💡 先設定這個 wireframe 要達到什麼目的
比如：是要以此先跟需求端對焦想法？還是要以此跟設計師溝通自己對於最終 UI 的期待？還是要以此跟工程師確認技術可行性？也可能同時要符合上述所有目的，總之，要先確立目的，才會知道繪製時要留意哪些事。
- 如果是 PM 要跟需求端對焦想法
一定要強調這個 wireframe 只是「示意圖」，不要拘泥於裡面的文字大小、線條粗細等細節，重點是整體的排版與頁面上包含的功能是否符合期待。
比如 PM 用 wireframe 呈現了農曆新年的促銷活動頁，需求端要看的重點應該是活動頁包含哪些區塊（比如首圖主視覺、活動介紹區塊、主打商品區、活動備註等），以及這些區塊的順序。在這個階段，因為還沒有設計師介入，所以對於整體配色、自行、文字大小等，基本上都還不用特別討論。
- 如果是 PM 要跟設計師溝通自己對於最終 UI 的期待
這就看 PM 有哪些「期待」了，比如：版面配置（要左右欄還是上下欄）、UI 元件（希望按鈕是空心還是實心、選項是多選的 checkbox 還是單選的 radio button）、資訊的先後順序（哪些資訊要放在第一屏，哪些塞在 footer 就可以）。
只要是自己已有很明確想法的部分，都可以在這階段先提出，讓設計師能提前思考規劃。但當然自己也要在心中劃下期待與界線：對於 UI，基本上設計師有最終決定權，他們也有更專業的眼光和經驗能做出判斷，PM 只是提供建議，要小心不要變成控制狂了。
- 如果是 PM 要跟工程師確認技術可行性
如果是跟前端工程師溝通，通常他們比較會著重在畫面本身，比如怎麼排版、桌面版跟行動版會不會有差、小螢幕時怎處理；如果是跟後端工程師溝通，他們對於畫面的長相通常不會有太多意見（畢竟那是前端職責），但對於相關的操作邏輯和資訊運算就會有較多建議。
比如今天要在頁面上做一個搜尋功能，PM 可能只是想知道「我們的產品能否做出搜尋功能？如果可以，要花多久才能做完？」，並依此準備了 wireframe 想跟工程師討論。
接著，前端工程師可能會問：搜尋 bar 要放在哪？要用什麼形式呈現搜尋結果頁？搜尋結果是要點選 load more 還是自動載入？若沒有對應的結果，空畫面要長什麼樣？後端則會問：要搜尋哪些資訊（用戶名字、email、還有什麼？）、怎麼比對（部分符合就出現？還是要全部符合才出現？）？一次要顯示多少筆搜尋結果？
有些問題算是比較細（比如空畫面），但有些確實是在一開始就得討論（上面列的，除了空畫面之外，其他都算是蠻基本的），才能確認雙方對這個功能的認知沒有差太多，畢竟功能的複雜度與開發工時有很大的關係。
如果每個人都對 wireframe 有意見？
完成 wireframe 之後，一定要跟需求端確認這是否符合他們的期待，也要跟實作端（設計、工程師）確認是否可行。
不過，在這過程中偶爾也會出現大家都各有意見、找不到折衷的情況，比如文字可不可以再大一點？按鈕要空心還是實心？整個排版應該要置中還是置左？這時，如果沒有數據可佐證，也沒有人有足夠的決定權的話，建議還是交由使用者來決定，畢竟他們才是真正在使用產品的人。
比較簡單的做法是，可以請設計師準備較精美或整齊一點的 wireframe（有時可能需要直接準備更擬真的 mockup 或 prototype 了），請公司其他同事直接使用，藉此收集大家的意見。
若是更嚴謹的做法，也有人會設計一份完整的測試問卷，並且直接寄送給真實用戶，不過這個時間成本非常高，得先衡量相關效益才行。
等 wireframe完成、大家終於都達成共識後，就可以準備進入 mockup 繪製的環節了！
