在B端設計中，設計規范怎么建立才能落實下去之前一直困擾著包括我在內的廣大設計師老鐵們。設計師期望參與產品的每一個角色（產品，設計，前端開發，測試）都能遵循設計規范，結合設計規范內的內容，保證前端開發頁面的還原度。因此從目標來說，其實設計師小伙伴與研發小伙伴的目標是一致的，但是實現起來其實并沒有想象中的簡單。在業務初始階段對業務不熟悉，盲目就著手建立規范其實并不是一個明智的選擇，很多B端的萌新小朋友會在業務尚未明確情況下就從第一個版本就開始制定設計規范，這會蘊含巨大的風險在里面，也不易推動落地。在初期有限的研發資源里只有了解了業務的實際場景，針對場景進行深度思考與分析，與規范涉及人員進行深度溝通統籌各方面資源，才能最后形成一套可以落地執行滿足設計標準和業務需求的設計規范。

目錄

01.B端設計為什么要制定設計規范？

02.什么階段適合建立設計規范？

03.推動規范需要像需求一樣去迭代！

04.B端的設計規范需要整理那些東西

05.搭建組件庫你需要知道的幾件事！

06.如何輸出規范？

07.整理設計規范對個人的影響！

對產品來說

搭建原型可直接調用組件庫，能搭建出高保真的原型。與設計師溝通更加順暢，小的修改可以直接和開發溝通不需要通過設計師出圖，極大增加了前期的節奏。

對設計師來說

當同一個項目由多個設計師共同協作時，由于設計理解不一致等各種原因都會出現設計控件使用混亂等問題，此時為了保證設計各方面統一性需要一份設計規范做引導。

對開發來說

按照設計規范建立好公共組件庫，開發效率提升有了明顯的提升，可復用的東西確定了下來不會頻繁改動，設計走查的問題也會逐漸減少。

對測試來說

模凌兩可的交互可以有地方看交互樣式了，不需要再詢問設計師。有更多的時間專注于測試功能上的問題了。

過往，設計師一般默認在啟動一個項目的初始階段進行設計規范的制作，具體時間點跟著版本節奏走。在1.0版本之前就著手規范的制作，其實這是很欠缺考慮的做法，其中蘊含著極多的風險因素在里面。此處分享個人工作中兩個比較建議的規范建立時間點供大家參考。

2.1 業務處于探索期

在初始版本開發并未制定相應的業務組件。規范主要涉及到色彩，字體，間距，布局，柵格等通用設計原則以及常用業務組件的定制。此階段搭建的規范具備高效性以及靈活性的特點，由于尚未搭建特殊的業務組件（當領導想要突然調轉方向也不會很慌，改動較小就可以完成整體的規范轉向）此時搭建規范組件庫需要考慮到預留后續更改的空間。 

優點：靈活，滿足業務隨時更換的需求

缺點：體量小，僅能支持初步業務場景

2.2業務處于成長期

當業務已經迭代幾個版本后，整個團隊對業務的理解都不可同日而語。產品也正到了較為穩定的版本，此時若提出搭建組件庫可以結合業務設計出符業務場景的樣式，每個符合當前業務的組件邏輯和樣式都不是初始階段憑空想象出來的，當產品有一定的發展，有足夠的業務邏輯，積累足夠的業務場景，才能設計出有著自身業務的完善組件庫。

優點：可以依據反饋沉淀組件庫，發展到一定階段整體變數不會太大

缺點：0-1階段需要設計師對整體業務設計有比較足的把控力

我們公司在2020年初開啟的項目，目前已經過了探索階段處于向成長階段過度，當時正值疫情高發整個項目都由我個人負責。現階段整個公司在今年第四季度把系統性的產品和服務競爭優勢提上了日程，畢竟沒有設計規范對整個業務底層設計架構進行指引是很難做好產品差異化和規范化。也是趁此機會，設計可以針對性對現有的業務組件庫以及規范進行一次全面的復盤，迭代出一個新的版本，在團隊內推動落地以便更好適應產品的發展。

