深度分析｜领跑：一款运动类APP的交互设计（2万字干货）

这次的分享是前不久完成的一次比较完整的交互设计工作，基本上涵盖了前、中、后期的完整流程，包括前期的定位分析、用户调研、业务需求分析、目标用户画像、用户需求分析、关键因素分解、路径分析，完整的交互设计文档，以及后期的可用性测试。希望对需求分析、交互设计或可用性测试感兴趣的朋友们有用。

第一卷 需求分析

1 概述

1.1 产品目标

以运动为主题，选定某一种运动形式，完成一款 APP 产品的交互设计，内容集中在统计和分享运动量方面。

1.2 关键词分解

运动，APP，统计，分享，运动量

1.3 工作流程与任务排期

1. 基本定位分析（7月8日）：通过头脑风暴，由产品目标确定基本的分析思路和调研方向。见本卷第2节。
2. 问卷/访谈调研（7月9-11日）：根据基本思路制定调查问卷，对目标用户进行问卷调研，寻找已有思路与用户期望的结合点。见本卷第3节。
3. 业务需求分析（7月12日）：确定产品的核心任务点，据此分解产品的业务需求。见本卷第4节。
4. 明确目标用户（7月12日）：由业务需求确定目标用户特征，分析核心流程的用户场景。见本卷第5节。
5. 用户需求分析（7月13日）：寻找目标用户使用过程与业务需求的结合点，分解产品的用户需求。见本卷第6节。
6. 关键因素分解（7月14日）：对所有需求进行关键因素分解，确定各个需求的动机、担忧和障碍。见本卷第7节。
7. 归纳用户需求（7月14日）：汇总用户需求，去重、合并近似需求，形成需求清单。见本卷第8节。
8. 路径分析（7月15日）：画出用户体验路径和情感坐标，整理各个接触点的问题和惊喜，力图在一套完整的路径上满足用户需求和提升用户体验。见本卷第9节。

2 基本定位分析

接到需求后，可以感觉到这是一个看似简单却又不容易做好的需求。

从关键词分解结果看，很容易想到，产品的核心流程就是“运动-计步-统计-分享”，也就是“产生数据-记录数据-统计数据-分享数据”的过程。相对于骑行、甚至登山、徒步等运动形式，跑步是最为普及、也最容易形成习惯的一种。

同时，在跑步类应用上，市面上已有咕咚、悦跑圈、虎扑跑步、动动、Nike Running、Feel等一众数不胜数、又各自都拥有一定的用户数量的竞品。虽然这样的数量说明这一市场已具有一定的饱和度，新产品脱颖而出的难度比以往任何时候都更大，但从另一个角度，这样成熟且已经发酵多年的竞品环境，已经为后来者提供了一片在合适的切入点可以快速成长的沃土，因为当前国内具有“使用APP记录跑步”习惯的用户基数，也是以往任何时期都不具备的条件。

同时，恰恰是这样的数量，也说明没有一家产品能够占据垄断性的地位，每个产品都在“运动-计步-统计-分享”这一主流程的基础上，通过各自的特色，吸引了具有相应目标用户特征的用户群体，都保有自己应有的生存空间。

因此，考虑到跑步（尤其是城市上班族的夜跑）族已日趋成熟的APP使用习惯和较为可观的用户基数，以及众多竞品提供的参考和分析样本，本次设计选择了夜跑这一运动形式，作为产品的主题。

确定了运动形式后，在设计调研问卷之前，还需要明确产品在数据的“产生、记录、统计、分享”这一枯燥的主要功能线之外需要突出的特色。

经过头脑风暴的罗列、筛选和整合，我最终选择留下的是下面四个关键点，作为产品定位的关键：

1. 值得炫耀：满足用户炫耀的需要。
2. 群体感：给用户提供群体参与感。
3. 竞争感：通过竞争产生激励。
4. 简洁：简化所有与主流程和以上三个关键点无关的功能。

第一点，是运动类APP很特殊也很有趣的一个地方。用户选择使用APP记录自己的运动成绩和统计数据，无论有任何其他强身健体、结识跑友之类的动机，几乎100%的用户都无法否认“炫耀”是一个非常大的使用动机和动力。因此，如果能提供“格外值得我炫耀”的东西，就可以对几乎所有用户产生一定的吸引力。

第二点是由目前处于“战国时代”的运动类APP市场上，用户群体的分散度所决定的。无论使用的是几大主流运动APP中的哪种，在同时使用这款APP的朋友都只有那么几个。即使几乎所有主流运动APP中都做了社区甚至IM功能，即使微信、QQ、朋友圈这几大分享途径成了每款APP的标配，也还是无力改变用户永远只有屈指可数的几个朋友在和他一同使用同一款APP进行跑步的现状。而社区和IM功能中，无论推荐多少陌生人用户，他们的存在、他们的运动记录永远和用户自己的存在没有产生足够的结合点。因此，在接受了用户群体分散这个现实条件的情况下，如何让用户能与陌生用户产生更好的化学反应、产生一定的群体参与感，个人认为比想方设法把应用内IM做得像QQ、微信一样好更有效果一些。

第三点是目前以悦跑圈为代表的许多竞品都在注意到的一个方面。上面提到的炫耀决定了使用产品的动机，群体参与感决定了对产品的归属感和依赖，那么竞争感则可以为痛苦（对大多数普通人而言）的跑步提供坚持下去的动力。

第四点来自我个人作为夜跑群体的一员，使用和尝试过几大主流跑步APP的体验。上面提到，起初，各家产品都在主流程的基础上营造了各自的特色并以此为生，而每个有野心争取更多用户的产品在研究了对手之后，都不约而同地选择将竞品的特色功能搬进自己的产品——打个比方，A产品做了社区、圈子，不久后B产品也加入了社区和圈子。B产品做了IM，不久后C产品也更新了IM功能。C产品开始做线上马拉松，不久后A、B产品乃至D、E、F中马拉松类的赛事功能如雨后春笋。最后的结果就是除了小部分坚持特色（另一个角度上讲是迭代频率比较低）的产品功能还比较简单、具有辨识度之外（例如Nike Running，但另一方面，它的界面和功能上已经有点与时代脱节了），几家主流产品都发展成了相似度很高的“全家桶”。而这些“全家桶”的功能中充满你了不管适不适合自己就搬进来的功能，体积和使用体验都越发臃肿。因此，本次设计中将在参考竞品信息架构的同时，考虑删减大量对突出前三项特色无益的功能。

3 问卷/访谈调研

3.1 问卷设计

围绕以上整理出的四个关键点，我设计了由以下17个问题构成、涵盖有夜跑习惯和无夜跑习惯人群的问卷。问题清单如下：

3.2 调研方法

这里必须承认的是，在调研环节出现了本次设计中一个比较大的难关。首先，调研形式的选择上，出于个人在其他行业领域的线上问卷调研经历，个人认为在没有合适、专业的线上问卷投放渠道的情况下，通过QQ群等类似方式投放的线上问卷，回收后的结果通常是非常不可靠的。这种投放方式会导致具有相同特征的样本扎堆，且样本填写问卷的随意性较大，轻则导致统计结果无规律可循，重则严重误导根据统计结果而进行的决策。因此，本次设计中我倾向于选择线下调研。

但两天的线下问卷调研结果依然不尽理想，虽然样本填写问卷时随意性较大的现象比在线调研有了较大程度的改善，但在没有经费和人力支持的情况下，这样个人试验性质的小规模线下问卷在样本量上很受限，由此导致具有相同特征的样本扎堆现象依旧难以完全避免，难以形成具有统计意义的定量数据，只能形成一些定性的结论。

当然，就定性结论的可信度而言，已经比同样属于个人试验规模的在线问卷有了明显的提高。

最后一天，作为定性结论的有益补充，我根据第二节梳理出的前三个关键点，基本上依照与问卷类似的提纲，在朋友中对若干典型用户进行了访谈调研。

3.3 调研结论

