GV Design Sprints（前稱 Google Design Sprint）是講求效率與驗證的開發流程，旨在經過反覆研究、拆分流程、設計原型和驗證，在短時間內完成產品設計。不論產品的生命週期為何，從零開始的新想法或是改善原有的使用體驗，都可以遵循流程協助開發。
流程所示的步驟幾乎是產品設計的必經階段，最令人稱奇是要花一、兩個月的工序，Google 卻提倡在 5 天內（或更快）完成產品雛型。如何有效加快產品開發的速度而不失質素？講者提出致勝之道於「參與會議」。
依我所見，規模稍大的公司需面對開會這個大難題。正如片末有人如此提問：既然會議如此重要，一家中型公司的設計師，如何勸說管理層 (C-levels) 一起開會？講者認為持份者需明白參與會議是 Design Sprint 不可或缺的過程。大家必須獻上專業知識和時間，表述觀點立場，令跟進者能夠盡快做出符合各方要求的成果，而毋須日後反覆確認。項目初期開個會便能提升開發效率，在現今「時間等於金錢」的社會是不太可能遭到反對。
反觀現時公司的開發流程，經我多年「上諫」，設計總算佔一席地，但管理層、技術和設計上仍有不少分歧。設計經常因管理或技術所限而無法提供最佳方案，但追根究柢，問題其實有機會在初期解決。
現時客戶項目的開發以合約所述的時間、功能和成本為綱，然而合約乃項目經理所訂，難免會忽略或低估了為營造使用體驗而需要的成本。誰人可以編撰合約不是說了就算，我能做的是把牽涉的技術、資源和時間盡快估算出來。諮詢客戶及用戶後，呈上的 user flow、IA (Information Architecture) 及 wireframe 除了展示用法及導航外，須明確預視 UI (User Interface) 設計時會使用的模組和技術，以便工程師開發。另一方面，文件也交予工程師、項目經理及客戶審視和修改，確保用法合適及技術可行，項目早期集合大家意見這一點與 GV Design Sprint 十分相似。當然，我們的開發早在 UI 設計前已開跑，節省成本同時也非比尋常。設計師需要非常熟識技術限制和模組，方可配合流程製作更接近 UI 的 wireframe。因此 wireframe 為決定性的一著，要是持份者能夠盡早表達立場及準確估算可行性，則毋須憂慮，然而稍有不善，些微改動也難以獲批。
每次我也會稍為調整工作流程，從以前只有 wireframe，到現在為了令產品更貼近用戶需要，我要求 user flow、IA、prototype 在早期一併呈上，以便客戶及用戶具體地驗證產品，亦令工程師更加明白每個 UX 決策，而 wireframe review 時也盡可能向持份者「問到督」，集合各人意見以彌補缺乏 user validation 的缺陷。
Constance Tang 