UED在20世紀末，伴隨著互聯網公司在國內興起而出現。最早UED一般被稱作美工部，有的公司是把它作為產品部的一個組成部分（如最早的攜程和易趣），有的公司是把它作為技術部的一個組成部分；而那時候的UED其職責范圍也是非常簡單的，主要就是“網頁美化”，當時視覺設計方向的設計師并沒有明確的崗位職責劃分，都是“網頁設計師”。

1. 早期的UED

最早的網頁設計師是不負責html代碼編輯工作的，但幾年之內形勢就發生了轉變，一部分設計師開始使用frontpage，dreamweaver編輯簡單的網頁，這樣極大地減輕了技術部的工作，畢竟當時的技術部也沒有做到前后端代碼分開。

真正的分水嶺出現在2005年前后，當時雖然“UI設計師”“交互設計師”“前端工程師”的崗位名稱還沒有正式出現。但在大型的互聯網公司內部，已經出現了有不同側重點的崗位分工；特別是前端工程師，最早是從熟練運用frontpage/dreamweaver等網頁編輯工具中成長起來的，并逐漸開始接觸CSS和Javascript，這些設計師已經基本明確自己未來的職業走向，就是輕設計重代碼的發展方向。

2. 網頁設計師崗位分工出現

雖然交互設計（用戶體驗設計）的崗位分工和前端工程師的出現幾乎是同一時間，但在國內主流互聯網公司里，交互設計師崗位作為一個單獨的角色，則要相對較晚，大約2007年以后整個國內互聯網界才逐漸認識到交互設計和用戶體驗設計的重要性。

此時“用戶體驗”已經成為一個非常熱的詞匯而被各大公司領導層時刻掛在嘴邊了，而“UED”這個名稱被大范圍廣泛應用，也差不多就是在這個時期。從這個時期往后，UED部門受到了前所未有的重視，用戶調研、文案、運營等崗位分工也相繼出現。

3. UED規模最大時崗位分工

那個時候因為公司非常重視用戶體驗，也就非常重視UED，UED基本上獲得了它所能夠獲得的所有關注度和資源。很多與最初的“設計”相關度較低的崗位也成為了UED的一部分，如文案、數據分析、前端工程師等崗位；而UED的部門領導，最鼎盛時期是脫離了對于產品部門和技術部門的依附狀態，直接向CEO匯報的。

每個公司的具體情況不同，UED的規模和命運也都完全不同。但基本上來說，UED的這種鼎盛狀態，從2007年開始一直持續到大約2014年左右，然后就開始隨著新的崗位和角色開始受到重視，慢慢回歸到了本來的“用戶體驗”上來。這個過程是緩慢進行的，有些崗位的逐漸壯大和轉變是慢慢發生的。

如前端工程師逐漸脫離UED，是隨著移動互聯網的出現和發展同步進行的。新的JS框架打通了前后端，一個合格的前端工程師已經不再是僅僅需要熟練掌握原生Javascript和jQuery就足夠，而是需要開始學習很多新出現的框架。這時候UED對這個崗位的羈縻，就已經是明顯地力不從心了。而文案和數據分析開始逐漸遠離UED的過程，可能開始得還要更早一些。

接下來也有一些崗位即將會從UI設計中分離出來，而在有些公司已經在這么做了，這些崗位如插畫師、動效設計師、3D建模設計師等等。

這些崗位的逐漸發展壯大和離開UED，對于UED和整個社會的發展來說，不能算是一件壞事，因為隨著技術發展，崗位分工越來越細，越來越專業化，是一種趨勢，而沒有任何人、任何組織，能夠逆這種潮流而動。

二、UED內部的組織架構

談過了UED內部應該有的專業崗位分工，接下來就該聊聊UED內部的組織架構應該如何建立了。

UED的組織架構一般分為以下幾種，其中每種架構又適用于特定的公司管理風格和UED規模，每種架構方式都有其優點和弊端。

1. 按業務條線縱向劃分

UED完全按業務線劃分的公司，一般來說是各業務條線之間協作度較低，比較重視各業務條線獨立發展的公司采用的一種UED組織架構.

這種組織架構一般造成的結果是UED總體管理組織結構松散，各條業務線負責UED之間的協作性、向心力較差，一般這樣的組織架構下，UED的話語權也比較少。

2. 按專業崗位橫向劃分

一般規模比較小的UED可以采用這種架構，每個專業崗位小組里的成員針對全部業務線承接設計工作。這種組織架構方式在十幾人的小團隊里能夠發揮出最大的能量，團隊成員間的凝聚力，相互交流溝通和學習非常方便；同時每個設計師的能力和專業度都能得到最大程度的提升。

