Firebase 设计师分享: 如何推进产品设计改版

谷歌开发者 2019-06-13 09:30

作者: Maple, Designer, Google


Crashlytics 是一个崩溃报告工具,可以帮助移动应用开发者了解应用崩溃的原因。如果您是从 Fabric 时代过来的 Crashlytics 老用户的话,应该能一眼看出来前后两版设计中的关键区别:

△ 上图: Fabric 时代的 Crashlytics,下图: Firebase 时代的 Crashlytics

  • 了解 Crashlytics

    https://firebase.google.cn/products/crashlytics/


随着 Fabric 被 Google 收购,我的团队于 2017 年 1 月加入了 Firebase。此次收购的目标之一便是将 Crashlytics 整合进 Firebase。这意味着使用 Firebase 的风格体系对我们的产品进行改版和重构: Firebase 采用 Material Design 设计风格,且拥有非常独特的视觉设计体系。


这是个大工程,而我认为这是一个对用户体验进行整体性再思考的好机会,而不仅仅只是把原有的功能用新的 UI 包装一遍。Crashlytics 是一款深受喜爱的产品,但自 2011 年创建以来在设计方面 "欠账" 很多。很多用户向我们反映,他们在使用的过程中遇到了困难,或是找不到已经存在的功能。我们的团队也很难弄清楚应该在哪里放置新功能,因为对我们自己和用户而言,产品都缺乏明确的信息架构。现在是重新设计的时候了。


但首先,我需要力证彻底改版的必要性。

△ "产品改版可不是小事" / 图片来自: imgflip.com

一款产品的彻底改版可没说起来那么容易。这需要经历相当长一段时间才能理解用户,了解他们使用产品的方式,以及他们遇到的问题。在开始重新设计之前,我们需要获取这些方面的准确信息,以确保团队正在解决的问题是正确的问题,并且让大家始终锁定这些项目目标。



第一步: 了解用户


第一步是收集信息。我和很多人做了深入的交流,包括在 Crashlytics 团队中待了很多年的人,还有我们的开发者关系团队、用户研究人员,当然还有我们的用户。在弄清楚应该如何改善用户体验之前,我首先需要了解人们使用 Crashlytics 的原因和方式。


幸运的是,我的产品经理 Jason St. Pierre 在 Crashlytics 项目工作了 5 年多,经常与用户交谈,他对各种各样的用户群体如何使用 Crashlytics 有深刻的理解。他确定了 4 个最关键的 Crashlytics 用户场景:


  • 监控新发布的应用版本的稳定性

  • 检查应用稳定性

  • 给崩溃的修复工作划分优先级

  • 调试客户反馈过来的问题

△ Crashlytics 中最关键的用户场景: 监控新发布的应用版本的稳定性

这只是开始。接下来我将不同的用户角色 (Persona) 到这套流程中,发现所有 4 个场景中都存在一条暗线: "检查与修复" 子流程。我与团队分享了这些流程,并根据需要重新梳理了它们。这些流程让 Crashlytics 团队的所有成员从根源上了解了用户使用我们产品的方式。

△ "检查与修复" 子流程在核心用户场景里反复出现



第二步: 了解用户痛点


在对人们使用产品的方式达成一致的理解后,我们需要了解现有用户体验中的痛点。Crashlytics 团队的协作性非常强,所有人都在致力于为用户构建良好的体验。我想设法让他们参与到改版设计的过程里,这样就比我单方面地向他们分享设计概念并收集反馈要好,而且更体现协作精神。另外在设计过程中,产品团队拥有很多富有价值的上下文信息,毕竟他们中的许多人这么多年来一直在研究改进这个产品。


Crashlytics 团队的许多人都从各自的角度提到了首页控制面板需要改进。为了利用他们的知识,我决定进行一系列内部用户调研。我的目标是,基于我们多年来从用户那里听到的反馈,来了解用户体验中最大的痛点是什么。


我把 Crashlytics 的控制面板打印并裁成了单个的小块,然后逐一和团队成员们展开讨论,我要求他们重新组合这些小块,从而打造出新的控制面板,而且还要明确说出他们这么组合的思路。

△ 团队成员使用纸模重新排列设计控制面板

