规范性的指南在指导设计与开发的交接时很容易遵循与修改,但是这些具体的操作指南是否能跟得上未来新工具的更迭?

指导设计师与开发人员合作的5项原则

人们都喜欢步骤型的教学内容。我作为设计刊物的编辑,经常会见到许多类似于“10步完美与开发人员对接”或是“整理设计文件时的禁忌”,他们会吸引许多在执行日常工作前需要寻找指导的设计师。这些指南大多数都是一些策略性的小技巧,例如标注设计文件、整理文件夹,或是同类文件整理的最佳案例,这些小技巧被证明可以应用到工作中的各个方面。

规范性的指南在指导设计与开发的交接时很容易遵循与修改,但是这些具体的操作指南是否能跟得上未来新工具的更迭?

事实上有许多种方法可以整理文件,命名文件夹或是多版本管理。如果只是提供一种方法,那么设计者就没有考虑到每个团队的需求与执行方式都是不同的。

我们使用的工具会经常变化。设计师们处于各行各业,设计类型与所处团队规模都有差异,而且每家公司都有自己的组织影响设计师的工作流程,工具使用与执行。甚至在同一个团队中,由于时间与合作人数的变化,设计的具体流程也会发生较大的变化。

好的合作方式是提供原则指导,而不是具体策略

我工作了15年,见过许多迭代版本的设计师与开发人员的交接流程。甚至在我刚开始从事设计工作时,我们将设计文件存储在本地然后直接扔给开发人员,他们带入自己的主观审美将设计稿转化为代码实现。

经过多年来的发展,设计师与开发者的合作方式已经经历了许多变化。一些方法已经通过实践验证效果较好—但是在不同的项目中,也许某种方法很适合与这个项目,但是对另一个项目而言使用起来却很糟糕。如果我要撰写具体的合作指南,那可能我每隔一段时间都要重新撰写——所以我选择了聚焦于设计原则。原则不仅可以经历时间的磨砺,适用的设计师类型以及团队规模也更广。

下面的列表列出了我个人提出的合作原则,作为一名设计师,我每天至少花三分之一的时间与产品经理和实现设计的开发人员一起工作。虽然多年来具体的方法和技术已经发生了很大的变化,但这些原则仍然能够抵抗时间的挑战。

1. 开发人员是您的用户

如果我们像关注用户一样关注开发人员如何使用我们的设计(和设计文档)呢?

作为设计师,我们在思考产品带给用户的体验时,总是考虑用户的需求和痛点。除非你自己开发,否则最终用户永远不会与我们的设计互动,他们将与开发人员基于我们的设计文档构建的最终产品进行交互。这意味着我们在项目的这个阶段所交付给的真正用户是开发人员。

一旦我们将这个概念融入到我们的实践中,关于我们工作流程的每一个决定都是以开发人员为中心开始的。与我们对最终用户进行研究的方式类似,我们可以在项目开始时与工程团队进行面谈,以了解他们的偏好、过程和痛点,并提出满足他们需求的工作模型。

开发人员希望如何接收文档?多长时间?通过什么渠道?细节越多越好?书面文档和可视化文档之间的正确平衡是什么?对于特定的开发人员来说,如何使用系统里怎么去工作的非可视规则的最有效方法是什么?这如何与产品的其他部分和组织内的其他组织相结合?

团队可能为了方便协作会为项目建立一个维基百科文档;也许这个维基文档只是一个每周两次的会议记录,其功能更多的是作为记载会议的问答对话而无法形成具体的规范。有一些团队习惯在整理好所有设计文件后才会着手开发;还有一些团队比较灵活,会在开发迭代和实验中不断的完善规范。

既然我们在设计过程中要根据用户的需求调整我们的设计解决方案,同理我们也应该调整我们的设计工作流程,以适应我们的开发合作伙伴的需求。

2. 唯一能确定的是:改变始终存在

设计师需要灵活处理项目,我们不仅要调整我们的流程以适应不同的团队配置,而且还要随着项目的展开调整我们的工作流。

除了极少数案例外,我们每次启动新项目时都必须调整文档和工作流。随着经验的积累,我们总结形成了自己撰写文档的模版,这种模版在特定的环境下可能会很好用,但不一定在所有环境下都完全适用。一个模版不是处理每个团队的设计文档和协作的好方法。

其次每个开发人员的习惯不同,有些开发人员喜欢和设计师面对面交流处理具体问题,还有一些开发人员可能更喜欢通过线上消息沟通或是投票表决来解决问题。

不是所有的事情都可以在设计师的掌控中,设计师唯一确定的是:每个项目都会存在变话。

有时候一些客观的因素会影响你的工作,例如新同事加入团队,发布日期的突然调整,不可预见的平台或网络技术的约束。学习识别团队中无形的协作机制并让自己做好快速调整工作流程的准备,这也许不能在短期内避免挫折,但是会让你变得更好。

3. 设计永远不会终结

当我们完成一个项目的设计时,其实我们只完成了一半的工作。

