登录 免费体验Demo
首页 新闻资讯 增长秘籍 4000字干货,GrowingIO的B端交互设计师是怎么工作的?

4000字干货,GrowingIO的B端交互设计师是怎么工作的?

来源:GrowingIO微信公众号    2022-12-16

这期我来给大家说说设计中」的工作流程和方法。话不多说,上图~


B端1.png


「设计中」的三个环节:

交互方案设计设计评审技术评审


之所以把设计评审和技术评审也算进来,因为评审也是完善设计方案的重要环节。



1、交互方案设计


什么是交互方案设计?


我理解的交互方案设计不是照搬竞品UI,或者按照PRD中描述的内容做单纯的信息展示,而是要收集有价值信息然后进行思考和决策,最终转化成能创造用户价值的最高投入产出比的解决方案。


一个完整而合理的交互方案通常具备哪些特征?我总结了以下几个方面:


  • 满足核心用户故事,具备所有MVP功能

  • 明确不同场景和状态下的UI样式,配有详细而条理清晰的交互说明

  • 设计决策基于前期的调研、测试获得的有价值信息,而不是基于设计者的凭空猜想、主观判断

  • 遵循现有的设计系统和设计语言

  • 具备技术可行性

  • 能在规定时间节点内完成,并有较高的投入产出比


(欢迎大家补充更多~)


在进行交互方案设计的时候,思考的重要性远远高于画图。前期的需求调研、竞品分析等过程,已经是思考的开始;后期的画图阶段,只是把前期思考的结果进行可视化呈现。注意呈现的过程要符合现有的设计语言。有时间的话,建议在方案完成后进行可用性测试,进一步确认是否符合用户预期。



B端和C端有什么不同?


(1)设计方法不同


B端和C端大部分的设计方法是相通的,但也有些不太一样的地方:


C端通常以目标为导向进行设计,从一个目标拆解到可能提升目标的所有场景,再到具体功能和页面,设计师由点及面发散开来,从全链路寻找设计发力点。其设计重点放在引导方式、交互细节、视觉样式等方面。


比如一个C端金融类产品,目标是引导用户发生投资转化,那么我们可以梳理用户从接触产品到离开产品,整个过程中有哪些场景可能发生投资转化。每种场景下,如何引导和刺激用户才能让其更容易发生转化。这就是由一个目标发散到多种场景,场景挖掘得越多,提升目标的可能性越大。


B端大多从解决用户实际问题出发,功能范围和需求边界更加明确,设计更聚焦。比如用户需要一个定时发送日报周报的功能,你只需要围绕这个功能进行设计就可以了。


B端更注重组件化设计思维,通过原子组件来搭建功能模块,这样不仅能提升设计效率,降低开发成本,还能保证产品体验的一致性。对于产品还不成熟的公司,在组件库上的创新能带来的收益微乎其微,B端设计师可以把更多精力放在提升整体体验,关注流程上的、全局性的设计策略。


近年来很多B端产品越来越C化,那么C端的设计方法也可以灵活运用到B端。


(2)设计语言不同


C端设计重运营重体验,设计师可以加入更多的想法和创意,通过情感化设计、氛围感来感染用户,引导其发生转化,C端设计语言是感性而冲动的。B端大多为工具类产品,设计目标是提升效率,运营需求较弱,B端设计语言是理性而严谨的。


(3)B端的一些特点


B端服务的是企业,是组织,而不是独立的个体,因此设计时需要有更大而完整的思考框架,支撑更复杂的业务场景。


比如不同用户角色需求有哪些、痛点如何解决、角色之间如何协作;新功能涉及到的数据权限、功能权限、资源权限如何分配和管理;功能与功能、系统与系统之间是否有依赖关系;考虑客户的行业特征、企业差异化需求,方案能否覆盖各类客户的使用场景;明确产品价值和用户价值,哪些优先做哪些后做;考虑各种安全性问题和加载性能的问题……


我在做【图表的创建流程优化】时,将所有类型的图表整合到了一个页面来管理(之前是每类图表单独管理),从功能上方便用户对所有图表进行全局查找,从交互上缩短了图表创建路径,从数据层面更方便存储和管理数据,针对此方案我还做了可用性测试。


B端2.png


原以为大功告成,但实际评审时,却发现了以下问题:


GIO平台中不同类型图表权限是分开管理的,每个用户角色拥有不同权限,如果将所有类型的图表整合到一起,就需要针对每个角色的不同权限情况分别做处理,给予提示和限制;另外,所有图表放在一起管理,数据量级增大,查询性能也受到影响,数据加载慢对用户体验的损伤很大。经过和研发、产品同学讨论后,我对方案又做了一些调整和完善。由此可见B端设计师需要考虑得更多。


给B端设计师的建议


(1)搭建设计系统,熟悉组件规范


设计系统是一系列可重复使用的组件和它们的使用指导文档,使用这些组件能够快速地开发不同平台的产品。设计系统让设计能够扩大规模,提供一种设计标准供不同的设计师参考。如果公司有长期开发的产品和多个设计师,建议搭建一套自己的设计系统,解放设计生产力。当然搭建设计系统也有成本和弊端,可以根据自身情况来选择。


此外,熟悉组件规范是设计师的基本功,了解每个组件的状态及样式、适用场景、组件的可控参数,以便在设计方案时更灵活地应用,避免乱用组件,减少不符合规范的设计。


2)及时和研发同步设计进展


