UI设计交接给开发之后看起来更糟的7个原因，以及为什么这可能是你的错

今天小编给大家带来的是UI设计交接给开发之后看起来更糟的7个原因，以及为什么这可能是你的错，本篇文章描述了我们交付设计的时候一般的流程，以及提出了7个为什么交付给开发做出来之后产生问题的原因以及相对应的提升思路，一起来看看吧！

 

前言

你听说了好几周的那个令人兴奋的新网站项目已经逐渐浮出水面。该项目正在顺利进行中。用户体验研究的工作已经完成、撰稿人负责的产品文案已经精心编写完毕、项目收录了很多超级棒的照片素材。整个团队正在致力于信息整合，品牌元素和项目需求的工作。

紧接着就是界面设计。你最喜欢的部分。在这个环节可以利用你的设计技能来制作完美的UI。

这将是不可思议的！世界将歌颂我！

发光的时候来了！

你开始用Sketch绘制草图，然后在Figma里做整套UI设计。你与利益相关者一起解决问题。你进行可用性研究并迭代设计，直到你对它们有信心为止。

然后终于在某个时候，设计被审核通过。真棒！

做得好，设计师，它已经被通过了。我们什么时候可以上线？

完成后我一定会把它放进我的作品集！

交付

现在，你讨厌的部分来了。将经过微调的设计交给项目的前端开发人员。

害！总是在这个环节开始走下坡路……

接受，不接受！

你通过电子邮件向开发的同事发送你的设计稿。从以前的经验中学到，你应该指定字体大小和间距。也许ta甚至可以从Figma或Sketch原型中提取一些CSS。

现在交给ta！如有任何疑问，ta会尽快与我联系。

你需要耐心等待设计返回正常的测试版本。

 稍等片刻

几天后，开发向你发送了测试版本的链接。你的心沉了。在查看它的前10秒，你会发现几个问题。当你再凑近看时，还有更多。

一个打破了的破蛋不是煎蛋。 

 

由于某些原因，你对开发的同事丢了些印象分。ta对平板界面的布局做了些奇怪的决定。基准网格不起作用。全宽图片没有被正确裁剪。卡片没有水平对齐。界面也没有任何悬停状态。我可以继续，但是相信你也已经意识到了。

为什么总是这样？它有很多问题，这很明显！

你有点生气。为什么总是这样？是时候起草长长的修改清单的邮件了。这封电子邮件是明确且合理的。你要求进行特定的更改，并期望这一轮反馈足以解决所有问题。

你点击发送电子邮件，然后放松一点。至少你已经移交这个任务了。

嗨，xxx，感谢你发送测试版本的链接。但，这不是我所期望的…

你不能修复它吗？

开发同事阅读了你的《战争与和平》版本。ta回答了后续问题，进行澄清并提供了决策依据。

ta解释了为什么卡片不能水平对齐。标题的长度可以是6个字符到143个字符。这意味着标题的长度可以是1-3行，这打破了设计中显示的单行标题。

超过两行的标题就会破坏水平对齐方式。

ta针对如何解决此问题提供了两项建议，但它们看起来都不像你的原始设计那么好。

高度与该行中的最高标题匹配。

文本固定在顶部，按钮固定在底部。

你来回考量并选择其中一个选项。总是要妥协的，对吧？

当然，这不是我所设想的。我把所有的东西都排好了，看上去很完美，但是现在一切都搞砸了。

用相似的流程过完剩余的所有问题。该网站最终建好了，但结果却不如你的原始设计。你有些畏缩，不想把它放在你的作品集中做展示了。

那进展并不顺利。

下一步是什么？

你转到下一个项目，而没有真正去解决它。

当我向ta交付设计稿时，也许ta需要一封更具描述性的电子邮件？然后ta会知道所有的小细节。那是我下次要做的。

继续前进并不能解决问题。你其实可以做得更好。

我看过这种故事太多次了。作为一名会编程的设计师，我一直在这两个环节周旋，所以从这些经验中，我总结出很多可能会出现的问题。

真正的问题

在大多数情况下，开发都不是问题的制造者，设计师才是。我之所以这样说，是因为我作为一名设计师，在我的早期有时也遇到过以上这个问题。

好消息是，如果你了解有关Web平台的更多信息，提高自己的技能并与开发人员进行更清晰的沟通，你将获得更好的结果。

