OK Camera

概要

OK Camera 是我们在 2017 年初做的一次相机重设计的作品。我们一共做了 7 个优化点/新功能,以下仅介绍其中一个由我主导设计的优化点。

前期调研

在前期,我们分析了 10 款同类竞品,对 14 位用户进行深度访谈,回收了 200 余份调查问卷。另外,借助大数据平台,我们得知很多关键的相机使用数据。其中对我接下来的设计影响较大的是这个数据:

从这个数据可以看出,用户在使用系统相机的时候,单次使用时长极短。而在访谈中,也有好几个用户提到,除了自拍,拍照基本都能在 30 秒内完成。

因此,“高效率”必然是系统相机需要追求的目标。但我发现,现如今的相机产品对效率的追求分别朝着两个不同的方向。

系统自带相机,比如 Flyme 相机、Pixel 相机和 iOS 相机,通常是点击快门拍照之后,照片生成,但仍然停留在取景界面,等待用户快速拍摄下一张:

而很多第三方的相机,比如微信、Instagram、黄油相机,则是拍完一张,随即给出拍摄成品给用户预览,以决定是使用照片还是重拍一张:

换句话说,前者认为保证用户可以迅速拍摄下一张更重要,而后者认为让用户迅速预览拍出来的照片更重要。你会发现,它们都不得不牺牲了另一个任务的效率。

系统相机有没有可能兼备两种任务的高效率?

方案探索

查看相册其实是一个临时态,它终将导向下一个任务:要么是编辑、分享,要么是回头重拍一张。对于临时态,在移动终端上有一个手势非常合适,那就是长按:

长按相册入口即呼出临时相册,左右滑动快速浏览,向上滑动则打开该照片,松手则退出临时相册。这个流程看上去一气呵成。

然而,在准备深入完善细节的时候,我发现……iOS 的自带相机已经做了一个几乎一样的方案……区别只在于它用到的手势是 3D Touch 的 Peek 和 Pop:

我感到沮丧,因为我这个方案已经失去创新的价值;也感到高兴,因为发现 Apple 也在尝试解决同一个问题。

继续探索!

在产品设计中,我们常说的“操作成本高”,其实包括两方面,一是触发操作不方便,二是撤销操作不方便。而在我们的相机界面,想要优化查看相册的效率,最好也能兼顾这两方面的操作成本。

除了长按,还有没有办法让进入相册和退出相册都非常便捷?我想到了滑动手势(在达到以下方案之前,其实经历了非常曲折的变更,篇幅所限,不再话下):

  1. 拍摄照片后,屏幕底部会露出照片的一小块,暗示可以点击或上滑查看
  2. 上滑呼出相册,左右滑动浏览,随时下滑收起相册

无论是进入相册,还是退出相册,都只需要一个全屏可以响应的滑动操作。并且,由于整个流程没有跳转新的页面,用户对相册的感知会是非常“轻量”的,因此操作成本也会因此降低。

还不够

在提出上述方案的时候,我意外地发现,相册出现的动画轨迹与手机拍摄后恢复正常姿态的轨迹是恰好相对的。这意味着——我们可以增加一个体感识别,当用户手持相机拍完照,把手机拿下来准备查看照片效果的时候,相册自动弹出。

要知道,当我们使用后置摄像头拍摄的时候,手机与地面的夹角通常接近 90º;而当我们在浏览相册的时候,手机与地面的夹角通常在 30º ~ 60º 范围内。

我为这个想法感到兴奋。我的小伙伴们也都觉得很有意思。我们决定为此做一次用户测试。

原型制作

其实从一开始的方案探索,我就已经开始做原型了。可交互的原型能帮助你深入了解设计方案的优劣,从而更早地发现问题。

我用的原型工具是 Framer,它最大的特点是功能强大,能精确还原设计方案。

整个原型一共包含 600+ 行代码,4 个开源组件和 3 段音频。

(你可以通过这个链接体验原型。但是通过浏览器打开的原型将无法展示取景框和“拍完拿下来”的体感识别功能,如果你想要体验完整功能,需要先在手机上安装 Framer 客户端。)

用户测试

我们前往北师大珠海校区进行用户测试。

测试步骤的是:

  1. 请用户自主使用原型拍摄几张照片(原型只是模拟拍摄效果,并非真实拍摄)
  2. 请用户自主查看刚才拍到的照片
  3. 设法让用户自主发现“拍完照拿下来”的功能

经过 5 轮用户测试,我们得出结论:

  1. 新的相册入口在可用性上完全 OK
  2. 用户在发现体感识别功能之后都很感兴趣(也让我们感到惊喜)
  3. 部分用户习惯横屏拍摄,所以我们需要针对横屏做相应的适配方案

总结

这次概念设计持续一个多月,我们完整地走了一遍通用设计流程。其实一开始我们觉得相机已经没有什么可以做的了,无非就是把现在流行的第三方相机整合到系统相机里(三星相机就是这样做的)。但在第二轮头脑风暴之后我们发现,原来可以探索的方向还有很多。我们最终的方案也是超出了一开始的预期。

备注 1:本次概念设计是合作项目,上述任何工作,如果没有特别注明,有可能不是我独立完成的。

备注 2:上述方案并未上线。