本節書摘來自華章計算機《需求設計：建構使用者想要和需要的産品》一書中的第3章，第3.11節,作者： [英] 克裡斯·布裡頓（chris britton） 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
大家可能會發現，筆者在講述自己的這套it設計方法時，有很多地方都沒有談到。筆者沒有像其他設計方法的講述者那樣，對原則、做法、政策、會議以及任務版等内容進行講解。之是以這樣做，是因為情境驅動設計本身并不想發明一套最佳做法，而是想把其他設計方法之中已有的那些做法移用過來。例如，如果我想把設計階段做得較為自由一些，那我就會采用類似于目前靈活項目的做法來進行程式設計。
即便采用設計先行的辦法，也依然可以分成多個階段來釋出，依然可以把工作量拆成小塊，以便漸進式地進行傳遞，并且依然可以把最新版本展示給利益相關者，同時做好他們可能改變主意的準備。情境驅動開發的巨大優勢，在于它可以從代碼及業務這兩個方面上，迅速地指出改變所引發的後果，并且確定這種變化不會影響全系統的完整性。與現有的設計方法相比，情境驅動設計的一個重要優點，就在于它能使我們了解變化并對其加以管理。
對于現有的做法來說，筆者覺得還有一個地方需要改進，那就是應該提前做技術設計，并且要一直等到可以證明它能夠完全正常地運作并滿足需求之後，我們才結束這段工作。總是有人想先寫完全部的功能代碼，然後再去處理性能和可用性方面的問題，而筆者剛才所說的建議，則是為了反制這種傾向。稍後可能還是需要對技術設計做出調整，但由于我們一開始就做出了堅實的設計，并且可以對修改後的設計進行重新測試，是以這種調整執行起來，會容易很多。
筆者從目前這些做法中所獲得的第三個認識，是覺得不同的項目應該針對所要設計的内容而采取不同的風格。情境設計、內建設計、使用者界面設計與資料庫設計，需要由自我激勵式的團隊來做，而實作階段則可以采用現有的scrum等開發方式，但是可能要有所調整。技術設計則介于前兩者之間。