3.1做好產品定位

在B端的項目評審時，設計師就需要做好B端的用戶畫像，弄明白產品的目標用戶以及使用用戶的區別，他們通常并非同一類人。除了目標用戶的差異外，不同用戶的使用場景也是不一樣的。只用弄清楚了各個角色的關系以及功能設計的邏輯，具體用戶年齡，解決什么問題，才可以產出符合用戶需求的設計。

3.2整理規范的內容和分類

在制定規范前，需要明確產品中主要有哪幾種分類，將最基礎的分類定義好方便后續針對分類內容進行整理。B端產品與C端產品既有共同性也有著很大的差異化，可以借鑒但是切忌生搬硬套C端的設計規范。

3.3排優先級嵌入版本迭代內

一套完整的規范蘊含內容是非常豐富的，將程序小哥的頭發全部薅完也難以在1個版本迭代里面改完的。因此我們需要將自己作為設計規范這個項目的產品經理，針對現有的需求進行拆分，并排出優先級分版本迭代進產品里面，我們可以依據從大到小的原則進行優先級排序。對產品設計風格影響大的先排，影響小的后排。那么針對我們業務優先級排序是：設計準則＞框架布局＞組件＞控件＞場景。當然設計規范的制定不單單局限于設計團隊內部，在嵌入版本里面時可與產品和開發多溝通，以便達到更好的落地效果。

上面的場景是否很熟悉，開發小哥每天都得忙很多的事情，如果不用線上文檔進行同步的話，他們可能轉頭就會忘記哦～

4.1 頁面布局

統一設計尺寸

據統計，目前 PC 端用戶屏幕分辨率占比排名前三的是 1920*1080、1366*768、1440*900，以 1440 來設計的話是一個比較合適的尺寸，向上適配或者向下適配誤差會比較小。

頁面框架

主流頁面框架主要分為左右欄布局和上下欄布局。

左右布局：頂部菜單欄、左側菜單欄為固定結構，右側主體內容根據分辨率進行動態縮放。

上下布局：頂部菜單欄為固定結構，主體內容進行動態縮放，需定義兩邊空白區域寬度

柵格布局

柵格系統的使用是為了解決自適應和響應式問題，從而更好地進行產品設計和產品開發。響應式柵格常采用 12和24 列柵格系統實現，以滿足 2，3，4，5，6 分比布局等多種情況。固定寬度 Column，將間隔 Gutter 進行動態縮放。

• 網格（Grid）

• 柵格總寬度（Container）

• 列和槽（Column&Gutter）

• 邊距（Margin）

• 區塊（Col-n）

  
  

我們的產品是在1440px的框架下進行設計的，采用左右布局的形式，將左側菜單欄（100px）以及間距（24px）減去以后，就是自適應的內容區域（1292px）

4.2顏色/字體

顏色

主色的選擇，需要依據使用人群，目標用戶，使用場景，產品屬性等因素綜合進行考慮，在顏色使用上B端與C端的目的并不相同，C端顏色使用更大膽自由一些，以抓人眼球為主。而B端端使用則是以輔助產品功能為主，需要遵循對比原則，提升產品易讀性。

小例子：以我們產品舉例，在定義主色之前我向產品要來了關于用戶人群的調研報告以輔助我去推測目標人群以及使用場景，并通過相關平臺（七麥網）（艾瑞網）去找到競品的行業報告。這些資料不僅可以幫你定義產品使用的顏色，還可以輔助你進行風格的定義，將這些報告放入評審的會議里面可以極大增強設計說服力和專業性。

通過鯨準與艾瑞網等數據相關網站可以輕松獲取行業內的一些基本數據，這些數據足以讓我們進行用戶畫像的初步建立了。

在規范好顏色以后，需要與前端進行同步，將顏色賦予單獨的編號，方便雙方就顏色上達成統一。如下圖所示，一個編號對應一個RGB色值。