多和研发同学同步和沟通设计进展,了解技术实现的边界,对于不可行的设计策略及时调整,降低设计返工的风险。


在【可视化图表优化】项目中,使用第三方图库开发比自行开发成本更低、性能更稳定,但可视化呈现效果也会受到图库能力的限制。


由于对图库底层能力不了解,我在设计过程中多次向研发同学请教。图表有哪些参数可以改,哪些样式可以自定义;哪类图表由图库实现,哪类图库无法支持;哪些功能做到图库里,哪些功能留到应用侧去写,这些细节都要做到心中有数,并在图表设计规范中去定义和约束。设计细节依赖于技术框架,缺少了技术的支撑,设计寸步难行。设计师多了解一些技术知识能事半功倍。


(3)多设计师协作时做好同步工作


不同设计师负责不同模块,但是模块间难免有重叠和相互依赖的部分,这时候做好同步工作,保证设计的一致性很有必要。


我负责分析模型的设计,KPI分析单独由另一个设计师负责。KPI分析也属于分析模型,与其他分析模型有重复的功能,我们在设计时却没有统一。这不仅增加了开发成本,还给用户带来了困惑。由此可见,同步工作多么重要



2、设计评审


什么是设计评审?


我来介绍下我们团队的设计评审制度。

主设计师邀请组内同学参与评审,会上大家针对方案进行讨论,各自发表建议和反馈。意见分歧时,主设计师拥有最终决策权。


我很喜欢我们公司开放、包容的团队文化,鼓励每个设计师都发言,不用担心被嘲笑,大家会耐心倾听,尊重每个人的发言。Leader和组内成员拥有平等的发言权,谁有道理听谁的。


B端和C端有什么不同?


(1)评审流程不同


C端的评审流程比较简单,让设计Leader、产品经理过一遍方案,或者有经验的设计师自己来定就可以了。


相比之下,B端的评审流程更复杂,也更重要。设计评审是组内同学一起参与,一方面由于B端项目复杂,需要考虑的问题多,多个设计师能献智献策;另一方面,不同模块之间有依赖关系,功能重叠性高,设计师们也可以同步信息,保证设计的一致性。有必要的时候,还会邀请有经验的行业专家进行评审。


(2)评审侧重点不同


C端评审重点在于是否能助力产品达成目标,交互是否合理,能不能更优。B端评审重点在于能否实现用户价值,产品功能是否完整,组件是否符合规范。


给B端设计师的建议


(1)善于利用动态原型演示方案


设计方案很重要,讲解方案也很重要。评审时多利用动态原型来实操演示,让大家更清晰地理解设计细节,更直观地看到产品实现效果。


在设计看板共享功能时,三类角色会高频使用这个功能。基于这三种角色我建立了三个Persona(用户画像),通过讲故事的方式描述了每个角色的使用场景,分别演示了他们设置共享的操作流程。这个过程不仅展示了完整的交互细节,还把大家带入到用户故事中去,让大家更好地理解用户场景和产品价值。


(2)做好评审记录


设计评审不仅仅停留在口头,还应落实到文档。设计评审表就是一种比较好的记录方式。评审表中可以记录项目信息设计目标评审反馈,主设计师填写好项目信息和设计目标,参与评审的同学把问题记录到评审反馈,后期由主设计师进行回应和跟进。另外,Figma中的Comment评论功能也很好用哦。

(飞哥整理了一份好用的设计评审表模板,有需要的朋友可以私信~)



3、技术评审


什么是技术评审?


技术评审会上产品经理讲解PRD,设计师展示完整的设计方案,大家针对需求和方案的合理性展开讨论,设计师收集反馈重新调整方案。研发团队评估技术可行性和开发周期,并为下一步技术方案设计做准备。


技术评审产品经理、主设计师、研发团队都会参加,必要时还会邀请产研Leader、系统架构师等人员。


B端和C端有什么不同?


(1)B端更注重技术评审


C端技术对接,需要给研发同学讲清楚设计方案,一般来说竞品有的功能,技术基本上都能实现。B端就不同了,竞品能做的,自身的系统架构、底层技术框架不一定支持,因此受技术侧的限制更大一些。很多时候设计师不得不因为技术限制而妥协,通过设计方案的调整来解决技术上无法攻克的难题。


给B端设计师的建议


(1)多了解技术实现原理


在实际工作中,处理好和研发同学的关系,多请教多提问。积极参加公司的技术分享会、技术方案设计评审会,了解产品的技术实现原理。有时间也可以自己去学习前端后端知识。相信你在了解这些知识后,做设计会更有底气,方案评审也能更轻松“通关”。


(2)注意沟通方式,以理服人


以开放的心态来面对评审。不要害怕暴露问题,发现问题是好事,知道哪里不足才能进一步提升。如果方案被质疑,首先要保持情绪稳定,不要着急反驳,耐心听取对方的建议和反馈。如果不认可对方的观点,就摆出前期调研和测试的“证据”,给对方讲解设计演进的过程,平和友善的沟通态度和有理有据地回应,能让你更有说服力。


小结


从「设计中」的流程可以看出,设计的过程不仅由设计师一个人来完成,还要和其他不同专业领域的人一起交流、探讨、思维碰撞,合力打磨出一个最优的解决方案。好的设计师善于收集信息、协调沟通、权衡利弊,并最终方案细节呈现出来。在产品研发过程中,设计师起着非常重要的作用。

最新新闻

全域全场景智能易用的分析云

探索