△ 有一些纸模设计甚至还 "加了料",因为现有的模块无法满足需求

这样做非常有用。它不仅有趣 (毕竟如今的设计师日常工作时几乎接触不到纸模),还能让我看到每个人眼中痛点的位置,同时让他们免受任何固有印象的影响,从而使我更容易定位反复出现的那些问题。例如,每个人都专注于改进过滤器,并改善信息层次架构。我还从开发者关系团队了解到哪些功能让用户感到难以使用,或者压根就很难找到这些功能。


我将这些信息分享给了团队,并在一个设计文档里对改版设计的工作进行了细分 (这个文档会持续迭代)。我还与团队一起设置了每周设计签到机制,以便分享设计更新,并确保他们能一直跟进改版设计的过程。

△ 设计文档里的一页,强调了重点设计课题



第三步: 定义设计课题


在了解了用户的使用目标和痛点之后,设计课题自然会更加清晰。我从纸模阶段以及团队对话中吸收了大量的信息,并据此总结出了主要的设计课题。


课题1: 用户很难轻松查看自己最关心的数据

从一个细节可以看出来问题: 大多数用户在我们的首页面板上做的第一个操作是向下滚动。因为他们正在寻找的信息往往位于页面中靠下的位置,或需要多次点击才能到达。众多不太重要的功能淹没了真正重要的信息。

△ 出错报告详情页就是用户不得不 "多点几下" 才能看到的页面


问题2: 用户不知道某些功能已经存在

曾经有一个用户要我添加一个功能,来记录应用中导致崩溃的事件日志。但这个功能已经存在于首页面板中,只是隐藏在 UI 里而已。许多用户都向我们的客服团队提出了类似的问题。这些情况也反映了团队面临的普遍问题: 难以确定应该在哪里放置功能。

△ 日志功能早就有了,但只是一个不显眼的 "开关"

上面两个设计课题之所以会出现,从本质上讲,还是因为我们的产品信息架构不明确。所以我向利益相关者提出了应该解决的主要问题,由于这些人一直都在参与上述的设计过程,因此我提出的这些改进计划很容易就被认可了,而且在具体推进时也轻松了很多。



第四步: 迈向成功


现在我们的状态是: 团队正式认可了改版的必要性。他们了解了用户遇到的问题,并就用户体验的哪些部分需要改进达成了一致。成功了一半!


接下来的工作自然就是重新设计产品面板。在接下来的几个月内我们组织了大量的头脑风暴、协作、设计签到 / 讨论,以及用户测试。


说服整个团队进行产品设计改版涉及到大量的利益权衡工作。作为设计师,您可能会认定产品显然需要重新设计,但这毕竟只是一家之言,到了需要团队决策的时候您会发现一个巴掌根本拍不响。重新设计产品是一个团队的工作,全体成员都必须意识到这么做的必要性才行。所以,如果您不了解产品目前是怎样被使用的,就谈不上扎实有效地进行针对性的重新设计。


通过深刻理解 Crashlytics 用户、他们的痛点和他们的问题,我更好地重新设计了产品。通过带着其他人经历全过程,整个团队也得以更好地了解用户,并满足他们的需求。经过数月的努力和与用户的交流,我们最终成功地将 Crashlytics 进行了改版,并有机地整合进了 Firebase。在这个过程中,新功能上线以及信息架构的重组做到了两全其美。


最后,让我展示一下 Crashlytics 改版后我最喜欢的设计 "甜点":

△ "抓住 bug 啦!"——解决 bug 之后的小动画

您的产品在上线后有经历过彻底的改版吗?在改版中遇见了哪些问题?或者收获了哪些经验?欢迎在评论区和我们分享。



 点击屏末 | 文 | 进入 Firebase 官方首页



推荐阅读

  • Google I/O 2019 上的 Firebase 新功能速递

  • Android Q Beta 4 来啦!公开 API 也已定稿!

  • 为应用提供 64 位原生支持 | Android 中文教学视频




谷歌开发者 Google 中国官方账号。汇集 Android, Flutter, Chrome OS, AI 等开发技术,以及 Google Play 平台出海相关信息。
评论
热门推荐
相关推荐
我要评论
0
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