字體

B端頁面可讀性很大程度是由排版所決定端，而在排版中文字更是重點中的重點。

字體選擇

在參考相關線上的成熟產品后，發現字體的渲染是一個很復雜的過程，首先我們需要知道在Web世界中存在著五大字體家族，江湖人稱font-family：serif、sans-serif、monospace、cursive和fantasy。

font-family規定元素的字體系列，可以把多個字體名稱作為一個“回退”系統來保存。如果瀏覽器不支持第一個字體，則會嘗試下一個。

在實際使用場景中，用戶的電腦一般是PC和Mac，但是這兩個平臺的屏幕材質、渲染方式都不一樣，所以使用的默認字體也是不一樣的。PC默認使用微軟雅黑，而Mac默認使用蘋方。

當我們打開一個網站，瀏覽器會讀取font-family中的字體名稱，并去檢索用戶電腦系統中的字體，如果有的話就顯示，沒有的話檢索下一個。

字號與字重

字號的選擇有多種方式進行參考，比如等差遞增和等比遞增的方式。我們自身在字體選擇上選擇由4為基數進行等差遞增方式，在定義字號大小時默認采用偶數。

字重的功能是為了在文本種突出重點強調內容，在文本中常采用3種規格的自重（regular，Medium，Smlbold）

設定標題一律采用Medium

正文一律采用Regular，強調內容采用顏色區分大于字重去區分。

在使用字體時，我們需要判斷其與背景色的對比度是否符合WCAG2.0的最低標準，即3:1，此處我們可以在創建文字樣式時將標準標注進去。當我們使用文字樣式的時候就可以隨時提醒我們不要濫用。

4.3分隔與間距

在日常工作中，會常常出現多個小伙伴協同工作時采用的間距不一致的情況。雖然之前有進行口頭上的統一（采用8px為基數）進行設計，但是還是會出現同一情況間距不一致的問題。在參照現有的成熟系統以后，依據親密性原則與格式塔原理整理出符合現有業務的間距規范。

我會將間距分為豎向間距與橫向間距。為了方便管理與溝通我會將他們進行尺寸上的區分（XS、S、M、L、XL）。

豎向間距：常用于模塊與模塊之間，一般采用24px，32px，48px

橫向間距：日常設計中使用頻率最高的間距，一般出現在組件與組件之間

4.4 圖標規范

B端設計和C端設計里的圖標無論是從功能，應用場景，圖標的狀態等方面都有非常大的差異，如果按照C端的方法去繪制B端的圖標那簡直是費力不討好。在之前做C端的圖標時常常需要考慮精致感與氛圍營造，而B端圖標功能則是降低用戶認知為優先。為了方便圖標端管理我將圖標分為兩大類型，分別為基礎圖標和業務拓展圖標。且圖標規定在3種尺寸分別為：XS=12px / S=16px / M=20px / L=24px以方便業務隨時調用，且遵循偶數原則。

基礎圖標 ：常規圖標，復用性高且出現地方多

業務拓展圖標：依據不同業務場景進行定制化的圖標，常常跟著業務走

圖標尺寸規范

與間距類似，將圖標同等進行劃分等級。12號字體搭配外框為12px 圖標；14號字體請搭配 16px 的圖標；16號以上的字體搭配 20px 圖標，以達到更好的視覺效果：

keyline

通過keyline我們可以保證繪制不同形狀的圖標的一致性，在keyline的基礎上畫圖標時基線可以給予我們一定的參考避免圖標的比例失衡。可以說keyline是圖標的柵格也不為過。

業務圖標制作規范

除了常規基礎圖標外，針對業務場景制作的定制化圖標如果不加以限制就會顯得五花八門非常雜亂。當圖標數量增加到一定程度時就會出現同一表意圖標有不同的樣式結果。因此有必要在保持圖標美觀易讀的前提下對業務圖標進行規整。

圖標命名規范

