身为产品设计师,我从工程师身上学到的产品开发心法

www.pptschool.com 沐鸣平台注册 2020-04-28 1,593 次浏览 没有评论

由于我这几年都是就职于 design agency(设计工作室),我们并没有很多 in-house (组织内)的工程师资源,唯一的前端工程师人在伦敦,我从来没机会跟他合作。

因此,我一直以来对接的都是客户端的工程团队,将设计文件寄出去之后不一定有办法实时回馈,如果不在档案或信件中解释清楚的话,对方有很大的机率会误解,所以我交付档案给工程师的时候都比较慎重、详尽。

直到几个月前,我们工作室为了孵育自家产品,招募了两名工程师,一名后端工程师与一名偏向 UX Engineer 的工程师。

两位都是从竞争激烈的游戏产业出身(他们之前在植物大战僵尸的公司工作),各自都有将近十年的实战经验,也曾经管理过工程团队,所以对于产品开发的理解比我们公司所有人都更熟悉。

最近我也投入自家产品的开发,跟这两位工程师和一位资深互动设计师组成四人项目小组,发现自己简直爱翻跟工程师并肩合作了。

导入产品开发流程

由于设计工作室的性质,我们以往都是根据客户的需求以及时限来推进项目,例如三个月的项目要花两周完成产品策略、四周完成线框图之类的决定都在项目一开始就非常清楚,所以我们虽然有设计迭代(从设计图 A 转变成设计图 B),却没有很明确的产品功能迭代。

工程师将他们的产品开发流程导入到我们的 workflow 中,几项简单的例行事项就让我们的 workflow 越来越流畅,也让我学到许多产品开发的眉角。

Daily Stand Up 每日站立会议

工程师很坚持每天都要有十五分钟到三十分钟的 stand up meeting,让每个人概略报告一下自己昨天做了什么、今天打算做什么。

站立,而不是坐着,强化了该会议打算简短且避免浪费时间的想法。站立会议并不是一个解决问题的地方,而是让一个团队意识到现在的状态。如果需要讨论,适当部门可以安排另一个更长的会议。(摘自 MBA 智库百科)

一开始我很疑惑为何需要如此坚持每一天都要开会,毕竟有时候设计卡关,可能连续几天都在做一样的事情,stand up 的时候反而会感到自己没什么能分享的。

后来发现每天 stand up 让大家永远有机会可以提出问题,或是分享遇到的困难,比较不会因为偶尔一次的大会而感到有问题太小不该问,或是有问题还等到下次开会的时候才问,那都可能已经太迟了,stand up 能够帮助团队迅速注意到症结点。

Sprint planning 冲刺规划会议

我们采用 sprint 的方式开发产品,利用 Asana 当作项目管理的工具。工程师提出一种理念是:在每个 sprint 开始时都重新建立一个 Asana board,目标是要在 sprint 结束时将所有卡片消掉,没消掉的卡片就要在下一次 sprint planning 时决定是否延续此项任务,要不然就做好 documentation(文件纪录)之后摒弃掉,绝对不存 backlog 在这个 board 里头。

另外,在创建任务卡片时也不会一开始就指定负责人,因为设计工作室的接案本质,每个设计师都有可能因为新进的项目而被抽出这个小组、转移重心,所以最重要的策略就是要让任务模块化,卡片可以随时交接,当我重新加入项目时可以将没有人负责的任务捡起来做。

Retrospective 回顾会议

再来说说我最喜欢的项目 — 回顾会议(Retrospective,简称 Retro),在每次 sprint 结束后都会开一次,顾名思义是要回顾这个 sprint 的好与坏,藉此更加精进我们的流程,以下是我们 retro 的架构:

1. 回顾上次的行动项目(action item)

根据完成程度帮自己打分数,我们是用笑脸、木然脸跟哭脸当作评分

2. 做得好的部分

称赞大会,将这次 sprint 里头运作良好的部分提出来。曾经出现过的赞赏是任务量计划得刚刚好、工程师跟设计师沟通良好等;也会提到一些比较随兴有趣的,比如说伦敦的工程师当爸爸了、感恩节要到了。

3. 有待加强的部分

