购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

1.3 互联网产品团队的工作流程

协作流程是产品孵化的命脉。协作是由一个个具体的人构成的工作关系,细致的协作流程没有完全正确的标准,因为在业务的不同阶段,团队成员的构成不同,所需的人力资源也不同,因此每个团队的协作环境也是不同的。

1.3.1 产品迭代流程和交互设计师的角色

每个产品的发展都是逐步完善的。我们之所以感觉“微信”“淘宝网”“京东”等App越来越好用了,是因为它们是由无数次大大小小的迭代支撑起来的。产品迭代不是单纯地对功能或设计元素进行增加、删除、修改、优化,虽然这是迭代中的行动点,但迭代的总体目标是“围绕用户体验和产品目标进行产品打磨”。在此期间,要协调、平衡许多利益点,然后将其拆分成阶段性目标,最后将其分配给个人去执行。常规性的产品迭代流程和交互设计师在每个阶段所扮演的角色如下图所示。

1.需求调研和版本(功能)规划阶段

清晰明了的迭代节奏体现了产品团队的成熟度,一次迭代的开发内容通常可以为下一次迭代打好基础,功能的完整性通常不会一步到位,体量庞大的功能一般由多次迭代实现。合理的版本规划有助于交互设计师提前考虑设计内容的扩展性,开发工程师可以提前搭建代码框架,避免后期的重复工作和不必要的修改。版本的迭代包括双周一次的“小迭代”、一个月一次的“大迭代”及特殊任务的“专项迭代”,具体采用哪种迭代周期由产品业务决定。迭代内容来源渠道是丰富的,包括上个版本遗留的问题、用户反馈的问题、设计师提出的优化建议、产品战略层面提出的要求及外部市场的竞争问题。在版本规划阶段,产品经理首先要确定该版本发布后要达到的阶段性目标、明确要做哪些事情、明确这些事情的具体业务思路、执行资源的调配、所需的迭代周期等,然后输出产品需求文档(PRD)或功能说明书,再对需求进行筛选、辨别,最后按照优先级,将事件整理成可传达的任务项。如果需求的明确度不高,或者正在专项打磨产品的某个功能,那么通常会开展需求调研和用户调研,用于判断需求的可行性。

交互设计师的角色:参与者

需求调研和版本(功能)规划阶段的主导者主要是项目负责人或产品经理,而交互设计师只是参与者,主要负责支持项目负责人或产品经理完成需求调研,协助他们框选本次迭代的功能和设计优化,并且将用户研究中整理的需求点、体验走查发现的优化点提交给产品经理进行规划排期。虽然该阶段的主导者是产品经理,但交互设计师参与其中,可以降低对需求的理解成本,并且可以接触到真实的用户,为下一步的设计工作带来帮助。

2.需求定义和评审阶段

产品经理在确定需求后,会组织产品团队对迭代需求的策划方案进行内部评审。迭代需求内部评审一般和迭代需求宣贯会或宣讲会同时展开,即通过开发力量和设计力量共同解决需求落地的疑问点,将任务划分到个人头上,评估执行工期。迭代需求内部评审要求每位评审人员都能理解该迭代的任务项和意义。如果要对产品团队外部的需求进行评审,那么通常由产品经理面向业务方、需求方或领导层进行需求计划汇报,即确认需求规划的正确性,然后组织迭代需求内部评审。对于逻辑比较复杂的功能,初次迭代需求评审通常会存在遗留问题,因此产品经理会重新梳理迭代需求,甚至开展研讨会,通过团队的力量梳理业务需求,并且对重新确认的迭代需求进行二次评审,直到大家对需求逻辑都没有疑问,才会进入各自的执行阶段,否则会因为后续的重复讨论影响迭代节奏和进度。迭代需求评审的最大作用是评估迭代需求的可行性和迭代需求落地的价值,通常在迭代需求评审中会解决以下6方面的问题,让参加评审的人员对迭代需求有清晰的认识。

需求评审: 本次迭代的任务项分别有什么样的需求背景?某个需求是来源于用户,还是来源于战略?为什么要满足某个需求?

正面评审: 如果需求落地,那么用户会在哪些场景中受益?用户会因为本次受益产生消费行为或推荐行为吗?

负面评审: 如果需求不落地,那么是否会影响用户对产品的使用意愿?口碑传播是否存在负面影响?分享意愿是否存在风险?