隨著業務增多，團隊內之前的隨意命名的習慣也開始凸顯出弊端。在圖標規范中，業務圖標需要將每個業務區分開，每個業務都有著單獨的后綴，這樣可以讓公用圖標與業務圖標更方便的溯源。

圖標的圖層整理

著業務線拉長，涉及的團隊人員也越來越多。簡潔整齊的圖層不但能提升團隊效率還可以讓會影響接手工作小伙伴的心態。所以圖層整理還是得納入規范內的，此處不進行具體規范僅做提醒和警示作用。

圖標交付/iconfont

在與前端開發溝通達成共識，圖標制作完成確認后，將圖標上傳到阿里巴巴圖標庫中，更方便前端調用圖標大小和調整顏色。如果開發需要自己去找到相關圖標，也可以給予權限讓開發從藍湖上傳圖標（前提是得整理好圖標到藍湖上）

5.1組件庫到底是什么？

組件庫常可以類比于常玩的樂高玩具，每個組件都是積木，而產品相當于我們拼好的模型。我們可以根據業務需求，以“搭積木”的方式，讓“模型”快速拼起來。但是并不是說我們可以隨心所欲搭建積木，至少需要看一看“說明書”，而這“說明書”就是設計規范。產品、組件和規范差不多就是這樣的關系。

5.2搭建組件庫前需要知道的小知識

原子設計/拆分

在業務已經發展到一定體量情況下，需要將項目中具備服用行以及拓展性的模塊進行拆解，對于B端產品來說篩選的時候會依據之前迭代的版本內容，把頁面一一羅列出來，將可替換與相似的模塊提取，并利用思維導圖的方式統一歸納，并做成可以被替換的組件。組件的替換建議合成一個大的排期進行替換，避免了線上組件不一致導致體驗問題。

以我們產品為例：

依據產品類型將組件拆分為：基礎組件 、業務組件、數據可視化組件、常用模塊。

原子設計

將產品拆分后，此時得到很多可復用組件。我們再依據原子設計理論針對性進行拆解直至拆分出5個層面

• 原子（元素、要素）

• 分子（組件）

• 組織（模塊）

• 模板（原型）

• 頁面（填充內容）

從原子開始重新依據定好的視覺規范進行更改，再由原子組成新的分子。

盒子box

在與開發小哥溝通設計規范制定的過程中，常提到他們寫CSS樣式的時候是采用盒子（box）去寫的。通過一個個盒子填充來將我們的組件元素放入其中，最終形成前端展示的頁面。

走查時使用瀏覽器我們也可以看到開發寫的盒子，了解盒子也可以方便我們走查時知道問題在哪。

5.2按鈕

按鈕設定有五種類型：主按鈕、次按鈕、虛線按鈕、文本按鈕和鏈接按鈕。主按鈕在同一個操作區域最多出現一次。設計師可以依據自身業務屬性，針對性修改按鈕的圓角大小與描邊，圓角曲率越大越柔越小越硬朗。除了按鈕狀態，在制定規范時還需要考慮到按鈕的其他情況。比如按鈕在放大使用時圓角曲率的變化。

按鈕的尺寸規定

常用的按高度可設定為：24px、32px、40px、48px，超出48px的按鈕都屬于特殊按鈕，需要進行單獨設置的，寬度隨著內容區域自適應。常規的按鈕可分為：主要按鈕（Primary Button ）， 次要按鈕（Secondary Button），虛框按鈕（Dashed Button），失效按鈕（Disable Button ），危險按鈕（Danger Button），文字按鈕（Text Button）等，對照著不同使用場景靈活運用即可。

按鈕的自適應

按鈕與按鈕間的間距隨著網頁尺寸變化而變化，常設定幾種斷點規格進行選擇。

5.3表單

表單承載著采集數據信息的功能，是用戶在數據輸入的核心模塊之一。表單基礎單位是由標簽，輸入框，填寫提示，操作按鈕構成。一行行列表單位組成表單界面。