以下是本次设计的问卷与访谈相结合的调研方式形成的定型结论，虽然没有大样本的定量数据那样优秀的说服力，但对个人试验性质的设计而言已足够具有一定的指导意义：

1. 夜跑频率为3~4次的最多，而5次以上的极少。
2. 夜跑者以独自夜跑居多。
3. 夜跑强度集中在4公里以下，其中以2~4公里间居多。
4. 有较多的夜跑者有同时使用APP的习惯，其中以咕咚和悦跑圈的用户居多。
5. 无APP使用习惯的受访者中，多是由于不知道有这样的产品，还有部分用户认为带手机跑步麻烦，或怕手机摔坏，因而不带手机，或选择了手环类的产品。
6. 群体参与感和竞争感最有可能提高用户使用产品热情和增强用户粘度，其次是科学的数据分析，而作为跑步类而非综合健身类的APP，类似“健身指导”的功能并没有被特别的重视。
7. 受访者对竞赛功能的兴趣最高，其次是运动数据分析功能。
8. 愿意将数据截图在朋友圈或微博分享的用户比例基本上是一半，不愿意分享的受访者认为这样的行为有可能招致朋友的“酸意”或产生厌烦感。
9. 无夜跑习惯的受访者中，认为可能诱使他们开始夜跑的原因以“群体参与感”居多，这一结论与有夜跑习惯的受访者类似。
10. 对无夜跑习惯的受访者而言，没有运动的习惯、缺乏动力、孤独感，可能都是不习惯夜跑的根源。
11. 绝大多数受访者都认为，有竞争气氛的情况下做一件事的动力或热情会更高。
12. 对一项竞赛和排名而言，无论涉不涉及经济利益，作弊都是最影响口碑和参与积极性的因素。
13. 相比分享单纯的运动数据，愿意在社交平台分享证书的用户比例较高。
14. 大多数受访者认为，当排名位于后半部分时，将使其产生的负面情绪大于产生的激励

4 业务需求分析

根据基本思路梳理和用户调研的定性结果，整理形成以下12个业务需求。按重要性分为核心需求、主任务需求、配套需求三类：

• 核心需求：赛区/赛季功能、升降级功能、等级证书功能、反作弊措施
• 主任务需求：记录运动数据、可视化的数据统计与分享、跑伴（好友）及声援（留言）功能
• 配套需求：注册功能、推送提醒、问题反馈、用户评分、广告

以下逐条对业务需求的目标、目的、指标和用户行为进行分析。

4.1 赛区/赛季功能

业务需求：赛季/赛区功能。用户可选择加入一个本地赛区和合适的组别（即每次运动最小需要完成的距离），参与一个赛季的竞赛。

• 业务目标：为用户提供一个可产生归属感的群体
• 业务目的：为用户提供群体参与感，培养稳定的使用习惯
• 衡量指标：报名参加赛季的用户数
• 用户行为：选择赛区，选择组别，报名新赛季。

4.2 升降级功能
业务需求：升降级功能（参考足球联赛系统、或炉石传说等游戏的“天梯”系统），同赛区、同组别的用户作为同一个系统，在不同级别进行每赛季一定比例的升级和降级。在赛季中坚持进行计分运动（即结果与赛季得分挂钩的运动，与不挂钩的自由运动相对应）获得积分。

业务目标：营造竞赛氛围，为用户提供竞争感。

业务目的：充分激发用户的好胜心，抓住用户不甘心落后甚至降级的痛点，通过竞争激励和鼓励用户坚持使用产品。

衡量指标：坚持全勤或缺勤次数少于一定值的用户数目。

用户行为：进行计分运动。

4.3 等级证书功能

业务需求：在赛季结束时为用户生成电子版的等级证书，可生成高清图片，视觉效果与真实证书力求相近。

业务目标：刺激用户进行分享。

业务目的：提升产品知名度，吸引更多潜在用户。

衡量指标：证书页面的分享计数，或注册用户数。

用户行为：查看证书页面，并向QQ好友、微信好友或在微信朋友圈分享证书。

4.4 反作弊功能

业务需求：依据运动的配速、步频、轨迹，通过一定技术手段并辅以人工抽查，进行最严格的反作弊筛查。

业务目标：增强平台数据真实性。

业务目的：鼓励诚信参赛，为用户更好地参与竞争增强信心。

衡量指标：各反馈渠道中关于作弊的投诉数量（降低）。

用户行为：上传真实有效的运动数据。

4.5 记录运动数据

业务需求：记录运动的配速、时间、轨迹。

业务目标：为一切的运动统计、分享和竞赛提供数据基础。

业务目的：通过数据的记录和积累带给用户成就感，刺激用户使用产品的积极性。

衡量指标：上传的运动数据数量。

用户行为：记录运动并上传数据。

4.6 可视化的数据统计与分享

业务需求：对运动数据在多个维度进行统计，对重要数据提供可视化图表，提供比截图更便捷的分享途径。

业务目标：通过数据的对比和可视化的图表，让用户更好地感知自己锻炼情况，并乐于将其分享给朋友。

业务目的：增强用户成就感，刺激用户使用产品的积极性和分享运动结果的冲动。

衡量指标：运动结果统计页面的点击数和分享数。

用户行为：查看运动结果和历史统计页面。

4.7 跑伴及声援功能

业务需求：提供跑伴（好友）系统和声援（留言）功能，同时提供邀请其他社交工具中的好友进入跑伴的入口。

业务目标：在不影响主功能体验的情况下，提供最基本的应用内社交功能，设置邀请途径。

业务目的：建立用户间交流、用户引流的渠道，提高用户粘度。

衡量指标：人均好友数量和用户的日均声援数量。

用户行为：添加跑伴，声援跑伴，邀请好友。

4.8 注册功能

业务需求：要求用户使用注册功能注册账号后才可使用产品。

业务目标：提高注册转化率。

业务目的：有效进行用户管理。

衡量指标：注册用户数量。

用户行为：完成注册流程。

4.9 推送提醒

业务需求：定时发送推送提醒用户使用产品。

业务目标：提醒用户使用产品。

业务目的：提高用户粘度，培养用户使用产品的习惯。

衡量指标：日活跃用户数。

用户行为：通过通知条打开产品。

4.10 问题反馈

业务需求：在应用内提供问题反馈的渠道。

业务目标：获取真实用户反馈。

业务目的：根据真实的反馈改进现有问题。

衡量指标：反馈数量。

用户行为：提交问题反馈并留下联系方式。

4.11 用户评分

业务需求：在应用内提供前往APP Store评分的渠道。

业务目标：吸引更多评价、评分。

业务目的：让产品显得人气旺盛。

衡量指标：评分数量。

用户行为：前往Apple Store进行评分。

4.12 广告

业务需求：在合理的位置设置注重情感化设计的广告。

业务目标：让用户接受广告的存在并产生兴趣。

业务目的：提供盈利渠道。

衡量指标：广告的引流量。

用户行为：浏览广告并对商品留下印象。

5 目标用户与典型场景

通过基本定位思路、调研结果与业务需求的分析，本次设计将产品初步明确为“以含升降级制度的竞赛为核心特色，重视激励和习惯养成，简洁而美”的一款应用，并给它赋予一个能体现上述特色、又非常容易记忆和传播的名字——“领跑”。

5.1 目标用户

针对这样的初步定位，可以同时确定领跑的目标用户：

特征

1. 20~35岁之间的大学生或职员
2. 年轻，勇于也乐于参与竞争，喜欢新事物，热衷社交，有运动热情

经验

1. 有一定的互联网产品使用经验
2. 对跑步类APP（或运动手环等同类产品）有一定的使用经验或了解

5.2 人物模型

产品需要为具有特定需要的特定个体类型设计。如果产品涵盖受众过多，只会增加所有用户的认知负担及导航成本。例如，能够取悦某些用户的功能设置可能对其他用户造成困扰。因此，人物模型有助于避免设计对用户的理解过于弹性化、将自己过多地代入设计、或将一些边缘功能当做重点。根据调研结果和上述目标，可以构建两个典型的人物模型：

