設計崗位的邊界,該如何處理?

2 評論 4506 瀏覽 17 收藏 16 分鐘

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

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

一、模糊專業邊界

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

1.1 思考產品

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

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

1.2 思考實現

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

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

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

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

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

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

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

1.3 思考協同

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

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

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

二、明確崗位邊界

2.1 需求范圍

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

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

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

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

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

2.2 合理的推動邊界

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

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

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

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

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

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

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

三、守住設計邊界

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

3.1 長期跟進的業務

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

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

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

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

3.2 臨時支撐的業務

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

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

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

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

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

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

本文由 @聿來體驗筆記 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. ????

    來自湖南 回復
  2. 說的很中肯,很多時候會遇到這種事。

    來自北京 回復