B端設計|設計落地

編輯導語: 對於B端設計來說,哪些因素會對設計落地產生影響呢?本文作者從需求內容、功能流程、資料資訊、設計執行力四個方面對此作出了分析,一起來看一下吧。

B端設計|設計落地

最近看到一些關於B端設計的一些作品集,引發了心裡的一些對B端設計內容的想法,從B端設計的一些影響因素和和各位討論下設計落地的觀點。

首先對於B端設計而言,個人觀點它是有門檻的,這個門檻其一是對專案業務的瞭解;其二是B端設計是很商業行為(老話長談);其三目前來看B端設計沒那麼高的視覺美觀度;其四設計師個人能否接受不好看的設計頁面。

B端設計還是需要落地的設計,落地影響要素大體分為以下幾種:

也很希望設計師能把自己的設計內容當成一個產品來看,不要極度完善美化它,溺愛終究不能茁壯成長,必然經過跌跌撞撞前行。

一、多變的需求內容

需求主體:需求主體來源是產品經理其次是市場部門再次是甲方客戶(設計基本接觸不到)。

一個成熟的需求必然是有一個成熟經驗豐富的產品經理,來應對多變的需求訴求,設計師的任務就是將產品需求(產品會將使用者需求整理成產品需求的)轉化為設計需求(設計將產品需求落地,整理成設計執行需要的需求),為己所用。

1. 外因:需求變化

個人經歷來看設計推進是個迴圈往復的過程,這個時期可能是重複否定的過程,否定的原因有設計側、產品側、開發側,共同的原因是來自需求的變動,要重複調整設計內容,具體到頁面的佈局,以及考慮基本的優先順序等等。

1. 外因:需求變化

同時這個短板過程也是因為對專案瞭解不夠深入,考慮不夠周全,可能會有“怎麼會有這個問題”、“原來可以這麼個設計方式”等等此類疑問。由此不斷豐富自己,完善內容過程。

2. 內因:需求理解

這裡更多是設計和產品的“博弈”,關於設計內容的“價效比”的討論。產品經理要求的是短平快,1+1+1模式,而設計師容易陷入做細做深的死角0。5+0。5+0。5+0。5+0。5+0。5,完善中間步驟。比如說異常提示,警示提醒等,這就是放大了使用者操作範圍。而產品經理是直接控制操作範圍,直接為目標服務。

二、功能流程多變

這裡更多的是在提功能的操作方式、操作流程。多變的主體是對需求的理解不夠,對甲方的需求沒理解到位。因為操作物件是有專業技能的甲方B端使用者,即便他們有著常規的操作方式。實際工作中經歷多次功能操作的變化,變化的緣由是甲方覺得操作不順手,但又不清楚如何做的明確方式。

產品與設計是站在兩個不同角度對需求的理解,所以設計的提案可能會出現功能複雜,操作難度大,學習成本高等問題。在沒有標準答案的情況下,設計需要堅持自己的價值嗎?我給的答案是不需要,聽從產品經理堅持的價值!不要槓。

產品經理對使用者的理解會比設計高的。

三、動態的資料資訊

設計師設計出來的設計圖,是靜態,且資料資訊是理想狀態下的樣例,不能作為唯一標準,標準應是動態變化的。資料變動大體會在以下幾種情況常出現:

2. 內因:需求理解

即欄位長度約束,常應用於表格表內的欄位長度約束,考慮因素可能出現單個欄位佔領過多的可視區域。超出長度常採用隱藏展開方式。同樣包括標題、段落摘要、按鈕欄位、選擇器等內容。標籤可能不在考慮範圍,有些標籤是比較專業性的詞,短不了。

3. “價效比”:衡量需求度

表格載入,分批載入資料,以頁碼或是滑動滑鼠梯次載入資料(檢視更多文字作為標記),大片段落分批載入不常有。

3. “價效比”:衡量需求度

資料輸入格式可能有文字、數值、金額、百分比等,型別變化,賦予相應的預設提示文字。

1)欄位長度極值

檔案上傳(上傳檔案型別不同)常出現的斷網、空資料、網路慢資料不完整、載入失敗等。

四、執行力

快速且準確,明確展示需求資訊,快速反饋產品需求的準確度,不要美化粉飾,一切添油加醋只會阻礙業務發展。草稿上即聽即畫,較快的將需求頁面呈現出來,且能找到問題所在。

說到這裡,可以再次回到開頭設計門檻的討論,業務瞭解的加持,能較快的縮小需求理解週期,後邊的功能操作流程、具體的細節資料動態變化都能比較好的應對和改善。甚至可在細節處做到預判,幫助產品經理完善細節。

本文由 @Ychen(啊嗚計) 原創釋出於人人都是產品經理,未經許可,禁止轉載。

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