移动端聊天界面表情 编码_界面设计在编码时看起来更糟的7个原因以及为什么这可能是您的错...

移动端聊天界面表情 编码

重点 (Top highlight)

You spend weeks hearing about the Exciting New Website Project on the horizon. The project gets underway. UX research is done. A copywriter crafts perfect copy. Great photography is sourced. The team works on messaging, brand elements and project requirements.

Ÿ欧花费数周时间在地平线上听到令人振奋新网站项目 。 该项目正在进行中。 用户体验研究已经完成。 撰稿人精心制作完美的副本。 伟大的摄影源。 该团队致力于消息传递,品牌元素和项目需求。

Then it comes to interface design. The part you love. Where you get to use your design skills to craft perfect designs.

然后是界面设计。 您喜欢的部分。 在哪里可以利用您的设计技能来制作出完美的设计。

This is going to be incredible! The world will sing my praises!

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

闪耀的时候来了! (Time to shine!)

You sketch the interfaces then flesh them out in Figma. You work with stakeholders to address concerns. You run usability studies and iterate on the designs until you have confidence in them.

您可以绘制接口草图,然后在Figma中对其进行充实。 您与利益相关者一起解决问题。 您进行可用性研究并迭代设计,直到对它们有信心为止。

At some point, the design is approved. Awesome!

在某个时候,设计被批准。 真棒

Image for post
Well done, Designer, it’s been approved. When can we launch?!
做得好,设计师,它已经被批准。 我们什么时候可以发射?

I am definitely putting this in my portfolio!

我肯定会将它放入我的投资组合中!

交出 (Handover)

Now for the part you hate. Handing your finely tuned designs to the front end developer on the project. Let’s call her Olivia (not a real person).

现在,您讨厌的部分。 将经过微调的设计移交给该项目的前端开发人员。 我们称她为Olivia(不是真实的人)。

Uggghhh, this is where it always goes downhill…

哎呀,这总是下坡路……

Image for post
Take it, no you take it!
接受,不接受!

You email Olivia your designs. You’ve learnt from previous experiences that you should specify the font sizes and spacing. Maybe she can even extract some CSS from your Figma or Sketch prototypes.

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

Over to her now! She’ll get back to me if she has any questions.

现在交给她! 如有任何疑问,她会尽快与我联系。

You wait patiently for the designs to come back as a functioning website.

您需要耐心等待设计返回正常运行的网站。

坚持一分钟 (Hold on a minute)

A few days later, Olivia sends you a link to the staging site. Your heart sinks. There are several issues you spot in the first 10 seconds of looking at it. And a bunch more when you look closer.

几天后,Olivia向您发送了指向登台站点的链接。 你的心沉没了。 在查看它的前10秒,您会发现几个问题。 当您靠近时,还有更多。

Image for post
A broken egg is not an omelette.
破蛋不是煎蛋。

For some reason, Olivia has missed the mark. She made weird decisions about the tablet layout. The baseline grid isn’t working. The full-width images aren’t cropped properly. The cards don’t align horizontally. There aren’t any hover states. I could go on, but you get the idea.

由于某些原因,Olivia错过了分数。 她对平板电脑的布局做出了奇怪的决定。 基线网格不起作用。 全角图像无法正确裁剪。 卡不水平对齐。 没有任何悬停状态。 我可以继续,但是你明白了。

Why does this always happen? There’s so many things wrong with it — it’s obvious!

为什么总是这样? 它有很多问题,这很明显!

You get slightly annoyed. Why does this always happen? Time to draft a long bullet-list email of changes. This email is clear and reasoned. You ask for specific changes and expect this one round of feedback is enough to address all the issues.

你有点生气。 为什么总是这样? 是时候起草长长的更改电子邮件列表了。 这封电子邮件清晰明了。 您要求进行特定的更改,并期望这一轮反馈足以解决所有问题。

You hit send on the email and relax a little. At least it’s off your plate for a while.

您点击发送电子邮件,然后放松一点。 至少有一段时间了。

Image for post
Hey Olivia, thanks for sending the link to the staging URL. It’s not quite what I was expecting…
嗨,奥利维亚,感谢您发送指向登台URL的链接。 这不是我所期望的...

你不能修复它吗? (Can’t you just fix it?)

Olivia reads your version of War and Peace. She responds with follow-up questions to get clarification and provide the reasoning behind her decisions.