5.3 情境场景

通过情境场景可以由叙事的方式简明描述运用“领跑”实现以上两个人物模型的具体目标的过程，聚焦于两个人物模型及其思考和行为方式，从“他们”的角度描述一种理想的体验。本节将分别对两个人物模型，就其接触领跑、使用领跑这两大核心流程进行场景描述。

5.3.1 核心场景一：接触领跑——注册、登录与了解

（1）杨鹏

杨鹏合上笔记本屏幕，揉了一下眼睛，这么凉快的傍晚，这样宅在宿舍实在不符合他的性格。

杨鹏走到阳台，看了一眼足球场，曾经那是他和班上的球友下课后奋战的地方，然而大三之后大家各有各的事情，想找齐人去踢球已经变成一件很困难的事情。

他百无聊赖地打开微信，越来越多的同学开始用微信，尤其是喜欢发朋友圈，他没有这样的喜好，但也越发喜欢没事刷新一下朋友圈，看看他们在分享什么有趣的东西。

下拉刷新后，一张精美的证书映入眼帘：

“领跑 广州大学城赛区 男子三公里组 乙级B 银奖”——这一下子激起了他的好奇心，更让他燃起了获得同样证书的想法。他点开大图后在醒目的位置发现了这张证书的出处，是一款名为领跑的APP，旁边附有二维码。

他用扫描图片中的二维码功能顺利扫码下载了领跑。简单地通过手机注册后，就进入了第一次使用时的资料设置环节，填写个人资料、选择头像后进入的是赛季的介绍页，并询问他是否要马上参加一个赛季——当然！这就是他下载领跑的原因。

进入赛季报名流程后，首先要选择的是赛区，杨鹏看到提示语——原来赛区的选择是和起跑地点挂钩的，与赛区不符的运动是没法有效计分的，“大概是怕投机取巧的人去竞争不强的赛区刷好名次吧”他一边这样猜着，一边选择了广州大学城赛区。

接下来是选择组别，页面中同样附有提示语，告诉他组别代表了每次运动要完成的最小长度，而每周需要完成4次这样的运动，因此建议没有长期跑步习惯的人从较短的组别开始适应。他想了想自己大三开学后就没怎么运动的事实，决定选择最低的组别“一公里组”开始尝试。

最后一个页面显示了从“入门级E”到“甲级A”一共14个等级的升降规则，这更激起了他作为一个对足球联赛和游戏里“天梯”机制着迷的男生的挑战欲。这样一来，杨鹏就完成了一次流程没有任何冗余、提示清晰、又突出产品特色的注册和首次登录体验。

（2）潘晓

晚上八点半，潘晓站在下班的公交车上，她的左手拉着扶手，右手拿着手机把玩着。这是打仗似的一天工作结束后，和晚上自己的运动、英语学习计划之间，最美好的放空时间。

忽然，她的微信收到一条来自闺蜜阿春的消息，她通过通知条打开消息后，发现这是一条APP的注册邀请链接，附言是“晓儿，最近还跑步吗，试试这个。”，紧接着又蹦出一条运动记录的分享图片。有别于常见的截屏图片，这张图片是应用内部生成的，将运动轨迹、数据拼合在了同一张图上，顶部还有一张有趣的插画——看到插画她这才想起今天是夏至，看来这个应用会每天出品不同的主题图片。

这很让潘晓欣喜，她在之前使用咕咚作为跑步APP时，一度很喜欢在朋友圈分享运动记录，但每天看上去千篇一律的缩略图不仅让她自己觉得单调，甚至引起了一部分朋友的厌烦，所以她已经很久没有发过这样的截图了，这也是阿春不清楚她还有没有在跑步的原因。

简短地询问阿春后，潘晓确认了这款应用会每天更新不同的主题图片，类似Google的Doodle形式。每个赛季（即每个月）也会更新不同的月度主题图片，这让每天的使用和分享都有新的体验。

通过分享链接进入APP Store后，潘晓看了看搜索结果，领跑的评论数并不多，看起来是一个比较新的产品。但风格极简的图标却在第一眼就引起了她的好感。应用的副标题中强调了，这是一个简洁而美的应用——这无疑更让潘晓坚定了尝试使用的决心，她已经被同类产品越发臃肿的界面磨失了使用的耐心。

作为一个APP控，她轻车熟路地完成了她已经非常习惯的注册和登录流程。

而在首次登录流程中，当页面询问她是否有意报名参加下赛季时，潘晓对赛区的设定产生了兴趣。在以往使用同类应用时，身边使用同样一款应用的朋友少之又少，而陌生人方面呢，虽然应用提供了社区、IM功能，但她和其他用户之间始终处于一种“各跑各的”的状态，即使她有意结识陌生人，对方的运动也和她没有任何关联。

潘晓期待着，处于一个彼此相互关联的赛区里，或许在跑步时不会像以往那样有“踽踽独行”的感觉吧。就这样，在泳道控件中依次选择了赛区和级别后，她完成了一次充满期待的报名流程。

5.3.2 核心场景二：使用领跑——完成运动、完成赛季与分享

（1）杨鹏

经过一个月的使用，原本不熟悉运动APP的杨鹏也逐渐开始习惯于坚持跑步，无论是下午下课后，还是晚上自习回来。
今天也不例外，这是杨鹏在这个月——也就是这个赛季中的最后一次计分运动，这次运动结果上传后，官方就将在几天后公布本赛季的结果——这件事已经让他兴奋了很久。

杨鹏一边下楼，一边戴上耳机。他打开另一款音乐APP放着自己挑选的、适合运动的歌单，然后双击Home键、选择返回领跑界面后，他点击当前赛季的详情页又确认了一次自己截止上周结束后的排名——他排在11%~20%。而赛季的升降级规则中清楚地写着，要紧急下一个级别（入门级D）需要排在前10%，这样不但可以获得金奖，还可以获得升级资格。

杨鹏对计分规则已经熟记于心——只要一周坚持4次有效的运动，就可以获得100分的基础分，少一次会扣除25分。而附加分则根据每周4次有效运动的平均配速，随在赛区内的排位，由10分到0分递减。杨鹏认为这样“坚持第一，竞速其次”的设置还是有道理的，毕竟这是一款鼓励人们坚持运动的APP，而不是真的要拼死拼活地去竞速。

“我现在的得分是316”，杨鹏想，“如果想在最后一周突破进前10%的话，这周只有拿到8~10分的附加分才有机会。”这样的念头已经激励他在这周的前三次运动中每次都在刷新着自己的最好成绩。不可否认，这样类似于“天梯”的升降级制度对争强好胜的他而言，实在是让他恨不得每天都去跑步的一剂强有力的兴奋剂。

“今天也不例外！”杨鹏走出宿舍楼前，又打开朋友圈翻出朋友分享的那精致漂亮的证书。“等拿到电子证书，我一定要第一时间在朋友圈分享他的喜悦”杨鹏不禁笑了笑，不可否认这种心态有炫耀的成分，但是，成为一个更好、更健康的人，本来就是值得一个自信的人“炫耀”给朋友的事情。他咬了咬牙，随着“3、2、1”的倒计时，在路灯下的校道上向前奔去。

（2）潘晓

潘晓在洗手间飞速地换上短裤短袖后，把换下来的正装收进纸袋，放回了办公室西侧的私人储物柜里。
每天下午五点半是她固定的跑步时间——当然了，跑完步，吃完饭，回来还有月报要赶，今天大概又是末班地铁的节奏。

她习惯使用领跑已经不知不觉三个多月了，跑步也渐渐从一件“有心情、有精力”甚至“想在朋友圈发点什么证明自己的存在感”时才有念头去做的事，切实地变成了融进她生活的一种习惯。

正因为如此，考虑到自己这样下班时间不固定、经常下班已是深夜的工作特点，她开始把跑步时间改到了下午。正常下班时间过后，即使要加班，五点半到七点之间这段晚饭时间还是相对固定而且没人打扰的个人时间。