业务逻辑: 拟落地的需求的业务逻辑是否通畅?是否可以形成闭环?中间是否有遗漏的业务场景?

数据指标: 拟落地的需求对产品数据指标有什么影响?如果短期内无法使某项指标正面提升,那么是否有其他可量化的价值?

确认最终实现优先级: 根据当前的迭代人力资源,拟落地的哪个需求是最重要且紧急的?设计和开发的优先级是怎样的?

交互设计师的角色:协作者

如果交互设计师在进行需求评审前参与了需求调研,那么他在需求评审中对需求的理解压力会较小,甚至可以帮助产品经理提前产出概念原型图,将其与需求文档一并演示。交互设计师站在用户体验的立场上,有时与产品经理是对立关系,经常发生争议,但是在前期的需求定义阶段,要与产品经理达成密切协作的战友关系,因为产品经理是交互设计师的上游,没有他们的耐心解读,交互设计师可能无法正确理解需求和设计方向。

3.设计规划和设计执行阶段

交互设计师根据需求评审的内容开展工作,首先确认需求设计的优先级,保证优先级高的任务先交付;然后进行方案输出,将抽象的需求设计成具象的产品原型图,主要包括设计研究和测试、低保真原型图、页面和功能流程图、信息和功能结构;最后需要准备交互设计评审的相关材料,如交互文档、设计参考效果演示、交互原型图Demo等,并且组织交互设计评审会议的召开。在资源比较紧张或没有细分交互设计岗位的团队中,交互设计评审会议和视觉设计评审会议一起召开,统称为设计评审会议。在细分交互设计岗位的团队中,在完成交互设计评审后,需要将交互方案传递给视觉设计师,从而推动高保真效果图的产出和验收。

交互设计师的角色

交互设计范围-主导者: 在设计规划和设计执行阶段,交互设计师首先要思考如何通过设计手段达成产品目标;然后要考虑用户的使用感受;最后要提前了解方案落地的成本,否则会出现因落地成本较高而无法实现的“飞机稿”,导致将时间消耗在返工上,而不是对有效方案的思考上。对于不好把控的开发落地成本,可以提前找开发工程师沟通确认。

视觉设计范围-协助者: 视觉设计师的主要工作就是对产品表现层的设计。我们需要再次将交互文档传递给视觉设计师(第一次在交互设计评审会议上,该会议一般不会讨论视觉细节),并且对重点信息进行解读,如交互原型图中的设计背景、注意点和视觉设计建议,也就是引导视觉设计师通过视觉手段达成产品目标和用户体验目标,最后协助视觉设计师完成落地交付和制定设计规范。

4.开发和测试阶段

在产品的开发和测试阶段,开发工程师会通过代码实现设计师提供的效果图和交互文档,测试工程师会准备相关的测试用例、分配测试任务。在该阶段,交互设计师的工作是准备设计验收清单,将需要验收的地方罗列清楚,避免在后续进行设计走查时遗漏关键点。前端开发工程师在该阶段通常会找设计师确认效果和细节问题,具体的沟通频率受设计文档的细致程度影响。在测试工程师将开发工程师提出的验收问题解决完后,通常会预留1~2天时间,对本次迭代的内容开展一次演示会,将所有的迭代任务正式演示一遍,产品经理、设计师、开发工程师、测试工程师及相关的业务人员都要在场,共同把关。演示会相当于一次产品团队的及时性迭代复盘,以便发现并及时解决现存问题。在完成以上工作后,下一步就要筹备上线工作了,产品经理会准备上线邮件、发布内容说明和推送版本升级通知,并且将其同步给需求方和运营人员,以便提前准备好相关的宣传物料。此外,要将该版本的遗留问题归纳到需求池中,以便在后续的迭代中继续优化。

交互设计师的角色:验收者

在产品开发的测试验收阶段,交互设计师的主要工作是与开发工程师密切沟通并验收开发效果,配合他们减少落地效果与设计稿的偏差度,并且提供开发所需的落地素材(如一些页面状态、微交互、设备适配等)及相应的参数和演示,引导他们实现所需的效果。在开发环节完成,进入测试环节后,交互设计师需要与测试工程师、视觉设计师一起验收开发效果,组成产品上线前的“最后一道防线”。

5.产品运营阶段

在产品上线后,进入产品运营阶段,运营人员会对迭代内容进行推广和宣贯,其间可能会用到设计规范、宣传物料等材料,交互设计师需要及时提供。该阶段是整个产品迭代流程的闭环点,并非终点,因为产品经理会准备组织下一次迭代的需求评审会议,从而有节奏地循环开展迭代工作。

