产品设计中请求原谅,而不是请求许可

0 评论 319 浏览 1 收藏 9 分钟

本文从产品设计的两种极端现象出发,探讨了“请求原谅,而不是请求许可”的设计理念,即在设计中大胆地为用户提供预设的解决方案,而不是让用户在每一步都进行繁琐的确认。

PART1 产品设计碰到过的两种极端

说到产品设计(这里甚至可以适当泛化,交互设计、硬件设计、多媒体设计等),很多人容易走向两个极端,“有(不)幸(料)”在产品设计的经历中我都见到过:

第一种,用户都是小白,得听我们的!

他们根本不知道自己想要什么,他们不会知道怎么做,他们很容易犯错。

这是很多设计者一厢情愿的担心。这种情况的假设前提是,设计者自认为深谙背后的地图全貌,站在上帝视角俯瞰用户,自然会觉得用户的思考浅显而无知。设计者就像大包大揽的父母一般,制定好成长、前进的路径,约束好各种边界和规则,不允许任何的违逆和回旋。

用户在这种环境的活动受到严格的限制,没有丝毫的自由空间和创造性,甚至于既定的规则和路径并不与用户所处的使用场景事实相符合。

第二种,必须要让用户自己做决定,产品不能承担任何后果!

出了问题怎么办?不能说是产品/系统导致的吧!必须要让用户自己一步一步明确的确认和操作。

这是另外一种极端情形。作为设计者,从一开始就想要剥离所有的纠纷和瓜葛,所有的确认、授权、提示,都要求用户明确并给出操作才能继续,这样一来,就像是保险须知的条款,非常完备,除了问题,那是用户自己的责任啊。

用户在上面这种环境中,如同原始社会,已经失去了任何的工具支撑,想要喝水,系统会问你是不是想要水?是河水、湖水、海水?怎么取水,自己还是他人?用什么取水,手捧、葫芦?只怕一连串的确认操作之后,用户也快渴死了,至少也被烦死了。

PART2 产品设计理应如何思考呢?

《交互设计精髓4》一书中有一段话,我想可以用来呼应上述part1的现象。

“大部分的时间里面,我们应该做很可能是正确的事情,而不是每次尝试都必须做好充分的判断。软件只应该做很可能是正确的事情,然后为用户提供强大的工具来调整第一次的尝试,而不是给张白纸,挑战用户。这样一来,应用程序不用请求权限去采取行动,而是做了之后再请求谅解

对大多数人来说,从空白开始很困难,而在别人做好的基础上开始则会更简单。用户能够轻易微调程序提供的近似值,以精确达到自己的要求。”

PART3 现实世界里的花花绿绿

大包大揽的家长式设计(第一种设计)现在可能并不多见了,毕竟市场会教育他们,用户也会用脚投票,严格制式的系统逻辑怎么可能面对发展的业务和各式各样的团队。

但如果是面对b端/g端用户,卑微的乙方或者没有话语权的自研团队可能更容易出现的是第二种情形,设计者想尽办法的规避软件/系统的责任,一切的操作需要用户的许可、授权、选择、确认,最终的结果会是:无尽的提示弹窗+二次确认弹窗+无尽的“我知道了”、“确认”、“下一步”、“提交”。

如此的设计虽然说很好的规避了产品的责任,把一切都推给了用户,同时也尽可能保证了产品/系统逻辑的清晰明了、简化,也不需要额外复杂的兜底逻辑。但b端、g端产品更注重的生产力和效率,这里你说是不是完全相背了呢?

PART4 多做一点点,改变世界

所有的许可都抛给用户,只能说是产品设计的懒惰造成的(这个锅多半得产品经理自己来背),不够深刻理解用户/业务场景,对任务流程把握不准确,这样的设计拿出来根本不是一把利斧(工具),而是“原石”(白纸)一堆。

用户打开一个信息页面,数据刷新都不做,这是不是偷懒呢?即便用户不需要,但是我们也应该在做一些基本的预设:

1、打开页面时进行数据查询刷新
2、用户点击已阅读、知道了之后,就应该自动执行下一步操作,而不是再让用户点下一步
3、提交数据之后,就应该自动返回信息列表或者详情预览,并展示最新数据

产品/系统应该做到的远不止上面这些,更多的应该在业务场景、用户场景、流程协作中体现出来。

最近偶然翻看到一篇工作笔记(正是基于产品设计视角大胆的做可能正确的事情),是2021年刚到上个团队时,做的2个迭代版本,功能不大,它们都是干的同一件事情:“信息结构优化”,这当然属于是提供给用户一定的功能分类基础,而不是让用户像白纸一样在系统里自己去盲目探索。

信息结构是呈现给用户的支撑性框架,信息结构构建了用户的大脑导航地图。当时接手的产品基本也到了近2.0的阶段,可是在对于业务贴合的信息结构构建上做的很不足。我猜当时大概率有几种可能:

  1. 当时团队的普遍能力模型,在信息结构上是有待提升的
  2. 调研草草没有深入到用户的场景里面去

用户一定没有错,如果有问题一定是设计者需要反思的!

导航的视角不只是当一个用户,对于B端产品来说(很多企业级应用产品),用户其实是协作网络上的不同角色。我们有不同角色的用户,他们可能互相独立、也可能互为依赖,而对于一条主业务流程上的串联用户的来说,信息结构不只是对于当前用户的事情,也要考虑信息随着主流程在用户链条上的传递。

类似此类的识别、判断,我们大可大胆的让系统去先做了,然后提供一些兜底、容错、撤销、撤回机制给到用户用于修正不符合事实的操作。“请求原谅,而不是请求许可”,更像是一种设计思想,需要设计者能够深刻共情用户与场景。

作者:Kris_3zzz, 公众号:iSpiik产品说

本文由 @Kris_3zzz 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自 Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!