惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

月光博客
月光博客
IT之家
IT之家
Hugging Face - Blog
Hugging Face - Blog
J
Java Code Geeks
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 叶小钗
MyScale Blog
MyScale Blog
G
Google Developers Blog
Microsoft Azure Blog
Microsoft Azure Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
大猫的无限游戏
大猫的无限游戏
博客园 - 三生石上(FineUI控件)
Google DeepMind News
Google DeepMind News
Engineering at Meta
Engineering at Meta
The Cloudflare Blog
Martin Fowler
Martin Fowler
酷 壳 – CoolShell
酷 壳 – CoolShell
N
Netflix TechBlog - Medium
MongoDB | Blog
MongoDB | Blog
I
InfoQ
WordPress大学
WordPress大学
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
H
Help Net Security

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
Apple music用户体验分析,原来苹果也没有把这些做好
彩云sky · 2022-08-02 · via 人人都是产品经理

编辑导语:Apple Music是苹果推出的一款具有付费订阅流媒体服务功能的新音乐产品,但是用户体验似乎并没有想象中优秀,本文作者整理了一些Apple music存在的体验问题,感兴趣的朋友一起来看看吧。

Hi,我是彩云。

我自从在2014年入手了第一台苹果本后,就把身边常用的手机,耳机之类的常用设备都换成了苹果系列,也算是资深果粉了。对于苹果的软件产品,也非常信任,毕竟是业界的体验标杆了。但即使如此,它们也并不完美,我个人觉得最失败的就是苹果鼠标的设计,充电的时候居然要插在底部,每次没电了就不能工作了,不知道你怎么看?

当然,今天这篇文章是以国外一位产品设计leader的视角来分析Apple music的很多体验问题,看看他是如何分析一个标杆产品的使用体验吧。

一、Apple Music诞生的原因?

我是果粉,在过去的10年里一直在用苹果产品,很欣赏乔布斯早在那时就倡导的优秀设计理念。在那些年里,我迷上了苹果的生态系统,因为对我来说,“它太好用了”。

其中一个便是iTunes。我会花大量的时间仔细整理我的音乐库,并将它同步到我的iPod上。

在中间,我发现了Spotify,几年后,我曾经喜欢的iTunes乐库已经积灰了。

在大量的猜测和谣言之后,苹果最终加入了流媒体竞争——完全放弃iTunes,并推出他们的新音乐产品,带有付费订阅流媒体服务的可选功能,名为“Apple Music”。

Apple music用户体验分析,原来苹果也没有把这些做好

Source: Apple

在用了Spotify多年后,我决定给苹果一个机会,重新尝试用苹果的音乐产品,到现在用了苹果音乐大概一年。

不多废话了,以下是我作为一个产品设计师和一个想听音乐的普通用户整理的一些想法,分析下Apple music存在哪些体验问题。

二、Apple Music存在的体验问题

1. 搜索

音乐APP的一个关键功能就是搜索,在APP中它的使用频率很容易排到前三。那么,Apple music的搜索功能我觉得做的还不够好。

假设我们想要搜索一个知名的摇滚乐队Weezer,他们是一个很酷的乐队。

Apple music用户体验分析,原来苹果也没有把这些做好

我们正确输入了Weezer,自动提示似乎已经出现了。但是等等——这是自动提示吗?

让我们试着输入“Wezer”,假装我们拼错了乐队的名字,以再次确认这确实是一个自动提示,帮助我们确认它与苹果库中的Weezer匹配。

Apple music用户体验分析,原来苹果也没有把这些做好

看到这个结果,我猜这应该不是一个很好的自动提示。为了确定是否真的做了自动提示功能,我们换一个关键词,这次选另一个非常受欢迎的摇滚乐队-Queen。

Apple music用户体验分析,原来苹果也没有把这些做好

这次好像终于是有自动提示了,但为什么Queen能快速出关联结果而Weezer没有?

Apple music用户体验分析,原来苹果也没有把这些做好

好吧,让我们继续寻找线索。点击那个下拉列表,看看它将带我们去哪里。

Apple music用户体验分析,原来苹果也没有把这些做好

结果出现了一个全新的“结果页面”。如果能够完全跳过这一页就好了(就像我们搜索Queen的时候),因为我真正想做的是直接进入Weezer的音乐。

此时想想我们下一步要做什么。我不记得我最后去了哪里,但我知道我想回到最初的位置。我们该怎么做呢?可能像我们在浏览器一样有一个后退按钮,对吧?但没有找到。

事实证明,没有后退按钮。至少,它没有通用的后退按钮来撤消你所做的任何导航操作。你能猜到为什么吗?

2. 导航

我不知道你怎么想,但我发现Apple Music的导航是它最令人困惑的方面之一。优秀应用不会让你思考你在哪里,每一个页面都会是清晰的且可以很容易撤消和回到你之前的地方。

苹果iOS的人机界面指南为应用提供了三种类型的导航,苹果似乎也在macOS中使用了这些概念,苹果音乐就使用了平行导航。