值得注意的是，以我的经验，跨职能团队可以避免许多此类问题。 设计师和开发人员同时紧密合作，可以使流程更加顺畅。在传统的乙方瀑布式流程中，这些问题似乎更经常出现。

 

正文：开发之后设计看起来更糟的7个原因

1.你没有完全掌握和理解响应式设计

你可能知道什么是响应式设计。但是，了解它的含义并牢记在心的设计并非总是会合在一起的。

Amy Schade描述了如下响应式网页设计：

响应式网页设计（RWD）是一种Web开发方法，可根据屏幕尺寸和用于查看它的设备的方向来动态更改网站的外观。RWD使用所谓的断点来确定站点布局的外观：在断点上方使用一种设计，在该断点下方使用另一种设计。这些断点通常基于浏览器的宽度。

设计响应式界面时，你至少应考虑三种尺寸：手机，平板电脑和台式机。实际上，这三种尺寸并不存在精确的像素尺寸。手机，平板电脑和台式机的尺寸都不同。Screensize.es列出了设备尺寸，并且有数百种。因此，这三个断点基本上用作隐喻。

你不能告诉我设计东西的大小吗？

你该怎么办？与其考虑设计在每个断点处的外观，不如考虑其在“断点”的位置。换句话说，调整画板的大小，当界面开始显得怪异时，你需要定义一个断点来更改该尺寸大小的设计。

随着屏幕变小，通常你需要将元素堆叠在一起。具有6个组件的水平排版将需要以比具有4个组件的行更大的屏幕宽度垂直堆叠。即使是在移动设备上，包含2个并排组件的行也可能永远不需要堆叠。

为多个断点进行设计可能意味着比现在更多的设计工作量。但是，好处是你做出的决策越符合相应标准，开发人员需要做出的猜测就越少。

 

响应式设计的Tips：

在三个屏幕断点处设计每个界面。

你选择设计的确切像素大小并不是很重要。不管是Google Pixel或iPhone，请不要担心。

考虑设计排版在被小尺寸压缩时的宽度，并设计如何修复这些压缩。

 

2. 你设计了一系列海报而不是一个系统

开发人员从事研究系统和模式的工作。他们看到了标题2的样式，并编写了一些CSS来描述标题2在整个网站上的外观。但是你已经决定了主页上的标题2应该是大写的。然而侧边栏中的标题2在其上方带有边框。这些类型的更改取决于具体界面，和你在自己内部定义但未传达的规则。

如果设计师不懂如何为Web界面进行系统性设计，那他们就是在设计海报。这是“主页”海报，这是“联系页面”海报。海报是为一种尺寸设计的，并且未与其他海报连接。

网站是一个连接的，适应性强的系统。你的设计应尽可能地模拟这一点。

我们的设计应用程序内置了许多出色的工具，可以帮助我们进行系统的设计。

最常见的一种是文字样式功能。你定义你的文本样式，并将其应用于界面中的所有文本。尽可能多地使用这些工具。当你对文本样式进行更改时，它可以使你的设计工作更快，并且可以更轻松地为开发人员移交生成模式库或设计系统。

帮助你更有系统地设计的Tips：

 

为你的网站/APP上的每段文字创建一种文字样式。是的，每一段文字。

创建一个模式库。这可以很简单，只需一个长页面，其中包含你网站上正在使用的每种元素的清单。所有文字样式，图像样式，表单元素，按钮和所有其他设计元素都应包括在内。这对于向开发人员展示你做出的系统化设计决策至关重要。

请注意，每当你根据项目的样式规则，将元素从其应该放置的位置移动几个像素时，就会创建一个新的变体，你需要将这个动作传达给开发人员。这适用于系统之外的任何其他一次性样式更改。

 

进一步阅读：

Zack Rutherford：设计系统与模式库与样式指南—有何区别？

https://www.uxpin.com/studio/blog/design-systems-vs-pattern-libraries-vs-style-guides-whats-difference/

Paul Boag：如何创建模式库，以及为什么要花时间在这里

ttps://boagworld.com/design/pattern-library/ 

 

3. 你没有设计交互元素所需的所有状态

你设计了一个按钮。也许你还设计了辅助按钮样式。但是，你是否设计了处于不同状态的每个按钮？

 

每个按钮应具有以下状态：

默认值：正常状态下的外观。提示，它应该看起来像一个按钮

焦点：用于通过键盘导航选择按钮时。没有它，用户几乎不可能通过键盘或其他定向输入设备进行导航。