等电梯的时候，潘晓打开领跑下意识地四处翻看着。她的赛季排位还是牢牢地排在前10%，从入门级E开始的三个赛季她已经连续三个赛季升级了，如今在入门级B，已有长期夜跑历史的她在女子四公里组这个对女生而言较为“艰苦”的组别中，依然优势明显。

实际上潘晓反而不像很多使用者一样在意级别的升降和奖项，对她而言，每天把自己的运动成绩和那张精巧可爱又富有设计感的每日主题插画一起保存下来，时常翻看着自己在奔跑中度过的节气、节日和纪念日，是一件在她看来更有趣的事情。她相信，这种认真对待每一天的态度，正是这个产品，包括每日、每月主题插画的设计师想传达给使用者的。

潘晓也不像以往那样把枯燥而千篇一律的数据截屏发到朋友圈，而是输出很多天的运动结果页后，挑选其中主题插画最合她意的9张，凑齐九宫格再发朋友圈。这样既避免了引起朋友的反感和审美疲劳，也更说明她是确确实实地每天都在运动——而不是一时兴起或纯粹的炫耀。

潘晓忽然留意到“跑伴”页面右上角的消息中心有两个红点，点击后她看到其中一个是来自跑伴“白夜漫步”的声援——“明晚我从公司跑过来合江亭，希望再和你偶遇，哈哈”。她不禁一笑，点击对方的头像进入对方主页，然后回复了一句声援：“好像每个月都会偶遇一次，这个月还没偶遇过，看来明天的几率格外的大：）”。白夜漫步是在东门附近上班的一个刚毕业的小女生，两个月前她在“跑伴推荐”的“赛区跑伴”列表里忍不住加了这个频繁出现的哈士奇头像，几番闲聊，两个人发现很投缘，而且公司竟然距离这么近。当白夜漫步偶尔选择沿河边跑步时，偶尔会和潘晓遇到——这也算领跑带来的缘分一场。

潘晓返回消息中心，点开“跑伴验证”标签页，通过了一条新的跑伴申请——她只要看到头像合眼的就会通过，或许又能交到像白夜漫步这样同样热爱跑步、热爱生活的朋友呢。

潘晓走出公司所在的写字楼，穿过马路来到河边，在很好的夕阳斜照下开始了她又一天的运动。

又有多少个赛区的跑伴们，正在同样的夕阳下努力锻炼、成为更好的自己呢？潘晓一边矫健地跑动、一边微微笑着——这种和一个赛区的伙伴们一起运动的感觉，和贯彻了宣传语中“简洁而美”的设计，大概是潘晓坚持使用领跑至今最大的原因所在吧。

6 用户体验目标

结合目标用户的特征与经验、典型用户场景、用户行为，我们可以分析得出用户使用产品的体验目标，即期望得到的最终成果。领跑的核心用户体验目标可以总结为以下10点：

（1）用户需求：流畅的注册与登录流程

• 用户场景（每当）：首次下载使用本产品
• 用户行为（想要）：简洁清晰的注册流程，首次使用时必要的引导
• 用户体验目标（就能）：以最快的速度、带着必要的了解开始体验产品
• 衡量指标：注册用户数

（2）用户需求：记录运动轨迹与数据

• 用户场景（每当）：开始运动
• 用户行为（想要）：即时或在结束后了解自己的运动轨迹和数据
• 用户体验目标（就能）：增强对身体行为的了解，获得成就感
• 衡量指标：培养跑步时使用产品的习惯（提高）

（3）用户需求：运动结果的查看与分享

• 用户场景（每当）：每次运动结束
• 用户行为（想要）：了解本次运动数据，分享统计结果页面至朋友圈等
• 用户体验目标（就能）：了解本次运动结果。显示自己是一个健康、积极向上的人，受到点赞或肯定，获得满足感
• 衡量指标：单次运动结果页面的分享次数

（4）用户需求：赛季数据的查看与分享

• 用户场景（每当）：了解当前情况，希望得到更理想的名次。分享自己本月的成就至朋友圈等
• 用户行为（想要）：每周排名更新或赛季末
• 用户体验目标（就能）：获得对本月所有付出的肯定。显示自己是一个健康、积极向上、且有坚持、有始有终的，人受到点赞或肯定，获得满足感
• 衡量指标：排名、证书页面的查看次数

（5）用户需求：选择赛区与公里级别

• 用户场景（每当）：首次使用或新赛季开始前
• 用户行为（想要）：选择市区和适合自己的级别，参与一个无需较多熟人参与即可享受竞争气氛的竞赛
• 用户体验目标（就能）：有助于更好地坚持下来，并获得参与感，告别独自夜跑或只有少数熟人相互排名的孤单感
• 衡量指标：报名并坚持夜跑的次数，用户使用产品的频率和粘度

（6）用户需求：自由运动模式

• 用户场景（每当）：未来得及参加当前赛季或暂时不想参加赛季时
• 用户行为（想要）：在未参加赛季的情况下也能尽可能多地参与其中
• 用户体验目标（就能）：体验产品的特色，激发参加下赛季比赛的兴趣和热情
• 衡量指标：在非月初开始使用产品，并在本月剩下的时间体验自由跑的用户数

（7）用户需求：跑伴功能

• 用户场景（每当）：希望与熟悉的朋友在平台内互动，或结识志同道合的朋友并与之交流
• 用户行为（想要）：邀请朋友、搜索账号或通过推荐列表添加好友
• 用户体验目标（就能）：在平台内通过社交互动带来参与感和归属感
• 衡量指标：人均跑伴数量

（8）用户需求：查看历史统计

• 用户场景（每当）：参加多次自由跑或多个赛季后
• 用户行为（想要）：查看自己的历史统计数据
• 用户体验目标（就能）：由日积月累的数据得到满足感
• 衡量指标：历史统计页面的查看次数

（9）用户需求：意见反馈

• 用户场景（每当）：有建议或问题时
• 用户行为（想要）：有途径反馈自己遇到的问题和意见
• 用户体验目标（就能）：认为产品可改进、可靠
• 衡量指标：收到反馈的数目

（10）用户需求：反作弊功能

• 用户场景（每当）：阶段性结果更新（每周）或赛季排名更新（每月）
• 用户行为（想要）：确信自己的排名没有因为有人作弊而下滑
• 用户体验目标（就能）：对竞赛的公平性产生信任
• 衡量指标：用户使用产品的频率和粘度

7 关键因素分解

根据业务目标（见第4节）对用户意愿进行分析，可以得出使用产品前的动机和可能面临的担忧。而根据用户体验目标对用户行动进行分析（见第6节），则可以明确用户在使用过程中可能面对的障碍。如何创造动机、排除担忧和解决障碍，是将这三大关键因素转化为合理的设计依据的关键。

7.1 流畅的注册与登录流程
用户体验目标：以最快的速度、带着必要的了解开始体验产品

关键因素分解：

（1）动机

• 开始使用产品、成为产品的用户和服务对象
• 初步解决方案：在欢迎页结束后即要求用户注册

（2）担忧

• 是否需要注册一个使用频率未知的新产品
• 注册流程繁琐，导致放弃注册

初步解决方案：

• 在欢迎页将产品特色完整、精炼地告诉用户，吸引目标用户克服不确定感，完成注册流程
• 简化注册流程

（3）障碍

首次注册登录后对产品的特色和使用方法缺乏基本的了解

初步解决方案：

注册成功后即提供一个首次使用时才会出现的设置头像、昵称、赛季报名的流程

7.2 记录运动轨迹与数据

用户体验目标：增强对身体行为的了解，获得成就感

关键因素分解：

（1）动机

• 希望记录运动轨迹
• 希望记录自己的用时与配速等数据
• 希望可以在不查看屏幕的情况下不断获知当前的数据

初步解决方案：

1. 通过GPS功能实时记录运动轨迹
2. 实时统计配速、时速、步频等数据
3. 提示音功能，每隔一定距离播报当前用时和配速