交互设计师的角色:支持者

在产品运营阶段,很多交互设计师都会忽略对用户使用情况的监测。在该阶段,交互设计师可以做一位忠实的支持者,帮助产品运营人员或用户研究员关注并收集用户反馈信息,并且利用用户行为数据监测、执行可用性测试等(可用性测试在产品开发的前、中、后期都可以做,并且在每个阶段的作用都有所不同)。交互设计师在该阶段可以倾听用户的声音,为后续的产品迭代注入更多体验上的优化;也可以验证自己的设计成果,提高设计的显性价值和说服力,为将来开展工作赢得更多的话语权。

1.3.2 交互设计师的工作流程

交互设计师在产品迭代流程的每个阶段都起着不同的作用,但这并不代表交互设计师丧失了自己的工作重心。交互设计师从接收需求到方案上线的周期中,有一套通用的工作流程,适用于常规性的产品迭代。交互设计师的日常工作内容,可以从迭代流程节点中体现,涉及需求分析和研究、设计执行和验证、组织交互设计评审、设计走查和验收、设计复盘和记录。非常规性的工作内容一般可以从以上流程分支体现,可能不会按照严谨的工作流程执行,如临时插入的紧急设计需求、不属于产品迭代范围内的设计师创新型需求和团队赋能型需求等。实际上,交互设计师在产品迭代流程中的关键价值在于发现问题、分析问题和解决问题、跟踪问题。

1.需求分析和研究

开展交互设计的第一步不是立即执行,而是先了解后面的设计执行是为了解决什么问题、达成怎样的目标,这一步比产出怎样的设计稿更重要。需求分析是设计执行的前置条件,在常规性的产品迭代中,需求分析由产品经理传递给交互设计师,传递形式分别为需求评审会议和产品经理与设计师的需求讨论会议,在传递过程中,交互设计师不仅要了解产品需求的背景,还需要掌握用户的真实意愿,以及在产品层面要达到怎样的效果。可能有的产品经理并不会对这些信息进行详细剖析,因此需要交互设计师主动发起沟通和提问,如果一次沟通解决不了问题,则可以发起多次沟通,直到把需求问题了解清楚为止,否则后续设计执行可能会存在偏差。对于业务逻辑较复杂的需求,可以组织相关业务人员和其他设计师一起沟通,这些活动是需要交互设计师主动发起的,不然只能停留在被动接收需求的阶段。在对需求进行剖析和理解的过程中,可以利用笔和纸绘制草图,用于沟通设计想法,将我们对需求的理解通过可视化的方式呈现,有助于提高沟通效率。

需求沟通所面向的角色通常是传递需求的人,但此人通常不是用户,所以用户对产品意愿的传递过程,中间隔了一层——产品经理,这虽然能够让交互设计师掌握需求过滤后的精华部分,但无法探索用户意愿的本来面貌。对于体量较大或对用户意愿不好把控的需求,交互设计师需要主动发起面向真实用户的调研,了解用户可能存在的使用场景和可能发生的操作问题,然后将这些问题自行转化为设计需求,并且在交互原型图中将其解决。可以根据实际情况选择合适的用户调研手段,如获取用户行为数据、发起问卷调研和用户访谈等。需要注意的是,新人交互设计师或准备转岗为交互设计师的朋友,可能会认为用户画像也需要在此阶段设定,这其实是一种理解上的误区,虽然用户画像是用户研究的工具之一,但并不是每个项目、每次迭代都需要重新设定用户画像。

2.设计执行和验证

如果通过前期的需求分析和用户调研,发现设计方案更具有易用性,则可以再次找产品经理讨论需求的合理性。除了前期的需求分析和必要的用户调研,开展同类型的竞品分析也是设计执行的重要环节。因为此时的设计方案还处于构思阶段,所以开展竞品分析相当于讨论设计方案的可行性,有助于交互设计师打开眼界和思路,以及修正一些设计思路上的错误。