奥利维亚(Olivia)阅读您的《战争与和平》版本。 她回答了后续问题,以进行澄清并提供其决策依据。

She explains why the cards don’t align horizontally. The titles can be anywhere from 6 characters to 143. This means that a title can be anywhere from 1–3 lines long, breaking the one-line titles shown in your design.

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

Image for post
Titles that span two lines break the horizontal alignment.
跨越两行的标题会破坏水平对齐方式。

Olivia gives two suggestions for how to address the issue, but neither look as good as your original design.

Olivia针对如何解决此问题提供了两项建议,但它们看起来都不如您的原始设计。

Image for post
The height matches the tallest title in the row.
高度与该行中的最高标题匹配。
Image for post
The text is anchored at the top, and the button anchored at the bottom.
文本锚定在顶部,按钮锚定在底部。

You go back and forth and settle on one of the options. It’s always a compromise, right?

您来回移动并选择其中一个选项。 总是妥协吧?

It’s not how I envisioned it, that’s for sure. I had it all lined up and looking perfect, but now everything’s kind of messed up.

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

Rinse and repeat for all the remaining issues. The site gets built in the end, but the result doesn’t look as good as your original design. You cringe at some parts of it and don’t want to show it in your portfolio.

冲洗并重复所有剩余的问题。 该网站最终建好了,但结果却不如您的原始设计好。 您畏缩了它的某些部分,不想在投资组合中展示它。

Image for post

那进展并不顺利。 下一步是什么? (That didn’t go so well. What’s next?)

You move onto the next project without addressing it.

您转到下一个项目,而无需解决它。

Maybe Olivia needed a more descriptive email when I sent her the designs? Then she’d know about all the little details. That’s what I’ll do next time.

当我向她发送设计时,也许Olivia需要一封更具描述性的电子邮件吗? 然后她会知道所有的小细节。 那是我下次要做的。

Moving on is not addressing the issues. You can make this better.

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

I’ve seen this story play out many times. I’ve been on both sides of the fence as a designer who codes, so I know from experience where the issues can arise.

我看过这个故事很多次了。 作为编码的设计师,我一直在篱笆的两侧,所以我从经验中知道可能会出现问题。

真正的问题 (The real problem)

In most cases like these, Olivia isn’t a problem. The designer is. And I say this as a designer who may have been that problem at times in my early days.

在大多数情况下,Olivia都不是问题。 设计师是。 我说的是作为一名设计师,在我早期的时候有时可能会遇到这个问题。

The good news is you can get a much better result if you learn more about the web platform, improve your craft and more clearly communicate with the developer.

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

It’s worth noting that, in my experience, cross-functional teams avoid many of these issues. Designers and devs working closely together at the same time makes for a smoother process. These issues seem to pop up more often in traditional agency waterfall processes.

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

编码后界面设计看起来更糟的7个原因 (7 reasons your interface designs look worse when they’re coded)

1.您没有完全接受响应能力 (1. You didn’t fully embrace responsiveness)

You probably know what responsive design is. But knowing what it is and designing with it in mind don’t always go together.

您可能知道什么是响应式设计。 但是知道它是什么并牢记在心的设计并不总是可以并存的。

Amy Schade describes responsive web design like this:

艾米·谢德 ( Amy Schade)描述了如下响应式网页设计

Responsive web design (RWD) is a web development approach that creates dynamic changes to the appearance of a website, depending on the screen size and orientation of the device being used to view it. RWD uses so-called breakpoints to determine how the layout of a site will appear: one design is used above a breakpoint and another design is applied below that breakpoint. The breakpoints are commonly based on the width of the browser.

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

When designing a responsive interface, you should consider at least three sizes: mobile, tablet and desktop. In reality, those three sizes don’t exist as exact pixel dimensions. Phones, tablets and desktops are all different sizes. Screensize.es lists devices sizes, and there are hundreds of them. So those three breakpoints are essentially used as a metaphor.

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

Can’t you just tell me what size to design things at?

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

So what should you do? Rather than think about what a design looks like at each breakpoint, you should think about at what point it “breaks”. Put another way, resize your artboard, and when it starts to look crappy or weird, you need a breakpoint to change the design at that size.

那你该怎么办? 您不必考虑设计在每个断点处的外观,而应该考虑它在“断点”处的位置。 换句话说,调整画板的大小,当画板开始显得cr脚或怪异时,您需要一个断点来更改该大小的设计。