（2）担忧

1. 在GPS没有定位准确的情况下开始运动，造成记录不准确
2. 有其他用户利用长时间的暂停功能作弊

初步解决方案：

1. 在运动开始的界面提醒用户当前GPS信号是否过弱
2. 计分运动模式下，每次暂停最多暂停1分钟

（3）障碍

1. 过于复杂的操作
2. 过马路等待红灯时影响速度记录

初步解决方案：

1. 一键开始
2. 提供暂停功能

7.3 运动结果的查看与分享

用户体验目标：了解本次运动结果。显示自己是一个健康、积极向上的人，受到点赞或肯定，获得满足感。

关键因素分解：

（1）动机

• 希望在运动结束后可以可视化地查看本次运动的数据统计
• 希望分享并收获更多的“赞”以满足被肯定的心理

初步解决方案：

1. 提供每次运动的统计页面，通过数据、图表等方式综合呈现本次运动结果
2. 在数据完善的基础上，提供尽可能美观、具有设计感的分享页面

（2）担忧

经常性的分享（或圈子里有其他人同时在分享）时导致朋友审美疲劳甚至厌烦

初步解决方案：

在分享页面提供每天不同主题的、富有趣味性的插画（参考Google Doodle）

（3）障碍

• 不便阅读或需要过多滚动才能看完完整内容
• 操作复杂，需要使用系统截图后再转至其他应用程序内发送
• 系统截图带有状态栏、底部导航栏等干扰元素，且无法在同一张截图呈现3个标签页的完整信息

初步解决方案：

1. 将轨迹、数据、图表分为3个标签页显示
2. 提供内置的分享图片生成功能，以及分享至QQ好友、微信好友、微信朋友圈和生成分享链接的直接入口
3. 内置生成用于分享的图片中，不含状态栏、导航栏等信息，且截图中将3个标签页的信息由左至右逐次拼合，从而可以完整地显示全部内容

7.4 赛季数据的查看与分享

用户体验目标：获得对本月所有付出的肯定。显示自己是一个健康、积极向上、且有坚持、有始有终的，人受到点赞或肯定，获得满足感。

关键因素分解：

（1）动机

• 了解自己的排名
• 希望晋级更高组别，或不甘心降入更低组别，以证明自己的实力
• 当获得理想的成绩时，希望分享并收获更多的“赞”以满足被肯定的心理
• 获得真实的证书的成就感

初步解决方案：

1. 将实时排名信息在开始页用尽可能醒目的布局显示
2. 在当前赛季页的排名数据下方附上鼓励性文案
3. 在应用内提供完整、高清证书图片的生成与保存功能
4. 证书页面设计得更接近用户生活经历中所习惯的证书形式

（2）担忧

• 排名不如期望，产生挫败感
• 经常性的分享（或圈子里有其他人同时在分享）时导致朋友审美疲劳甚至厌烦

初步解决方案：

1. 对排名靠后的用户不再显示详细的排位，而是只显示“后50%”这一非常宽泛的范围，以降低用户的挫败感，辅以激励性话语
2. 在赛季证书页面提供每个月不同的主题Banner

（3）障碍

• 不便阅读或需要过多滚动才能看完完整内容
• 操作复杂，需要使用系统截图后再转至其他应用程序内发送
• 系统截图带有状态栏、底部导航栏等干扰元素

初步解决方案：

1. 无需滚动即可显示全部内容
2. 提供内置的分享图片生成功能
3. 内置生成用于分享的图片中，不含状态栏、导航栏等信息

7.5 选择赛区与级别

用户体验目标：参与赛区有助于告别独自夜跑或只有少数熟人相互排名的孤单感。合适的级别有助于更好地坚持下来，并获得参与感。

关键因素分解：

（1）动机

• 参与一个赛区，让自己的运动与周边用户产生有机联系
• 选择适合自己运动量的级别，参与本月的竞赛

初步解决方案：

1. 以行政区划为基础，基本上按城市的区县划分赛区
2. 按公里数区分运动量，分为多个等级

（2）担忧

• 一时兴起或对自己的体能估计错误，选择了过高的级别，导致无法坚持
• 在选择时建议用户（尤其是首次使用的用户）选择较低的级别

（3）障碍

• 难以判断自己适合选择哪个级别
• 不清楚在选择后是否能再次更改，可能造成草率地选择

1. 给出级别选择建议
2. 明确地告知用户在选择后在本月度无法更改

7.6 自由运动模式

用户体验目标：体验产品的特色，激发参加下赛季比赛的兴趣和热情。

关键因素分解：

（1）动机

• 由于并非在月初开始使用本产品，无法参加本月竞赛，但希望体验产品特色
• 提供除不计成绩外与计分模式功能完全相同的自由运动模式

（2）担忧

• 缺少对产品主功能的参与感，与使用同类产品时没有功能上的区别，出现被排除在主要功能外的负面情绪
• 不清楚是否由于不属于计分运动，运动结果无法记录

初步解决方案：

1. 提醒用户可以通过自由模式，在赛季开始前充分热身
2. 自由运动的跑步数据可以照常保存和累计

（3）障碍

• 不清楚自己是在计分运动还是在自由运动
• 还有过久才能参与赛季，淡忘甚至放弃产品

初步解决方案：

1. 设置不同的标签页分离两种类型的入口
2. 设置赛季周期为一个月，既不会太短导致失去“赛季”的意义，又不会太长导致错失报名的用户需要等待过久

7.7 跑伴功能

用户体验目标：在平台内通过社交互动带来参与感和归属感。

关键因素分解：

（1）动机

• 希望与熟悉的朋友在平台内互动
• 希望结识志同道合的朋友并与之交流
• 希望与同一赛区的参赛者进行互动

初步解决方案：

1. 提供搜索账号添加好友的方式。
2. 提供邀请好友加入领跑的入口。
3. 随机推荐附近的跑伴或同级别的参赛者。

（2）担忧

• 担心被来路不明的陌生人打扰
• 担心需要频繁处理验证消息

初步解决方案：

1. 出现在推荐列表中的跑伴或参赛者都是有一定的运动数据积累的用户，以此筛掉大批“来意不明”的用户。
2. 在底部导航栏上不显示未读红点，只有点击“跑伴”页时，右上角的消息中心旁会出现计数红点。仅在用户有意查看时才提供未读提示给用户，避免打扰。

（3）障碍

没有在运动类应用内聊天的习惯，对即时性的聊天产生反感

初步解决方案：

只保留最基本的非即时留言功能（声援）

7.8 查看历史统计

用户体验目标：由日积月累的数据得到满足感。

关键因素分解：

（1）动机

查看自己的历史运动数据

初步解决方案：

提供历史统计页面。

（2）担忧

对间歇性使用产品的用户而言，可能疑虑是否可以按特定时间段进行数据统计，避免总体数据被空档期大量的零数据均摊，导致统计结果让其产生挫败感。

初步解决方案：

可以按周、月、年、总计等四个维度，查看总体数据或某一特定时段内的数据。

（3）障碍

历史数据过于庞杂，造成用户的信息负担

初步解决方案：

设置不同标签页，分离周、月、年、总计等不同维度的统计数据，每个页面注意设计层次感

7.9 反作弊功能

用户体验目标：对竞赛的公平性产生信任。

关键因素分解：

（1）动机

希望有一个公平的竞争环境

初步解决方案：

提供并在欢迎页强调反作弊功能

（2）担忧

1. 其他用户使用骑车、汽车作弊
2. 其他用户使用利用暂停作弊

初步解决方案：

1. 通过技术手段（包括但不限于步频判断和配速范围判断），防止骑车、汽车作弊
2. 计分运动模式下每次暂停最多1分钟，要再点击一次暂停才能继续

（3）障碍

计分运动时，不清楚每次点击只能暂停1分钟

初步解决方案：

将计分运动模式下的暂停按钮文案直接设计为“暂停1分钟”

8 用户需求清单