特别是在瀑布式开发的项目中,或是敏捷性开发的初级阶段,有一种常见的误解:即设计师的工作就是将所有屏幕显示需要的图绘制出来就完成了所有工作,例如设计产品模型或原型,会让人误以为设计师的职责仅仅是满足开发要求设计师做的每个网页图片。但实际上设计师应该不仅应该考虑屏幕上显示的页面图片,还需要分析背后的功能。

真正的挑战开始于开发人员开始四处寻找关于我们设计的问题以及测试人员分析出设计师没能预见的用例。添加的限制和规则越多,我们就越难在这些条条框框容纳新的需求,并同时保持体验的简洁与明晰。那就是关键时刻:大多数团队能画出合格与优秀设计师之间的那条线。

我见过太多设计师推卸责任——这绝不是一件好事。如果最终的体验没有按照我们的设想实现,那么这就是包括我们设计师在内所有人的责任。我们的角色是创造易于使用的体验方案,而不是看上去漂亮的界面。这意味着我们需要为团队实现的最终产品负责。

4. 少一点,但更好

当产品经理砍掉产品某些功能来得到一个最小可行性产品时,设计师并不会感到沮丧,而是将它变为提升已有功能集合内体验的机会。

富有远见的德国设计师Dieter Rams时二十世纪最受认可和最具影响力的设计师之一。作为功能主义的坚定信仰者,他对设计的理性认识可以概括为他的著名短语:“少一点,但更好。”虽然他当时显然是针对工业设计,但这一概念对于我们当今创造的数字产品和服务仍然适用。

随着设计的发展,产品经理开始优先考虑功能,这时设计师会发现他们的许多工作都被缩水为最小可行性产品,包括他们对产品的最初设想和经验,这会令人感到沮丧。而我所知道的最优秀的设计师会将这种沮丧转变为机会,他们知道提供更少的功能是完全可以的,只要能提升体验即可。

对于我们设计师而言,需要设计的功能变少意味着:

我们能将更多的时间花在更少的设计方案上使其更好:例如过场,状态,动画,复制。我们能更紧密地和开发人员合作以保证我们正确传达了初始设想。5. 激情具有感染力

在一些公司中,开发人员不参与早期的构思、设计探索和产品经理的战略层次讨论。我们如何才能帮助他们理解和领会,从而真正了解正在开发的功能?

设计师代表了团队中用户的声音。我们常常理所当然地认为,我们有能力设身处地为用户着想,而忘记了我们可以在团队中传播这种观点和看法。可以是我们在研究过程中从用户那里听到的一个小故事;或者是某个人的个人故事,因为我们所创造的产品改变了他的生活方式。

我们的同理心,对用户的关注以及我们的热情—这些都是宝贵的资源,我们可以用来启发开发人员,帮助他们理解某个特定功能应该如何工作,并且了解它将如何影响人们的生活。

设计是一项团队活动

(谢天谢地)“摇滚明星设计师”的旧模式正在消失。随着数字团队的增长与项目变得更加复杂,设计师因其协作技能和团队支持而受到重视,而不是仅仅绘制具体的交付物。定义团队之间的合作原则才是我们执行具体工作的第一步。

原文地址:https://uxdesign.cc/5-principles-for-better-designer-developer-collaboration-36b4094887db

本文由 @喵吉斯蒂 翻译发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议




阻力设计在产品中的应用

阻力设计在产品中的应用

阻力是指物体在流体中相对运动所产生与运动方向相反的力,不仅在自然间中常见,在互联网中也广泛存在。本文作者从五个角度,深入分析阻力设计在产品中的应用,希望对你...

2020-06-18
如何成为一个合格的数据架构师?

如何成为一个合格的数据架构师?

数据架构师在互联网行业中是个很重要的职位,是企业数据资产最重要的“奠基者”。那么,如何成为一个合格的数据架构师呢?本文作者基于自身经历,从三个方面展开介绍,推...

2020-06-18
倒推“抖音短视频”APP产品需求文档

倒推“抖音短视频”APP产品需求文档

文章是倒推“抖音短视频”APP产品需求文档,但由于作者是第一次写需求文档,所以仅对核心需求进行了需求分析与说明。一起来看看~ 目录: 一、文档综述 1.1文档属性 1.2产...

2020-06-18
微信“拍一拍”,真的是一个没什么用的功能吗?

微信“拍一拍”,真的是一个没什么用的功能吗?

昨天微信上线了“拍一拍”功能,用户点击2次头像,会产生头像抖动,震动反馈,且在聊天框中显示“XX拍了拍XX”。 这个功能推出后,很多微信群都在疯狂拍一拍,引起了一波拍...

2020-06-18
数据大屏设计师,我不信你没有这些困惑(上)

数据大屏设计师,我不信你没有这些困惑(上)

从事互联网行业的人,每天都在接收新知识,时常也会有迷惑的时候,尤其是数据大屏这样比较少有人踏足的领域。本文作者以自身经历出发,对数据大屏设计提出了自己的一点...

