木子素材 首页 大神 UI设计 查看内容

想做项目推动型设计师?来看这篇实战总结!

2021-2-7 00:43| 发布者: admin| 查看: 223| 评论: 0

摘要: 回顾之前的一些 B 端的项目,主要通过“组件库搭建”和“日常项目”来举例,分享关于 B 端设计师在日常工作中可抓的价值点。 篇首语 提到 B 端产品设计,大家可能脑海闪现的是“逻辑复杂,绕来绕去,做数学题一样” ...
二维码1

扫一扫
官方手机版

AI创作助手小程序

扫一扫
AI创作程序

木子官方公众号

扫一扫
木子公众号

木子AI官方公众号

扫一扫
AI公众号

回顾之前的一些 B 端的项目,主要通过“组件库搭建”和“日常项目”来举例,分享关于 B 端设计师在日常工作中可抓的价值点。

篇首语

提到 B 端产品设计,大家可能脑海闪现的是“逻辑复杂,绕来绕去,做数学题一样”等印象。对于设计师而言,相比于 C 端的创新和趣味,B 端设计更显得克制和理性,视觉发挥空间相对有限。这个时候就会有人说,产品的推动靠产品经理,设计靠现成的组件规范,那 B 端设计师的价值又有多大呢?

本文将会从多个角度,结合实际案例,呈现 B 端设计师如何在项目中发挥设计价值,希望会对处在这个领域感到迷茫的设计师有所指引和帮助。

定位好自己的角色

很多设计师想做“项目推动型设计师”,却找不到切入点,部分原因是:设计师没搞清楚自己的角色和该角色所具备的责任、技能和价值。

我们先描述一下 B 端设计的工作日常:

想做项目推动型设计师?来看这篇实战总结!

如上图描述,B 端设计在整个项目中,是跨团队+全链路参与的角色。在整个链路里,设计师在每个环节,都有可挖掘和贡献的价值点。

如何挖掘设计价值?

接下来会根据设计师日常工作流程和具体案例,来阐述设计可抓的赋能点。

1. 设计前:培养争取的思维方式

有的设计师是被动接需求做图,如果只执行输出设计稿,价值发挥有限,要转被动为主动。设计和产品的配合是互相成就,互相补位。面对 B 端复杂的业务需求,在和产品思维对焦时,需要思维前置,辩证的去思考产品方向,帮助产品梳理需求,从需求背景出发,收集来自用户、需求方的反馈,综合考虑根本要解决的问题是什么,再去想如何产出设计解决方案,不要只做被动接受的工具人。

想做项目推动型设计师?来看这篇实战总结!

2. 设计中:锻炼解决问题的能力

B 端设计师的核心竞争力就是解决问题的能力,快速理解业务和处理业务的能力,只有拥有这些能力后,才可以去创造更多的价值。

B 端设计可以在这些地方寻找发力点,锻炼和挖掘自己的价值

规范的定义:

一个庞大的后台的搭建,都是在一套统一的前端 UI 框架规范基础上进行的。规范是服务于设计和技术团队更高效的产出体验一致,视觉统一的基础。

前面有说现在市面上已经有成熟的设计规范框架,但设计和技术团队并不是直接照着挪用的。使用前端 UI 框架最大的目的是为了提升效率,不用自己重头造车轮,一个成熟的组件规范的搭建,设计可提供的价值是不可或缺的,拿一个组件库 0-1 的搭建为列:

在探索期设计要主动和技术拉通“统一组件规范”的背景和目标以及价值,以及去建立技术和设计的配合方式,设计内部的配合方式,保证规范顺利的推进;要去进行组件规范的竞品调研,从技术和设计层面综合考虑,哪种方式更提效更稳定,支持的场景更全面...

(权限原因图片打码)

想做项目推动型设计师?来看这篇实战总结!

技术选型后,设计要在规范框架的基础上,定义出具有自己品牌特性和适合系统特性的视觉规范,而不是照搬别人的视觉语言;随着产品需求的累积,规范覆盖的范围也会从原子级组件逐步扩展到页面级。

想做项目推动型设计师?来看这篇实战总结!

组件的需求增加,设计不仅要结合整个系全局的考虑到组件支持到什么程度是最通用的(组件无需为特殊的业务场景去设计),未来的延展性也需考虑到,并和技术沟通好,以及新增的组件要在整个设计团队和前端团队里信息拉齐,避免不同技术团队重复相同组件的工作量。