在明确迭代的设计目标和设计思路后,即可正式进入设计执行阶段。此时,我们可以把前期思考过程中的关键结果记录在交互文档中,以便在设计过程中随时对标,原型图和流程图也在此时开始绘制。在编写交互设计说明时,并不会一开始就梳理得非常细致,因为这是交付给视觉设计师和开发工程师的东西,而该阶段的交互设计执行并没有结束,通常在梳理出核心流程和一些相关的页面后,会找到对接的产品经理进行确认和讨论,用于保证交互方案在大方向上是没有问题的,这样后续就不会频繁地改动了。在与产品经理确认完成后,即可继续将交互设计说明、下级页面或交互状态完善,直到输出一份细致的交互文档。至此,我们的产出物中包含需求分析记录、设计思考记录、用户调研报告、用户测试报告、原型图、流程图和交互设计说明,这些产出物足以支持一次交互设计评审会议的召开了。

如果设计内容是核心业务流程和重要、庞大的页面流程,那么通常会开展一次可用性测试,用于验证交互方案的正确性。可用性测试面向的群体是真实用户,还是模拟用户,可以根据迭代的时间和人力资源进行衡量。进行可用性测试是非常有必要的,有助于将交互方案打磨得更细致,并且测试结果可以提高交互设计师在后续设计评审中的说服力。如果设计内容是页面级别或模块级别的,那么,为了设计的严谨程度,一般会将交互方案发给其他设计师共同把关,是设计师的内部评审环节。在对可用性测试和内部评审过程中发现的问题进行优化后,就可以预定会议室,准备组织召开面向项目组的交互设计评审会议了。

至此,交互设计师的主要产出环节即将结束,在方案产出期间,我们会面临许多思维博弈。例如,是选择A方案,还是选择B方案;用户是否能够看懂;符合设计原则;等等。面对这些思维博弈,我们可以自己钻研竞品进行衡量;也可以发起临时的设计讨论,借助大家的力量进行衡量;还可以通过与产品经理沟通进行衡量;在涉及实现技术的知识盲区时,可以向开发工程师进行请教,从而在现有资源下,做出更合适的设计方案。如果不考虑开发成本,那么在后续的交互设计评审会议上,设计方案很可能被大家否定,因为超出开发成本的方案可能会影响迭代的发布进度,这在流程规范化的团队中是很严重的一件事情,需要向上级领导报备。如果交互设计师有用户体验价值高于开发成本的方案,则可以拿出来尝试说服大家,或者拆分阶段进行落地,也就是将设计方案转化成设计需求,分发到下次迭代中。

3.组织交互设计评审会议

面向产品团队的交互设计评审会议必须要覆盖到产品经理、交互设计师、视觉设计师、前端开发工程师、后端开发工程师、测试工程师等角色,在特定场景中还可以邀请业务负责人、运营人员或设计负责人参加。产品经理确认过或用户测试过的交互方案在再次进行交互设计评审时,一般主要起传达设计方案并研究落地方法的作用,重点面向角色是开发工程师,他们需要掌握有多少功能要实现、数据接口如何调用和资源如何分配的问题。因为产品经理已经对方案有所了解,所以接下来只需要协调开发资源和把控进度。而视觉设计师在评审会议后,通常会与交互设计师进行二次沟通,主要传递交互设计对视觉设计的预期想法,以及一些设计细节上的问题。如果将设计细节问题放到设计评审中进行讨论,那么很容易降低评审会议的质量和效率。如果设计负责人和业务负责人在场,那么他们可能会考量设计方案的总体表现,帮忙找出欠缺考虑或遗漏的设计点,并且对疑问进行研究讨论,通常会当场给出修改意见。如果交互方案涉及的调整面积较大,那么需要组织召开第二次设计评审会议,直到上、下游的相关工作人员对设计方案达成共识,才可以启动下一步的视觉设计或开发落地工作。

在设计评审期间,交互设计师作为会议的主持人兼主讲人,不仅要详细阐述设计思路和方案的交互流程,还可能要面对来自开发工程师的“挑战”,如“难以实现”“不好实现”“需要时间”“有没有更简单的方案”等问题。如果交互设计师对业务流程和交互方案的实现问题没有把握,但担心设计评审中发生的讨论环节会延长会议时间,那么在召开设计评审会议前,可以组织一次小范围的预研会,即预先研究方案实现问题的讨论会议。该会议只面向产品经理和开发负责人等相关核心人员,提前解决有实现难点的问题,用于分担后续设计评审的压力,使交互设计师能够及时调整设计方案,减少返工次数。在交互设计和视觉设计的评审结束后,如果有需要调整的设计细节,则可以第一时间进行调整,然后交互设计师需要将定稿邮件同步给产品团队和参与设计评审会议的人员,大家以邮件里的交互文档为主,开启执行后续的落地工作。如果在开发期间对交互方案进行了修改,则需要第一时间将修改后的交互方案同步给大家,并且标明修改位置。在一般情况下,如果交互方案仅在前端进行了优化,那么交互设计师可以主动找到视觉设计师和前端开发工程师进行沟通,并且知会产品经理和设计负责人;如果交互方案在前端和后端进行了优化,则需要优先将交互方案同步给产品经理并说明优化原因,因为涉及后端的优化通常是业务数据层面的,返工成本相对较高,事先说明情况,可以避免在开发工程师修改的过程中发现隐患问题,导致工期延长。