常見的組合樣式

據統計，表單內常見的組件樣式有：文本框，文本域，選擇器，開關，checkbox，radio，步驟條，上傳/下載，標簽頁等。組件類別繁多，在選用組件時需要考慮其排布形式，在多列表情況下會著重描述這一點。

單列表單與多列表單如何選擇？

在web頁面內，在左側導航條較小情況下會導致右側輸入區域空間較大，縱向空間不足的情況。若此時業務需求輸入內容較多且難以采取分模塊，分步驟交互時，采用雙列或多列表單的形式提高空間利用率也是可以接受的。（ps：可以參照菲茲定律，采用多列的形式需要著重考慮文本框內容長度以及表單間間距的合理性）下面以自身業務為例子，列舉在工作中多列表單出現的一些狀態。

多列表單極端情況

采用多列表單后，隨著復雜程度提升會出現各種各樣的情況，此時設計師還需考慮到極端情況下表單顯示問題。如標簽過長規則（標簽最好在最初階段進行限制），帶按鈕如何進行換行，屏幕分辨率改變如何進行處理等。建議由設計師制定規則時與前端小哥進行深入溝通，以保證最終的落地效果。

讓表單具有節奏感

之前我在表單寬度沒有進行有意識的規范，導致整個表單呈現一種無序狀態，通過有意識控制表單的寬度可以使我們對整體頁面有著更好對把控，整體對品質感得到提升。可以對現有業務的表單進行梳理，整理出適合自身業務的表單長度單位。此處推薦閱讀Ant_Design《整齊劃一？不如錯落有致》相信你會有更深的理解。

5.4 表格

表格，常用語展示數據，用戶既可以在表格里面獲取信息，也可以在表格內進行數據輸入。相對于表單，表格可以進行多維度的數據整理與分析。其難點在于表格的組件交互聯動多，以及數據展示的形式多。表格的信息密度很高是我們在B端頁面設計中涉及最多的一個組件。

表格的構成

為了方便記憶，個人將表格分解為2大區域分別是：操作區域以及信息展示區域

操作區域：標題，工具欄，操作單元格

信息展示區域：表頭，信息展示單元格，分頁控件

表頭與單元格

表頭：表頭分為帶選框與不帶選框/帶icon與不帶icon，需要注意的是表頭上文字表意要清晰，簡潔的表頭能讓用戶更快明白此列的內容。此時需要與業務方溝通限制字數，若字數過長無法刪減，則可以考慮使用tooltips。

單元格：在與開發溝通后發現，開發在寫表格時并不與我們設計師的邏輯相仿，設計師在設計表格時是依據行與列的思維進行表格的設計，而前端則是通過許多的</tr>標簽與</td>標簽進行堆砌而成。因此在設計時將單元格規范好，前端將更容易還原好表格。

表格在頁面中的樣式規范

一般來說，表格內組件功能復雜，為了提升整體表格統一性與設計效率，我整理了業務上幾乎所有的表格樣式。整理需求后發現幾乎所有的表格蘊含序列號與復選操作，故整理了一套通用表格規范以供小伙伴們參考。常規頁面通過柵格，由列的數量決定列寬，與現在的主流框架組件一致；特殊頁面可以與前端溝通后，在設計稿里面標注某單元格進行固定寬度，其他百分比縮放進行處理。

業務中表格的常見問題

此處僅提出幾個個人業務中常見情況，更多的表格問題解決方案推薦查看CE青年《B端設計指南06 - 表格（下） 》。

有些特殊字段采取左對齊不美觀該怎么規范對齊方式？

常規文本字段：可點擊的字段、普通文本類、數字字母等，此類長短參差不齊的，建議采用左對齊的方式

特殊字段：日期、時間、字符數一致且比較短可控的，建議與表頭居中對齊

業務字段：金額、狀態標簽、類型標識等業務性較強的，可根據相關特性與閱讀習慣確定對齊方式

文本內容過長怎么解決？