对第7节三大关键因素的分解结果进行汇总、整合、去重，可以将来自动机、担忧、障碍三个关键因素的用户需求清单整理如下（扩折号后为对应的初步解决方案）：
8.1 创造动机

1. 开始使用产品、成为产品的用户和服务对象——在欢迎页结束后即要求用户注册
2. 希望记录运动轨迹——通过GPS功能实时记录运动轨迹
3. 希望记录自己的用时与配速等数据——实时统计配速、时速、步频等数据
4. 希望可以在不查看屏幕的情况下不断获知当前的数据——提示音功能，每隔一定距离播报当前用时和配速
5. 希望在运动结束后可以可视化地查看本次运动的数据统计——提供每次运动的统计页面，通过数据、图表等方式综合呈现本次运动结果
6. 希望分享并收获更多的“赞”以满足被肯定的心理——在数据完善的基础上，提供尽可能美观、具有设计感的分享页面
7. 了解自己的排名——将实时排名信息在开始页用尽可能醒目的布局显示
8. 希望晋级更高组别、避免降入更低组别，以证明自己的实力——在当前赛季页的排名数据下方附上鼓励性文案
9. 当获得理想的成绩时，希望分享并收获更多的“赞”以满足被肯定的心理——在应用内提供完整、高清证书图片的生成与保存功能
10. 获得真实的证书的成就感——证书页面设计得更接近用户生活经历中所习惯的证书形式
11. 参与一个赛区，让自己的运动与周边用户产生有机联系——以行政区划为基础，基本上按城市的区县划分赛区
12. 选择适合自己运动量的级别，参与本月的竞赛——按公里数区分运动量，分为多个等级
13. 由于并非在月初开始使用本产品，无法参加本月竞赛，但希望体验产品特色——提供除不计成绩外与计分模式功能完全相同的自由运动模式
14. 希望与熟悉的朋友在平台内互动——提供搜索账号添加好友的方式
15. 希望结识志同道合的朋友并与之交流——提供邀请好友加入领跑的入口
16. 希望与同一赛区的参赛者进行互动——随机推荐附近的跑伴或同级别的参赛者
17. 查看自己的历史运动数据——提供历史统计页面
18. 希望有一个公平的竞争环境——提供并在欢迎页强调反作弊功能

8.2 排除担忧

1. 是否需要注册一个使用频率未知的新产品——在欢迎页将产品特色完整、精炼地告诉用户，吸引目标用户克服不确定感，完成注册流程
2. 注册流程繁琐，导致放弃注册——简化注册流程
3. 在GPS没有定位准确的情况下开始运动，造成记录不准确——在运动开始的界面提醒用户当前GPS信号是否过弱
4. 经常性的分享（或圈子里有其他人同时在分享）时导致朋友审美疲劳甚至厌烦——在分享页面提供每天不同主题的、富有趣味性的插画（参考Google Doodle）
5. 排名不如期望，产生挫败感——对排名靠后的用户不再显示详细的排位，而是只显示“后50%”这一非常宽泛的范围，以降低用户的挫败感，辅以激励性话语
6. 一时兴起或对自己的体能估计错误，选择了过高的级别，导致无法坚持——在选择时建议用户（尤其是首次使用的用户）选择较低的级别
7. 缺少对产品主功能的参与感，与使用同类产品时没有功能上的区别，出现被排除在主要功能外的负面情绪——提醒用户可以通过自由模式，在赛季开始前充分热身
8. 不清楚是否由于不属于计分运动，运动结果无法记录——自由运动的跑步数据可以照常保存和累计
9. 担心被来路不明的陌生人打扰——出现在推荐列表中的跑伴或参赛者都是有一定的运动数据积累的用户，以此筛掉大批“来意不明”的用户。
10. 担心需要频繁处理验证消息——在底部导航栏上不显示未读红点，只有点击“跑伴”页时，右上角的消息中心旁会出现计数红点。仅在用户有意查看时才提供未读提示给用户，避免打扰
11. 对间歇性使用产品的用户而言，可能疑虑是否可以按特定时间段进行数据统计，避免总体数据被空档期大量的零数据均摊，导致统计结果让其产生挫败感——可以按周、月、年、总计等四个维度，查看总体数据或某一特定时段内的数据。
12. 其他用户使用骑车、汽车作弊——通过技术手段（包括但不限于步频判断和配速范围判断），防止骑车、汽车作弊
13. 其他用户使用利用暂停作弊——计分运动模式下每次暂停最多1分钟，要再点击一次暂停才能继续

8.3 解决障碍

1. 首次注册登录后对产品的特色和使用方法缺乏基本的了解——注册成功后即提供一个首次使用时才会出现的设置头像、昵称、赛季报名的流程
2. 过于复杂的操作——一键开始
3. 过马路等待红灯时影响速度记录——提供暂停功能
4. 不便阅读或需要过多滚动才能看完完整内容——将轨迹、数据、图表分为3个标签页显示
5. 操作复杂，需要使用系统截图后再转至其他应用程序内发送——提供内置的分享图片生成功能，以及分享至QQ好友、微信好友、微信朋友圈和生成分享链接的直接入口
6. 系统截图带有状态栏、底部导航栏等干扰元素，且无法在同一张截图呈现3个标签页的完整信息——内置生成用于分享的图片中，不含状态栏、导航栏等信息，且截图中将3个标签页的信息由左至右逐次拼合，从而可以完整地显示全部内容
7. 不便阅读或需要过多滚动才能看完完整内容——无需滚动即可显示全部内容
8. 操作复杂，需要使用系统截图后再转至其他应用程序内发送——提供内置的分享图片生成功能
9. 系统截图带有状态栏、底部导航栏等干扰元素——内置生成用于分享的图片中，不含状态栏、导航栏等信息
10. 难以判断自己适合选择哪个级别——给出级别选择建议
11. 不清楚在选择后是否能再次更改，可能造成草率地选择——明确地告知用户在选择后在本月度无法更改
12. 不清楚自己是在计分运动还是在自由运动——设置不同的标签页分离两种类型的入口
13. 还有过久才能参与赛季，淡忘甚至放弃产品——设置赛季周期为一个月，既不会太短导致失去“赛季”的意义，又不会太长导致错失报名的用户需要等待过久。
14. 没有在运动类应用内聊天的习惯，对即时性的聊天产生反感——只保留最基本的非即时留言功能（声援）
15. 历史数据过于庞杂，造成用户的信息负担——设置不同标签页，分离周、月、年、总计等不同维度的统计数据，每个页面注意设计层次感
16. 计分运动时，不清楚每次点击只能暂停1分钟——将计分运动模式下的暂停按钮文案直接设计为“暂停1分钟”

9 体验路径分析

设计用户体验需要在体验路径的全程都能满足用户的期望，对领跑而言，我们可以将各种细微末节的流程归结为以下7个核心接触点：欢迎、注册与登录、赛季报名、运动、运动结果、赛季数据与证书、跑伴。同样的，用户的体验路径基本也可以用这7个接触点按上述顺序一一涵盖（其中“跑伴”属于主流程之外的支线，位置可能出现在注册登录完成后的任意节点，因此暂放在最后考虑）。

在需求分析的最后，本节将对这条体验路径中的惊喜和问题进行分析。以下是用户体验路径和情感坐标。

首先，对这7个接触点中用户会感受到的（与同类产品显著不同）惊喜，以及尽管已经采取相应措施，仍然可能面临的细节问题做一梳理。

接下来，针对各个接触点所面临的惊喜和问题的不同权重，判断各个接触点的情感高低并将其连接起来，进而与两个主要竞品（悦跑圈和咕咚）的情感曲线进行对比：

