CSM|敏捷設計，讓設計更高效

設計師是一群具有藝術氣質的思想家，他們以天馬行空的創新、特立獨行的行事風格存在於各個團隊裡。

區別於其他工作的是，這是一個更注重“靈感”和修養的行業，在東方文化環境下，更又崇尚“頓悟”，因此，上下游的同學都知道，和設計師相處過程中，耐心是要足。

為什麼要敏捷?

在廣告創意公司工作過的設計師都知道，加班永遠是主題。踏入網際網路的領域後才發現，命是天定的，人性化的BAT企業也有那麼多的加班。

對於像設計師這種習慣創新的族群，自然地會尋求，天底下是否有一條撒滿鮮花的舒適坦途?企業則也會去思考，有設計參與的專案是否可以一樣敏捷高效?

在設計公司實施敏捷是非常挑專案的，因為它需要更早地規劃好專案日程，且配合的團隊需要結構穩定、預留好相對固定的資源。我們無法讓一個個朝生夕滅的臨時專案系統化地敏捷起來。

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

敏捷的方法

跨專業明確分工

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

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

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

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

晨會

各種kink off 評審會溝通會在專案中會佔大量的時間，但這些關鍵會議又在達成一致意見，大多不能省略，所以縮短會議時間、增加會議效率是必由之路，而短暫、固定的站立晨會是解決這個問題的好辦法。

站立晨會的時間控制在15分鐘以內，只談解決方案和核對進度，不展開討論，有分歧的可以會後單獨私聊達成一致，第二天晨會更新上來即可。

並行投入

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

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

並行產出

在產品規劃階段，ued根據業務需求，從使用者視角開始前期使用者體驗模擬設計，並及時提供給產品、技術參考，技術根據業務需求產生技術基礎解決方案，這種方案的前提是不依賴互動體驗，純粹從技術角度，按最佳技術路徑來解決問題，提出解決方案供產品、ued參考。

在此時，ued與技術均不用精耕細作，提供完整的大致解決方案即可，在設計中表現為“低保真的互動稿”。並且，這裡的角色是互動的，產品、ued和技術提供方案的同時，也從協作方彼此獲得對方的初步解決方案，並實時調整自己的對應方案，這是一個來回不斷斧正的過程，最終的成果是——帶互動設計的、在技術實現上論證可行的、有解決方案的產品prd。

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

先進度，後體驗

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

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

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

產出物

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

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

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

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

敏捷化的設計師

瞭解商業和技術

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

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

跨專業的工作

大家的專業都是從學生時代就確立的，往往跟個人愛好、能力傾向有關。進入公司後，一般都會提倡複合型人才，你會的越多，解決問題的能力越強，最好幾個不同的問題，無需再跑幾個部門，找你一個人就解決了。

然而對設計師來說這是巨大的挑戰，視覺兼顧部分互動，要解決自身邏輯和結構化思考能力問題，互動兼顧視覺，則有美學培養的要求在。

然而，這些能力培養是長期的，跨專業工作也不是要求培養通才，只是希望在原有的知識框架邊上，做少許延展，方便上下游的接駁，當然，在緊急重大的專案中，更提倡有能力的設計師一肩承擔，更能加快專案程式，節省大量溝通成本和轉接專案的資源損失。

溝通與談判能力

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

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

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

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