(不论在组件发展的哪个时期,这些配合的机制和方法都是通用的)

想做项目推动型设计师?来看这篇实战总结!

组件完成后,需要去走查在各个业务线上的覆盖情况,尤其是新组件替换旧组件的场景,很容易出现新组件“消化不良”的问题,需要设计和技术配合走查并记录问题,并给出合理的优化方案。

想做项目推动型设计师?来看这篇实战总结!

可以看出在一套规范里,绘制设计稿的成本可能只占了 30%,前期的调研和思考,各个团队的协作和沟通,组件的验收到完美落地,这些环节,才是最费时费力的,也是最能体现设计价值的部分。

业务的赋能:

一个设计需求的完成可分为两种:

  • 设计支持:设计 100% 完成业务需求;
  • 设计赋能:在完成业务需求的基础上,设计主动进行了xx行动,给出xx方案,更好的解决了xx问题,带来了xx价值。

业务需求 100%的支持,是设计师的本职工作,这里我们就不多讲了。难点是设计赋能,那“赋能”是什么呢?“赋能”顾名思义,就是给谁赋予某种能力和能量,通俗来讲就是,你本身不能,但我使你能。

放在设计赋能上,就是在项目协作间、产品大目标中寻找突破口,分析他们的需求,在这些痛点上追求更好的效果、更高效率、更科学的方法。

那设计在业务上的赋能具体表现是什么呢?

  • 了解是前提:

透彻的了解业务,了解才有发言权,才能提出合理建议,否则脱离了业务,设计工作将无实质意义,即无法解决用户需求,也无法带来优质体验。

以“客服 IM-设计优化”案例具体说明:

想做项目推动型设计师?来看这篇实战总结!

  • 行动是关键:

勇敢跨出自己的圈子,设计可以主动去进行竞品调研,用户调研,这样不仅可以让我们更清晰的了解用户需求和业务场景,在这个过程中,往往也会更容易挖掘出需求的突破点,找到更好的解决方案和更有价值的驱动点。当设计在整个项目中参与度越高,贡献越大,那设计的价值自然就提升了(如果设计能够自己发起并立项,去组织和推动整个项目,那整个项目话语权都是归属在设计手中的)。

通过对业务的了解和归纳,设计以“降低舆情差评”为行动点,进行相关数据收集,并将整理的数据业务规划,以及初拟解决方案。

想做项目推动型设计师?来看这篇实战总结!

在沟通后,设计可以挖掘出在这个阶段能解决的问题,和业务方确定安排优先级并进行排期解决。

想做项目推动型设计师?来看这篇实战总结!

  • 结果是衡量的指标:

行动只是体现了我们的主动性和行动力,但是设计的行动是否产生了价值,都是要通过结果来衡量的,没有价值的行动 = 只有苦劳没有功劳...

B 端结果的衡量可以通过量化的数据来验证,如果没有条件进行数据分析,也可通过客户的买单量,效率的提升,用户的满意度,来去论证设计的价值。

3. 设计后:复盘结果定期总结经验

复盘是设计师自我提升的有效方式。不论是工作还是学习,设计可以通过回顾和思考,归纳分析其中的成功与不足,把那些对后续有帮助的、复用性高的经验加以总结,沉淀出自己的方法论,从而查漏补缺提升设计能力,避免低效率的重复工作。

当沉淀累积到一定程度时,可以对团队输出自己的方法论,这种知识分享的方式不仅提升自己对团队的价值,也可以锻炼自己的表达和控场能力。

结尾

不论是精细打磨用户体验的 C 端,还是系统思考去搭建一个完整的服务场景体系的 B 端,有些找寻价值的方法是通用的。

设计想要提升自己的价值,产生更强的影响力,不能只沉浸在产品传达的业务需求里,顶多算执行能力。B 端的设计和产品互相成就、互相补位,没有明确的界限和划分,设计独有的用户体验思维+业务理解能力,可推导出产品的可发力点,抓住并完善这些发力点,也从中体现了设计的价值。

手机扫一扫,阅读下载更方便˃ʍ˂

@版权声明

1、本网站文章、帖子等仅代表作者本人的观点,与本站立场无关。
2、转载或引用本网版权所有之内容须注明“转自(或引自)网”字样,并标明本网网址。
3、本站所有图片和资源来源于用户上传和网络,仅用作展示,如有侵权请联系站长!QQ: 13671295。


路过

雷人

握手

鲜花

鸡蛋

最新评论

广告图片
悬浮图片
×