如何减少设计师与工程师之间的偏见.docVIP

如何减少设计师与工程师之间的偏见？作为一个在以工程为核心的公司里工作十余年的设计师，我绝大部分时间与工程师们一起工作。而这些合作无疑是我最具实用性、最有成效的工作关系。 　　同为设计师的你，也可以创建与工程师之间和睦的关系。你只需通过减少设计师与工程师之间的个人偏见，为彼此间的有效合作关系创造空间。如果你做到了，达到那一步的好处将远远大于偏见带来的困难。 　　在业界，我曾在一家世界顶尖的工程公司当顾问。我见过很多设计表现手法，也和很多类型的设计师合作过，不管是注重技术、概念、视觉或者其它方面的设计师。 　　设计师有几种类型的行为会让工程师和设计师的关系糟糕。但是我在一家以工程为中心的公司从事设计时，通过自己的方法在工作过程中，与工程师们建立了其他设计师没法达到的一种长期、信任、高效的合作关系，取得较大的成就。对于一个好的设计师来说，如果拥有不错的工程合作伙伴将会事半功倍，但要达到这样，就必须做一些调节。 　　以下是我对于建立设计师与工程师之间有效关系的几个建议，目的是通过减少双方的成见，帮助建立强大的团队从而做出更好的产品。 　　1、使用程序员使用的工具 　　当设计师加入一个团队或者新的项目时，首先要问自己“你喜欢怎样去工作?”很多设计师都会犯这样的错误：他们只接触自己熟悉的工具和程序，或者总从以前的团队中获得成功经验。但如今软件更新如此迅速，并且每个团队都是不同的。 　　通过询问技术团队喜欢的工作方式和现在使用的工具，就可以跳过那种痛苦的磨合过程。一些团队喜欢创造一个合作文档来追踪漏洞，或者使用一些常规的漏洞追踪软件。而另一些团队则喜欢用电邮沟通，或者使用简单的项目管理工具，比如Pivotal Tracker。 　　设计师成功的关键不在于他们作品有多漂亮，而在于他们在让作品变得更符合理想设计的沟通过程中是否成功。一个真正成功的设计师可以接受任何能有效沟通设计的产品——即使要花一点时间去学习该工具，但因此减少与工程师的摩擦是值得的。 　　2、参与到整个工程周期 　　设计师总是等到产品快发布时才会出现，这样设计师就容易和工程师交恶。工程师会觉得一个旁边者突然就进来插一脚，要求在细节上作出改变(如果你只在产品发布前出现，那你当然是一个旁观者)。 　　工程师需要设计师全程参与产品的整个生命周期，而不只是开发前端。设计师应该深刻地意识到(如果他没有全程参与的话)建立数据结构、储存、检索和UI结构是一项艰难的工程。设计师应该与工程团队的每一个成员推动工程进展，即使它只是一个半成品。 　　我看过很多设计师对工程师的早期样品持批评态度。如果工程师在面对一项他们还没有仔细思考的事情时就遭到了设计师的批评，那么在未来，他的反馈也不会是积极的。最后，设计师在产品发布的时候总希望工程师做很大的改动，但是通常工程师都不会答应。 　　3、充分说明需要改进的地方 　　很多设计师认为当他们交给工程师一件完整的，“像素级别完美”的模型就完事儿了。设计师在茶品发布前夕都会感到焦躁。但是不要对工程师说：“这和我的模型不符，这里是新的模型”，而是要在充分说明需要改进的地方。 　　设计师被训练得会注意到常人不会注意到的细节。工程师不是故意忽视这些细节的——就像设计师不会关心基础功能和开源代码一样，工程师也不会优先关注这些细节。设计师的工作就是找出这些问题，并且以尽可能详细地指出来，因为与你一起工作的工程师们并没有像你们一样被训练得如此注意细节。 　　在做现场的意见反馈时，把你的模型和demo放在一起。在demo中出现的截图都要详细标注，到底是哪里需要改进，把这些展示给工程师并且进行说明。我经常会在意见反馈中标注“之前/之后”的截图对比，并且用列表形式总结需要做的改进。用这种方式，视觉型和文字型的工程师都可以迅速并仔细进行改进。 　　我做得不止这些。我还把交互设计的改进也单独进行归类整理，因为你的团队中工程师可能擅长这方面或那方面——如果要分类的话，整理能方便分摊工作。总体而言，工程师对改进的分类反响良好，因此他们可以系统地进行改进，一旦完成便可以核对。这是我职责之外的事情，但是这让我少跑了几趟腿。 　　4、现实中的聊天很好，但是聊天记录无法被追踪 　　我所知的很多设计师都喜欢单独与一个产品经理或者工程师私聊设计细节。这很棒，而且可以增强团队的凝聚力，但是不好的地方在于没有“书面记录”。除非你的团队只有你和工程师两个人，否则所有的事情都必须记录在案以便整个团队了解和反馈。 　　所以即使你和你的工程师在私聊时在设计改进上碰撞出了火花，但是你仍要回到桌子前，立刻用邮件或者意见反馈的形式总结出来这些内容。这会给团队一个机会去反馈，并且可 　　以作为决策的记录。在最后所有事情都变得错综复杂的时候，没有记录在案的每一个决策都要引起注意。 　　5、和你的工程师喝一罐啤酒吧