(彩云注:这里我跟大家解释下iOS的三种类型导航模式)

  1. 层级导航(Hierarchical navigation)。这个导航模式只能在每个屏幕做一个选择到达一个目的地。为了到达另外的目的地,你必须重新开始你的步骤或者从起点重新开始,做出不同的选择。设置和邮箱就使用这种导航样式。
  2. 平行导航(Flat navigation)。这个导航模式允许在多个内容目录之间转换。Music和AppStore使用这种导航样式。
  3. 内容驱动或者体验驱动导航(Content-driven or experience-driven navigation)。这个导航模式在内容间自由移动,或者依据内容本身定义导航。游戏,图书和其他沉浸式app基本使用这种导航方式。)

Apple music用户体验分析,原来苹果也没有把这些做好

Apple music有一个侧边栏,但我觉得这样意义不大。平行导航在移动端体验中非常好用,因为屏幕面积很小。如果你经常使用导航栏,你可以知道你在哪个标签页上,还可以独立于其他选项卡更深入地探索一个选项卡。

Apple music用户体验分析,原来苹果也没有把这些做好

这是一个自iPhone发布以来一直保持的惯例,人们不会轻易混淆自己在哪里。那么这在桌面上是如何工作的呢?

Apple music用户体验分析,原来苹果也没有把这些做好

简而言之,这也意味着侧边栏中的每一项都有自己独立的导航。现在让我们看看Spotify是如何处理桌面导航的。

Apple music用户体验分析,原来苹果也没有把这些做好

注意到了吗?Spotify似乎结合了侧边栏的优点,无论你点击应用的哪个位置,它都允许你轻松地回溯你的步骤。

为什么在我看来这比苹果的设计更好?

它可以减少认知负荷。人们没有时间去记住他们上次在应用中的位置。人们习惯于使用他们的浏览器的后退键。Spotify利用了这一点,使新用户的行为符合心理预期。

它还降低了用户焦虑感,允许用户自由探索,而不用担心搞砸或无法解决问题。

3. 系统反馈与探索

点击是任何应用的一个重要部分,因为你需要点击来操作。但Apple music的点击体验有点糟糕。

就拿这个正在播放的状态来说吧。

Apple music用户体验分析,原来苹果也没有把这些做好

自从iTunes诞生以来,这在很大程度上保持着相同的功能一致性,一种查看当前正在播放的歌曲的方式。

当你听着Weezer的一首新歌,然后想,“嗯,这支乐队太棒了,让我看看他们其他的目录!”让我们从这里点击Weezer !

Apple music用户体验分析,原来苹果也没有把这些做好

当我们点击了标题和专辑,但毫无效果。你能猜到这里具体要怎么操作才能达到我们想要的效果吗?

Apple music用户体验分析,原来苹果也没有把这些做好

你猜不到的是居然要点击“更多”菜单,浏览列表,然后在列表底部看到“在Apple music中显示”。

但在应用的其他地方呢?你可以点击歌曲、专辑或艺术家吗?好像也不行。

Apple music用户体验分析,原来苹果也没有把这些做好

在这一点上,你可能会想,我为什么要在这个问题上做文章?因为我认为音乐应用的全部意义,尤其是在一个巨大的流媒体库中寻找新音乐的意义:是点击、探索,并轻松地找到歌曲、专辑和艺术家。

我认为用户不应该因为不遵守应用希望使用它的方式而受到阻碍。

(彩云注:这里作者想要表达的问题是交互上不应该让用户去遵循产品的规则,而应该尽可能的满足用户的心智模型,用户在这里的需求很清晰,打通这里的流程问题很重要)。

4. 响应时间

一款好的应用不会让你等待。我们知道加载时间会极大地影响网页的跳出率,我不认为我们必须区别对待本地应用。

这让我想到了使用Apple Music时最大的痛苦之一:

Apple music用户体验分析,原来苹果也没有把这些做好

在页面之间等待,等待。想知道下一个糟糕的行为会是什么?失去当前的状态提示。因为延迟,无响应的问题,不知道当我点击“播放”时,我的歌曲是否会真正播放。

三、总结

我相信好的设计应该是令人向往的。我想喜欢Apple music,更重要的是,我相信苹果仍然有很强的设计原则。但我这次在apple music中没有让我享受到该有的好体验。这是一个遗憾,因为作为一项服务,Apple music还是有很多优点。

Apple music用户体验分析,原来苹果也没有把这些做好

  • 从策划的角度来看,我发现苹果选择的曲目质量很高。从人工挑选的歌曲(比如上面显示的播放列表)到算法根据我的听歌习惯为我提供优秀的音乐。这感觉非常像苹果,我一直惊讶于它的选择是多么的好。
  • 从音频的角度来看,我实际上更喜欢音乐的质量,这一点要Spotify要好。

这些优点反而让我更加失望,因为这个产品本身不容易使用。

说到底,真正的问题在于苹果没有明确定义他们的产品是什么。如果说音乐应用是iTunes的继承者,那么不幸的是,它没有达到目标,因为他们试图将流媒体服务(Apple music)嵌入到传统模式中。如果Apple Music是他们的重点,他们并没有让它作为一个独立的服务脱颖而出。

有一件事是肯定的,桌面版的Apple Music如果要达到一个像样的可用性水平,还有很多工作要做。

你觉得呢? 你在体验苹果产品时,还遇到哪些痛点?

原文作者:Jake Dragash

原文链接:https://uxdesign.cc/apple-musics-ux-problem-e8f5fac756de

译者:彩云Sky,腾讯高级视觉设计师;公众号:彩云译设计

本文由@彩云sky 翻译发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。