更深入高效的产品设计上下游协同模式探索

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

在大公司里,传统的产品设计工作流程往往是环环递进的瀑布式协作,交互设计师等到 Prd 评审开始才介入需求,然后交付黑白线框稿等给视觉设计师跟进;这种工作模式固然可以让每个人在自己的岗位上做得更专注、专业,但却不利于项目整体效率提升和设计师个人的横向能力发展。比较幸运的是,虽然我是大公司的一员,但身边不少同事们却都更倾向和鼓励岗位全面发展和交叉协同,当我提出想改变在项目中合作模式的想法时,也能得到「好啊让我们一起来试试吧」的响应。

cpjl

需求阶段的共创脑暴

如果等到 Prd 正式评审后才开始介入设计,交互设计师对于设计背景的理解程度会更容易被业务方限制死(尤其是设计师本人缺乏真实用户代入感的B端产品),对业务目标、用户故事、用户目标等的阐述也更容易变成对业务方需求的简单复述,而难以产生自己对产品的独到见解,容易变成只会将固有需求画出来的「线框仔」,如果遇到的还是那种会把 Prd 画得很精细的 PD,思维限制就更强了。

而现在,我们开始和 PD 团队一起尝试在项目的需求前期做更多「共创」。运营、PD、设计师共同作为观察员角色参加用研组织的焦点小组会议,设计师直接倾听到不同目标用户的真实声音与诉求(而不是仅仅接收业务方加工转述的信息),进而主动形成对产品接下来的设计方向的思考(如我们发现不同用户访问产品的场景和诉求差异较大,一套通用的内容解决方案难以应对,所以提出将「个性化」作为接下来产品设计的主要方向之一);在和业务方达成具体的产品改版大目标共识后,又一起进行需求框架、用户画像、故事板、功能布局等的头脑风暴,共同将需求细化清楚后,由设计师全面负责图形化解决方案的思考,PD 则不再画线框出传统 Prd,而是更关注「看不见」的业务底层逻辑(如内容推荐的算法实现思路等)。

PD 团队并不觉得这么做是被我们抢了饭碗,反而很喜欢大家一起在白板前拿着便签纸马克笔脑暴的形式,甚至主动鼓励我们去作为项目中某一块内容的 Owner。在前期需求阶段的积极参与有利于我们更深入地理解业务、理解用户,从更全局的角度思考问题,做出更满足业务与用户诉求的设计方案,和获得更多项目组的信任与话语权。

交互与视觉如何分工

我不太认同交互设计与视觉设计可以完全合并为一个岗位,虽然自己也没少在项目中直出视觉稿,但最多只能覆盖一部分 UI 设计的活,在品牌、平面、插画、推广等领域的素养和专业视觉设计师还是无法相比。

但这并不意味着在实际项目中,就需要严格遵循交互画完黑白线框稿、交付视觉探索风格输出高保真这样的工作流程。在实际项目中,是存在一部分重交互轻视觉(比如有大量可复用成熟组件的后台产品)和重视觉轻交互(比如强运营推广性质的单一页面)的需求的,一个略懂视觉的交互/一个略懂交互的视觉完全可以独立承担(但在正式评审前需要彼此把关质量),这样有利于节省更多沟通确认和二次评审带来的时间成本,减少更多价值不大的重复拼凑,也更加锻炼设计师的横向专业能力。

目前我已经开始和视觉设计师一起在项目中推动这种一人覆盖彼此把关的协作模式,而这种模式在公司其他设计团队里已经出现得不少,在项目时间急资源紧的情况下,更能够带来比较实用的价值;于个人而言,在锻炼横向能力之余,也可以节省出来更多的沟通评审时间用来做一些思考沉淀性质的工作,而不是让完成业务需求占据了全部精力。

精益设计思维的应用

在学校的时候,我曾以为类似《赢在用户》里那些五花八门的用户研究方法在企业工作中是标配,但参加工作了却发现完全不是这样,事实上,专业的用户研究从发起到输出报告的时间周期是比较长的,难以跟上快速迭代的产品业务节奏,很多项目中甚至完全没有专业的用户研究环节,最多有一些业务方的用户访谈记录。

在项目有正式的焦点小组之前,我多是通过翻阅业务方的用户访谈报告、和业务方交流、参加部分目标用户对焦会等形式来了解用户痛点与诉求,在试图基于此推导出解决方案时,被指出缺乏有力的数据埋点和用户调研支撑,有了解决方案也不好验证是否起到了积极效果;而在旁听了几场焦点小组会议之后,却发现和之前那些非专业用研得到的用户痛点诉求吻合度很高,PD 组也觉得更多是验证已有的想法结论,新发现不多。

这让我想起两年前接触的 Lean UX 理念,「提出假设,快速验证,不断迭代」,我设计的并不是那种随便一个小改动就可能招致吐槽无数的产品,用户端压力相对较小,产品设计方案其实并不一定需要等到有专业数据和用研产出支撑再开始,先假设再验证迭代的思路反而能更快速有效地推进自己想做的项目;而如果被动等待数据、用研报告一一出来,在这个相对较长的周期里会迅速被其他业务需求分散精力(公司怎么会让你闲着等呢哈哈),最后「拖着拖着就没声音了」。所以我提出在之后的项目中实践 Lean UX 思维,也得到了业务方的初步认同,不过具体见效如何就要等后文了。

建立开放的共赢心态

产品设计协同模式的改变并不是一个人说了算话的,也需要获得上下游各职责一致的认同,不过让我惊喜的是,在和项目组伙伴沟通自己对于协作模式改进的想法时,并不需要花费什么力气去「撕逼」说服他们,而是刚一提出就能得到认同、甚至他们之前就已经有了不谋而合的想法。

我觉得这应该是大家普遍都有一个相对开放共赢心态的缘故,都不满足于只做好自己岗位范围内的螺丝钉角色,也不对别人「入侵」自己的领域产生防范抵触心理,而是觉得只要一起更高效有力地拿到最后结果就是好事。很幸运,继续加油!

 

本文由人人都是产品经理专栏作家 @鸿影 原创发布于人人都是产品经理 。未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中