2020-06-18
客户关系管理的15个模型总结(下)

客户关系管理的15个模型总结(下)

对于ToB产品,仅仅基于用户需求来设计产品架构是远远不够的。B端产品服务的是有着几年,甚至几十年管理积淀的企业,必须依靠一定的理论知识来支撑系统的设计规划。本文...

2020-06-18
B端产品设计:价值主张与需求对应的价值

B端产品设计:价值主张与需求对应的价值

B端产品的需求来源于场景,产品经理通过满足客户需求从而产生价值。因此,SaaS产品经理面对扑面而来的需求时,应当更清晰理解并评判需求的价值。 01 2008年,著名商业...

2020-06-18
以知乎为例,探讨未来产品设计的几大变化

以知乎为例,探讨未来产品设计的几大变化

知乎作为一个典型的问答社区,它本身反映了内容社区产品的很多典型问题。本文以知乎为例,探讨社区类产品未来发展的一些变化,对内容社区感兴趣的童鞋不要错过。 前段...

2020-06-18
如何用产品思维打造线上课程?

如何用产品思维打造线上课程?

如何用产品思维来给自己打造一个线上课程呢?本文从市场调研、课程开发、运营推广、成交这几个方面分享如何打造自己的课程,希望对大家有所帮助~ “地摊经济”重出江湖,...

2020-06-18
「武侠连载」营销中心设计——优惠券

「武侠连载」营销中心设计——优惠券

优惠券是常见的一种营销推广的方式,但是你真的了解它吗?本文作者以武侠故事的形式,对优惠券展开了生动的分析,对优惠券感兴趣的童鞋不要错过哦。 (武侠情节接上文“...

2020-06-18
金融支付财务融合业务-实践分享1:订单、账单、交易流水、账套知识解构、原理解析

金融支付财务融合业务-实践分享1:订单、账单、交易流水、账套知识解构、原理解析

本文作者从实际工作实践出发,结合案例等分享了电商金融支付财务融合中的基本概念和相关原理解析,包括:订单、账单、交易流水和账知识解构,供大家一同参考和学习。 ...

2020-06-18
关于卡片设计的分析与思考

关于卡片设计的分析与思考

卡片是APP常见的设计形式,它既有好处也有弊端,因此需要根据场景和内容确定展现形式。本文从四个方面对卡片设计展开分析,推荐给对卡片设计感兴趣的童鞋阅读。 卡片是...

2020-06-17
内容型产品中,付费会员功能如何设计?

内容型产品中,付费会员功能如何设计?

付费会员制度让用户预付会员费,将钱留在平台,那么未来一定会有消费行为,那么会员制度要如何设计,才能激励用户付费呢? 01 为什么要做付费会员? 讨论这个问题之前...

2020-06-16
文字社区是否可以拥有弹幕?

文字社区是否可以拥有弹幕?

从社区产品的角度来思考,弹幕功能对于内容生产方,内容消费方以及平台方而言各自有什么意义?图文内容社区是否有机会拥有弹幕呢?如果可以发弹幕,用怎样的形式呢?本...

2020-06-16
FMS财务系统收支结算总结

FMS财务系统收支结算总结

本文按照FMS收支结算划分,结算流程分类及各系统交互,财务系统内部结算基础能力,收支结算整体结构的顺序来依次介绍,总结财务系统收支结算的结构,和一些作者的个人思...

2020-06-16
如何迅速提升用户好评?试试这三种方法

如何迅速提升用户好评?试试这三种方法

小编推荐:如何提高一个产品的用户评分,改变大家对这个产品的印象呢?本文作者给大家介绍了三个概念:用户体验地图、峰终定律和服务蓝图,并详细解释了该如何使用这三...

2020-06-16
对工具型产品易学习与易使用的思考

对工具型产品易学习与易使用的思考

小编推荐:易学习是指怎么让新用户的学习成本降低,能够很快地掌握产品的使用,它的前提是足够简单和容易理解。而易使用是指,如何让用户快速、高效地完成一项任务,达...

2020-06-16
比对象还懂你!推荐算法为啥这么准?

比对象还懂你!推荐算法为啥这么准?

信息过度和广告过多的社会中,推荐算法的使用也就显得理所当然,但是它是如何做到了解用户的呢?本文从用户画像的定义和设计出发,结合实际案例,深入浅出地阐述了基于...

2020-06-15
B端平台产品需要培养的4种意识

B端平台产品需要培养的4种意识

对于许多刚入行不久的产品经理来说,B端平台产品是比较有难度的一项工作。本文作者基于自己的工作经历,提出了四点关于B端平台产品需要培养的4种意识,希望对你有帮助。...

2020-06-15
广告系列:保留价

广告系列:保留价

在一次拍卖中如果所有买家的报价均小于卖家的估价时,则拍卖品不出售由卖家保留,此时卖家的估价就是保留价,也叫底价,全称市场保留价。对于卖家来说,保留价的设置保...

2020-06-15