哪來有畫 Wireframe 就是有做 UX 的錯覺？UX 不是 Wireframe，使用者體驗為什麼會是線框稿？當然不是啊！很多人以為有畫 Wireframe 就等於有做 UX 了，那整天抱著數據統計寫文件的 UX 設計師在幹嘛？會把有畫 Wireframe 當成有做 UX 的人，合作的 RD 同事通靈技能大概 LV99 點滿了。
UX 在做的事和 Wireframe、Mockup 息息相關但表面上看不出來，這牽涉到到專案開發和架構、功能需求，已不再是表面的視覺而已。大家都知道 UX 做好就能讓增加使用者滿意度、或是讓更多的人註冊付費…所以有畫 Wireframe 就能夠吸引使用者？怎麼推導出來的結論？
先找到問題才能解決問題
- 如果問題是「如何透過增加使用者體驗的方式吸引更多使用者？」
- 解決問題的方法是「畫 Wireframe」。
- 那問題就變成「為什麼畫 Wireframe 可以增加使用者體驗？」。
Wireframe 傳達的是「UI」，User Interface 使用者介面，是「文件」的一種。在除去所有視覺影響的情況下，能讓閱者把注意力放在介面構成、操作、元素配置上。
UI 是 UX 的一部份，但 UX 不是 UI ，獨角仙是昆蟲的一種，但決不會把昆蟲都叫做獨角仙一樣。如果這句還是不懂…你媽是女的，所以女的就是你媽？（某大大這句話真好用，迫力十足。）參考舊文 我是UID，不是UXD 。
常見 UI 的工作是 Flow、Wireframe、Mockup、切圖、標示文件…等。
UX 的工作應該是使用者測試、數據統計、研究報告…等。
（不過都被混在一起講了，業界現況喊做 UI/UX 的大多只是平面設計，少數在做視覺設計、更少數是 UI、極少數做 UX。）
研究方法
真正的 UX 很像實驗室那群披白袍的研究僧，整天和數據、實驗打交道，寫不完的報告和文件。針對專案開發不同階段和目的，有各式各樣的研究方法求取答案。之前也寫過一串的文章，簡單介紹專案各個階段會遇到什麼問題、可用哪種研究方法解決。
UX，設計的方法（專案初始）
UX，設計的方法（專案執行）
UX，設計的方法（專案中期）
UX，設計的方法（專案後期、追蹤）
如果問題是「如何透過增加使用者體驗的方式吸引更多使用者？」那該問的下個問題是「現有產品遇到什麼問題需要改進？」、或是「使用者特別在意產品的什麼部分？」有了問題，才能找解答方式。
現有產品遇到什麼問題需要改進？
可用性測試 Usability Testing
記錄使用者在操作上有什麼不順的地方加以改進。最簡可行性產品 MVP、快速反覆測試評估法 RITE
甚至在開發階段就用簡易 Prototype 做測試，是不是就能解決產品上線了才知道哪裡有問題要改的情況。
使用者特別在意產品的什麼部分？
狩野分析
這功能到底有沒有做的必要，是使用者需要的嗎？使用者旅程圖 Customer Journey Maps
找出使用者在什麼情境下會遇到什麼狀況，將產品修改得更符合使用者需求。
遇到問題，尋找解決方法。而不是「我看到有這種方法，咱們來研究下這方法能解決什麼問題」，順序錯了。而 Wireframe 就更不可能回答上述的使用者體驗問題，根本找錯方法。
結論
回到文章一開始提到的，畫 Wireframe 為什麼就是有做 UX？做 UX 是為了解決什麼問題？想解決的問題透過畫 Wireframe 就能解決嗎？Wireframe 為什麼能改善使用者體驗？
UX 不是 Wireframe，使用者體驗不會因為畫了 Wireframe 就有所提升，Wireframe 只能降低通靈程度、減少溝通落差、讓專案開發進行順利，並不附加提升使用者體驗的屬性。真的想解決產品遇到的問題、提升使用者體驗，還是運用下研究方法、跑點數據寫點統計報告吧。
