设计师如何与开发者合作（二）：需要询问开发者的问题

2016-11-01 11:03:00

设计师如何与开发者合作（一）：什么是为开发而设计？

@王希玺：这篇译文来自Invision团队免费提供的系列课程：设计师如何与开发者合作。本文是第二期，一起来看。

从哪里开始：需要询问开发者的问题

伟大的设计能够在不破坏用户体验的情况下驾驭各方面的约束

在响应式设计的世界，约束来自方方面面：从现有用户的浏览习惯到技术开发团队的实力。

在这一篇，我们将讨论在你开始设计之前可以咨询开发团队的具体问题，从而确保你们能更好地合作。

超级产品经理

问题1：你希望以何种形式交付成果？

我喜欢关注开发者是否习惯于我的交付物，因为这决定了你使用哪款软件来创建模型。

我见过太多设计师（包括我自己）完成设计后，被要求回去改为另外一种文件的格式。想想吧，你好不容易完成了最终稿，充满士气地拿去开发，结果被打回来要求用另外的文件格式来交付设计物。

下面是几个在开始设计前需要和开发团队沟通的问题：

所有的资产如何准备？

他们是喜欢你把图切好，把所有的资产放进一个有层级的文件夹？

还是说他们希望拿到源文件，然后自己来提取图像？

如果是后者，他们想哪种源文件？

PSD？

AI、EPS、PDF？

Sketch？

他们的软件版本和我是否相同？（他们是否能打开这些文件？）

你需要如何组织和命名你的图层来帮助他们快速找到他们需要的资产？

他们希望你从DW或WYSIWYG编辑器输出HTML吗？

如果现在你在用DW直接输出HTML，一定要问清楚他们这是否是最佳方法。十有八九他们可能不喜欢这种方式。

就我的经验，从图形用户界面直接生成的代码往往缺乏组织且没法用，这种办法常常会同时拖累设计师和开发者，所以尽量避免通过图形用户界面产生代码。在你使用这种办法前一定要好好跟开发者讨论一下

超级产品经理

资产需要附带说明文档吗？

你打算如何记录那些在你递交的模型中无法直接表示的元素？像颜色代码，高度/宽度尺寸，字体，字体大小，间距，Alpha值，悬停效果，动画和其他数据点等资料必须定义和记录，而不是让开发人员去猜测这是怎样实现的。

一些有用的软件：

Omnigraffle：轻松添加箭头，符号和其他按键，来帮助解释一个设计的细节。

Avocode：它可以让你从Photoshop和Sketch中导出色彩，图像资源，字体，文本，CSS，大小和尺寸。可以解决很多麻烦。

Invision：非常优秀的快速原型工具，你可以在几分钟内制作可交互的原型，并且适合团队使用。

超级产品经理

问题2：网页是用前端框架构建的吗？

现在有许多开发者和设计师在长期工作中总结出来的框架。了解它们，并利用它们来修正你的设计。

许多流行的框架如Bootstrap何the 960 Grid都采用了12行布局。为什么是12行布局？12是最容易被分解的数字，你可以在此基础上设计12,6,4,3,2或者其他等距的行布局，这会让你更快地做出设计决策。

根据这些框架来设定结构预先设定好尺寸。你需要了解你所使用框架的各种属性：填充值，列宽。分割线宽度，媒介断点值等等。

我曾经在设计过程中有过中断，因为我在sketch中设置的5px边距比Bootstrap的默认边距要大。这不是什么好事情。因为这个设计得重新编码和配置，来解决这个本不应该出现的问题。所以在设计前要明白网页将使用哪个框架来构建，并且知道它们在设计软件中会是什么样子。

除了网格系统，很多前端框架都有内置的设计元素，像按钮，表单这些。如果想要修改这些默认样式（我也推荐你自定义来适应品牌调性），一定要确保开发者知道这一点。

基本上每一次我设计一个带有特定颜色、宽度的表单是，开发者最后还是使用了框架默认样式。都是因为我没有沟通好。

永远不要指望开发者注意到了你用了2像素的圆角来精细化按钮。他们可没有被培训说要注意这些。但是他们可以很精准地按照指示行事。所以确保跟他们沟通好。

一些现在流行的前端框架：

Bootstrap
Foundation by Zurb
Pure by Yahoo
Skeleton
Semantic UI

…还有许多别的。

在开始设计之前一定要搞清楚开发者偏好使用哪个框架。

大多数框架都配备了模板资源。你可以很容易地找到它们并在PS或Sketch中精确地匹配。这方便了所有人，所以尽情使用它们吧！

超级产品经理

问题3：开发环境是由哪些语言和库构建的？它们有什么限制？

就算你自己不知道怎么写代码，你可以找到一些优秀的插件。每个代码片段都是现成的。它们使得在你的网站上添加功能变得比过去容易很多。美中不足的是，插件不可能适应所有的情形。

如果你想为自己的网站找一些已经构建好的部件，那是很正常的念头，也很有帮助。但你在这么做这钱，你需要明白使用什么语言来搜索这些部件。

每一个插件或者小部件都是由它们的作者使用特定的编码语言完成的。很多时候，某个部件的编写语言与你的网站的开发环境是不匹配的。这会让你的开发者大为恼火。

一个用Ruby构建的天气应用程序不会在PHP上搭建的网页上运作。一个WordPress插件没法应用在用NET搭建的网站上。角度加载条可以用在Javascript中但不能用在Backbone.js中。

你能明白我的意思吧？

就算你找到了一个跟你的开发环境匹配的部件，并使用它向你的团队解释你想实现的效果，如果开发者愿意选择实现它，那是最好不过了。但你最好不要直接发给他们一个代码压缩文件，然后就要求他们“在我们的产品里实现这个效果”。这就像一个客户给你发了一堆100px的缩略图，然后要求你“把它们变成高清大图”。这是很自以为是且居高临下的态度。