As a screen gets smaller, generally you need to stack elements on top of one another. A horizontal row with 6 items will need to stack vertically at a larger screen width than a row with 4 items. A row with 2 items might not ever need to stack, even on mobile.

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

Designing for several breakpoints might mean more design work than you are doing now. But the tradeoff is the more responsive decisions you make, the fewer guesses the developer needs to make.

为多个断点进行设计可能意味着比现在更多的设计工作。 但是,权衡是您做出的决策越敏感,开发人员就需要做出的猜测就越少。

Tips for designing responsively:

响应式设计的提示:

  1. Design each interface at three breakpoints.

    在三个断点处设计每个接口。
  2. The exact pixel sizes you choose to design at aren’t really important. Don’t stress if it’s a Google Pixel or an iPhone.

    您选择设计的确切像素大小并不是很重要。 如果是Google Pixel或iPhone,请不要担心。
  3. Consider the widths where the design breaks, and design how to fix those breakages.

    考虑设计破裂处的宽度,并设计如何修复这些破裂处。

2.您设计了一系列海报而不是系统 (2. You designed a series of posters instead of a system)

Developers work in systems and patterns. They see a heading 2 style and write some CSS that describes how a heading 2 should look across the site. But you’ve decided that the heading 2 on the home page is in uppercase. And the heading 2 in the sidebar has a border above it. These kinds of changes rely on context, and rules that you’ve defined internally, but probably haven’t communicated.

开发人员从事系统和模式的工作。 他们看到了标题2的样式,并编写了一些CSS来描述标题2在整个网站上的外观。 但是您已经确定主页上的标题2为大写。 侧边栏中的标题2在其上方具有边框。 这些类型的更改取决于上下文和您在内部定义但未传达的规则。

Designers who aren’t designing systematically for the web are essentially designing posters. Here’s a “home page” poster, and here’s a “contact page” poster. A poster is designed for one size, and isn’t connected to other posters.

并非为网络进行系统设计的设计师实际上就是在设计海报。 这是“主页”海报,这是“联系页面”海报。 海报是为一种尺寸设计的,并且未与其他海报连接。

A website is a connected, adaptable system. Your designs should simulate this as closely as possible.

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

There are great tools built into our design apps for designing systematically. The most common one is text styles. You define your text styles and apply them to all the text in your interfaces. Use these tools as much as you can. It makes your design work faster as you make changes, and makes it easier to generate a pattern library or design system for developer handoff.

我们的设计应用程序内置了许多出色的工具,可以进行系统的设计。 最常见的一种是文字样式。 您可以定义文本样式,并将其应用于界面中的所有文本。 尽可能多地使用这些工具。 当您进行更改时,它可以使设计工作更快,并且可以更轻松地生成用于开发人员移交的模式库或设计系统。

Tips for designing more systematically:

更系统地设计的提示:

  1. Create a text style for every piece of text on your site/app. Yes, every piece of text.

    为您的网站/应用上的每段文字创建一种文字样式。 是的,每一段文字。
  2. Create a pattern library. This can be as simple as one long page that includes a shopping list of every type of element in use on your site. All text styles, image styles, form elements, buttons and all other design elements should be included. This is critical for showing the developer the systematic design decisions you made.

    创建一个模式库。 这可以很简单,只需一个长页面,其中包含您网站上正在使用的每种元素的购物清单。 所有文字样式,图像样式,表单元素,按钮和所有其他设计元素都应包括在内。 这对于向开发人员展示您做出的系统设计决策至关重要。
  3. Be aware that each time you nudge an item a few pixels from where it should sit according to its styling rules, you are creating a new variation that needs to be communicated to the developer. This applies to any other one-off styling changes that fall outside the system.

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

Further reading:

进一步阅读:

3.您没有设计交互元素所需的所有状态 (3. You didn’t design all the states needed for interactive elements)

You designed a button. Maybe you also designed a secondary button style. But did you design each of those buttons in their various states?

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

A button should have the following states:

按钮应具有以下状态:

  1. Default: what it looks like in its normal state. Hint, it should look like a button 😁

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

  2. Focus: For when the button is selected via keyboard navigation. Without it, navigation via keyboards or other directional input devices is almost impossible.

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

  3. Disabled: When the button cannot be interacted with. For example, if the action cannot be taken at this time.

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

  4. Hover: When the mouse is hovering over the button.

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

  5. Active: When the mouse is currently clicking on the button.

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