但這種組織架構對UED管理者要求比較高，可能需要承擔項目接口人和具體的項目管理工作，也可以把項目分配權力下放到各專業崗位組leader手中。

3. 先按專業崗位，再按業務條線

這種組織架構方式適合于UED規模特別大的公司（40人以上），這種組織方式的好處是如果在各個專業崗位組配合以資深的管理者，各專業崗位組內可以達到最大程度的專業交流。但同時整個UED的凝聚力又不會被削弱很多，因為一個組內的成員只是一個項目環節上的一環，要完成整個項目，成員必須在各個工種小組之間緊密聯系。

這樣就既兼顧了專業度，又兼顧了業務線的業務背景熟悉，是一種比較有優勢的組織架構方式，以前工作過的一家OTA公司的UED是采用這種管理方式。

4. 先按業務條線，再按專業崗位

這種組織架構方式也是適合于成員較多的UED團隊，UED先按照業務條線劃分為不同的組，每個組內再配備不同的專業崗位，優點是每個組因為僅針對自己負責的業務線，所以對于業務背景了解比較透徹，能夠在業務線內深耕細作，同時因為和固定的業務方協作，執行效率較高。

但這種組織架構也有缺點，一方面是長期運作，可能會被業務方業務指標裹挾而在用戶體驗上損失獨立性，因為設計組的指標和業務方指標會高度重合，而從宏觀層面看，UED的目標和業務方的目標應該是有很大不同的。

此外因為項目基本上是獨立在每個小組內獨立完成，很容易形成小作坊，跨業務組之間的溝通和協作以及向心力會有所減弱。這就需要跨業務組的其他團隊協作項目來作為有益補充，如定期分享、團隊建設活動。

5. 組合方式

組合的UED組織架構就是打亂了原來的單純按縱向業務線、橫向專業崗位劃分的局限，采用一種較為靈活的組織結構方式，比如把人力資源有限且使用頻次較低的部門單獨劃分，把其他部分按業務線劃分就是其中一種較常見的組織架構方式。

這種架構的好處就是公共資源池共享，但又兼顧了業務線的專業度和協作度以及快速反應能力，比較接近谷歌提倡的OKR式組織結構方式，區別就是時效性上沒有OKR小組那么靈活。

6. 按項目靈活劃分小組

這種組織架構方式一般在外包公司或廣告公司采用較多，UED是一個大的資源池和人力提供方，根據臨時進入的項目不同，項目負責人自己招募需要的人，最后按人和項目貢獻進行績效考核，這種組織架構方式對人員的能力鍛煉是非常有效且快速的，但同時帶來的問題就是設計人員會有較為嚴重的焦慮感和缺少歸屬感。

以上列出了目前互聯網公司比較主流的UED組織架構方式，當然不同的公司，有不同的企業文化和獨特的管理方式，不能生搬硬套。

我曾經見過有些從大廠出來到了中小型創業公司的UED管理者，還死抱著以前那“成建制、成規?！钡囊惶撞蛔?，拼命向公司要資源建立幾十人的團隊，結果項目需求根本完全不飽和，造成公司人力資源的極大浪費。

我也曾經見過有些UED管理者從小型公司一路發展壯大后，還是死抱著“扁平化”不放，事必躬親，最后自己非常疲累但團隊卻得不到鍛煉和成長，沒有形成梯隊，一盤散沙的情況。

“我之蜜糖，彼之毒藥”，具體的組織架構方式要具體情況具體分析，用的順手的就是好的，同時也要跟隨團隊一起成長，才能成為一個合格的UED設計管理人才。

三、UED怎樣承接各種設計項目

講完了UED組織架構方式，接下來就要講講UED怎樣承接各種設計項目了。

UED作為一個公共資源池，在設計項目承接、完成、驗收等環節要按照一套標準流程來運行，否則就會產生資源分配不均，厚此薄彼從而導致需求方產生懷疑和意見。

設計資源“不患寡而患不均”，如果在項目安排時按照一套嚴格的，始終如一的標準來分派項目，就會讓整個設計流程有序運行，提升產出效率；同時又不會過分對設計師造成壓力，達到各方都滿意的效果。

在管理UED整個部門時，對組織架構設置的專業崗位組或業務線組leader進行有效監督和管理，在各組leader行使自己權限時，不過分干預；同時了解高ROI的項目進行狀態，進行重點項目有針對性的跟進是比較好的管理方法。

