在與其他業務部門溝通過程中，有哪些工作是自己負責的，有哪些不是，這些都是需要我們明確雙方職責，針對性負責的。作者結合自身經驗，總結了在設計崗位中，應當如何處理好崗位邊界問題，希望對你有所幫助。

邊界感的話題要從試用期的述職PPT說起，有個價值觀和專業的聯系延伸，在中期用了“邊界外延”，轉正用了“底線策略”。近日又有些感觸，索性一起拿來寫一下。

一、模糊專業邊界

作為一個設計師，并不是獨立存在的，是要與產品、研發、測試等緊密配合的。在設計這個節點，為了使業務目標能從上到下的貫徹，需要設計師在專業上有更多的橫向思考。

1.1 思考產品

不得不說，一個整齊、清晰的界面是設計師最大的“門面”，往往在設計階段的后期，我們會花一部分時間去思考如何讓界面更精致，更吸引用戶。

但是在整個設計過程中，界面的表達不會是最主要的部分，重要的是如何去兜住業務，提升體驗，所以在設計之初，我們的主要精力還要前置到產品經理的角色，去思考業務場景是什么？需要打通什么流程，解決用戶的什么問題，解決之后能不能帶來業務上的提升，這樣的思考可以讓設計方案一直遵循需求發起的初心。如果不去考慮產品所處的場景，利用慣性思維處置需求，難免會出現盲人摸象的狀況。

1.2 思考實現

能滿足業務和用戶目標的方案就一定是最好的嘛？市面上不乏很亮眼的頁面和讓人驚喜的交互方式，但是如果該方案放到當下的業務場景下不一定是最適合的。

作者認為，單純從設計表達的角度去評估一個方案是否優良是有失偏頗的。如果一個完全不一樣的方案，同樣可以滿足用戶和業務目標，并且能夠實現，那么它應該比酷炫但難以實現的方案更有價值。所以在真實的項目環境中，除了滿足目標之外，還要符合當前的實現成本（時間、技術和水平）。

所以，我們在設計方案成型或者有了想法后，及時找產品團隊和研發團隊碰碰想法，這樣的話，正式評審時，可以大概率的增加方案的通過率，更主要的是，能快速定位設計方向。從某種程度上來講，團隊的研發和產品也是設計師的“用戶”。其實這也是最開始圖中提到的“范圍內做創新”，在已有的技術范圍內設計。

在最近的項目中進行了設計規范的搭建，搭建之初便定下了三條設計原則：要做、可做、能做。

1. 要做：確實有存在業務問題或者用戶有反饋，才會被納入到改造中，否則就用通用規范即可。
2. 可做：對所存在的問題進行預研，思考業務場景、競品現狀，看是否合理。必要時要與產品共同決策。
3. 能做：平衡設計方案與當前的實現成本，規范的改造設計一定是與相關研發負責人提前溝通過，確實可做，有技術方案，而不是設計師一拍腦袋，讓研發去實現。必要時，設計師應該主動發起規范評審。把自己放到項目中，設計的價值就是能在規定的成本范圍內，為客戶提供滿意的方案。

不過在真實的項目中，也會遇到一些不好處理的事情。團隊內部已經對問題達成了共識，方案也有了，但是卡在了研發側。比如這個方案很常見，競品已經普遍實現了，但是研發就說不好做，或者沒有工期。這個時候應該怎么辦？

如果經過自己的分析確實沒有更好的方案，拉產品做“盟友”，說服他（hhh），或者做兩個方案讓他們選擇，并且闡述當前方案的業務價值以及與競品的優勢，讓產品在評審的時候與研發溝通，讓他們先評估排期或者著手去調研。

1.3 思考協同

交互不止是出出原型，搞一下流程，具體的頁面尺寸或者展示數量等細節，與業務相關性比較大的樣式也需要做一定的思考和定義。因為和UI相比，交互往往是與業務更接近的，交互說明中要給UI相應的設計方向，減少業務目標的偏移。

比如：表格展示中，如果出現了可以拖動列寬的功能，交互要知道不同字段的最小列寬如何根據業務場景差異化定義、歸類，將這個方向傳達給下游設計師，或者直接定義好。免得信息不同步，導致實現后效果不理想。

雖然在說模糊專業邊界，但其實是為了更好的觸及到未知的問題，希望設計師能了解非專業范圍的事情，給設計方案帶來更多的確定性。

二、明確崗位邊界

2.1 需求范圍

從用戶體驗五要素的層級來看，設計介入的范圍是結構層、框架層和表現層。所以戰略層和范圍層的事情，前期的了解是為了能夠更好的貫徹業務目標，絕對不是到了結構層和框架層，設計師再去加個功能，減個流程。

想起來剛畢業做的很多虛擬項目，用雙鉆模型流程走的很全，從市場調研、用戶分析，得到機會點，然后確定需要解決什么問題，做什么流程和功能，最后設計表現。因為是虛擬的項目，所以什么對目標實現有幫助，就會用什么方式。

但是在真實的項目中，往往不會允許設計師去發散功能。比如在一個社區頁面，產品說把這個頁面設計的好看點，現在太丑了，用戶使用率很低。經過設計師的分析，這個頁面只有用戶的基本信息，畫面很單調，而且用戶粘性不高。

于是設計師就加了一個積分的功能，通過登錄次數和瀏覽次數，可以獲得積分，然后兌換獎品。但是這個功能并沒有出現在本次的產品需求清單中，即使有規劃，也不是現在就要去實現，會牽扯到前后端很多的開發細節。毋庸置疑，方案被斃，需要重新搞。