Wow, that’s a lot, right? Yep, and each time you add a new button style, you need to account for each of those states. And that’s only for buttons. All interactive elements contain states which need to be designed by someone. Might as well be you!

哇,很多,对吧? 是的,每次添加新的按钮样式时,都需要考虑每个状态。 那仅用于按钮。 所有交互元素都包含需要由某人设计的状态。 可能也是您!

Think of a tabbed section. The tab navigation should have default, active, hover and focus states. These states should be communicated to the developer. This is generally done via the pattern library or an interactive prototype.

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

Tips for designing and communicating states:

设计和传达状态的提示:

  1. Design each state of your interactive elements for ease of use, clarity and accessibility.

    设计交互式元素的每种状态,以易于使用,清晰和可访问。
  2. Communicate the design of each state of an element outside the context of your page layouts. Use a pattern library to communicate the states.

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

4.您不了解网络大小调整的原理 (4. You don’t understand how sizing on the web works)

Most web pages these days are full width on mobile. As the screen gets larger, the designer makes decisions about how the page will react. The most common convention is to place the website in the centre of the screen at larger sizes. If you decide to do this, you need to determine the maximum width of the interface. This is the only width that matters. On smaller screens, you get the 100% width.

如今,大多数网页在移动设备上全宽。 随着屏幕变大,设计人员将决定页面的React方式。 最常见的约定是将网站以更大的尺寸放置在屏幕中央。 如果决定这样做,则需要确定接口的最大宽度。 这是唯一重要的宽度。 在较小的屏幕上,您将获得100%的宽度。

A grid is another area where I have seen confusion. 12 column grids are common because they allow for good subdivisions (e.g. you can have 2, 3, 4, 6 items spread evenly across columns). The space between each column is called the gutter. The gutter can be fixed (e.g. 20px), or proportional (2%). Each will behave quite differently at different screen sizes.

网格是我看到混乱的另一个区域。 12列网格是常见的,因为它们允许很好的细分(例如,您可以将2、3、4、6个项目均匀地分布在各列中)。 每列之间的空间称为装订线。 装订线可以是固定的(例如20px),也可以是成比例的(2%)。 在不同的屏幕尺寸下,每种显示器的行为都大不相同。

Design tools such as Sketch and Figma force us to choose set sizes for elements. They don’t allow us to truly design responsively for proportionally-sized elements, despite them having tools for quick resizing based on the canvas/frame width.

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

What does this mean for you? Well, do you want that 400px wide box to scale proportionally with the page, or remain at 400px wide at all times? Maybe it’s 300px wide on small screens, or maybe it’s always 50% of the available space, allowing for two items across a row. You should know the tradeoffs of these decisions, and be able to communicate these decisions to the developer.

这对您意味着什么? 那么,您是否希望该400px宽的框与页面成比例缩放,或者始终保持400px宽? 在小屏幕上,宽度可能为300像素,或者始终是可用空间的50%,从而允许连续放置两个项目。 您应该知道这些决策的权衡,并能够将这些决策传达给开发人员。

It’s also useful to understand the various sizing units available to developers. Many designers aren’t aware of viewport units.

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

They are truly responsive length units in the sense that their value changes every time the browser resizes. — CSS Viewport Units: A Quick Start

它们是真正的响应长度单位,从某种意义上说,每次浏览器调整大小时,它们的值都会改变。 — CSS视口单位:快速入门

Viewport units are great for creating full-height sections. Think of those sites where you have a long page, and each section is 100% the height of the browser. That’s viewport units at work. Sitepoint has a good article on viewport units if you’re interested in reading more, although it’s aimed at front-end developers.

视口单元非常适合创建全高剖面。 想想那些您的页面很长的站点,每个部分的高度都是浏览器高度的100%。 那是工作中的视口单元。 如果您有兴趣阅读更多内容,尽管Sitepoint是针对前端开发人员的,但Sitepoint上有一篇不错的文章

Commonly-used sizing units are pixels, ems, rems, and percentages. However, you can also use points, mm, cm and others, but these have more limited use than the commonly used units.

常用的尺寸单位是像素,ems,rems和百分比。 但是,您也可以使用点,毫米,厘米和其他点,但是这些点比常用单位的使用范围更有限。

Tips for sizing on the web:

