從 Mockup 使用看軟體設計流程敏捷度
都可以用，但是
為什麼長的不一樣的兩個東西，都慣用同一個詞？
除了名詞定義的通用性之外，在傳統的設計流程裡，軟體介面設計需經過這幾個步驟。
在過往如果想要做前期的使用者體驗調研，大多只能先省後端的成本。
設計師使用 PS 
、AI 
等工具設計頁面，再交由工程師開發成可互動的前端程式(原型)，最後用來對真實用戶做測試。
所以就衍生了下面這個簡單的判斷邏輯，網路上很多人轉載，追溯起源可能來自此 Jay的商業筆記 。
在今天聽起來是一個土豪作法，因為一看就需要很多時間成本，事實上 User eXperience 在早期會被當成IT界奢侈品也是這個緣故。
在這個競爭激烈，用戶胃口很刁的環境下，原型設計工具 
也日新月異了起來。
所以今天來看這張圖加上是否可互動的註解，就會變成這樣。
為什麼不是往越高擬真才增加互動性？
今天的 WIREFRAME 已經套不進去上面的簡單判斷邏輯了，而且 MOCKUP 位置感覺尷尬尷尬的… 
再往上看一次名詞定義，人家都說了是「只可遠觀，不可褻完焉。」既然依照擬真程度 MOCKUP 的順序動不了，再加上前端工程師們長年累積而來對這個詞的高仇恨值，只好把它拔掉了… 
我們來看看 Adam 大大 2013 年在 WebConf.tw 的投影片:
還是有人用也不是真的被拔掉拉…
但為什麼在敏捷團隊裡面好像比較少聽到這個詞？
不知道什麼是敏捷的可以簡單先看這篇 
十年敏捷路，談企業轉型經驗
你可以這麼形容敏捷
如果花很多時間做出一個錯的東西，然後又剛好把時間用完，那就是瀑布。
如果用一半的時間做一個錯的東西，知道什麼會錯之後，用剩下的時間把比較對的東西做出來，那就是敏捷。
用一半的時間，做兩倍的事。 
敏捷不是快，但求做事有效率。
開發流程的演進是為了因應市場需求的快速變動，那設計呢？
在有敏捷 MINDSET 的開發團隊裡面，連座位旁的小蟑螂都敏捷起來了。
既然如此，那介面設計流程是不是也可以更敏捷點，才能設計出更貼近用戶真正的需要(NEED)的軟體介面，而不只是任何人自以為是所提出的需求(Requirement)。
因此，我認為演化後的設計流程會是這個狀態:
重點是趕快做使用者測試確認方向是不是對的
口頭討論或腦力激盪結束後，就趕快用工具 做出可互動的 WIREFRAME 進行使用者測試，並根據反饋立即迭代。
有經過使用者測試的確認，才叫做線框稿的完成。
我會叫同事好好學習XD的!