如果沒有按照規定的需求做設計方案，是要承擔延期風險的，代價就是自己加班補，然后被認為不專業（我曾經也這么干過??）。最明智的選擇就是按照產品的需求說明搞，如果沒有詳細的說明，一定要確定好范圍，做好記錄，隨時溝通。

2.2 合理的推動邊界

通過需求清單確定設計的范圍沒有問題，但是有的時候可能在思考業務流程的時候，難免會發現一些產品沒有考慮到的環節或者有更好的處理方式。

在一次批量創建任務的流程中，流程是打開對話框，先選擇任務模版，根據任務模版創建任務，如果沒有模版，用戶仍然可以點擊創建按鈕-創建任務，遵循的是系統的自有規則。

有些用戶沒有模版，看到空選項和頁面難免有疑惑，如果用戶有模版，展示的是空頁面也有點奇怪。因此在頁面設計的過程中，就與產品和研發溝通，系統的自帶規則是否可以設置為系統模版。

• 用戶沒有模版，進入頁面后，默認使用系統模版；
• 用戶有一個自己的模版，則默認用戶自己的模版；
• 用戶有多個模版，則默認系統模版，用戶可以修改；
• 在下拉框的底部給一個創建模版的快捷按鈕，支持用戶在這個頁面跳轉到設置頁創建新的模版。雖然這與需求是有出入的，需要后端處理數據，但是確實為用戶帶來了更大的便利，團隊覺得是值得做的，因此這個方案最后通過了。

如果設計師洞察出了新的問題，但是團隊覺得沒有價值，自己又想推動實施。這個時候可以先去了解用戶，確定設計方案的問題場景是否真實存在，如果不是，那么就要乖乖回去改方案咯；如果是，那就好辦了，收集用戶的意見去和團隊的成員講，或者讓用戶自己去提反饋。

在一些B端的場景，用戶的滿意度往往卡著項目的喉嚨（績效）。另外需要提醒的一點是，如果問題最終沒有與團隊達成共識，就不要操之過急，因為無論方案做的多優秀，沒有共識的價值是不會被承認的。

所以，推動崗位邊界，不僅需要一定的業務和專業積累，也需要失敗的勇氣。

三、守住設計邊界

這個邊界是前面圖片中出現的“底線策略”，如果分個類的話，上面兩個說的都是橫向邊界，而設計的邊界是縱向，這個設計邊界我是從兩個場景思考的。

3.1 長期跟進的業務

在自己長期支撐的平臺，需要保證的是不同時間、不同頁面的相似場景下的產出具有一定的一致性，這應該是我們每次做設計方案的目標之一吧，是個很常見的意識，主要是為了降低研發成本和用戶的學習成本。有很多的大公司為了平臺的可持續發展考慮，做了自己的設計規范，能很好的指導設計師做到全場景的一致性。

如果目前沒有現成的設計規范，設計師心里應該要有“一把尺”，自己的產物：最基本的頁面架構、基礎組件、交互方式和常規流程保持一致性。

當然并不可能一開始就能考慮全面，對于快速迭代的初期平臺，雖然允許設計師有更大的創新空間，但是對于通用業務場景還是要找一個能遵循的標準，比如第三方的組件庫，element、ant，直接拿開源的組件，搭建產品的初期形態，對于業務性較強的場景，可以根據實際需要，做一些創新性的表達方式。一邊做，一邊沉淀，等到穩定的迭代時機，實現整體的設計資源回落。

對于一些要持續優化的組件，比如一開始做的時候沒有考慮兼容性，出現了新的業務場景，需要做調整，這個時候一定要做好記錄，與團隊做好共識同步，是要特殊場景特殊處理，還是要統一更新，做好計劃節點，切莫到處挖坑，不然最后填坑的還是設計師。

3.2 臨時支撐的業務

另外一個場景是臨時被抽掉到其他的業務線做設計支撐，這個時候除了要快速融入到團隊中，另一個要做的是如何讓自己的產物融入到這個平臺的設計體系。

一開始，我做的事情就是上來先挑這個平臺的體驗問題和架構漏洞，一臉鄙夷的問這問那，但是后來卻發現，這并不利于工作的開展。講實話，人家是讓你來支撐的，是為了幫助項目順利推進，而不是讓你指導工作。

那應該怎么做，后來這類的任務做多了，我就總結了自己的工作方法：首先要熟悉這個平臺的業務邏輯，該理的流程梳理清楚；然后根據業務流程走查平臺頁面，熟悉平臺的頁面架構、基礎組件、交互方式和常規流程等，在已有的形態下，形成當前框架的設計總結，即使是漏洞百出的設計也會有自己的特點，掌握好“規律”不僅是為了能遵循一致，還能更好的做系統性優化。

同時記錄我們比較關切的問題，并將自己的記錄與團隊同步，詢問具體的實現場景以及是否要改進，如果不需要，遵循一致即可，往往用戶習慣是不好改變的。如果可以趁機優化，前期的設計走查總結就派上了用場。

以上便是我對設計師成長過程中邊界問題的思考，并不是所有的業務都是想象的那么完美，總會有一部分需要我們通過設計手段做不一樣的詮釋，也并不是所有的業務都是那么糟糕，總會有意外讓設計發揮更大的價值。

總之，練好設計的閉環基本功，才是成長的關鍵。后續也會對設計閉環能力進行總結闡述，希望一起在設計的路上越走越遠。