在网络上调整大小的提示:

  1. For each element you place in the interface, you should know whether it’s a proportionally sized or fixed size.

    对于放置在界面中的每个元素,您应该知道它是按比例大小还是固定大小。
  2. Communicate to the developer how each element should scale as the browser size changes.

    与开发人员沟通,随着浏览器大小的变化,每个元素应如何缩放。
  3. Learn what sizing units are available, and specify those units to the developer when you’re expecting the behaviour to respond to the browser size.

    了解可用的大小调整单位,并在期望行为能够响应浏览器大小时向开发人员指定这些大小调整单位。

5.您缺乏词汇或知识来解释您的想法 (5. You lack the vocabulary or knowledge to explain your ideas)

Perhaps your designs are well-considered, but you struggle to communicate to the developer how something is intended to work. If this is the case, it’s most likely your lack of domain vocabulary or knowledge holding you back. You aren’t on the same wavelength as the developer.

也许您的设计是经过深思熟虑的,但是您很难与开发人员沟通某些事情是如何工作的。 如果是这种情况,很可能是由于您缺乏领域词汇或知识而使您退缩。 您与显影剂的波长不同。

Here are a few things all designers working on the web should have an understanding of:

以下是所有从事网络工作的设计师应了解的几件事:

  • HTML element names, especially form controls

    HTML元素名称,尤其是表单控件
  • Techniques such as infinite scrolling, client-side rendering, server-side rendering, AJAX calls

    无限滚动,客户端渲染,服务器端渲染,AJAX调用等技术
  • Form validation and how to communicate errors to users

    表单验证以及如何向用户传达错误
  • Accessibility concerns as they relate to your designs

    与您的设计相关的可访问性问题
  • What server-side and client-side rendering is

    什么是服务器端和客户端渲染
  • Basic CMS editing, so you understand how the end-users will be creating content

    基本的CMS编辑,因此您了解最终用户将如何创建内容
  • Resolution and pixel density for various screens

    各种屏幕的分辨率和像素密度
  • How images are rendered on the web (e.g. bitmap vs vector)

    如何在网络上渲染图像(例如位图与矢量)

You don’t need to become a front-end developer to be a good interface designer. But it helps to gain empathy for their role just like you gain empathy for your users.

您无需成为前端开发人员即可成为出色的界面设计师。 但这有助于获得他们的角色的同理心,就像您获得用户的同理心一样。

Tips for learning the language of the web:

学习网络语言的提示:

  1. Learn the terminology, elements and concepts of the web. This will help you communicate with developers and be a more well-rounded designer.

    了解网络的术语,元素和概念。 这将帮助您与开发人员进行交流,并成为一名更全面的设计师。
  2. CSS Tricks has a good article that covers many terms that a designer should know.

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

  3. Smashing Magazine is a treasure-trove for all skill levels learning about web design and front-end development.

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

6.您不允许内容可变 (6. You didn’t allow for variable content)

When I described the issue of Olivia not nailing the horizontal alignment of a row of blocks, I touched on an issue I see regularly. Designers not catering for variable content. This creates disappointment when they see the design in a real-world situation.

当我描述Olivia的问题没有钉住一排积木的水平对齐时,我谈到了我经常看到的一个问题。 设计师不适应可变的内容。 当他们看到现实世界中的设计时,这会令人失望。

The beautiful dashboards on Dribbble with fake data are fun to look at. But don’t confuse these artworks with real, functional designs that rely on real data from a database.

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

Here’s some variable-content issues you may see:

您可能会看到一些可变内容问题:

  • Text blocks vary in length, breaking the horizontal alignment of elements.

    文本块的长度不同,破坏了元素的水平对齐方式。
  • Your layout has three items, but there’s four items to display.

    您的布局有3个项目,但有4个项目要显示。
  • Most blog posts have a featured image, but there are a few that don’t.

    大多数博客文章都有特色图片,但有一些没有。
  • An item in a list needs to display a piece of data which other list items don’t.

    列表中的项目需要显示其他列表项目不需要的数据。
  • You want to truncate some text with an ellipse, but the information is too important to hide.

    您想用椭圆形截断一些文本,但是该信息太重要了以至于无法隐藏。
  • You have no, or limited, data to show.

    您没有数据或要显示的数据有限。
  • A very long word which doesn’t hyphenate breaks out of its container.

    不会连字的很长的单词会从其容器中弹出。

So how do we pressure-test our designs so they adapt to variable content? If you’re dealing with a CMS, you need to know if the fields of data your interface displays have restrictions on them, and what type of content they are. Let’s say you have a title — does it have a maximum number of characters? If so, great, use that number of characters in your design.

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