禁用：按钮无法交互时。例如，如果此时无法执行该操作。

悬停：当鼠标悬停在按钮上时。

活动：当鼠标当前单击按钮时。

哇好多吧？是的，并且每次添加新的按钮样式时，都需要考虑每个状态。那仅用于按钮。所有交互元素都包含需要由某人设计的状态。可能也是你需要做的！

考虑一个选项卡式的部分。选项卡导航应具有默认，活动，悬停和焦点状态。这些状态应传达给开发人员。通常通过模式库或交互式原型来完成此操作。

 

设计和传达状态的Tips：

设计交互式元素的每种状态，以易于使用，清晰和可访问。

在页面布局的上下文之外传达元素的每个状态的设计。使用模式库来传达状态。

 

4. 你不了解Web端中元素尺寸调整的原理

如今，大多数网页在移动设备上显示都是平铺的。随着屏幕变大，设计人员需要决定页面的反应方式。最常见的规则是将网站以更大的尺寸放置在屏幕中央。如果决定这样做，则需要确定界面的最大宽度。这是唯一重要的宽度。在较小的屏幕上，你将有100％的宽度。

网格是我看到比较混乱的另一个区域。12列网格很常见，因为它们允许很好的细分（例如，你可以将2、3、4、6个组件均匀地分布在各列之间）。每列之间的空间称为槽。槽宽可以是固定的（例如20px），也可以是成比例的（2％）。在不同的屏幕尺寸下，每种浏览器的行为都大不相同。

Sketch和Figma等设计工具迫使我们选择元素的设置大小。尽管它们具有根据画布/框架宽度快速调整大小的工具，但它们不允许我们为按比例大小的元素进行真正的响应式设计。

这对你意味着什么？那么，你是否希望该400px宽的框与页面成比例缩放，或者始终保持400px宽？在小屏幕上，它的宽度可能是300px，或者可能始终是可用空间的50％，从而允许连续放置两个组件。你应该要知道这些决策的利弊权衡，并能够将这些决策传达给开发人员。

了解开发人员可用的各种大小调整单位也很有用。许多设计师并不了解这些视窗单位。

这些单位在每次浏览器调整大小时其值都会改变上，它们是真正的响应长度单位。— CSS视窗单位：快速入门

视窗单元非常适合创建全高界面。想想那些你页面较长的站点，每个部分的高度都是浏览器高度的100％。那是已经实现的视窗单元。如果你有兴趣阅读更多内容，尽管Sitepoint 是针对前端开发人员的，但Sitepoint上有一篇很好的文章帮助你理解这个概念：

https://www.sitepoint.com/css-viewport-units-quick-start/。

常用的尺寸单位是像素，ems，rems和百分比。尽管你也可以使用点，毫米，厘米等，但是这些点比常用单位的使用范围更有限。

 

在Web端界面上调整大小的Tips：

1. 对于放置在界面中的每个元素，你应该知道它是按比例大小还是固定大小。
   
2. 与开发人员沟通，随着浏览器大小的变化，每个元素应如何缩放。
   
3. 了解可用的大小调整单位，如果你希望某些元素的行为能够响应浏览器大小时，记得向开发人员指定这些大小调整单位。
   

 

5. 你缺乏词汇或知识来解释你的想法

也许你的设计是经过深思熟虑的，但是你很难与开发人员进行交流以达到预期目的。如果是这样，很可能是由于你缺乏领域词汇或知识而使你退缩。你跟开发同事的频道不同。

 

以下是所有从事Web端设计的设计师应了解的几件事：

• HTML元素名称，尤其是表单控件
  
• 无限滚动、客户端渲染、服务器端渲染、AJAX调用等技术
  
• 表单验证以及如何向用户传达错误
  
• 与你设计有关的可访问性问题
  
• 什么是服务器端和客户端渲染
  
• 基本的CMS编辑，进而你能了解最终用户将如何创建内容
  
• 各种屏幕的分辨率和像素密度
  
• 如何在网页上渲染图像（例如位图与矢量）
  

你无需成为前端开发人员才能成为出色的UI设计师。但是，这有助于获得他们的角色的同理心，就像你获得用户的同理心一样。

 

学习Web语言的Tips：
 

了解网络的术语，元素和概念。这将帮助你与开发人员进行交流，并成为一名更全面的设计师。

CSS Tricks有一篇很好的文章，涵盖了设计师应该知道的许多术语。

