隨著近年軟體開發的發展， 各式各樣的開發流派各有擁護者， 主流的有 MVP(最小可行產品)、 敏捷開發系列(Scrum)、 測試導向開發 (Test-Driven Development)， 以及接下來要介紹的使用者導向設計(User Centered Design)。
說起來各種開發流派在特定的情況下都各有其優缺點， 至於如何取捨就看產品主導者的喜好跟限制了。
UCD 主要的概念就是在每一個開發的循環跟步驟中， 都要將使用者的回饋及意見納入其中。
以使用者為中心的設計理念 :
圍繞在用戶如何能夠完成工作、希望如何完成工作來優化用戶交互界面，而不是強迫使用者改變他們的使用習慣來適應軟體開發者的想法。
實際在執行UCD的流程時，會遇到很多關於人的問題，而這方面的問題通常都不是工程師擅長的。
舉個例子： 常常會有使用者所提出的要求是很難達成的，像是 “就跟Line一樣的貼圖會很加分”、 “有點像是神魔之塔那樣就對了”、 “如果有自動判別我們說出什麼並打分數的系統就好了”。
如何有禮貌地與用戶互動並從中學習，是很花時間並有挑戰性的。
UCD並非是對使用者說的每一件事情都言聽計從
因為大部份的使用者並不了解技術面的細節以及可行性，很多時候他們會講出天馬行空的點子；
但如果仔細引導使用者， 他們的想法就會變得相當有參考價值，最後再謹慎決定哪些資訊該保留、哪些資訊該捨棄。
“詢問對的問題” 在UCD中是其中一個相當關鍵的要素。
如何傾聽並引導使用者， 針對產品的灰色問題 (aka. 不清楚該如何設計的環節)， 給予他們的意見。
在設計產品時，許多設計的決策很難在第一時間有所謂的好與壞、對或錯，而這時一個中性的使用者意見， 通常可以讓產品設計師或者工程師跳脫原本的框架， 以使用者的角度去看設計， 讓設計的情境能更貼近需求。
承認吧！ UCD最難實行的部分就是當產品的設計者原本擁有跟創世者一樣的權利， 可以對自己設計的產品新增需求、彷彿全知全能般對產品的種種假設提出解答， 在設計的過程中， 這種一切我做主的快感就彷彿吸毒一樣令人無法自拔啊！
如何讓產品的設計者將主導的權利轉交給使用者， 也是UCD要能夠實行第一個需要滿足的條件。
Step1 : 擬定計劃
在這個階段主要工作為下面幾項：
- 團隊使命宣言 -> 確立計劃基調 (初衷及願景)， 作為團隊的目標及對使用者的承諾
- 專案描述 -> App的目標、 為何要開發此程式？ 提供怎樣的價值？
- 使用者需求 -> 使用者最根本的需求
- 功能需求 -> 要以怎樣的功能來滿足使用者的需求
- 資料庫及資料流圖表
- 原型畫面
基本上計劃可讓思想變成文字， 將發散性的思維變成邏輯性有組織可行的需求。
這階段最主要的目的是為了能將撰寫非必要的程式碼以及無用功能的時間降到最低， 也能在這階段收集使用者回饋， 並透過策略性的流程， 確保你做了所有你應該做的。
軟體的開發是動態的；
想要預先想好所有的工作流程是不現實的。
實務上， 必須對於各種初始計劃沒設想到的狀況作出反應， 而此時一開始所建立的計劃， 就能提供最基礎的判斷依據來作出決定並補充解決未曾預料到的問題。
Step2 : 收集回饋
回饋階段主要任務是透過各種方式讓使用者對我們設計的應用程式提出個人的想法及意見。
這時需要詢問一些詳細的問題， 並且要放開心胸接受嚴厲的批評， 還需要觀察使用者， 並將結果記錄下來， 如此才能全面地了解哪些東西對我們有幫助， 而哪些又應該捨棄。
收集回饋時， 很難不把主觀的意識擺一邊， 讓數據客觀地說話， 通常人們只看得到自己想要看到的數據， 也只相信自己原先所認定的事實！
把自己的面子跟主觀丟一邊， 好好的與用戶交流並讓意見流暢的交換是這個階段最重要的目的， 推翻草稿重新設計遠比寫完產品後再推翻便宜多了！
Note: Jakob Nielsen 建議受訪者在這階段不需要超過五個人。
Step3 : 持續精進 （or 砍掉重練）
應用程式的第一版不可能完美無瑕，很多時候常常第一個版本出來時有相當多的臭蟲及有瑕疵的地方，必須要在時程及完美間取得平衡，一方面接受不完美的情形下推出應用程式，另一方面要有持續精進的決心。
這階段主要是透過使用者的回饋持續修改精進應用程式，回饋的反應若與預期的目標相距太大，必須做好重新開始的心理準備。
有時候， Pivot跟砍掉重練差不多啊 …