Google Design Sprint 開發流程

Google Design Sprint 是講求效率與驗證的開發流程,旨在經過反覆研究、拆分流程、設計原型和驗證,在短時間內完成產品設計。不論產品的生命週期為何,從零開始的新想法或是改善原有的使用體驗,都可以遵循流程協助開發。

流程所示的步驟幾乎是產品設計的必經階段,最令人稱奇是要花一、兩個月的工序,Google 卻提倡在5天內(或更快)完成產品雛型。如何有效加快產品開發的速度而不失質素?講者提出致勝之道於「參與會議」。

依我所見,規模稍大的公司需面對開會這個大難題。正如片末有人如此提問:既然會議如此重要,一家中型公司的設計師,如何勸說管理層 (C-levels) 一起開會?講者認為持份者需明白參與會議是 Design Sprint 不可或缺的過程。大家必須獻上專業知識和時間,表述觀點立場,令跟進者能夠盡快做出符合各方要求的成果,而毋須日後反覆確認。項目初期開個會便能提升開發效率,在現今「時間等於金錢」的社會是不太可能遭到反對。

反觀現時公司的開發流程,經我多年「上諫」,設計總算佔一席地,但管理層、技術和設計上仍有不少分歧。設計經常因管理或技術所限而無法提供最佳方案,但追根究柢,問題其實有機會在初期解決。

現時客戶項目的開發以合約所述的時間、功能和成本為綱,然而合約乃項目經理所訂,難免會忽略或低估了為營造使用體驗而需要的成本。誰人可以編撰合約不是說了就算,我能做的是把牽涉的技術、資源和時間盡快估算出來。諮詢客戶及用戶後,呈上的 user flow、IA (Information Architecture) 及 wireframe 除了展示用法及導航外,須明確預視 UI (User Interface) 設計時會使用的模組和技術,以便工程師開發。另一方面,文件也交予工程師、項目經理及客戶審視和修改,確保用法合適及技術可行,項目早期集合大家意見這一點與 Google Design Sprint 十分相似。當然,我們的開發早在 UI 設計前已開跑,節省成本同時也非比尋常。設計師需要非常熟識技術限制和模組,方可配合流程製作更接近 UI 的 wireframe。因此 wireframe 為決定性的一著,要是持份者能夠盡早表達立場及準確估算可行性,則毋須憂慮,然而稍有不善,些微改動也難以獲批。

每次我也會稍為調整工作流程,從以前只有 wireframe,到現在為了令產品更貼近用戶需要,我要求 user flow、IA、prototype 在早期一併呈上,以便客戶及用戶具體地驗證產品,亦令工程師更加明白每個 UX 決策,而 wireframe review 時也盡可能向持份者「問到督」,集合各人意見以彌補缺乏 user validation 的缺陷。