敏捷設計，讓設計更高效

設計師是一群具有藝術氣質的思想家，他們以天馬行空的創新、特立獨行的行事風格存在於各個團隊里。區別於其他工作的是，這是一個更注重「靈感」和修養的行業，在東方文化環境下，更又崇尚「頓悟」，因此，上下游的同學都知道，和設計師相處過程中，耐心是要足.

為什麼要敏捷

設計師是一群具有藝術氣質的思想家，他們以天馬行空的創新、特立獨行的行事風格存在於各個團隊里。區別於其他工作的是，這是一個更注重「靈感」和修養的行業，在東方文化環境下，更又崇尚「頓悟」，因此，上下游的同學都知道，和設計師相處過程中，耐心是要足夠的，好像也是必須的。

而對於企業來說，運營的效率是性命攸關的事情，時間就是生命。說到底，生存在社會中的設計師無法不受商業規律的影響，無法超脫世外地藝術化生活，也就說同任何工作一樣，效率和質量也是設計師必須面對的、永恆的難題。

作為在廣告創意公司工作過的設計師來說，加班永遠是主題，我曾經有過三天三夜不睡覺，設計一本書，被抬上飛機的經歷。踏入互聯網的領域後才發現，命是天定的，人性化的bta企業也有那麼多的加班。對於像設計師這種習慣創新的族群，自然地會尋求，天底下是否有一條撒滿鮮花的舒適坦途？企業則也會去思考，有設計參與的項目是否可以一樣敏捷高效？

在深圳工作的這6個多月里，我們同技術、產品等夥伴嘗試了一種新型的工作方式，這種工作方式令我們在1個月的時間裡，完成了通常需要3個月、甚至需要更多時間花費的工作，同樣的高質高量，同樣的快樂活潑。這種方式我們暫稱「敏捷設計」方法。

這種敏捷設計方法的是挑項目的，因為它需要更早地規劃好項目日程，且配合的團隊需要結構穩定、預留好想對固定的資源。我們無法讓一個個朝生夕滅的臨時項目系統化地敏捷起來。

且敏捷設計的參與人員要有創業精神，不糾結於流程和職位級別，一切以推動項目進展為準則。

敏捷的方法

跨專業明確分工

要想團隊敏捷起來，立即理清各自的職責分工是十分緊迫的，有的同學或許會問，大家平時的分工很明確，運營、產品、設計、技術、測試都是十分精確專業的分工，還需要二次分工么？怎麼分呢？

要想敏捷，所有合作者就必須跨專業思考，比如設計師要理解產品產生的原因，前端要理解設計美學的大致規則等，只有充分理解才能有誠意的合作。所以，跨專業思考是首先要解決的一點。

日常項目中，一個項目的原始溝通，要在彼此理解的前題下，非常明確地跨專業劃分職責，比如讓視覺和交互合一，有能力的設計師可以通吃交互視覺，交互承擔部分簡單的產品工作，產品承擔簡單的用研與分析工作，開發承擔部分前端工作等等。跨專業明確分工，是敏捷的關鍵第一步。

除此之外，敏捷設計需要調整彼此協作的具體方法，這裡總結幾點：

晨會

各種kink off 評審會溝通會在項目中會佔大量的時間，但這些關鍵會議又在達成一致意見，大多不能省略，所以縮短會議時間、增加會議效率是必由之路，而短暫、固定的站立晨會是解決這個問題的好辦法。站立晨會的時間控制在15分鐘以內，只談解決方案和核對進度，不展開討論，有分歧的可以回後單獨私聊達成一致，第二天晨會更新上來即可。

並行投入

為了敏捷起來，除了跨專業思考，理解上下游的承接方法，還必須並行投入，這是關鍵、並且會產生大量困難的一步。

所謂並行投入，最初溝通即要求技術、設計、產品都必須同時參與業務溝通，可以由產品或運營主導，來推動前期溝通，在這個步驟不僅產品自己理解了業務，更要讓後續的技術和設計明白，產品之所以如此設計的原因和業務目標是什麼，這樣有利於後續協作同學更早介入業務，更早思考起來，從技術、設計角度幫助產品貢獻創新思維，有時反而能事半功倍地達成所要達到業務目標。

並行產出

在產品規劃階段，ued根據業務需求，從用戶視角開始前期用戶體驗模擬設計，並及時提供給產品、技術參考，技術根據業務需求產生技術基礎解決方案，這種方案的前提是不依賴交互體驗，純粹從技術角度，按最佳技術路徑來解決問題，提出解決方案供產品、ued參考。在此時，ued與技術均不用精耕細作，提供完整的大致解決方案即可，在設計中表現為「低保真的交互稿」。並且，這裡的角色是互動的，產品、ued和技術提供方案的同時，也從協作方彼此獲得對方的初步解決方案，並實時調整自己的對應方案，這是一個來回不斷斧正的過程，最終的成果是——帶交互設計的、在技術實現上論證可行的、有解決方案的產品prd。

這種prd推出時，技術和ued的進度都不會像以往那樣還在0%的基礎上等待，說不定已經萬事具備，只欠f-prd這個東風了。

先進度，後體驗

