写点什么

表单设计: 一页只做一件事(三)

  • 2019-12-30
  • 本文字数:1315 字

    阅读完需:约 4 分钟

表单设计:一页只做一件事(三)
  1. 解决了性能问题


如果每件事都复杂无比——单页应用就是一个极端例子——性能问题就很难解决。是因为执行时间问题?内存泄漏?还是 AJAX 请求导致的?


人们很容易认为 AJAX 能提升用户体验,但增加代码量很少情况能创造更快的体验。


复杂性转移到客户端,会掩盖服务端的根本问题。但如果页面只做一件事情,性能问题就不容易产生。如果真发生了问题,排查原因也很容易。


  1. 它有一种在前进的感觉


因为用户在不停地前往下一步,会产生一种正在前进的感觉,在用户填写表单时给他们一种积极的感受。


  1. 降低丢失信息的风险


长表单需要更长时间来完成。如果所花时间太长,页面超时可能导致信息丢失,产生严重的挫败感。


又或者,电脑可能卡死,*《我是布莱克》*里的主角 Daniel 就是这样的例子。他的健康每况愈下,而且第一次用电脑就遇到了死机,然后数据丢失。最终他放弃了。


  1. 第二次使用的体验更顺畅


比如,假设我们储存了用户的支付信息,我们可以直接跳过那一页,直接带他们去“结账确认”页面。这会减少阻碍,提升转化率。


  1. 这是移动优先设计的一种补充


移动优先的设计,提倡在小屏幕上只呈现最重要的信息。一页只做一件事,也遵循着相同的方式。


  1. 设计过程很简单


当我们设计一套复杂流程时,分解成细小页面和组件,可以让人更容易理解这些问题。


还可以方便地调换页面来改变顺序。我们一次只研究一件事,这点和用户一样,能让我们更轻松地分析问题。


这可以减轻设计负担——这种模式让用户受益的同时,还能有这样的附加福利。


这种模式适合所有情况吗?


也不完全是。Caroline Jarrett 在 2015 年写过一篇文章《一页只做一件事》,里面讲得很清楚。她解释道,用户调研“会告诉你某些问题组合起来放在长页面里更合适”。


但是反过来,她也提到了“对于设计师来说‘属于一组’的问题……对于用户而言,并不一定要放在一个页面上”。


她提出了一个颇具启发性的例子,GOV.UK 的验证页面中,他们尝试把“创建用户名”和“创建密码”先后放在两个页面上。


就像许多设计师所认为的,Caroline 觉得把这两者放在不同页面有点太过了。实际上,用户对此一点也不介意。


关键在于,以一页只做一件事为出发点,然后通过用户研究,验证把其中一些项目编组合并,是否能进一步改善用户体验。


这并不代表最终结果一定是把页面合并——在我经验中,最好的结果往往是把事情拆分开来,仅此而已。当然,我也希望听听你的经验。


总结


这种低调不起眼的用户体验设计模式很灵活、高性能、有包容性。这是真正拥抱互联网的方式,对于自信满满和小心翼翼的用户而言都很简单。


一个页面上展现很多(或者全部)内容可能会营造一种简单的幻象,但就像代数式问题一样,除非把它们分解,否则很难处理。


如果把任务看作是用户想要完成的一笔交易,把它分解为多个小步骤很有必要。这就像我们在用网页的一砖一瓦来搭建渐进式表单。每一页背后的隐喻,都给潜意识营造一种正在前进的感觉。


我还没有遇到过哪种其他的设计模式,能具备这么多的优点。这就是那种真理时刻——答案总是最简单的。


作者信息:Adam Silver


原文链接:https://www.smashingmagazine.com/2017/05/better-form-design-one-thing-per-page/


本文转载自 Think 体验设计公众号。


原文链接:https://mp.weixin.qq.com/s/7yIAqH7nFhPHMtfmi_VeaQ


2019-12-30 18:02656

评论

发布
暂无评论
发现更多内容

国产主流数据库调研

TiDB 社区干货传送门

性能调优 实践案例

把云数据库服务变成黑盒子:ServerlessDB for HTAP丨Hacking Camp 进行时

TiDB 社区干货传送门

实践案例

一次 meet_lock 告警异常处理过程

TiDB 社区干货传送门

实践案例 故障排查/诊断

伴鱼数据库之监控系统

TiDB 社区干货传送门

TiDB GC 之原理浅析

TiDB 社区干货传送门

TiDB 底层架构

TiDB 赋权问题

TiDB 社区干货传送门

故障排查/诊断

TiDB Coprocessor 学习笔记

TiDB 社区干货传送门

TiDB 底层架构

TiDB HTAP 深度解读

TiDB 社区干货传送门

从使用者到开发者,知乎参与 TiDB 社区背后的故事

TiDB 社区干货传送门

实践案例 数据库架构选型

PD api基础框架源码分析

TiDB 社区干货传送门

TiDB 底层架构

PD api基础框架源码分析

TiDB 社区干货传送门

TiDB 底层架构

DM问题处理总结

TiDB 社区干货传送门

【TiDB 最佳实践系列】PD 调度策略最佳实践

TiDB 社区干货传送门

实践案例

线上mysql改表操作导致tidb同步延迟解决方法

TiDB 社区干货传送门

Tidb灾难恢复演练-多副本丢失

TiDB 社区干货传送门

故障排查/诊断

PD 关于tso 分配源代码分析

TiDB 社区干货传送门

TiDB 底层架构

pd集群多副本数据丢失以及修复实践

TiDB 社区干货传送门

实践案例

TiDB run and debug on M1

TiDB 社区干货传送门

实践案例 安装 & 部署

TiDB大规模删除实践

TiDB 社区干货传送门

管理与运维

Flink 最佳实践之 通过 TiCDC 将 TiDB 数据流入 Flink

TiDB 社区干货传送门

性能调优

TiDB 记录日志原理解读

TiDB 社区干货传送门

TiDB 底层架构

一个联合索引使用问题以及优化方案

TiDB 社区干货传送门

管理与运维 故障排查/诊断

Placement Rules 原理

TiDB 社区干货传送门

TiDB 底层架构

TiDB AutoCommit OFF 问题

TiDB 社区干货传送门

实践案例 故障排查/诊断 新版本/特性发布

微众银行数据库架构演进及 TiDB 实践经验

TiDB 社区干货传送门

实践案例

不定期更新,记录一些小知识

TiDB 社区干货传送门

监控 版本升级 安装 & 部署

TiDB 监控架构解读

TiDB 社区干货传送门

监控

小红书数据架构及 TiDB 使用场景

TiDB 社区干货传送门

伴鱼数据库之SQL审核系统

TiDB 社区干货传送门

使用Zabbix监控TiDB(一)

TiDB 社区干货传送门

实践案例

【TiDB 4.0 新特性系列】BR 特性及原理解读

TiDB 社区干货传送门

表单设计:一页只做一件事(三)_语言 & 开发_Think体验设计_InfoQ精选文章