在具體管理一個業務條線組或專業崗位組時，一般都會牽涉到具體的項目管理。

當然有些leader喜歡把負責項目直接安排到人，如果設計資源出現沖突或資源緊張時，再進行調配，這也是一種管理方式。我個人喜歡的管理方式是設計組leader直接做項目接口人，負責項目的分派、追蹤、驗收工作。

在管理設計項目時，可以使用多種方法跟蹤項目進度：

1. 10分鐘站立會

很多公司的開發部門和設計部門在每天早晨上班后讓所有組員圍成一圈相向，然后設置一個會議組織人（一般是leader），一個記錄人員（一般是組員輪值），大家依次介紹自己上個工作日完成的工作和本工作日需要進行的工作，以及在項目進行過程中遇到的問題或獲得的經驗。

因為大家都是站立，所以從形式上也就杜絕了拖延，一般只需要10分鐘左右。

這種方式能讓leader和組員快速掌握每個組員當天的工作安排，同時在資源上可以互通有無，相互支持，這種方式確實是提高工作效率，減少溝通成本的非常好的一種方式。

2. 寫日報/時報

要求組內設計師每天/每小時匯報自己在每個項目上的工作進度，以文字形式發送給leader。

這種項目管理方式是設計師的噩夢，leader的大殺器，一般情況下不能輕易祭出。

因為一方面設計工作是一種創意性的工作，前期素材準備，項目背景、用戶調研、需求分析這些準備工作是非常難以量化的。把設計師時刻捆縛在具體項目上，就如同用代碼行數來考核開發人員，注定要與目標南轅北轍，背道而馳；而且這種管理方式對UED凝聚力、效率傷害極大，一般不建議使用。

3. 周報

如果說日報/時報是方便了項目管理但嚴重傷害了設計師積極性，那么周報就是在這之間形成了一個微妙的平衡。不寫周報，項目進度會難以把控，設計師工作會無法準確衡量；效率高、設計質量高的設計師得不到正向激勵，就會導致劣幣驅逐良幣，導致設計師自由散漫，不利于項目管理。

所以要求設計師每周五總結本周工作，以固定格式發送給leader，以有效進行項目管理。

周報格式有多種，我們使用的格式是：

• 項目名：
• 項目重要程度（以星級展示）：
• 項目簡介：
• 項目進度：
• 項目需求方：

具體到每個公司，周報格式可以有所不同。

4. 項目管理工具

現在市場上有各種各樣的協作工作和項目管理工具，我個人偏好使用甘特圖來管理項目進度。甘特圖直觀、高效，可以快速掌握UED資源使用情況和工作飽和度，同時也方便對項目進入、進行中、完成全流程進行把控。

如果追求簡單，可以直接使用Excel來設計自己的Excel甘特圖項目管理工具（這是我以前公司領導傳授的技巧）：

用Excel生成橫向縱向尺寸相同的方格，以橫向來標示日期，以縱向來標示不同項目，同時凍結日期欄。甘特圖中的不同顏色可以用來表示不同的設計師，也可以用來表示不同的專業崗位、或者設計階段、或者項目類型，以你自己對項目管理的要求來定。

用這個工具即便是非常繁瑣的日常項目或時間跨度非常大的項目都可以進行有效管理，因為顆粒度是天，所以對于特別瑣屑的以工時計量的小項目不是很適合。

如果對顆粒度精確到工時的小項目，可以使用Outlook的日歷管理工具，也是非常方便的。

也可以使用第三方的項目管理工具，如Tower（tower.im），它的日歷工具也是顆粒度到天的項目管理工具，使用非常方便，而且支持多人協作，每個設計師可以自行維護自己負責的項目進度。

通過以上這些方式，可以讓管理者快速了解項目進度，進行項目管理工作。

要應付龐雜的項目需求，還需要對項目的優先級和重要程度進行評定。這個評定可以是完全公開量化的，也可以是以自己的標準根據項目需求特點快速給出判斷，一定要把影響公司戰略目標實現和戰略級的項目區分出來，優先考慮。

一旦確定了項目的優先級和重要程度，就要做到重點項目重點跟進，次要項目選擇性跟進，日常項目放手讓設計師跟進。

四、設計師對專業崗位的角色轉換看法

聊完了UED的設計項目管理，接下來再談談設計師對專業崗位的角色轉換看法。

UED內部主要的幾個專業崗位是：視覺設計師、UI設計師、交互設計師，這幾個專業崗位因為專業間跨度比較小，所以設計師比較容易在這幾個崗位之間做轉換。