當表格列數過多或者橫向數據過長時，難免出現單個單元格內數據展示不下的問題，此時常采取換行的方式處理。（ps換行處理后的結果需要與后端溝通好，避免出現換行不分字段的情況）

單元格內操作項數量不一致時，該怎么處理？

此處建議采用平鋪式進行處理，此方式適用方式比較廣，穩定性較高（親測）

將所有操作按照一定的預設排列順序進行平鋪，這種方式能夠適應B端的大多數場景，將操作都簡單平鋪出來雖然看上去簡單粗暴，但是在實際工作中，也是一種不錯的處理方式

每一頁表單展示多少行合適？

如果你經常與開發打交道你就會發現，開發對表格信息的處理邏輯是通過逐行從上到下進行渲染處理的。如果不對行數進行特定的規范，那么開發可能會采取漸進式加載（用戶通過滾輪下滑的方式滾動到末尾再進行下一批量的數據加載）來解決表格內容過多的問題，這就會導致體驗上的不統一。可以梳理當前業務，遵循盡量不讓用戶過多滑動為原則定制每頁的行數。

5.5彈窗

B端業務中使用的彈窗主要分為模態彈窗和非模態彈窗，其最大區別在于對師傅會打斷用戶的操作流程，模態彈窗會要求用戶必須給予操作。而非模態彈窗不會打斷用戶當前操作流程，僅僅起提醒用戶的作用，非模態彈窗常常過一段時間會自動消失。

常見的模態彈窗有：對話彈窗，表單彈窗分，分步彈窗等

常見非模態彈窗有：通知，全局提示，警告提示，氣泡提示，文字提示等

彈窗依據柵格自適應

為了方便規范系統內等彈窗位置和大小，將彈窗作為一個單獨模塊進行處理是一個不錯的選擇，業務中彈窗的性質一般都是橫向居中展示。將彈窗納入柵格體系中。前端小哥可以讓彈窗的寬度隨著列寬的大小變化而變化。

5.6組件庫如何進行迭代

當我們把第一個版本組件庫搭建完成后，對于它當更新和迭代需要依據業務當發展不斷去維護。建議設計團隊內有規劃有目地去維護組件庫當多樣性，以保證組件庫能隨著業務的發展一起成長起來。因篇幅原因，此處遍不細講此部分內容，如果大家感興趣后期可以再單開一篇講講組件庫的迭代流程，此處附上有贊的組件庫迭代流程供大家參考。

小總結：組件庫需要保持簡潔和清晰，不能為了做組件而做組件。最好的狀態是適合業務當前需求的狀態，組件在于精細而不在于數量。臃腫對組件庫不但不能提升整體團隊效率，反而會拖垮整個工作的節奏。

搭建設計規范和我們日常處理工作需求類似，并非輸出一份文檔就結束了。我們還需要將做好的設計規范推廣給包括設計小伙伴，PM和開發小伙伴的團隊內外，并且需要得到團隊內的一致認可才算是初步完成。

如何推廣給PM

利益點：提升協作效率，減少工作成本

在啟動設計規范的整理之前，內部宣講讓PM對于設計規范的搭建已經有了一個基礎的概念。否則也不會分配資源給予時間去搭建整體的設計規范。可以通過提升PM與設計的效率和降低原型搭建成本去切入，通過組件庫以及通用模版的搭建PM只需要極低的成本學習一下組件庫怎么使用（我們的PM是使用sketch搭建原型）即可搭建高保真的原型界面。甚至完善好組件庫后直接不需要設計的參與，開發通過原型組件庫搭建頁面。

設計團隊內部如何推廣

利益點：提升設計效率，減少人力損耗

設計規范一般由團隊內小伙伴共同制定，基本上已經對規范的優勢達成共識。因此主要講講如何更好在團隊內部使用規范。

Library共享+更新日志

通過Sketch Library 共享組件庫，并建立更新日志規范項目流程提升效率。

研發團隊內容如何推廣

