起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識交互設計方法論 2.0探討
引言：
CDC交互設計方法論的思考其實是個永恒的話題，在內部管理大會上有人演講，提到team 2.0概念，讓我深有感觸，結合我們自身在實踐中的設計方法及設計流程，在平臺化，多人參與，分享互動，個人貢獻的價值體現方面我們又該有什么樣的思考？關于設計流程化大家慢慢有了一個共識，就是：除了完整，規范，還要敏捷，有自我完善的能力。形象一點說也是要從1.0往2.0升級，那改革成功的標志應該是什么？隨著公司業務的蓬勃發展，CDC承擔的設計項目也越來越多，隨著項目經驗的逐漸豐富，我們發現在今天的研發環境中，存在著許多挑戰：人力成本預算限制，多并發設計的進度壓力，交付高質量設計方案，提供易學易用型的設計工具，學習和開發新的設計技術和嘗試新的量身定做的項目管理工具，這一切都是為了從多角度完善設計方法，敏捷設計流程，進而達到我們期望的理想設計目標，取得源源不斷的內部及外部競爭優勢。
從2006年上半年CDC成立開始，CDC交互設計一個很重要的使命是，將多年的設計經驗總結提煉成一套設計方法論，進而變成一個可復用，可持續改進的設計流程并加以執行。但是只有一兩條設計流程其實是不夠的，正如Web 2.0沒有一個明確的界限，而是一個重力核心一樣。不妨將交互設計方法論2.0視作一組原則和實踐方法的組合，由此來把距離核心或遠或近的諸多方法論和管理技巧聚合成為一個類似星系的網絡系統。
CDC交互設計方法論的幾個維度思考：
用戶參與
一個設計項目從立項啟動開始，我們即明確以用戶為中心的設計理念，在以滿足用戶需求為目的的交互設計過程中通過多種手段來理解用戶，理解他們的使用環境，限制（包括各種生理，心理限制），特征和任務目標。同時在需求提煉（主要是可用性需求），設計，評估及測試使用過程中，由交互設計師主導，把persona逐步還原演繹為成可供設計參考的use cases。
經驗法則：請不要“虛擬用戶”也不要“將產品需求方當用戶”，很簡單的概念，但是經常設計師在這一點上常常犯錯，當產品需求方講通過層層篩選提煉確定需求提交過來時，用戶的需求常常隱藏較深或者被有意無意遺漏，但是當設計師直接接觸用戶，并提供一個途徑讓產品能夠被用戶測試或使用到時，用戶必定能針對產品說出其優勢與不足，同時設計師掌握到第一手的用戶資料，也擁有了更大的話語權。設計師怎么樣掌握到第一手資料？我想這次和大家制定的H1 KPI中有結論，有一位內部的同事總結的很好，借用一下，大家共勉：“像觀察自己的BABY成長一樣，觀察用戶的行為、發掘用戶需求”。
需求管理
這里包括兩層意思，首先，對需求來源的格式加以定義，保證設計需求的明確化，規范化是很重要的一個前提，根據多年經驗，設計變更太多，設計稿通過率低很重要的一點是需求不明確，變更很隨意造成的。基于這個教訓，我們在流程上也特意強化了需求交接的規范，例如產品應該提供什么產出給設計師，設計師如何收集整理需求并條理化等等。
另外，我們也看到，業務需求和功能需求最普通，最容易收集。但用戶界面的特色，可用性，可維護性和擴展性等需求缺往往被忽視。如果沒有特意制定目標，用戶界面，用戶體驗上的特色要不就被盲目定義，要不就沒有定義。而且我們可以看到作為一個互聯網公司的產品，通常以內容性設計為主，在用戶界面上總是被要求精益求精，相對于IT業界的代碼水平，與用戶界面相關的代碼量通常增長在30%～50%以上，用戶對界面特色的理解和掌握總是需要花費更多的時間和精力，但從交互的三層結構模型來看，用戶對軟件的體驗，對交互設計而言的挑戰就是“如果想確保產品容易使用，最重要的是什么？”，因此，對于易用性，可維護性和擴展性等可用性需求，必須制定一個明確的，可看得見的定義，在CDC的交互設計流程中，我們把它叫做“可用性需求收集和定義”。這樣一來，設計目標遵循項目計劃和工作成果評估所能達到的程度將是可量化，并且是可測試的。
經驗法則：明確需求，一旦確定，就必須對它進行控制和量化管理，交互設計師作為團隊成員，必須清楚用戶和項目團隊不斷提出的需求和功能，并打造成為設計方案的基石。
制定計劃
對大多數的項目而言，項目團隊總是對進度想象得很樂觀，對進度保持樂觀很重要的一個原因是有很充分理解當前進行的工作。但作為公司的產品現狀而言，我們可以看到行業的用戶界面技術創新，其速度是高于開發實現技術的。設計師想要做到的許多UI風格和特色嘗試其實涉及到大量的細節，預期行為以及重復性，而這些并不能被項目組其它角色快速領悟到，并被以風險和技術實現限制的理由加以扼殺，這也常常造成一個現象“理想的設計永遠是在下一個未開發版本中”，基于這樣一種設計體驗，CDC交互設計方法論中特別強調了對設計需求的版本化細分，制定計劃，有步驟，分階段的實施，對遺留問題有跟蹤。對未實現設計目標有明確時間定義。
經驗法則：對于設計需要有切合項目現實的實施計劃，要宣導團隊認可的設計目標并細化成可實現，可跟蹤的feature list，并提供盡可能詳細的細節說明，一方面也考慮項目現狀，可用性需求可以分批實現，must，need，mayb，要心知肚明，形象一點來說，也就是大家俗稱的“討價還價”，一個主設計師很重要的能力就是議價能力，需要把項目當作“生意”來經營。
技能儲備
關于技能對設計目標的轉化，開發軟件的過程中，需要學習的東西很多，相關的新型操作系統，新的開發語言，新的應用軟件結構，對于交互設計師而言其實也是一樣，新的用戶界面風格，新的界面實現技術和新的設計工具。每樣新東西需要時間來學習，也是CDC要打造一流設計師團隊建設中很重要的一個環節，技能儲備的厚度，設計視野的深度直接影響到CDC的設計水準，一個很重要的問題是“如何將日常的設計積累應用到交互設計實踐中？”多數時候我們也認可這種轉化遷移其實是自覺自發的，但是為了保證設計質量，我們在交互設計流程中也明確了競品分析研究的環節，即在概念設計之前，設計師必須做一定的研究分析工作，對相關產品進行專業上的深度分析，對趨勢進行有理有據的推導，進而形成自己的創新點，項目的設計目標也得以確立，保證設計一開始就有一個高水準的起點。
設計技能的持續優化，主要是對設計工具優化而言，經過這幾年的積累，應對各個產品線，我們擁有了自己的設計開發工具，有了可復用的設計模板，有了越來越實用的交互統一規范，正在制定的可靈活調整的流程指南，希望做到的只有一點：成果的傳遞無障礙，經驗的積累可復用。我們也堅信，站在千人的肩上一定可以成長得越來越快。
經驗法則：技能的培養和使用無法保證項目自動獲得成功，但正確的實踐能夠清除項目中的錯誤，使用正確的方法和技術，可顯著提高設計項目成功的可能性，一定要先進行設計相關技術的儲備。
創新機制
條條道路通羅馬，同樣地，交互設計問題的解決方案也不止一種。我們總是在追求最好的解決方案，但考慮選擇的時候，通?？晒┻x擇的方式總是被時間，技術，資源，競爭等以上因素，甚至更多因素羈絆。有時為了“交貨”，通常我們總是選擇一個最穩妥，最保險的解決方案，只是很可惜通常這個解決方案看上去并不怎么創新。
對于交互設計的創新，我們通常愿意采用這樣一種形式，在提供切合目前現狀的最合適解決方案時，鼓勵設計師儲備“備選解決方案”，而備選方案的設計通常會有制度性的保障，例如當沒有想法的時候，設計師可以在交互設計組，甚至更大的范圍發起“頭腦風暴”會議，可以申請“設計封閉”，可以組建“工作坊”，當創新點梳理出來后，鼓勵自己動手，通過各種工具變成可演示Demo，以直觀豐富的形式向項目組展示，這個其實也是一個啟示，對設計方案的創新需要有孵化機制，需要包裝，需要推銷，“唯有震撼，才能影響”。
經驗法則：任何設計都是可以改進的，這是永恒真理，但只有適合當前項目需求的才是最優方案，不盲目創新很重要。
設計實踐
主要有兩個維度， 對于垂直維度，我們關注流程實踐，我們如何組合團隊搭建，用戶參與，設計評審，原型設計，專家評審，迭代設計等設計過程，以保證設計實踐的最優路徑，并做到快速漸進，在這個維度目前我們還在摸索，但隨著交互設計子流程的建立，應該說基石已經打好了。
對水平維度而言，我們關注共同成長，對于多數設計師而言，多年的設計實踐最終可以形成自己的行事經驗和專有技能。從此成為立命之本，對于CDC的設計團隊而言，我們還有很重要的工作就是團隊建設，如何分享設計師的經驗，如何取長補短，如何形成最優的設計實踐。其實是一件群策群力的事情，簡單而言，B1.0項目的教訓如何保證B2.0中不再重復，A項目的經驗能不能復用在B項目中。在一個大團隊中，很難保證一個設計師會跟一個產品跟n個版本，從生到死，當一個新人加入時，他（她）需要怎樣的準備才能快速成長，項目組之間的信息不透明，不對稱這些都是問題。目前我們是通過小組的制度來加以保證的，例如所有設計師參與的周例會，月會分享，原創寫作，項目組showcase機制，定期項目管理溝通會，郵件周知制度等來保證的。
一點題外話，從上可知，設計實踐產生了一個重要命題是“各項目線設計實踐中的零散經驗教訓如何轉化為群體智慧，從而保持基業常青”，從這個話題延伸，目前廣為人知的概念是design patterns，DP在產品設計中怎樣才能做到內容自發產生，被設計環節以最小制作代價復用，同時又能有很強的自我修訂能力？坦白講我們還在實踐，能夠看到的好的范例一個是yahoo的DPL，這個我們以后有時間再探討。
經驗法則：越早制訂設計流程越早遵循，設計實踐效果就越好，關注設計師團隊的共同進步，消除各自的能力短板，團隊才能互補。
風險管理
預先示警相當于提早準備，若能認識到軟件和用戶界面的實現均涉及較高風險，產品開發團隊就能夠預先管理整個過程。通常我們在業界的專業分享或者在外面能看到的很多case為什么不具有很強的參考性，一個很重要的原因是它們剝離了軟件研發環節的影響因素，“看上去很美”而已，規范風險在CDC的交互設計層面通常倡導幾個措施：
1.建立風險列表，提供可用性評估指標，例如“XXX”“XXXXX”“XXX”（請原諒我隱去的一些信息）。
2.設計初期引入用戶研究資源，保證客觀公正的建立典型用戶模型，對設計概念的接受程度進行測試，對設計方案的用戶操作問題進行觀察，在設計投給開發實現之前，盡量將界面可用性問題加以曝光，避免用戶界面和可用性出現大的缺陷和隱藏的缺陷。
3.確立內部專家評審機制，從設計的方向開始，到設計細節實現，內部專家（黃金圣斗士級別為主，也包括神斗士）會先進行一輪預審，然后才會到產品層面的評審，這樣也有助于設計團隊內部資源的合理利用。
4.將開發階段和測試階段的工作明確化，例如在開發之前需要確認設計方案的執行程度，在測試階段要提供界面實現評估報告等，一直到項目結束都有工作要做。這也成為了CDC交互設計師的日常工作之一，而不是提交完設計方案后就意味著任務結束。
經驗法則：有正確可執行的計劃只是第一步，引入check機制，強化執行和跟蹤水平，項目會更容易獲得成功。
復制成功
06年的時候，碰到的最大瓶頸就是低級錯誤在不同項目中重復出現，在不同的設計師稿件中重復，事后反思，其實可以看到，成功和失敗的經驗都沒有好的沉淀機制，形成群體智慧才是問題根源所在。僅靠明星設計師的影響力帶動和言傳身教是不夠的，無論是風光成功的項目經驗或是收獲慘痛失敗的教訓，此類知識如果集中在幾個人手中都是極具風險的?；剡^頭來看，在誕生于Web 1.0時代并且存活了下來，而且要繼續領導Web 2.0時代的那些巨人的成功故事（例如yahoo!雖然最近諸多問題，但并不妨礙他在2.0時代的偉大）的背后，有一個核心原則，就是他們借助了網絡的力量來匯聚集體智慧，評價一個團隊的專業水準首先要看的是他的知識沉淀是否有合理的平臺，其次是看在這個平臺上誕生同時具有成功氣質的知識的數量及頻率有多高，最后是看這些成功的知識又能多快體現在其它的項目中，這個本質上來講是也是評價一個team有多大的復制成功能力及有多大的執行力的標準，和豐田的精益求精，持續改進企業理念非常的類似。
經驗法則：建立多樣化的分享知識渠道，同時要建立快速完善的聚合平臺，把項目線的成果及時有效的轉化為專業線上的成就，聚合群體智慧，產生最大的利他效應，這是一個創造學習型設計團隊的最重要基石。
- (本文出自Tencent CDC Blog，轉載時請注明出處)
- 目前還沒評論，等你發揮！