https://css-tricks.com/web-nerd-terminology-explained/

Smashing Magazine是学习各种技能的藏宝库，这些知识涉及Web设计和前端开发。

https://www.smashingmagazine.com/

 

6. 你没有允许可变的内容

当我描述前面开发同事的问题，没有遵循一排元素的水平对齐时，我谈到了我经常看到的一个问题。设计师不适应可变的内容。当他们看到现实世界中的设计时，这常常令他们失望。

Dribbble上漂亮的界面带有假数据，很有趣。但是，请勿将这些艺术品与依赖于数据库中真实数据的真实功能设计混淆。

 

以下是你可能会看到的一些可变内容问题：

• 文本块的长度不同，破坏了元素的水平对齐方式。
  
• 你的布局有3个元素，但实际上有4个并列元素要显示。
  
• 大多数博客文章都有封面图，但有一些没有。
  
• 列表中的某个模块元素需要显示其他列表元素不需要的数据。
  
• 你想用折叠功能截断一些文本，但是该信息太重要了以至于无法隐藏。
  
• 你没有要显示的数据，也没有任何数据可以显示。
  
• 某些不能连字又很长的单词会从其文本框中溢出。
  

那么，我们如何对设计进行压力测试，使其适应各种内容？如果要使用CMS，则需要知道界面显示的数据字段是否对其有限制，以及它们是什么类型的内容。假设你有一个标题-它的字符长度是最多的吗？如果是这样，那就太好了，在设计中使用该数量的字符。

如果对字符数没有限制怎么办？如果使用现有系统，则可以查看数据库以查看最短，最长和平均标题。

如果没有可用的数据，请设计一个非常简短的标题和一个非常长的标题。然后优化出一个平均长度。

 

处理设计中可变内容的Tips： 

1. 用可变的内容对你的设计进行压力测试。打破他们。然后设计修复破损的方法。
2. 使用实际数据来衡量你要设计的内容的数量，长度和频率。

 

7. 你没有问足够多的问题

你可能会认为你不需要向开发人员提问。毕竟，我们一般交由开发人员提出问题以获取他们所需的东西。

不要那样做，你会错失给拥有互补技能的人做出贡献的机会。你应该向开发人员询问以下几件事。

 

开始进行设计之前的问题：

1. 你可以参加交接会议或后续会议吗？
   
2. 我应该注意哪些技术限制？
   
3. 除了设计文件和规范之外，你是否还想查看我们的UX研究，用户流程或任何其他文档？
   
4. 我计划在三个断点（纵向移动设备，横向平板电脑，桌面端）上创建所有设计。这对你有用吗？
   
5. 建议的设计文档格式是否合适（例如Figma）？你可以从我的文档中提取所需的内容吗？
   
6. 矢量图的SVG和2倍的JPEG / PNG是否适合现有的风格源码库？
   
7. Google文档中提供的文案适合你使用吗？
   
8. 你喜欢带注释的设计，还是带有微交互和动画的原型？
   
9. 开始工作后，我们应如何应对和处理中途出现的影响设计的新见解？
   
10. 你喜欢如何交流？Slack、电子邮件、Figma中的评论功能、电话？
    

 

在设计阶段的问题：

1. 你在设计稿上是否看到任何潜在的问题，或者有改进的机会？
   
2. 我是否提出了可能会使网站速度下降的建议？
   
3. 从你的角度来看，我是否提出了超出项目范围的建议？
   
4. 你对任何界面的用途感到困惑吗？（进行可用性测试的机会！）
   

 

项目完成后的问题：

1. 对于下一个项目，我们有什么可以改进的吗？
   
2. 我们应该尝试更好的沟通或协作工具吗？
   

 

进一步阅读

以下是一些不错的英文文章，它们描述了理想的开发人员移交流程：

Abstract公司如何为设计师提供的开发人员交接

https://www.abstract.com/blog/developer-handoff-for-designers/

Katica Babarczi的设计移交指南

https://uxstudioteam.com/ux-blog/design-handoff/

 

解决设计交付问题将促进与开发人员的协作更快，更有意义，并为项目带来更好的结果。归根结底，设计师可以了解更多有关Web平台的知识，从而提高他们的设计技术水平，并与开发人员进行更清晰的沟通。

 

 

译文地址：应谋鬼计（公众号）

作者：Jed Lehmann

译者：大鱼海棠Rena