4.设计走查和验收

在开发工程师将落地效果提交给测试工程师后,交互设计师就可以正式介入验收工作了。没有设计走查和验收环节的流程是不完整的,会导致开发工程师对设计稿的还原度存在偏差。设计稿的偏差度在一定程度上反映了设计师的项目推动能力,这个过程非常考验设计师的沟通技巧。通常在开始验收前,交互设计师会预先输出一份走查验收清单,将关键的验收点罗列其中,如下图所示。在正式开始走查后,交互设计师会与视觉设计师一起按照清单内容走查,将与设计稿有出入的地方记录在清单内,在版本发布前全部推动改进,并且进行二次验收。交互设计师主要负责验收开发落地效果与交互文档中描述效果的还原程度,包含但不限于页面跳转逻辑、组件使用规则、交互状态和细节、异常和特殊场景、整体操作流畅度、加载性能、各端设备的适配效果及界面兼容性等。

设计走查和验收工作的难点在于如何协助开发工程师更好地还原设计稿,可以选择制作Demo效果,也可以使用竞品效果作为参考,了解代码逻辑的交互设计师可以帮助开发工程师寻找落地方法。在此期间,可能会面临开发工程师的疑问和拒绝,但是为了保证设计质量、划分工作责任,交互设计师需要尽力推动开发工程师的执行工作。如果团队有设计验收环节,但交互设计师没有验收或遗漏验收,那么上线后出现的问题要由交互设计师承担。当开发工程师整改复杂的问题时,可能距离版本发布的时间所剩不多了,通常产品经理和测试工程师会要求优先整改系统Bug,因为这是产品体验的致命问题。对于设计遗留的整改问题,交互设计师需要做好记录,然后将其直接放到下一个迭代持续整改,切勿拖拖拉拉,因为交互设计师不重视的问题,开发工程师一般也不会主动整改。如果交互设计师需要通过用户行为数据验证设计效果,或者需要挖掘更多用户潜在需求,那么在不影响上线标准的问题整改完成后,可以对产品经理和开发工程师提出数据埋点的需求,并且准备相关的数据埋点清单,将埋点的代码跟随本次迭代一起发布。

5.设计复盘和记录

这里的设计复盘不是在每次迭代完成后正式组织一次复盘分享,而是养成及时记录的好习惯,将每次迭代过程中发现的问题、思考点和亮点记录下来,以便在正式的设计复盘和晋升汇报中知道自己曾经做了哪些有价值的东西,防止遗忘。为什么很多交互设计师一到复盘和汇报时,就不知道写什么东西了?因为平时就没有总结记录的习惯。笔者认为,总结记录是非常值得交互设计师执行的一种工作,也是当前职场中很多交互设计师缺少的意识,大部分人过于关注设计产出,却忽略了职场生存技巧。总结记录虽然和设计产出没有关系,但能够沉淀交互设计师的工作能力,帮助其在关键时刻“亮剑”。此外,交互设计师如果在团队中不关注有利于团队建设的事情,只知道低头产出设计方案,则很难获得晋升机会。

总结记录的形式不限,笔者一般用在线文档的形式进行管理,按照迭代日期划分目录,会记录一些平时工作中碎片化的问题。例如,因为与产品经理讨论不充分,导致设计理解有误,造成了返工事件;在设计沟通过程中,将大家的好评截图保存下来,如“设计得非常细致”“考虑得很周到”“这就是我们想要的方案”等;自己对设计方案的落地做出了哪些思考和研究等,这些都是交互设计师自证价值的因素之一。至此,一名积极且合格的交互设计师的工作流程才算形成闭环。 ax/TzUczDa4MapkMoEnChq9lu5Wvv4PgSjxUP7C/iRQKulH/ykttC6COHjeMPZRR

点击中间区域
呼出菜单
上一章
目录
下一章
×

打开