B端設計|設計落地
編輯導語: 對于B端設計來說,哪些因素會對設計落地產生影響呢?本文作者從需求內容、功能流程、數據信息、設計執行力四個方面對此作出了分析,一起來看一下吧。
最近看到一些關于B端設計的一些作品集,引發了心里的一些對B端設計內容的想法,從B端設計的一些影響因素和和各位討論下設計落地的觀點。
首先對于B端設計而言,個人觀點它是有門檻的,這個門檻其一是對項目業務的了解;其二是B端設計是很商業行為(老話長談);其三目前來看B端設計沒那么高的視覺美觀度;其四設計師個人能否接受不好看的設計頁面。
B端設計還是需要落地的設計,落地影響要素大體分為以下幾種:
- 多變的需求內容
- 功能流程多變
- 動態的數據信息
- 設計執行力
也很希望設計師能把自己的設計內容當成一個產品來看,不要極度完善美化它,溺愛終究不能茁壯成長,必然經過跌跌撞撞前行。
一、多變的需求內容
需求主體:需求主體來源是產品經理其次是市場部門再次是甲方客戶(設計基本接觸不到)。
一個成熟的需求必然是有一個成熟經驗豐富的產品經理,來應對多變的需求訴求,設計師的任務就是將產品需求(產品會將用戶需求整理成產品需求的)轉化為設計需求(設計將產品需求落地,整理成設計執行需要的需求),為己所用。
1. 外因:需求變化
個人經歷來看設計推進是個循環往復的過程,這個時期可能是重復否定的過程,否定的原因有設計側、產品側、開發側,共同的原因是來自需求的變動,要重復調整設計內容,具體到頁面的布局,以及考慮基本的優先級等等。
2. 內因:需求理解
同時這個短板過程也是因為對項目了解不夠深入,考慮不夠周全,可能會有“怎么會有這個問題”、“原來可以這么個設計方式”等等此類疑問。由此不斷豐富自己,完善內容過程。
3. “性價比”:衡量需求度
這里更多是設計和產品的“博弈”,關于設計內容的“性價比”的討論。產品經理要求的是短平快,1+1+1模式,而設計師容易陷入做細做深的死角0.5+0.5+0.5+0.5+0.5+0.5,完善中間步驟。比如說異常提示,警示提醒等,這就是放大了用戶操作范圍。而產品經理是直接控制操作范圍,直接為目標服務。
二、功能流程多變
這里更多的是在提功能的操作方式、操作流程。多變的主體是對需求的理解不夠,對甲方的需求沒理解到位。因為操作對象是有專業技能的甲方B端用戶,即便他們有著常規的操作方式。實際工作中經歷多次功能操作的變化,變化的緣由是甲方覺得操作不順手,但又不清楚如何做的明確方式。
產品與設計是站在兩個不同角度對需求的理解,所以設計的提案可能會出現功能復雜,操作難度大,學習成本高等問題。在沒有標準答案的情況下,設計需要堅持自己的價值嗎?我給的答案是不需要,聽從產品經理堅持的價值!不要杠。
產品經理對用戶的理解會比設計高的。
三、動態的數據信息
設計師設計出來的設計圖,是靜態,且數據信息是理想狀態下的樣例,不能作為唯一標準,標準應是動態變化的。數據變動大體會在以下幾種情況常出現:
1)字段長度極值
即字段長度約束,常應用于表格表內的字段長度約束,考慮因素可能出現單個字段占領過多的可視區域。超出長度常采用隱藏展開方式。同樣包括標題、段落摘要、按鈕字段、選擇器等內容。標簽可能不在考慮范圍,有些標簽是比較專業性的詞,短不了。
2)內容加載
表格加載,分批加載數據,以頁碼或是滑動鼠標梯次加載數據(查看更多文本作為標記),大片段落分批加載不常有。
3)表單輸入
數據輸入格式可能有文本、數值、金額、百分比等,類型變化,賦予相應的默認提示文本。
4)網絡
文件上傳(上傳文件類型不同)常出現的斷網、空數據、網絡慢數據不完整、加載失敗等。
四、執行力
快速且準確,明確展示需求信息,快速反饋產品需求的準確度,不要美化粉飾,一切添油加醋只會阻礙業務發展。草稿上即聽即畫,較快的將需求頁面呈現出來,且能找到問題所在。
說到這里,可以再次回到開頭設計門檻的討論,業務了解的加持,能較快的縮小需求理解周期,后邊的功能操作流程、具體的細節數據動態變化都能比較好的應對和改善。甚至可在細節處做到預判,幫助產品經理完善細節。
本文由 @Ychen(啊嗚計) 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于 CC0 協議。
- 目前還沒評論,等你發揮!