这大概是最重要的环节,只要专注于点出问题是什么,避免直接跳到解决方案,以免时间浪费在试图解决一个问题,却没有正视所有问题(这真的超级难,所以我们经常要口头提醒彼此不要跳到结论)。

4. 解决方案的行动项目

将有待加强的部分全数列出之后,选定几个来想出可能的解决办法,产生的行动项目要指定给某一个人,避免三个和尚没水喝的情况。

我很喜欢 retro,因为这跟个人的自我省思很像,每次反省都能让我们更了解自己、找出问题与解法,进而让流程越来越进步、顺畅。

工作过程中如果感觉自己因为某些流程感到困扰的话,也不会因为跟实际的设计工作无关而一直闷在心里,retro 时就可以一一点出。

工程师说从来没人喜欢过 retro,一直说我真是奇怪的人,但除了我认真相信反省能让团队变得更好之外,我也认为 retro 做得好的话是个近似于 team building(团队建立)的环节,让团队成员更了解彼此在乎的点。

迅速迭代

最后一项并不是实际方式,而是一种心态,跟设计工作室以往风格不相符的心态。

再一次,因为工作室的接案本质,最终成品往往是送出去之后就没有机会修改了,而送出去的成品代表着我们工作室的声誉,如果交出的质量不够好,客户就不会回购了,导致我们很多时候对最终设计过于小心翼翼。

一开始我们总是在很后期才跟工程师说设计需求,担心他们会做许多白工,工程师后来反倒反映说赶快产出各式各样的原型才比较好进行测试,让我们亲身感受一下我们画出的流程真的使用起来是什么感觉。

他们说,在开发产品初期做任何决策时,我们要扪心自问的第一个问题不是「这会成功吗?」,而是「我们可以从中学到什么吗?」

开发产品时就不能总是将完美当作目标,而是要以学习、改变为最高目标,不畏失败,先推出才有真实的数据跟回馈得以学习。

工程师总是鼓励我们只要产出「够好」的设计就可以了,我们永远可以在下一次迭代导入真实的回馈,无论是来自于真实使用者或是团队外部的回馈,来进行迭代,而不是单纯用设计师的臆测与想象中的完美不断自主迭代。

友善的工程师

虽然说比起视觉设计师,我自己在思想上本来就跟工程师比较接近,但这两位工程师真的是非常友善,从来没有让我感觉到设计师与工程师之间常有的紧张关系。

1. 沟通、沟通、沟通

第一次跟 in-house 工程师合作,能够进行各种现场交谈就已经让我觉得乐胜远程合作,而且他们又特别强调沟通的必要性,他们不断灌输我一个观念就是「如果被卡住超过 15 分钟,来找我们」「如果对工程限制有什么疑虑,来找我们」「如果想讲垃圾话,来找我们(欸)」

总之就是设计师有什么新想法都尽量跟他们说,他们都很愿意仔细聆听设计师的想法,同时也会提出身为工程方的见解,比较偏 UX Engineer 的那位甚至会提供解法,画出线框图跟我们沟通。

同时,他们也很尊重设计师的看法,当他们在架构后端的时候,偶尔也会丢出一些问题说「这样的数据处理方式,好处是 ooo,坏处是 xxx,我觉得这样做比较符合用户流程,设计师你们怎么想?」尊重设计师专业,不会径行做决定。

2. 合作弹性

对于设计迭代他们也完全接受,因为我们不走瀑布式开发,所以有时候设计师在画图的时候,工程师也同时在写同一个页面的 code,设计经常在变,导致他们时不时会需要这边改改、那边修修,他们完全 OK,我跟另一个设计师常常打趣地说我们完全被宠坏了。

结语

几个月的合作下来,跟这两位工程师在私底下也变成好朋友,很常跟他们在 Slack 私讯(额外发现:工程师真的很爱 meme 跟 gif),也偶尔会跟他们出去 happy hour 喝酒聊天,他们也一直说要教我怎么写 React(真是太看得起我了)。

最近深深感到能够跟他们认识并合作真的是太幸运了,从他们身上能学到很多在设计师身上学不到的东西,觉得自己对产品圈的知识又多了一些。

回顶部