可以看出，领跑对冗余功能的精简可能导致习惯了使用悦跑圈、咕咚等“大而全”的应用的用户在使用之初感觉到一些不适应，尤其是对好友系统和运动过程中的体验而言。但领跑从注册和登录开始贯穿体验全程的简洁感，最具特色的赛季和证书系统，以及富有设计感的界面和每日/每月主题插画，这些特色都让我们可以期待用户在注册、登录、赛季报名、运动结果、赛季结果等接触点产生显著区别于竞品的惊喜感。并且，领跑的情绪曲线具有显著递增特点（跑伴系统独立于主路径之外，对这一结论并无影响），将带给用户一种“越用越舒服”的感受。

在信息架构、流程设计以及正式的原型设计阶段，这一结论有助于设计能够坚持特色、扬长避短，对虽然会造成一定损失但利大于弊的功能删减做到“忍痛割爱”，对凸显产品特色的惊喜点进行勇敢、胆大心细的创新。

第二卷 交互设计文档

10 信息架构设计

11 总流程图

12 交互设计文档

交互文档中将所有任务经过整理，涵盖在1.登录前流程、2.跑步流程、3.社交流程、4.赛季流程、5.用户资料流程、6.设置流程共6个大流程、24个子流程中。并在文档中以子流程为单位，逐一清晰地传达了完成每个具体任务的交互方式。

这里展示的交互文档以0.12版为准，已包含了0.10、0.11版后可用性测试的整改结果

（注：0.12版本后因项目与交流原因，交互文档采用英文撰写）

12.1 登录前流程

12.2 跑步流程

12.3 社交流程

12.4 赛季流程

12.5 用户资料流程

12.6 设置流程

12.7 通用交互说明

第三卷 可用性测试

13 报告综述

评估对象：使用领跑0.10版本原型页面作为测试对象。

研究目的：了解领跑当前版本（0.10）的设计是否符合用户使用习惯，页面布局与交互逻辑是否会造成用户的使用障碍。

关注点：

1. 产品整体感知：用户对领跑初次使用的体验、印象，以及整体满意度；
2. 用户在使用领跑过程中的情绪曲线是否与设计时的分析结果和目的相符；
3. 信息架构与跳转逻辑：页面跳转逻辑是否让用户操作自如，并清除自己每步操作的后果；用户对整个站点的信息架构是否存在理解障碍或较高的学习成本。
4. 页面布局与界面设计：目前设计的页面排布是否合理，界面设计是否规范合理、具有一致性、能提供舒适的交互体验，操作含义是否明晰，用户对每步操作的理解会不会存在歧义或偏差。
5. 有运动类APP使用经验的用户在使用领跑时，操作是否顺畅，是否符合其使用同类产品的习惯。
6. 研究方法：可用性测试。
7. 执行概述：本测试的执行时间为2016年7月27日至7月30日，共4位典型用户参与了评估。

14 评估方案

14.1 用户资料

典型用户定义（详见需求分析报告第5节）：20~35岁之间的大学生或职员，年轻，勇于也乐于参与竞争，喜欢新事物，热衷社交，有运动热情，有一定的互联网产品使用经验，对跑步类APP（或运动手环等同类产品）有一定的使用经验或了解。

招募方式：朋友推荐。

招募要求：

1. 20~35岁之间。
2. 使用iPhone作为主要的通讯设备。
3. 有运动类APP使用经验的用户要求使用过咕咚、悦跑圈、虎扑跑步、Nike Running、Feel、动动、Runkeeper等运动记录类APP中的一种或多种，尝试过的种类越多越好。
4. 无运动类APP使用经验的用户要求对iOS端互联网产品有一定的熟悉度，熟悉程度越高越好。
5. 样本配比：根据领跑用户的典型特征并结合可用性测试评估的特点，最终确定了4位典型用户。包括2位有运动类APP使用经验的用户（以下简称：有经验用户）和2位无运动类APP使用经验的用户（以下简称：无经验用户）。有经验用户和无经验用户各招募1名学生用户和1名在职用户。

14.2 经费预算

40元/人。

14.3 项目计划

14.4 调研人员

主持人：董佳奇

记录人：董佳奇

14.5 测试执行计划

1. 暖场(3min)，简单聊天，消除用户紧张情绪
2. 测试说明(2min)，对测试内容、规则做说明
3. 测试前访谈(10min)，了解用户基本信息
4. 简单试用(3min)，让用户熟悉产品
5. 测试执行(35-45min)，提示任务并观察
6. 测试后访谈(15min)，针对疑问点进行追问，填写评价表
7. 道别(5min),感谢用户，与用户道别

注：场地安排——线上进行。

14.6 测试脚本

14.6.1 任务一：注册与登录

场景：周末的一天，你看到朋友的分享链接后对领跑产生了兴趣，希望通过领跑开始（/重拾/或进一步加强）跑步的习惯。

关注点：

• 用户能否从欢迎页了解到产品的特色
• 用户能否顺畅地完成注册和登录
• 用户是否能清晰地完成首次登录后的用户资料设置和赛区、组别选择流程

任务操作路径：

1. 进入欢迎页（闪屏）
2. 点击屏幕任意位置或等待3s后依次进入3张首次使用欢迎页
3. 进入登录页
4. 完成注册流程
5. 完成首次登录后的引导流程，包括用户资料设置和赛区、组别选择
6. 进入开始页

• 开始状态：欢迎页
• 结束状态：开始页

14.6.2 任务二：完成一次运动

场景：今天是月初的第一个星期一，也是你参加的新赛季的第一个比赛周，你决定下班后开始第一次计分运动，你认为今天的主题插画很有趣，决定在跑完后把运动结果分享给你最好的朋友。

关注点：

1. 用户能否找到将自由运动模式切换为计分运动模式的方式。
2. 用户能否顺利地完成运动设置，并开始一次运动。
3. 用户是否知道如何暂停和结束一次运动。
4. 用户能否顺利地切换标签页，以查看完整的运动结果信息。
5. 用户能否顺利地将运动结果分享给一个微信好友（使用应用内置的功能生成完整版图片，而不是手机截屏）。

任务操作路径：

1. 进入开始页（当前运动模式为自由运动）
2. 将运动模式切换为计分运动。
3. 进入本次运动设置页面确认设置。
4. 返回开始页，点击开始按钮，开始运动。
5. 完成一次运动，期间暂停一次。
6. 在运动结果页面切换至数据和图表标签页，再返回轨迹标签页。
7. 将运动结果分享给一个微信好友（使用应用内置的功能生成完整版图片，而不是手机截屏）。
8. 返回领跑（运动结果页）。

• 开始状态：开始页
• 结束状态：运动结果页

14.6.3 任务三：查看并分享你的赛季证书

场景：终于等到了期待已久的赛季最后一个星期天晚上，证书在晚上22:00准时发放，你获得了当前级别的前10%——也就是金奖和升级名额，你迫不及待地要将精美的证书分享到朋友圈。

关注点：

• 用户能否找到查看赛季证书的入口。
• 用户能否顺利地将证书高清版大图保存至手机。
• 用户是否顺利地将运动结果分享到微信朋友圈（使用应用内置的功能生成完整版图片，而不是手机截屏）。

任务操作路径：

1. 进入开始页
2. 进入赛季页
3. 由用户自由选择，通过赛季页或“我的”页面进入 “我的证书”页
4. 进入当前赛季的证书页面。
5. 将证书高清大图保存至手机。
6. 将证书分享到微信朋友圈。
7. 返回领跑（证书详情页）。

• 开始状态：开始页
• 结束状态：证书详情页

14.6.4 任务四：添加和声援跑伴

场景：你无意中看了一眼自己冷清的跑伴列表，觉得是时候添加几个跑伴了。你首先想到了经你邀请加入跑伴的好友小君，你也知道他的昵称，通过搜索功能应该就很容易找到他。加了小君后，你还想结识一些同赛区、同级别的“战友”。顺便，你还想给老同学老蔡发一条声援寒暄一下。同时，你看到了有几条申请加你为跑伴的未读验证消息，你决定全部通过。

关注点：

1. 用户能否找到搜索昵称查看用户的入口。
2. 用户能否通过搜索结果，顺利地向目标用户发送验证请求。
3. 用户是否知道怎样找到同赛季、同级别参赛者的推荐列表。
4. 用户能否顺利地通过推荐列表，向想添加的用户发送验证。
5. 用户是否能顺利地向跑伴发送声援消息。