利益點：封裝組件，更少的更改，縮短研發流程

需要研發團隊認可設計規范，前期前端的參與是必不可少的。在制作規范時設計師了解了前端開發的一些簡單原理，前端開發也能及時了解設計師的想法，大家不再是各司其職而是串聯起來共同協作，當規范確認下來前端就不會頻繁改動組件，而且在有限的項目時間中。設計規范的統一極大縮短了設計和前端開發所需的時間，為后面的項目爭取了空間。

小總結：本人時常聽到一些小伙伴的反饋在公司內部設計師的話語權不夠，公司不太重視設計。其實總結下來就是專業性得不到團隊內的認可。設計師在工作中如何體現自己的優勢是通過一次次的需求業務來體現的，許多小伙伴在做業務時既沒有前期調研，也沒有進行資料收集僅僅只是悶頭開始動手做，往往結果不會太好。在處理需求時團隊內部的同事也是可利用的資源之一，多與他們協作獲取業務相關的信息，不僅能幫你站在全局的角度去思考這個業務，而且能讓團隊內部成員具有參與感，輸出的結果當然更容易讓他人認可。

收集信息能力

通過整理規范，需要收集目標用戶，使用場景以及前期調研等眾多資料，此時我們需要去發現信息以及整理信息。這一點在日常工作中也常常被使用到，日常中我們在做需要時也需要不斷去挖掘相關對信息才能從容解決問題。

歸納總結能力

將收集好的信息進行分類整理，這要求需要一定對邏輯性。在設計基礎框架時合理對分類可以協助我們處理好每個控件對層級，這項能力無論實在工作還是日常中都有著巨大對好處，可以幫助我們從一堆繁雜的事物中“提綱挈領”，換言之就是“化整為零”，做減法，提取出最關鍵對因素。

全面復盤能力

將信息歸納整理好后，需要對全局進行思考，全局的交互都需要考慮到位，比如什么情況下適合跳轉頁面，什么情況下適合給與用戶彈窗。大體符合什么交互原則。除了對大體交互需要考慮到位，細節上也不可以忽視，比如異常情況，極端情況該如何去處理，組件之間該怎么去配合等。在日常工作中我們也可以逐漸有意識去培養此類技能，對項目全局思考的越多，那么對整體項目對把控能力也就越強，與他人合作也會越顯得專業。

表達能力

在整理設計規范時，難免會遇到模凌兩可舉棋不定的時候。此時可以尋求向上或者向下的資源尋求幫助，具備良好的表達能力能迅速幫助我們將問題闡述清楚，我認為表達能力是設計師需要具備的重要技能之一。每次在求助它人或向他人匯報，都需要在全面復盤問題過后做到心里有數，將問題自己復述一次是否有漏洞或者沒考慮清楚的地方。長此以往你表達的事情會更清晰，別人也更容易聽懂你說的事情快速理解內在邏輯，那么說服別人推動工作的難度也會越小。

溝通能力

在多次與他人溝通，個人認為是對我本人幫助最大的能力了。我總結了幾個和上下游溝通的小技巧希望能幫助到小伙伴們，在開始與他人溝通之前我們需要搞清楚我們溝通的原因與對象。

原因里面包含：

包含為什么要進行溝通？（推進項目還是告知）

想要達到什么結果？（自己能做多少妥協，底線在哪）

預判對方對這件事持什么態度？（支持/反對/無所謂）

希望對方做？自己的目的是啥？（求助還是說服）

對象里面包含：

和誰溝通？（上游還是下游）

他們對這件事了解多少？（比我多還是比我要少，需不需要簡單講解一些）

當然在溝通時還需要考慮方式和語氣，這些都需要好后斟酌。也遇到過情緒不太好的開發小哥，這個時候反倒我們更不能將情緒激化，一般這些情緒化對態度過一會都會消散，可以采取冷處理等情緒過后換一種方式溝通看看。

文章來源：站酷   作者：Weiyehe 

藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務