在UED管理過程中，發現有些設計師之間，有一條暗的轉換路徑存在：

很多視覺設計師在進行一段時間的視覺設計后，會有轉作UI設計師的想法；而有些UI設計師，卻想著去做交互設計師；很多交互設計師最后轉行做了產品經理；而從交互設計師轉作UI設計師、從UI設計師轉作視覺設計師的情況雖然也存在，但卻相較這條遷移路徑來說，較為少見。

我自己思考了一下這種遷移路徑的現象，同時在和我的領導KK討論后，我們認為這種現象主要由以下幾個原因導致：

1. 視覺設計和UI設計是需求方眼里更容易挑戰的工種

其中，視覺設計是最最容易被挑戰的，UI設計次之，而交互設計一般是黑白稿線框圖，需要更強的邏輯思維和產品思維才能提出意見；所以基于“柿子專挑軟的捏”的心理，視覺設計也就在設計工作中變成了最容易被需求方干涉的崗位。

我們經常拿來調侃的“我想要一個五彩斑斕的黑”、“我想要大氣的設計”、“再放大的基礎上再縮小一點”等等需求方的金句，其實是這種現狀的最真實反饋。

而設計師自己也認識到了這個問題，自然希望能夠更清凈不受干擾地做設計，這種情況下就產生了轉崗的想法，而在我同有這類想法的設計師溝通時，這個原因占比最大。

2. 視覺設計的待遇長期落后于其他專業崗位

視覺設計師因為進入門檻低，所以很多設計師都是從這個崗位起步進入用戶體驗這個領域。

因為進入門檻低，所以行業內長期以來視覺設計師的待遇是低于UI設計師和交互設計師的。而交互設計師這個崗位因為是隨著用戶體驗被公司越來越重視的背景下出現和發展的，它一開始就站在比較高的起點上，所以創業公司和小型互聯網公司一般沒有這個崗位，只要是有交互設計師這個的崗位的公司，崗位待遇一般是比較好的，這也客觀造成了設計師“人往高處走”，追求更好待遇的現實。

但這種現象慢慢也在被扭轉，因為我們可以看到好多大廠和創業公司發出來的JD，對于資深視覺設計師開出的價碼是令人咋舌的；而我認識幾個真正熱愛視覺設計的設計師大牛，在行業產生一定影響力后，都拿到了非常豐厚的報酬。所以說設計師朋友如果因為這個原因想要轉換崗位，真的需要三思。

3. 因為真的熱愛其他崗位

很多設計師是懵懵懂懂進入用戶體驗這個領域的，而在進入這個領域以后，在實際工作中才發現自己更加喜歡另外一個崗位的工作，這種情況也是很常見的。

我認識好幾個UI設計師是因為真的喜歡交互設計所以千方百計想要轉變，但很遺憾的是我內部無法幫他們實現這個目標，最后他們離開后去其他公司轉交互設計，結果都做出了很大成績。其中一位甚至還成了大牛，寫了一本交互設計方面的專著，這個案例也是我一直喜歡拿來跟設計師朋友分享的。

因為興趣愛好是最好的老師，基于這個原因轉換專業崗位的設計師，目標最純粹，所以轉換后也最能快速適應，并做出更大成績。

雖然我的權限范圍內可能因為當初招聘原因和承接項目類型原因等無法讓一個設計師轉崗，但我努力為每個設計師提供嘗試不同類型崗位的機會。

我會要求視覺設計師具備一定的UI設計領域的知識，UI設計師具備視覺設計師的功力和一定的交互設計能力，而交互設計師需要具備一定的UI設計功力。這樣可以讓設計師在日常工作中，可以體驗不同崗位的工作內容，同時可以讓設計師真正了解自己的優勢和特長。這樣的管理方式能幫助設計師認清自己的優勢，而且也讓設計師增加新鮮感，具備全棧能力，而且更加穩定。

所以如果有設計師朋友遇到了類似苦惱，想要向我咨詢是否需要轉變的意見，我覺得這個問題的答案，其實就在每個設計師自己心里：

你真的喜歡這個崗位嗎？你愿意為這個崗位奉獻自己所有的熱情和努力嗎？

如果答案是肯定的，那么義無反顧地去追求自己的目標吧。

人生最重要的追求就是找到適合自己的那個位置，并努力為之奮斗。

以上就是我在多年的設計管理工作中積累的一些經驗和心得體會，希望能夠跟各位設計師leader們一起探討，共同提高。

#專欄作家#

德升，人人都是產品經理專欄作家，平安好醫生UED高級設計經理。

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議