微交互:它们如何帮助实现流畅的 UI 体验。
#1. 考虑界面上的每种可能的场景和用户交互
作为设计师,我们通常倾向于采用“默认”用户流程,至少在项目的开始阶段是这样。默认流程考虑了大多数执行该任务的用户在“典型”场景中会遇到的体验,所有参数和响应都符合预期。
但这并不是现实世界中发生的情况。
在现实世界:
- 加载时间不为零(因此加载屏幕和动画)
- 错误:用户在文本字段中输入错误的内容(因此需要上下文相关的错误消息)
- 放弃:有时用户倾向于中途放弃某个操作并希望尽快返回首页(因此每一步都需要一个退出路径)
- 丢失数据:有时,特定的指标/信息可能不适用于实体或特定上下文,这会改变相关 UI 元素(例如卡片)的外观,甚至可能改变某些其他元素的位置。
考虑尽可能多的边缘情况、错误、交互场景(及其组合)是一个很好的策略,可以确保所有情况下的用户体验都是相关的、可预测的和一致的。也许我会称之为 RPC 框架。
#2. 始终保留以前的设计迭代 - 您永远不知道什么时候需要它们!
Figma 允许您访问该文件的先前版本,但最好不要删除过去的迭代。您永远不知道客户或内部利益相关者何时想要返回到以前的版本来检查某些小元素或行为。此外,以前的设计可以帮助您评估与初稿的差距以及这些决定背后的理由。
一个页面上有很多废弃的设计可能会令人困惑 - 特别是如果您使用的是免费帐户且仅限 3 个页面。如果您有权访问 Figma 中的团队帐户,事情会变得更容易,因为通过团队帐户,您可以根据需要创建任意数量的页面,因此您可以拥有用于垃圾、线框、设计系统等的专用页面。
#3。并非您将从事的所有项目都会成为投资组合级别的案例研究。没关系。
并非每个项目都会涉及从头开始的端到端设计。无论您是否只需要在应用程序的特定部分中设计特定页面(例如支付失败屏幕),都会有一些任务。没关系。
大项目需要时间,通常是几个月,从长远来看,如何解决这些小问题和细节非常重要。
这也意味着您需要能够轻松地使用其他设计师的现有设计。这反过来意味着团队中的所有设计师都应该理想地使用标准化的组织、文档和通信系统。这就是ODC框架。
#4。在面向客户、以服务为基础的公司中,客户与用户一样重要(如果不是更重要的话)。
这主要与在服务型公司工作的设计师相关。您可能会研究多个参考资料,并最终提出一个在功能和视觉上都比以前版本更好的设计,但客户只是更喜欢某种方式的设计和流程。这种情况比看起来更常见。
你的工作是提供选择和观点;并尝试说服客户做对用户有利的事情。这就是它停止的地方。重要的是不要执着于你的设计——最终决定权在客户手中。支付你账单的是客户。对此保持冷静。加快流程的提示:在从头开始自己的设计之前,询问客户是否有任何参考或想法。
当然,如果您正在做自己的事情(这是您能做的最好的事情),那么这些限制就不会发挥作用。
#5。从一开始就保存您的样式、组件和变量。
一旦您开始一个项目并经过空白画布/线框阶段,就开始使用适当的名称保存所有视觉样式(颜色、效果、文本样式、布局、边框等)。提示:不要以上下文特定的方式命名组件,例如购买购物车选项卡。该名称通常应与用途无关。
这有助于您以后节省宝贵的时间,因为在您意识到之前,“一些初稿”可能会变成 10 个流程和 100 个屏幕。良好的产品设计不可或缺的一件事就是一致性。在项目生命周期的早期利用自动布局、嵌套组件和变体的强大功能来确保一致性。
#6。始终做好(设计师间)交接的准备。就好像今天是你的最后一天一样工作。
每个人都讨厌交接。我从来没有因为接手其他设计师的项目而感到兴奋过。但它们是设计团队中不可避免的祸害。停产和重新分配不仅仅是设计问题——它几乎无处不在。
作为一名设计师,您无法控制其他设计师的工作(除非您的团队还没有在设计文档和组织上设置一些标准操作程序)。但你可以采取某种方式做事,这样别人在你交接项目时就不会咒骂你。
这意味着在设计文件中以结构化方式组织资产,正确编码和命名它们,使用部分来区分流程,坚如磐石。想想当您收到其他人的项目文件时您讨厌的一切,并消除所有这些痛点。
#7. 不要忘记添加开发人员注释。
产品设计师,或者任何参与构建产品的人,不能(也不应该)在孤岛中工作。我们必须让开发人员更容易理解产品的外观和行为方式,以便将愿景转化为现实,而不会损失任何保真度。
您可能认为您设计的界面或流程已经尽可能直观了。但你已经研究这些设计很长一段时间了——这会让你的判断产生偏见。独立的眼睛可能根本不觉得它们是直观的。
论您完成的原型设计水平如何,在模型屏幕旁边添加相关注释都有助于让开发人员了解预期内容。
#8 响应式设计不是事后的想法
如果您正在为网站设计桌面屏幕,请立即考虑响应式版本。至少对如何去做有一个基本的想法。要领先一步,请利用移动优先的设计理念。
这将帮助您提出可以(相对)轻松地适应较小视口的设计,例如平板电脑或移动设备上的视口。
我见过许多设计师首先设计多个流程的桌面版本,然后最后将这些设计强制安装到移动框架中。这不是最佳选择,而且还有可能导致两个版本之间出现更大的不一致。您可能还需要在最后一刻进行大量更改。
更好的方法是同时设计它们,以便尽早识别和适应任何约束。