設計師如何在小需求中體現價值

0 評論 865 瀏覽 7 收藏 10 分鐘

當我們日常大部分時間都在面對小的業務需求,且日常工作的細碎需求較多,該如何提升自己呢?本文就這個話題展開分析,一起來看。

最近有小伙伴提到:“我畢業后就在這家公司了,大部分時間都面對小的業務需求,日常工作也是細碎的需求較多。3年下來了總感覺自己沒有提升,請問在這方面有什么好的建議么?”

今天我們就來聊聊這個話題~

01 調整心態

小的業務需求是我們設計師日常工作中經常遇到的,把這些小需求做好其實并不是一件容易的事。

很多人覺得這些小需求做起來沒有價值,而是戴著有色眼鏡覺得它很“無趣”,認為對自身的專業提升沒有太大幫助。

“沒有小角色,只有小演員”。

這句用于演員身上的話其實也可以用在我們設計師身上。小需求的解決本質是工作職責的一部分,我們首先需要調整的是自己的心態(畢竟我們是一個合格的職場人,需要認真對待工作),建立工作的責任心,要有信念感。這句話還真不是雞湯,設計師的作用是憑借自己的專業能力促進業務目標的完成。我們需要考慮的更深遠些,學會給自己加戲。

學會放大需求!

不能把目光局限于表項的業務訴求,我們需要從專業的角度去審視它,可以按照設計的前、中、后3個階段來拆解。

02 設計前

2.1 提煉業務目標

小的業務需求與大的需求相比,通常在體量和復雜性上存在差異。這可能導致在日常設計工作中,我們容易低估小需求的重要性和潛在價值,因為這些項目看似簡單,可能只涉及小的界面或功能點的優化。

我們經常會因為這些看似的簡單而忽略它的業務目標。日常工作中過于專注于這個需求任務的執行,而忽略了核心問題:這個小需求的背后的業務目標是什么?是不是只要按照需求方想要的效果直接按照產品的思路實現就好。最終我們會發現如果沒有明確定義的業務目標,設計思維通常會停留表項,產生結果的偏差,因為真正的問題并沒有解決。

因此,為了深入挖掘小需求背后的價值,我們首先得看產品的業務目標。

那我們該如何提煉業務目標呢?

小需求背后的業務目標是產品業務目標的延續,我們可以利用 MECE 法則對其目標的進一步的細化,拆到足夠的細致。

例如我們產品大的業務目標是提升云計算平臺的安全性和數據隱私。那么我們需要關注實現目標所需的關鍵模塊,這包括用戶訪問、數據傳輸、身份驗證等模塊內容。再將這些模塊拆為小業務目標。對于 “提高用戶數據隱私保護”,可以拆解為 “增加數據加密標準” 和 “改進隱私政策和用戶許可管理”。為每個小業務目標確定具體的改進措施。

在 “改進隱私政策和用戶許可管理”方面,我們可以優化隱私政策文檔,提供更清晰的用戶許可選項。

是不是覺得自己每天接的小需求的目標清晰了些。

2.2 挖掘需求場景

知道了這個需求是為了滿足不同角色什么樣的業務目標后,我們就要進一步明確方向,即找到核心的需求場景。

組織架構中涉及這個功能模塊的干系人是誰?在什么樣的情況下提出這功能模塊?想解決什么問題?這個問題發生的頻率多大?這個功能與上下游的工作流程的關系是什么?

上述的一連串問題需要我們主動詢問,多問幾個為什么。有同學會有疑問,產品需求文檔不是已經把這個功能點講清楚了,直接照著做就好了么,還浪費什么時間,這不是影響工作進度么。

實情還真不是這樣!

產品與業務方在專業知識上是不對等的,業務方有時候并不清楚自己提這個需求最終在產品中如何呈現,產品有時候也未必理解業務方真實的含義,因此業務方的需求需要經過再次分析才能判斷“虛實”。

在此我們可以借助5W2H 分析法來做好需求場景的判斷工作,有關該分析法的詳細內容在我之前的文章《交互設計的技能清單》有所涉及,這里不做贅述。

03 設計中

3.1 加強視覺價值

對于我們 B 端產品體驗而言,交互是一種必備但很難在產品中證明的能力。很多設計師花了大把時間,可能在產品眼里就只是對于原型圖的優化而已。

在一個大的設計團隊內,眾多產品體驗設計師的內卷中,想要證明自己的交互能力遙遙領先是一個成本極大的事。而視覺能力強對于設計師而言則可以做到錦上添花。

我們需要再團隊內保證交互設計能力不存在短板的情況下,加強自身的視覺價值。特別在我們工作中假如總是接到小的業務需求,更是應該在短時間內把自己的價值展示清楚。

這里“不弱的交互能力+較強的視覺能力”則會成為你的加分組合。

可能有同學會有疑問,B端產品不是更應該重視交互么,為什么還需要視覺能力?

設計表達對于咱們設計師而言至關重要。畢竟咱們也是設計師,僅僅“能用”的設計方案不不夠的,我們還需要盡可能的做到“好用”,界面設計也是我們的基本功。本著“美觀即實用”的法則,不能因為設計稿的平平無奇影響別人對我們專業能力的判斷。

3.2 沉淀業務組件

當公司的產品變多,業務方向越來越清晰,設計團隊逐漸壯大,我們接觸的業務需求足夠的多時發現這個模塊的組件樣式好像跟另外一個模塊中的組件樣式有略微的區別,這時我們要意識到可以沉淀業務組件了。

首先我們把各功能場景中反復出現的樣式進行匯總,結合部門內的通用組件進行二次優化,將其變為滿足業務需求的業務組件。

通過業務組件的封裝沉淀,可以降低開發成本,避免大量重復且無意義的工作,保證產品體驗的一致性。

04 設計后

設計稿交付后不是意味著與我們沒有關系了,我們仍要繼續跟進。

有時候我們經常會遇見這個需求的設計雖然小,但是對于我們而言很重要,體現了我們的工作量,但從開發的角度來看則不是這么回事了。這是因為在產品開發進度中,設計的優先級存在差異,如果它不是核心內容,可能優先級沒有那么高。

一個簡單的需求設計,我們交付的是幾個頁面或者幾個圖標 ,看起來簡單但假如開發不認可你設計的重要性,對這個需求價值懷疑,開發周期緊張的話則會選擇不做或者往后延遲。這時候需要我們與開發頻繁溝通,予以他們充足的支持,比如幫助他們尋找競品類似場景的實現效果或者組件資源,也可以自己主動掌握一些開發的嘗試和技巧,協同開發一起推進設計效果還原度的實現。

寫在最后

業務需求雖小但復雜度一點不小,我們需要利用好每一次小需求的機會展示自己的設計能力,通過對小需求的賦能更好的展示自己的價值。

以上只是我針對如何在小需求中展示價值的個人感悟,希望該文章對你有所啟發,也歡迎感興趣的同學一起探討~

專欄作家

江鳥,微信公眾號:江鳥的設計生活,人人都是產品經理專欄作家。8年互聯網行業經驗,擅長體驗設計思維、設計方法論、交互設計研究。

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

題圖來自 Pixabay,基于 CC0 協議

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!