功能都做了卻被嫌難用？因為你的Wireframe只是利害關係人的許願池！
◆ 滿足了需求，再來說「難用」
很多 PM 在畫 wireframe 的時候，腦袋裡同時要應付很多聲音：
老闆說：「這裡幫我放一下最新活動。」
營運說：「最好這邊有一個 banner，可以主打檔期。」
客服說：「會員常問這個問題，要幫我放連結。」
業務說：「客戶要一進來就看到這個數字。」
你很努力，把每一句話都「尊重」地放進畫面裡。
區塊一塊一塊堆上去，按鈕一顆一顆加上去，
最後從需求的角度來看，好像也沒哪裡錯。
直到上線驗收，大家開始說：
「東西都在，但就是很難用。」
「我每次要找那個功能，都要找半天。」
「畫面好擠，看了好焦慮。」
這時你才發現，
你其實不是在設計一個頁面，
而是在蓋一個「所有人都想要投幣」的許願池。
◆ 先滿足「聲音」，還是先滿足「使用者」？
現實一點說，多數專案一開始，都不會從「UX」出發，
而是從「誰的聲音比較大」開始。
PM 很容易被迫做出這樣的排序：
先滿足老闆、客戶、營運、業務、客服，
最後才輪到真正使用系統的人。
這也不完全是錯，
畢竟專案要活下去，本來就離不開利害關係人。
問題是，如果你在畫 wireframe 的時候，
心裡只有「每個人要一塊」這件事，
卻沒有問過自己：
「這個畫面，對真正的使用者來說，他最重要的一件事是什麼？」
那最後的結果，常常就是——
每個人的需求都「有放」，
但沒有人真的覺得好用。
◆ UX 不是「漂亮」，而是「減少被使用者罵的機率」
很多人會把 UI / UX 混在一起看。
UI 講的是視覺、風格、美感；
UX 講的是路徑、成本、心情、犯錯之後會發生什麼事。
UI 很直覺會被丟給設計師；
UX 很容易被丟到空氣中，
大家嘴巴上都會說「重視體驗」，
但實際上沒人真的負責。
在 wireframe 階段，如果 PM 完全不想 UX，
後面幾乎可以預期會發生：
設計師畫得很辛苦，
工程師做得很痛苦，
使用者用得很無奈，
最後回頭說：「當初怎麼會畫成這樣？」
很多「難用」，
其實不是因為設計師不會做 UX，
而是 PM 在畫第一版 wireframe 的時候，
沒有先把幾個最基本的體驗概念放進去。
◆ 畫 wireframe 前，先想清楚「這一頁要幫誰解決什麼事」
最簡單、也最常被略過的一題，就是這句：
「這一頁，主要是給誰用的？
來這裡，他最想完成的一件事是什麼？」
舉個例子：後台「訂單列表」。
如果你沒有想清楚使用者是誰，
很容易畫成一個「什麼都有一點」的畫面：
上面是訂單搜尋，
中間是一長串欄位的表格，
底下再放幾個統計資訊、匯出按鈕、客服筆記區。
看起來功能豐富，
實際上使用者每天打開的時候，只想做兩件事：
快點找到我要處理的那幾筆訂單；
在不出錯的情況下，把它們處理完。
如果這時你願意退一步，在 wireframe 上做一個小調整：
把搜尋和篩選做得明顯、好用一點；
把最重要的欄位放在左邊、變大一點；
把不常用的資訊折疊起來，放到詳情頁或滑出區塊；
你會發現，
即便什麼花俏的 UI 都還沒上，
使用者的感受已經差很多。
◆ 「約定成俗」的使用習慣，不是限制，是省腦力的捷徑
UX 裡有一個很務實的觀念：
不要浪費使用者的理解成本。
有些東西之所以會「約定成俗」，
不是因為大家懶得創新，
而是因為換一種玩法，使用者就會需要重新學一次。
舉幾個很常見、卻很容易被 PM 改壞的例子：
搜尋欄位通常在上面，不要藏在不明顯的角落；
主操作按鈕，通常在右下或右上，顏色要明顯；
刪除、停用這種高風險操作，要有二次確認或撤銷機制；
列表中的文字過長，用「…」加 tooltip，比硬是塞完來得好；
「上一頁／下一頁」要一直出現在同一個位置，而不是每頁都亂跑。
當你在畫 wireframe 時，
願意尊重這些「使用習慣」，
就是在幫使用者省掉學習成本。
你不是不能打破規則，
但每打破一個，你就要問自己：
「這樣做，真的有比原本那種習慣好到值得嗎？」
◆ Wireframe 裡最被忽略的一塊：錯誤、等待、做錯事
大部分的 wireframe，
都只畫「成功時」的樣子。
成功登入的畫面、
查詢有資料的樣子、
按完送出一切順利的狀態。
但真正在專案裡，
最容易被罵的，通常是另外三種：
沒有資料的時候（Empty）
資料還在路上的時候（Loading）
出錯的時候（Error）舉例來說：
你畫了一個搜尋頁面，
只畫「查到結果」時的列表。但實際上，使用者更常遇到的是：
關鍵字打錯，一筆都沒有；
網路狀況不好，轉圈圈一直轉；
後端忙線，過了幾秒才回錯誤。如果這些狀況，在 wireframe 階段都沒被畫出來，
設計師有可能會直接忽略，
工程師有可能用最省事的方式處理（整頁白掉、秀一串看不懂的錯誤碼），
最後在驗收時，就會變成：
「這系統怎麼一點錯誤處理都沒有？」其實不是沒有，
是從最一開始畫畫面的時候，
就沒有人認真把它當一回事。
◆ UX 不是設計師的專業而已，PM 也要有一點點「概念」
嗨，我是廣三。
在軟體開發的現場，看過太多版本改來改去，
最後大家總結一句：「好難用。」
但如果回頭看整個過程，
你會發現問題很少是出在「設計師不懂體驗」。
更多的時候，是在 wireframe 的階段，
PM 就已經做了這幾件事：
只顧滿足每個利害關係人的「我要有」，
卻沒有替主要使用者想「這樣好不好用」；
只在意功能「有沒有放上去」，
卻沒有整理清楚資訊之間的層級與關係；
只畫順利完成任務的那一條路，
卻沒有想到使用者一旦走偏會發生什麼事。
UX 當然有很多方法論、流程、工具，
但對 PM 來說，最起手式的練習其實很簡單：
每次打算拉第一個框之前，問自己三個問題：
這一頁，主要是給誰用？
他來這裡，最想先完成哪一件事？
如果他失敗了、等太久了、找不到東西了，畫面要如何幫他？當你願意在 wireframe 階段
多花一點時間想這幾個問題，
後面在設計、開發、驗收時，
「改畫面」這件事，就不會那麼頻繁、那麼痛。
因為你不是只是把需求排上去，
而是從一開始，就試著站在使用者那邊，
替他把那條路鋪平一點。
這，才是 PM 在 wireframe 裡
能替 UX 做到的、最實際的一件事。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言