任务操作路径：

1. 进入开始页
2. 进入跑伴页
3. 进入“新的跑伴”页
4. 搜索昵称“君_1989”
5. 进入小君的用户主页，点击添加跑伴按钮。
6. 编辑并发送验证消息。
7. 返回“新的跑伴”页
8. 进入“同级跑伴”标签页
9. 进入推荐列表第二个用户的主页，点击添加跑伴按钮。
10. 编辑并发送验证消息。
11. 返回跑伴页，在跑伴列表中找到老蔡的头像。
12. 进入老蔡的用户主页，点击声援按钮。
13. 编辑并发送声援内容。
14. 返回跑伴页，进入消息中心。
15. 在“跑伴验证”标签页通过所有新收到的验证申请。
16. 返回跑伴页。

• 开始状态：开始页
• 结束状态：跑伴页

14.7 测试后访谈

我注意到您(操作/表现)，您为什么会这样操作(原因)？您觉得理想的应该是怎样的(评价、建议）？

SUS量表：整体测试结束后，邀请用户根据对产品试用的体验在下面的陈述上进行评分。“1”代表完全不赞同，“3”代表既不赞同，也不反对，“5”代表非常赞同。

15 测试结果

15.1 总体评价

15.1.1 有经验用户

正面评价：

1. 具有鲜明的特色，赛季系统亮点突出，在同类产品中辨识度高
2. 简洁小巧
3. 期待有机会使用

负面评价：

1. 主题插画和简洁的设计是把双刃剑，在赋予产品美感的同时，可能造成产品艺术性过强，与运动的主题不确定能否恰当地融合（需要到视觉设计阶段才能判断）
2. 部分交互可用性问题（见15.3节）。

15.1.2 无经验用户

正面评价：

1. 赛季的升降级系统是个让人有意愿尝试的激励手段
2. 界面规范，使用起来上手应该比较快
3. 期待每日/每月主题插画以及简洁而美的设计这一理念贯彻到实际UI中的效果

负面评价：

1. 需要在迭代中收集名次不理想的用户的反馈，长期名次靠后甚至降级产生的负面情绪如何引导和转化为激励，是一个必须面对的问题。
2. 部分交互可用性问题（见15.3节）。

15.2 SUS量表反馈

1. 我认为我会愿意经常使用领跑：3.3
2. 我发现领跑没必要这么复杂：1.3
3. 我认为领跑容易使用：3.5
4. 我认为我会需要技术人员的支持才能使用领跑：2.0
5. 我发现领跑中的不同功能可以被较好地整合在一起：2.8
6. 我认为领跑太不一致了：2.0
7. 我以为大部分人会很快学会使用领跑：3.8
8. 我发现领跑使用起来非常笨拙：1.8
9. 对于使用领跑，我感到很自信：3.5
10. 在我可以使用领跑之前，我需要学习很多东西：2.8

15.3 可用性问题

在自由熟悉应用、按脚本完成任务的过程中，我们发现了一系列可用性方面的细节问题。其中，有较多页面存在性质相同的问题，可以归结为同一类典型可用性问题。经过合并、整理，在本次可用性测试中发现的典型可用性问题共有以下7个大类：

1. 信息冗余，影响层级清晰度
2. 信息密度过高影响可读性
3. 缺少必要的快捷跳转入口
4. 需要默认值的表单中没有提供默认选项或默认文案
5. 存在必要性不大的确认对话框
6. 垂直列表缺乏适当的分组
7. 链接文本没有清晰地告知用户跳转去向
   以下将对7类问题各取一个最典型的页面进行举例分析。另外，在可用性测试完成后，我已立即对测试中提出的问题根据修改建议进行了逐一处理（作为最终提交的原型版本0.11），以下的分析中，将同时列出修改建议和处理方案。

15.3.1 可用性问题例析1

页面：开始页

元素：运动模式Tab项

截屏：

可用性问题：信息冗余，影响层级清晰度

问题重要程度：2

问题分析：标签页的形式作为在两个彼此完全独立（在看到A的时候不需要看到B的入口）的元素之间的切换方式不是很合适，且容易造成页面的层级不清，用户不清楚哪些元素会随着标签页的切换而变得不同、哪些会保持一致。

建议与处理结果：已在0.11版本修改为更简洁、清晰的箭头（或滑动）切换。

15.3.2 可用性问题例析2

页面：运动结果页-分享页

元素：用于分享的拼合版图片（及其预览图）

截屏：

可用性问题：信息密度过高，影响可读性

问题重要程度：4

问题分析：在用于分享的图片中汇集了轨迹、数据、图表信息，虽然全面完整，但考虑到实际分享后的图片尺寸和视觉效果，评委认为在这样尺寸的图片中图表信息是根本看不清的，存在是一种对空间的浪费，同时造成了数据信息的空间被压缩，原本可以显示清晰的数据因此同样变得有可能看不清。

建议与处理结果：已在0.11版本将图表从图片中去除，仅保留轨迹和数据。

15.3.3 可用性问题例析3

页面：开始页

元素：去往新获得证书页面的快捷入口（缺少）

截屏：

可用性问题：缺少去往新获得证书页面的快捷入口

问题重要程度：4

问题分析：正常状态下，查看已获得的证书信息的路径是：①赛季-我的证书-证书详情，或②我的-我的证书-证书详情。而当一个赛季结束，用户获得了新证书的时候，0.10版本并没有显式的提示告知用户，用户需要不断重复上述步骤查看证书列表，才能确认是否收到了新的证书。

建议与处理结果：已在0.11版本补充了浮窗提示：

当一个赛季结束后若干天，证书发布后，登录时如果收到上赛季的证书，则在屏幕中心弹出悬窗（外部加60%黑色遮罩），点击“稍后再看”按钮后，浮窗消失，不进行跳转。点击“前往查看”按钮后，跳转至该证书的详情页。

15.3.4 可用性问题例析4

页面：“加为跑伴”页

元素：验证消息输入框

截屏：

可用性问题：没有提供默认文案

问题重要程度：3

问题分析：对验证消息这一多数用户不愿意重复进行过多输入（尤其是从推荐列表添加多个跑伴时）、且输入内容的主题基本一致的字段，应当提供默认文案，减少用户重复输入，避免引起用户烦躁。

建议与处理结果：已在0.11版本中的验证消息输入框提供了默认文案：

15.3.5 可用性问题例析5

页面：“消息中心”页

元素：通过验证时的确认对话框

截屏：

可用性问题：存在必要性不大的确认对话框

问题重要程度：2

问题分析：“适度的反馈是可以的，但弹出一个注定要被关闭的对话框没有必要。确认对话框显示了软件没有自信对操作承担责任。”——《About Face》

建议与处理结果：已在0.11版本中取消了这一确认过程，点击“通过”后即直接通过验证申请。

15.3.6 可用性问题例析6

页面：“下一赛季”页

元素：垂直列表

截屏：

可用性问题：垂直列表缺乏适当的分组

问题重要程度：4

问题分析：垂直列表同一区块信息密度过大，没有适当的层级结构，让评委认为可读性较差。

建议与处理结果：已在0.11版本中将多个不同类型的信息分块显示（其余多个存在类似问题的页面也做出了相应的修改，如下面右图的“个人信息”页）。

15.3.7 可用性问题例析7

页面：首次登录设置流程-马上开始

元素：规则详情跳转链接

截屏：

可用性问题：“详情”链接跳转目的地不明确

问题重要程度：4

问题分析：用户不了解“详情”的跳转目的，对自己点击后的去向心里没数。

建议与处理结果：已在0.11版本中将该链接文本改为“了解详细的计分与升级规则”。

 

作者：Qinsman，通信行业UE设计师，微信公众号：西市馒头铺子。博客：http://qinsman.com/，欢迎大家与我交流。

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