资产移交

在由设计师和前端开发人员组成的团队中，当涉及到将资产从一个团队成员移交给另一个团队成员时，可能会出现很多挫折和困惑。这些可能是设计模型、图标或横幅等的高保真图像。无论这些移交的内容是什么，这个过程总能有所改进。

根据项目的不同，开发人员通常需要某些材料才能使开发尽可能顺利。因此，我想回顾一下设计师可以采取的一些步骤，以缓解这些压力点。

1. 在项目开始时与开发人员讨论他们的需求

这听起来像是一个显而易见的说法，但在过去，我曾在一些团队工作过，我们没有在流程的早期进行过这样的对话。这可能导致各种沟通故障，开发人员不知道哪些资产是最新的。然后，这可能导致实施根本不需要的功能。

以下是一些你可能在开始时提出的问题

• 前端开发人员是否熟悉Photoshop或Illustrator？
• 是否最好在某个特定应用程序中提供模型，或者他们可以使用已导出的简单图像来构建网站？
• 我们需要什么图像尺寸？我们通常如何处理图像？是否有构建工具正在创建我们需要的各种尺寸？
• 我们使用哪种错误跟踪工具？以及我们应该如何描述、命名和标记需要开发的新组件？

2. 模型移交应由小型模块化组件组成

如果开发人员收到一个Photoshop文档，其中概述了模板的整个设计，例如“关于”或“主页”，他们更有可能编写糟糕的代码，将所有这些上下文相关的组件绑定在一起。 正如Harry Roberts所论证的，这仅仅是不好的设计。

如果需要根据UI组件放置的位置更改其外观，则设计系统已失效。就这么简单。事物应该被设计成无知的；事物应该被设计成我们总是只拥有“这个组件”，而不是“当在……内部时的这个组件”。

这意味着开发人员最好先构建独立的组件，然后再将它们捆绑到特定的视图中，例如那个“关于”页面。这不是一个新想法——原子设计多年来一直在告诉我们这一点——但我的观点是，移交过程也应该反映这种思维方式的变化。

3. 执行界面清单

在将新项目添加到团队的任务列表之前，我们需要确保他们不会遍历每个模型来查找该新组件的每个修改。收集设计中每个按钮或图标的过程应该是设计师的角色，因为这将帮助其他团队成员将视觉设计更改推断到代码中。

Brad Frost 将此过程称为 界面清单，理想情况下，它应该记录模型中每个组件的每个修改和偏差。

界面清单类似于内容清单，只不过它不是筛选和分类内容，而是对构成网站的组件进行盘点和分类……界面清单是构成界面的小部件和片段的综合集合。

在设计师执行此界面清单后，他们可以开始将所有这些变体添加到像Trello这样的应用程序中，正如我们之前提到的，当设计师可以 跟踪错误并定义需要构建的新功能 时，它有多么有用。在我们的待办事项列表中，最好将这些界面清单附加到项目本身，而不是使用一段文本，例如这样

作为一名前端开发人员，我发现这比一个巨大的模型目录更容易访问，我需要检查并挑选出每个组件（特别是如果我不熟悉特定设计师的图层结构）。说到这里……

4. 如果必须移交PSD，请确保仔细描述每个图层

关于这一点，没什么好说的，除了如果将来有人需要浏览这些图层，保持这些图层的组织性非常有意义。

5. 导出资产

在过去，我参与过很多项目，其中开发人员负责接收移交的模型并浏览每个文件以导出所有内容，即使他们不熟悉设计。这些可能是横幅图像或图标，甚至可能是副本的最终草稿。

但是，如果我们有由模块化组件组成的较小的移交，则误解的可能性较小。

6. 只导出SVG资产

由于开发人员现在可以使用许多构建工具（例如Grunt和Gulp），这些工具可以根据需要生成位图图像（例如.png或.jpg），在某些情况下，开发人员只需要特定资产的SVG。例如，在为项目开发一组图标时。在大多数情况下，添加这些位图资产可能是浪费设计师的时间，因此只需要从设计师选择的应用程序中导出的原始SVG。

同样，优化图像也不是一个好主意，因为我们的构建工具可能会处理这些修改。但是，如有疑问，请事先与前端开发人员交谈。

7. 为图标和图像命名，并将它们放置在正确的目录中

这一点有点棘手，因为它需要再次与开发人员交谈。但是，将图标命名为image-1.svg或icon-13.svg显然不如person-running.svg或windmill.svg对开发人员更有用。在大多数情况下，这些文件将存在某种预先存在的命名系统，特别是如果我们需要多个版本出于某种原因，例如windmill--large.svg或windmill--small.svg。

总结

没有正确或错误的方法，但这确实要求团队中的每个人都按照相同的标准工作。如果您有权访问存储库，则最好将其中一些想法添加到自述文件中，以帮助将来的其他设计师和开发人员。

如果您有任何其他想法，请务必在下方添加评论，我将更新此帖子以供进一步参考。