What if there are no restrictions on the number of characters? If you’re dealing with an existing system, you can look into the database to see the shortest, longest and average titles.

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

If you don’t have that data available, design for a very short title and a very long title. Then optimize for an average length one.

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

Tips for dealing with variable content in your designs:

在设计中处理可变内容的提示:

  1. Pressure test your designs with variable content. Break them. Then design ways to fix the breakages.

    用可变的内容对您的设计进行压力测试。 打破他们。 然后设计修复破损的方法。
  2. Use real data to measure the number, length and frequency of content you are designing for.

    使用实际数据来衡量您要设计的内容的数量,长度和频率。

7.你没有问足够多的问题 (7. You didn’t ask enough questions)

You might think you don’t need to ask questions to the developer. After all, it’s up to the developer to ask their questions to get what they need.

您可能认为您不需要向开发人员提问。 毕竟,由开发人员提出问题以获取所需的东西。

Don’t do that. You’re missing out on the opportunity for a person with a complementary skill set to contribute. Here’s a few things you should be asking a developer.

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

Questions for before you start working on the design:

开始设计之前的问题:

  1. Will you be available for a handover meeting and perhaps a follow-up?

    您可以参加交接会议或后续会议吗?
  2. Are there any technical limitations I should be aware of?

    我应该注意哪些技术限制?
  3. Do you want to see our UX research, user flows or any other documentation aside from the design files and spec?

    除了设计文件和规范之外,您是否还想查看我们的用户体验研究,用户流程或任何其他文档?
  4. I plan on creating all designs at three breakpoints (portrait mobile, landscape tablet, desktop). Does this work for you?

    我计划在三个断点(纵向移动设备,横向平板电脑,台式机)上创建所有设计。 这对您有用吗?
  5. Is the suggested format suitable (e.g. Figma)? Can you extract what you need from my files?

    建议的格式是否合适(例如Figma)? 您可以从我的文件中提取所需的内容吗?
  6. Are SVG for vector, and JPEG/PNG at 2X suitable for assets?

    向量的SVG和2倍的JPEG / PNG是否适合资产?
  7. Is copy supplied in Google Docs suitable for you?

    Google文档中提供的副本适合您吗?
  8. Do you prefer annotated designs or prototypes for micro-interactions and animations?

    您喜欢微交互和动画的带注释的设计或原型吗?
  9. How should we address new insights that affect design once you’ve started work?

    开始工作后,我们应如何应对影响设计的新见解?
  10. How do you prefer to communicate? Slack, email, commenting system in Figma, phone?

    您喜欢如何交流? 松弛,电子邮件,Figma中的评论系统,电话?

Questions for during the design stage:

在设计阶段的问题:

  1. Are there any potential issues you see with the design, or opportunities for improvement?

    您在设计中是否看到任何潜在的问题,或者有改进的机会?
  2. Have I proposed anything that might slow the site down?

    我是否提出了任何可能会使网站速度下降的建议?
  3. Have I proposed anything that falls outside the scope of the project from your perspective?

    从您的角度来看,我是否提出了超出项目范围的建议?
  4. Are you confused about the purpose of any of the interfaces? (a chance for usability testing!)

    您是否对任何接口的目的感到困惑? (进行可用性测试的机会!)

Questions upon completion of the project:

项目完成后的问题:

  1. Is there anything we can improve for the next project?

    对于下一个项目,我们有什么可以改进的吗?
  2. Are there better tools for communication or collaboration we should try?

    我们应该尝试更好的沟通或协作工具吗?

Further reading

进一步阅读

Here are a couple of good articles that describe an ideal developer handoff:

以下是一些不错的文章,它们描述了理想的开发人员移交:

  1. Developer handoff for designers from Abstract.

    从Abstract 为设计师提供的开发人员交接

  2. Design handoff guide by Katica Babarczi

    Katica Babarczi的设计移交指南

Fixing handoff issues will result in faster and more rewarding collaboration with developers and result in a better outcome for the project. It boils down to the designer learning more about the web platform, improving their craft and more clearly communicating with the developer.

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

翻译自: https://uxdesign.cc/7-reasons-your-interface-designs-look-worse-when-theyre-coded-and-why-it-s-probably-your-fault-42bcf27e034c

移动端聊天界面表情 编码

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值