一個項目閃亮登場，當然是全部參與者的共同目標，也是最好情況。但是在大多數互聯網項目中，因為要搶在某個時間點搶先發布，不斷迭代、小步快跑是常態，這時設計師有必要調整好心態，同協作夥伴一起，規劃體驗還原度的時間表，讓項目的進度不受到一些小細節上的還原度的影響，但又能保證某個時間點，體驗基本實現一致。

比如可以要求一個項目進度中，在灰度測試時，實現60%的體驗還原度，正式發布前實現80%，上線後第1-2次迭代後實現95%的還原度。這樣的進度符合商業速度，也能在兼顧前端、開發同學的承受能力的同時，保證體驗的基本水準。至於100%的還原度，那可能要過一個比較長的時間，甚至要準備永遠都不會實現，因為互聯網項目生命周期太短，更迭也太快，無法追求永恆的完美。

先進度，後體驗，不是說放棄一部分體驗，這裡特別要注意前期的體驗還原度時間表的嚴格規劃，和後期的及時跟進，否則就會變成只有進度，毫無體驗。

產出物

一般來說，協同作戰容易誤傷，不注意的話，一不小心就給自己合作夥伴挖了個小坑。所以大家的協同時，一定要先商定最後產出的形式，在上下游都能接受的情況下再協作。

首先，設計師的體驗流程要與產品經理的商業流程一起產出，並及時核對，這一步基本就確定了大致的頁面數量、交互路徑，也確定了前端工程師在頁面這塊的工作量。所以，必須在體驗流程圖與商業流程圖都要具備的情況下，並且這個流程是經過業務方確認的，才進行設計工作。

其次，除了並行產出的「低保真的交互稿」和「帶prd的視覺稿」外，設計師應與前端工程師達成一個關鍵性的「合同」——前端在實現視覺稿時，把通用的部分，如按鈕、輸入框、彈出框等等組建，全部模塊化，像一個個盒子一樣封裝起來，後續不僅前端不需重複開發，設計師不需重複設計，甚至能實現讓產品經理自己組裝頁面結構，這對整個項目敏捷度的影響將是革命性的。

當然，搭積木一樣的模塊化操作，必然會對用戶體驗指數有一些負面影響，這裡就要求設計師注重最後對最終產出物的驗證，在上線前必須的用戶走查，上線後可以通過真實用戶測試、或者AB-test研究來檢驗模塊化組裝的頁面，並由設計師做後續設計修正。

敏捷化的設計師

了解商業和技術

達到商用路徑的方法，往往在專業上有好幾條不同的路徑，設計師理解了項目的商業訴求，更有利於找到一條對項目來說最合適的設計之路。

設計師大多數對商業規則和原理不感冒，對商業設計之類關注更多，現在提倡設計師了解商業也是流行話語，不過，商業這個名詞太大，我們設計師究竟要了解商業的哪個部分呢？我的主張是從目前做的項目入手，先理解這些具體項目的相關的商業，比如項目目標和未來規劃是什麼？生命周期多久？影響項目的商業數據是哪些？弄明白這些，基本能保證設計方向不會有錯。

跨專業的工作

大家的專業都是從學生時代就確立的，往往跟個人愛好、能力傾向有關。進入公司後，一般都會提倡複合型人才，你會的越多，解決問題的能力越強，最好幾個不同的問題，無需再跑幾個部門，找你一個人就解決了。然而對設計師來說這是巨大的挑戰，視覺兼顧部分交互，要解決自身邏輯和結構化思考能力問題，交互兼顧視覺，則有美學培養的要求在。然而，這些能力培養是長期的，跨專業工作也不是要求培養通才，只是希望在原有的知識框架邊上，做少許延展，方便上下游的接駁，當然，在緊急重大的項目中，更提倡有能力的設計師一肩承擔，更能加快項目進程，節省大量溝通成本和轉接項目的資源損失。

溝通與談判能力

溝通和談判能力中語言表述只是一個方面，更為重要的是對項目背景、上下游情況、商業目標的透徹理解，可以說台上一刻鐘，台下十年功，一個對項目基本背景都不深入了解的人，是無法站在談判桌上的，更不要提向對方推介自己的設計了。所以，溝通和談判能力是建立在對項目深度理解的基礎上的，設計師不應做沒有準備的設計評審和討論。

另外，注重對會議管理學習，通常溝通就時一場小的會議，溝通之前必須知道自己要得到什麼（會議目標），可以放棄什麼，底線在哪裡，做好部分妥協的準備。

設計溝通時還有一個情況是，設計師需要發揮自己的優勢，以圖形化的方式直觀的展現自己的見解，或幫助對方梳理清楚他的見解。必要時的寫寫畫畫，勝過千言萬語。並且這個方法的好處是，設計師可以把用戶需求直接植入討論中，植入最終結果中，討論的圖像也可以作為一個存檔，化解以後理解分歧，以備長期查驗。

設計的敏捷化是根據互聯網產品的日新月異的更新速度，新時代用戶紛繁複雜的用戶體驗場景做出的設計方法優化，用於化解設計創意時間長，與項目商業需求緊急之間矛盾。很多資深的設計師都有一套自己的「獨門秘籍」，大家可以在這個問題上展開多次專業討論，以利於我們設計的最終成功。這裡說的敏捷設計，只是一個引子。

推薦閱讀：