回顾之前的一些 B 端的项目,主要通过“组件库搭建”和“日常项目”来举例,分享关于 B 端设计师在日常工作中可抓的价值点。
提到 B 端产品设计,大家可能脑海闪现的是“逻辑复杂,绕来绕去,做数学题一样”等印象。对于设计师而言,相比于 C 端的创新和趣味@ 1 W @ D,B 端设计更显得克制和理性,视觉发V = 9 q m %挥空间相对有J / a 3 3限。这个时候就会有人说,产品的推动靠产品经理,设计靠现成的组件规范,那 B 端设计师的价值又有多大呢?
本文将会从多个角度,结合实际案例,呈现 B 端设计师如何在项目p L ) & Y C t u q中发挥设计价值,希望会对处在这个领域感到迷茫的设计师有所指引和帮助。
很多设计师想做“项目推动型设计师”,却找不到切入点,部分原因是:设计师没搞清楚自己的角色和该角色所具备的责任、技能和价值。
我们先描述一下 B 端设计的工作日常:
如上图描述,B 端设计在整个项目中,是跨团队+全链路参与的角色。在整个链路里,设计师在每个环节,都有可挖掘和贡献的价值点。
接下来会根据^ j 1 I = E i x设计师日常工作流程和具体案例,来阐述设计可抓的赋能点。
1. 设计前:培养争取的思维方式
有的设计师是被动接需求做图,如果只执行输出设计稿,价值发挥有限,要转被动t V j ~ = ? 7 X *为主动。设计和产d s Z E [ o F m v品的配合是互相成就,互相补位。面对 B 端复杂的业务需求,在和产品思维对焦时,需要思维前置,辩证/ X C的去思考o g ;产品方向,帮助产品梳理需求,从需求背景出发,收集来自用户、需求方的反馈,综合考虑根本要解决的问题是什么,D : &再去想如何产出设计3 6 C – I K #解决方案,不要只: } ! G ! ( =做被动接受的工具人。
2. 设计中:锻炼解决问题的能力
B 端设计师的核心竞争力就是解决问题的能力,快速理解业务和处理业务的能力,只有拥有这些能力后,才可以去创造更多的价值。
B 端设计可以在这些地方寻找发力点,锻炼和挖掘自己的价值
规范的定义:
一个庞大的后台的搭建,都是在一套统一的前端 UI 框架规范基础上进行的。规范是服务于设计和技术团队更高效的产出体验一致,视觉统一的基础。
前面有说现在市面上已经有成熟的设计规范框架,但4 8 ? I 3 7 U x设计和技术团队3 . l C G @并不是直接照着挪用的。使r – x H P用前端 UI 框架最大的目的是为了提升效率,不用自己重头造车轮,一个成熟的组件规 t . , O B范的搭建,设计可提供的价值是不可或缺的,拿一个组+ g @ L @ B + L件库 0-1 的搭建为列:
在探索期设P d Q ] 9 J j q (计要主动和技术拉通“统一组件规范i & T I ~ p !”的背景和目标以及价值,以及去建立技术和设计的配合方式,设计内部的配合方式,保证规范顺利的推进;要去进行组件规范的竞品调研,从技术和设计层面综合考虑,哪种方式更提效更稳U ~ m 1 z 4 =定,! K U 7 N支持的场景更全面…
技术选型后,设计要在规范框架的基础上,定义出具有自己品牌特性和适合系统特性的视觉规范,而不是照搬别人的视觉语言;随着产品需求的累积,规范覆盖的范围也会从原子级组件逐步扩展到页面级。
组件的需求增加,设计不P D : ~仅要结合整个系全局的考虑到组件支持到什么程度是最通用的(组件无需为特殊的业务场景去设计),未来的延展性也需考虑到o . E : b 7 $ R 6,g e ` 并和技术沟通好,以及新增的组件要在整个设计团队和前端团队里信息拉齐,避免不同技术团队重y ~ , a W z j复相同组件的v u H L k 4 1 $工作量。
(不论在组件发展的哪个时期,这些配合的机制和方法都是通用的)
组件完成后,需要去走查在各个业务线上的覆盖情况,尤其是新组件替换旧组件的场景,很容易出现新组件“消化不良”的问题,需要: Z = ` Q q + 8 8设计和技术配L ] 0 n R 7合走查并记录问题,并给出合理的优化方案。
可以看出在一套规范里,绘制设计稿的成本可能只占了 30%,前期的调研和思考,各个团队c F o U % } ~ k w的协作和沟通,组件的验收到完美落地,y l ; Z这些环节,才H r Y是最费时费力的,也是最能体现设计价值的部分。
业务的赋能:
一个设计需O I h 1求的完成可分为两种:
- 设计支持:设计 100% 完成业务需求;
- 设计赋能:在完成业务% B # n需求的基础上,设计主动进行了xx行动,给出xx方案,更好的解决了xx问题,带来了xx价值。
业务需求 100%的支持,是设计师的本职工作,这里我们就不q c R | E / I ) e多讲了。难点是设计赋能,那“赋能”是什么呢?“赋能”顾名思义,就是给谁赋予某种能力和能量,通俗来讲就是,你本身不能,但我使你能。
放在设计赋能上,就是在项目协作间、产品大目标中寻找突破口,分析他们的需求,在这些痛点上追求! * X更好的效果、更高效率、更科学的方法。| N c b U _ a m A
那设计在业务上2 u d b d G ) ` n的赋能具体表现是什么呢?
- 了解是前提:
透彻的了解业务,了解才有发言权,才能提出合理建议,否则脱离了业务,设计工作将无实质意义,即无法解决用户需求,也无法带来优质体验。
以“客服 IM-设计优化”案例具体说明:
- 行动是关键:
勇敢跨出自己的圈子,设计可以主动去进行竞品调研,用户调研,这样不仅可以让T e | : ! L ~ i ~我们更清晰的了解用户需求和业务场景,在这个过程中,往往也会更z j , 7 h – _容易挖掘出需求的突破点,找到更好的解^ J R B v = , c f决方案和更有价值的驱H o [ F V x D Q动点。当设计在整个项目中参与度越高,贡献越大,那设计的价值自然就提升了(如果设计能够自己发起并立c F l H P { t项,去组织和推动整个项目,那整个项目话语权都U ^ ^是归属在设计手中的)R g S 6 { D x J。
通过对业务的了解和归纳,设计以“降低舆情差评”为行动点,进行相关数据收集,并将整理的数据业务规划,以及初拟解决方案。
在沟通后,设计可以挖掘出在这个阶段能解决的问题,和业务方确定安排优先级并进行A k o `排期解决。
- 结果是衡量的指标:
行动只是体现了我们的主动性和行动力,但是设计的行动是否产生了价值,都是要通过结果来衡量的,没有价值的行动 = 只有o * b C苦劳没有功劳C y ~ 0 J { ~ M…
B 端结果的衡量可以6 4 N 9 o L o E .通过{ $ X 2 / : % 1量化的数据p @ W –来验证,如果没有条件进行数据分析,也可通过客户的买单量,效率的提升,用户的满意度,来去论证设计8 t O j # Y的价值。
3. 设? ) T }计后:复盘结果定期总结经验
复盘是设计师自我提升的有效方式。不论是工作还是学习,设计可以通过回顾和思考,归纳分析其中的成功与不足,把那些对后续有帮助的、复用1 h G ;性高的经验加以总结,沉淀出自己的方法论,从而查漏补缺提升设计能力,避免低效率的重复工作。
当沉淀累1 ] x : Y & k !积到一定程度时,可以对团队输出自己的方法论,这种知识分享的方式不仅提升自己对团队的价值,也可以锻炼自己的表达和控[ U t场能力。
不论是精细打磨用户体验u 3 $ K t @ 5 p q的 C 端,还是系统思考去搭建一个完整的服务场景体系的 B 端E U V B S,有些1 f / 8 o 1 ! |找寻价值的方法是通用的。
设计想要提升自己的价值,产生更强的影响力,不能只沉浸在产品传达的业务需求里,顶多算执行能力。B 端的设计和产品互相成就、互相补位,没有明确的界限和划分,设计独有的用户体验} } ] p /思维+业务理解能力,可推导出产品的可发力点,抓住并完善这些发力点,也从中N ? L * c = ]体现了设计的价值。