1. 为什么适老化测试不能照搬普通可用性测试先说一个我印象特别深的场景。前两年我参与过一个医疗类App的改版项目产品经理拿着后台数据说我们的用户里50岁以上占了快四成但是投诉率最高、流失率也最高的人群恰恰就是这批人。当时团队的第一反应是把字体调大、按钮做宽觉得这样就算适老化了。结果上线之后老年用户的投诉不降反升后来我们找了几位叔叔阿姨来做现场访谈才发现问题远不止字太小这么简单。有个阿姨说了句话特别戳我她说你们这个手机上的东西我按它它不说话我就不知道它到底听见没有。这句话让我意识到适老化测试跟普通可用性测试完全是两码事。老年人的认知习惯、操作经验、心理预期都跟年轻用户不一样你拿一套面向互联网原住民的测试方法去测他们测出来的数据根本没有参考价值。所谓适老化移动应用界面易用性测试核心不是测这个界面好不好看而是测这个界面在真实老年用户手里能不能被理解、能不能被操作、能不能在出错之后自己找回来。普通可用性测试关注的是效率和完成率适老化测试关注的是最低门槛下的可用性和出错后的恢复能力。这两者的测试指标、任务设计、执行方式都不一样。这篇文章我会系统性拆解一套经得起推敲的适老化界面易用性测试体系从测试对象、指标维度、任务设计、执行流程到实施策略结合我实际跑过的项目经验和踩过的坑尽量给你一条可以直接落地的路径。不管你是产品经理、交互设计师、测试工程师还是在做移动应用开发大作业的大学生这套方法都能让你在面对适老化三个字的时候不再只知道改字号。1.1 先搞清楚一个根本问题适老化测试到底在测什么很多人一提适老化就想到无障碍规范比如WCAG 2.1、无障碍设计指南之类的东西。但规范这种东西本质上是底线而不是标准。你照着规范把对比度调高了、触摸区域加大了只能说明技术上达标了不能说明老年用户真的会用。我习惯把适老化测试要测的东西分成三个层级第一层是感知层也就是看不看得清、听不听得见。字号、对比度、图标辨识度、语音反馈是否清晰这些都在这一层。第二层是认知层也就是理不理解。界面上的按钮叫什么名字、图标表达什么意思、操作流程是否符合老年人的生活经验。这一层是适老化测试跟普通可用性测试差异最大的一层。年轻人看到我的就明白那是个人中心老年人可能觉得我的是个没有什么实际含义的字。第三层是操作层也就是按不按得动、点不点得准。包括按钮尺寸、滑动手势、输入框弹出键盘的交互方式、误触后的撤销路径等。一套合格的适老化测试体系必须三个层级全覆盖缺一个都会出问题。我见过很多团队测完了感知层就宣布我们适老化做完了结果老年用户连返回按钮都找不到因为那个返回手势是向右滑动屏幕边缘——这个手势对60岁以上、没有鼠标操作经验的人来说几乎是不可能自发学会的。1.2 老年用户画像不是年纪大了一句话就能概括的这个问题经常被团队忽略但又特别关键。55岁和75岁的用户虽然在老年这个范畴里但他们的数字化经验、身体机能、学习能力有着巨大差异。我一般是这么拆的55-64岁我叫它数字移民活跃期。这批人很多还在工作或者刚退休有较多触网经验会主动用微信、刷短视频甚至会用线上支付。他们对App的基本逻辑是有一点概念的但仅限于微信式操作逻辑。遇到跟微信不一样的交互方式照样会卡住。65-74岁我叫它数字被动期。这批人通常有智能手机但绝大多数功能是被子女、朋友被动教会使用的。他们能完成特定操作但换一个入口就懵。比如他会在微信里发语音但如果你告诉他用这个App也能发语音他会下意识问怎么跟微信不一样。75岁以上我叫它数字隔离期。这批人很多还在使用老年机或者刚接触智能手机不久。他们对触摸屏的理解都很薄弱不知道点击和长按的区别更理解不了滑动切换这种抽象交互。所以你在搭测试体系的时候第一步不是选工具而是确定你到底要服务哪一类老年用户。这直接决定了你的招募标准、任务难度、辅助方式甚至数据校验方法。一个75岁用户测出来的失败数据不代表你55岁用户也会失败反过来也一样。2. 测试体系架构从指标定义到任务设计一套完整的可复用测试体系我认为至少包含四个模块测试角色定义、量化指标体系、测试任务设计、执行环境准备。这四个模块是层层递进的关系你先把它们搭清楚了后面真正执行的时候才不会手忙脚乱。2.1 角色定义必须要有双重视角我在实际项目中一般会给测试团队设置两个角色一个叫观察记录员负责记录用户的行为路径、犹豫点、出错点记录方式可以是标准的操作日志表加录屏。另一个叫引导陪测员负责在测试过程中跟用户交流发出口头提示观察用户的反应。这两个角色必须分开不能是同一个人。原因是引导陪测员需要把大量注意力放在用户身上如果同时还要记录数据几乎必定会漏掉关键信息。我在一次测试中让同一个人既引导又记录结果用户在一个确认弹窗上停顿了将近40秒引导员光顾着记纪要了没注意到用户的手一直在屏幕上方悬着不敢按下去这个信息后来复盘的时候完全丢了。专家走查视角我也建议保留。在真实用户测试之前让交互设计师或者有经验的测试专家先按任务清单走一遍提前排查掉那些明显有问题的硬伤。明显有问题的硬伤包括按钮小于44x44ptApple HIG推荐的最小触摸目标文字对比度低于4.5:1页面上同时存在多个相似图标操作后没有任何反馈无震动、无声、无状态变化引导文案使用了专业术语或者中英文混排这个步骤能帮你把宝贵的时间留给真实用户去暴露深层次问题而不是花在那些一眼就能看出来的低级Bug上。2.2 量化指标别只盯着完成率很多团队做可用性测试只看一个指标任务是否完成。这个指标对年轻用户还可以但对老年用户远远不够。你想一个年轻人如果没完成任务多半是功能本身有问题但老年人没完成任务可能性就多了可能是没找到入口可能是找到了但不敢点可能是点了但没意识到自己已经点成功了还可能是操作太快误触了。如果你只记录完成/未完成两个值这些信息就全丢了。我常用的指标体系是这样的按优先级排指标定义数据获取方式说明任务完成率用户独立完成任务的比例行为观察录屏不区分独立完成和在辅助下完成辅助依赖度用户完成任务过程中需要陪测员口头提示的次数现场记录这个指标很多团队不做但我强烈建议做因为它是衡量界面自解释能力的直接体现操作效率用户完成任务的实际耗时与专家估算耗时的比值录屏计时老年用户通常会是专家耗时的2到5倍超过5倍说明流程不符合认知惯性错误恢复率用户出错后能否自行回到正确路径行为观察这个指标最有价值也要单独记录主观满意度用户完成任务后的主观感受SUS量表或简化版标准SUS对老年人不够友好建议用简化版本关于SUSSystem Usability Scale量表原版的10个题目、5级李克特计分很多老年人做起来很吃力。我试过不少次遇到的情况基本是老人对我觉得这个系统没必要这么复杂这种反向题目完全反应不过来会直接回答说我不懂你在问什么。我后来都是把SUS改成三档满意、一般、不满意同时把反向题全部去掉反而能拿到更真实的数据。你要是做学术研究、必须用标准SUS那你也最好把每道题都用口语解释一遍否则数据可信度存疑。2.3 任务设计要从真实场景出发不要从功能清单出发这是我在跟很多团队协作时反复强调的一点。你说测试一下支付功能这个指令对测试执行人员太抽象了。你要设计成一个具体的任务假设你想在网上买个药你打算用微信支付它请帮我完成付款。这个任务里包含了入口查找、商品确认、支付方式选择、密码输入、结果确认多个环节一次就能测出整条链路的适老化水平。任务难度要分层一般分三档简单任务单步操作比如找到首页上的我的入口。这类任务主要测感知层。中等任务2到3步连续操作比如找到你昨天的挂号记录。这类任务主要测认知层和基本流程理解。复杂任务完整业务流程比如预约下周二的专家门诊并且收到确认通知。这类任务用来测综合体验。每档任务最好准备2到3个方便轮换防止上一个任务的操作路径给下一个任务提供了提示。还有一点任务描述不要用App内的专业术语要用老年人能理解的生活语言。你问请点击右上角搜索图标不如说你想找高血压这个病有哪些注意事项想办法在这个手机上查一查。前者是在测图标识别能力后者才是测真实使用场景下的可达性。2.4 执行环境设备、地点和记录方式都有讲究老年人的测试环境不能随便找个会议室就行。普通人可能觉得这是个小事但实际上对测试结果影响巨大。我踩过的坑是有一回在一个有空调外机噪音的房间里测试老年用户本来就听力下降语音提示基本没听到导致连续多次操作失败。后来一看数据有一项任务的失败率100%我还以为是大问题复盘才发现是环境噪音干扰。所以执行环境的控制一定要注意用老年人熟悉的真机不要用测试机不要用模拟器。很多老年人对不是自己的手机有种天然的距离感操作会变得更犹豫。场地保持安静建议配备收音设备。如果做语音记录还要提前确认录音设备的拾音范围。手机亮度、字号、系统设置要统一避免因为系统设置不同造成数据偏差。最好有外接的录屏工具或者用手机自带录屏功能方便后续回放标注。如果条件允许给测试机贴一块防眩光膜。老年人对屏幕反光很敏感光线稍强就会看不清。这个细节在很多正式报告里不会写但对实际执行效果影响明显。3. 核心流程拆解一场适老化测试的完整实操实录下面我完整拆解一次测试的执行过程。这是我用一套标准流程跑过的活动类App适老化测试这里把关键的实操细节和当时的处理方式都记录下来。3.1 测试前准备招募、筛选和预沟通招募老年用户这件事难度比想象中大得多。你不能在普通问卷调查平台上随便发个链接因为能自己点开链接完成问卷的老年人本身就已经是数字能力达标的用户了你的样本会有严重偏差。我更常用的招募渠道社区居委会、老年大学、老干部活动中心通过工作人员协助招募已有老年用户群让客服人员在电话回访时邀请线下门店、药店、体检中心通过现场扫码招募并赠送小礼品筛选的时候我通常会问几个关键问题您现在每天用手机的时长大概是多少您会用微信视频通话吗您会自己下载App吗这些问题能快速给用户分层避免把数字隔离期的老人安排去做需要基础数字素养的复杂测试。每场测试建议安排6到8名用户这基本能达到测试饱和点——再多的用户也很难暴露新问题了。测试前一天要给用户打个电话确认到场时间同时提醒携带老花镜或助听器。这个细节一定要做很多老年人觉得我这个状态还行不愿意戴老花镜到了现场又看不清屏幕直接影响数据有效性。正式开始之前要给用户讲清楚整个测试的流程和规则。重点强调三句话这不是在考您是在考这个软件好不好用您遇到任何困难都不是您的错是软件的问题您随时可以停下来休息这三句话看起来不起眼但实际效果非常好。很多老年用户一开始紧张得手都在抖说完这些话之后就放松多了能更真实地暴露操作问题。3.2 操作过程中的观察策略什么该记、什么该问这次测试中我印象最深的是一位65岁的退休教师。她在完成预约挂号这个任务时连续五次滑动预约时间列表都没有成功因为她的手速太快、滑动力度太大每次都直接跳过了目标日期。当时陪测员观察到她的表情已经出现了明显的沮丧甚至叹了口气说哎呀我这脑子不行了。陪测员第一时间介入说了句不是您的问题是这软件滑动太灵敏了我们记录一下这个问题。然后在她情绪平复后让她再试一次并换了种滑动方式果然成功了。这个案例中有两个关键观察点值得你注意第一仅仅记录失败是不够的要记录失败时的策略。这位老师不是不努力她反复尝试了5次而且每次滑动力度在减小说明她在主动调整策略。这种用户自发调整行为的信息直接指向了滑动手势的参数设置不当。第二情绪信号是极其重要的边缘数据。你不需要专业的心理学背景只要留心用户的叹气、皱眉、放下手机等动作就够了。一旦出现明显的挫败情绪陪测员要立刻介入做情绪安抚防止用户因为自尊心受挫而放弃参与甚至产生我真的老了、不行了的负面自我评价。这不仅是测试伦理问题也是保证后续数据有效性的重要措施。我不会要求观察记录员记录每一秒的行动那会导致关键信息被噪音淹没。我一般给记录员一个标准化的记录模板包含这几个字段任务编号、用户动作、页面停留点、是否出现犹豫犹豫时长、是否出现误操作误操作内容、是否需要提示提示内容、情绪反应。为了节省时间我还给动作类型设了代码比如V顺利点击P页面切换D犹豫超过10秒E错误操作A求助这样记录员只用填代码加简单备注就行。3.3 任务结束后尽量做一次回放式访谈任务做完之后立刻带着用户一起回看录屏这个环节的价值比很多人想象得大。普通可用性测试可能做完问卷就让人走了但适老化测试中用户在做任务时的很多操作是自动化的你问他刚才你为什么点那里他往往答不上来。回放录屏就不一样每看到一个具体动作就能唤醒用户的记忆。我在一次测试回放时问一位72岁的用户您刚才为什么在这个页面上停了很久他说我在找返回但是我看到下面有个话费充值的按钮我以为点那个能回上一页。这个信息如果不做回放式访谈根本拿不到——它说明用户把底部导航栏误解成了路径指引栏。这种认知错位在数据上可能就表现为任务失败但只有访谈才能知道失败的具体原因而这恰恰是改版设计最需要的输入。回放式访谈要注意时长控制。老年用户的体力一般一场测试加上访谈总时长最好控制在40到50分钟以内超过这个时间用户的注意力就开始明显下降。如果任务多就分成两场做不要贪多。访谈结束后还要给用户准备一份简单的感谢礼。这不仅是基本礼貌也是维持社区、老年大学招募渠道长期合作的关键。别小看这个细节愿意来参加测试的老年人回到群体里会把被尊重、被倾听的感受传播出去下次招募就会顺利得多。3.4 数据的整理与问题分级测试完成后把录屏、记录表、问卷数据汇总到一起需要做一个去重和归并同一个用户在同一页面上的多次误操作记为1条问题记录但3次发生不同用户在同一页面出现同样的操作困惑单个记录合并为同类问题并统计频次。然后按严重程度×影响频次把问题分成四个级别P0必须修复老年人完全无法理解或无法操作任务无法完成。比如一个关闭弹窗的按钮面积过小导致用户反复点错或者付款页面的确认按钮在取消按钮旁边非常容易误触都会导致用户直接卡住。这类问题在去重后哪怕只出现1次也应该强烈建议修复。P1强烈建议修复操作能完成但是需要依赖额外的辅助提示或者用户会明显犹豫超过30秒。比如连续滑动翻页这个手势在没有任何引导的情况下60岁以上用户有一半以上不知道能滑动必须当成刻不容缓的问题处理。P2建议优化任务能完成但用户操作路径跟设计预期不一致或者效率明显偏低。这类问题不一定影响完成但会让老年用户产生我不太会用的挫败感。P3可暂缓体验细节不够完美但影响不大比如某个图标的颜色不够醒目但用户通过文字标签还是能识别出来。我在实际做报告时每个问题条目会附带问题描述、截图或录屏片段、影响数据涉及人数、占比、用户原话引用、修改建议、优先级。这样一来产品、设计、研发拿到报告就能直接干活儿不用再问这个问题到底有多严重。4. 实施策略小团队怎么把测试做成可持续的流程很多团队做适老化测试是一次性的项目上线前赶个工期做了几场就交差。这套做法的最大问题是测完的问题改没改、改了之后有没有引入新问题没有人跟进整个测试过程的价值就被打了一半折扣。所以我想单独聊聊实施策略的问题——怎么把测试从一个活动变成一个流程。4.1 资源有限的团队用轻量式测试起步如果你所在的团队没有专门的用研岗位或者经费有限不要一上来就搞大而全的可用性实验室。我建议你从轻量式开始核心思路是每次小步快跑、只测关键任务、积累少量但可信的数据。具体做法是这样的每个月抽一个下午邀请3到4位符合目标画像的老年用户来到公司或社区活动室用一台手机加一个手机支架花1个小时完成2到3个核心任务的测试。不需要眼动仪、不需要专业实验室只要你坚持做半年积累下来的数据就足够支撑你判断界面改版方向对不对。轻量式测试的关键是快速反馈闭环。测试当天晚上就可以整理出问题清单第二天跟产品、设计团队过一遍确定下一迭代改什么。这里有个常见问题测试完经常出现问题报告很好但排期排不上的情况。我的处理方法是在每次迭代计划会上把P0和P1级别的问题作为必须排入的项而不是建议排入。测试数据已经在手上就没有理由等到下个版本再说。如果你发现自己写的测试报告经常不能被研发团队接受大概率不是研发不愿意改而是你的报告只说了体验不好没有说清楚有多少用户受影响、对关键业务指标有什么影响。你把这两个点说透优先级自然就上来了。4.2 别忽略对照测试改版前后都要测我见过很多团队只测改版后的版本对改版前的版本已经完全没有数据记录导致后续复盘时根本没法量化说这次改版到底提升了多少。所以从搭测试体系的第一天开始就要建立一个原则改版前先测一次改版后再测一次用同一套任务和指标做对照。这样做还有一个额外的好处你可以计算出适老化改造的投入产出比。比如改版前完成率是40%改版后是75%这个35%的提升就能作为团队的成果展示也为后续争取更多适老化投入提供了依据。数据驱动的说服力永远比我觉得这样更好用要强得多。当然对照测试有一个隐含的坑如果两次测试用的用户不是同一批组间差异可能会干扰结论。我的处理方式是尽量招募背景相似年龄、触网经验、教育水平接近的用户并把用户的基本背景信息作为报告的附件。招募不到完全同质用户的时候就在报告里明说这个局限性不要藏着掖着。4.3 把测试结果翻译成团队成员能听懂的话这个点我觉得值得单独拿出来讲。做测试的人容易有一种我测了就该改的心态但产品经理关注的核心是这个改动对用户留存和业务转化有什么价值研发关注的是这个改动的工作量有多大、会不会影响现有架构设计师关注的是具体改到什么程度才算到位。同样的测试数据对不同角色要给出不同的包装。对产品经理我用一句话从根本上说明问题参与测试的8位老年用户中有6位在支付环节失败如果这个比例在真实用户中成立可能意味着每天有超过XX笔订单流失。这个数据一摆出来产品经理自己就会去推动排期。对研发我把问题精确到具体的组件和交互逻辑。我不会只说滑动不好用而是告诉他该界面使用的ViewPager滑动灵敏度对老年人不友好建议在RecyclerView的滑动监听中增加灵敏度调节或者改为按钮翻页。这样研发不用做二次排查可以直接干活。对设计师我会附上用户实际操作路径和设计路径的对比图让他们看到真实用户是怎么走的以及跟预期的偏差在哪里。视觉上的好看和适老经常有矛盾而测试数据是最好的裁判。5. 常见问题与避坑指南以下问题是我在多年适老化测试项目中反复遇到过的整理出来给朋友们做个速查。5.1 老年人不愿意说出真实感受怎么办这个现象太常见了。中国老年人普遍有不给别人添麻烦的心理在测试过程中即使遇到困难也倾向于自己忍着不愿意主动说。甚至在被问到好用吗的时候为了顾全面子还会回答挺好的。这个群体效应如果处理不好你的满意度数据会严重失真。我的应对策略是这样的把满意度这个抽象提问变成具体行为提问。比如不问他你觉得好用吗而是问如果这个App可以不用花钱你会愿意装到你自己手机上吗或者你会推荐给你老伴用吗。行为倾向比态度评价更接近真实心理。另外我会在正式访谈前建立一个安全关系——让用户知道他的意见是被真心欢迎的不是来配合检查的。语气和身体语言比问题本身更重要。还有一种情况是老年人习惯性夸奖年轻人觉得你做的东西很辛苦不好意思批评。我的方法是在访谈中故意给一个反向示范上次有一个阿姨跟我说这个App很难用她女儿也这么觉得你怎么看这种第三方故事的引入常常能让用户放下心理包袱开始表达真实的负面感受。5.2 测试执行过程中老人突然情绪崩溃怎么办我遇到过不止一次。尤其是在涉及到线上支付医疗挂号等跟钱、健康相关的敏感任务时老人因为担心按错造成损失会非常紧张严重时会直接拒绝继续操作。这时候最重要的是先处理情绪再处理任务。陪测员必须先停下来把手机从用户面前移开陪用户聊几句家常或者让用户喝口水、休息一下。等情绪稳定后再征询用户是否愿意继续不愿意就直接终止绝对不能为了凑任务数据而强迫用户完成。同时在后续数据标注中把该用户这次任务标记为因情绪因素终止不计入完成率统计单独保留观察笔记。5.3 老人假装会用怎么识别这个现象特别迷惑性。有些老人为了证明自己还行会假装理解操作界面。常见表现是手指在屏幕上比划但迟迟不落下、嘴里念叨着对对对我看到了但手指没有进行实质操作、表情明显紧张但嘴上说不难。识别的方法是做即时追问用户一旦说我看到了但没操作立刻问他你看到的是什么能帮我点一下吗。这个方法很温和不会伤害用户自尊同时能判断他是不是真的理解了。还有观察手指的悬停位置也有用如果手指频繁在非可点击区域晃动说明用户很可能是在猜而不是真的知道该点哪里。5.4 测试数据跟预期完全相反有一次我们测一款金融App的适老化改造版本团队普遍认为简化后的首页应该更好用结果测试数据显示改造后的首页任务完成率反而比旧版低了15%。当场所有人都懵了。复盘的时候才发现问题简化后的首页删掉了很多入口文字换成了纯图标。年轻设计师觉得图标已经很直观了但老年用户根本不认识这些图标的抽象含义反而更依赖文字入口。这个案例带来的教训是简化不一定等于易用。在适老化设计中一些看似冗余的文字标签实际上是老年人最重要的认知锚点。你删掉了文字就删掉了他们理解界面的线索。这个案例也告诉我任何改版决定都不能只靠团队以为必须回到真实用户面前检验。5.5 如何让测试报告真正推动产品改进最后的落地问题也很现实报告写得再好不推动执行就等于白做。我自己的经验是测试报告不要以文档的形式发给团队而是要以会议的形式带着团队一起过一遍。会上逐条播放关键录屏片段让产品、设计、研发直观看到老年用户的操作困境。一个真实用户的叹气声比十页纸的文字描述更有说服力。会后的行动计划也一定要明确到人哪个问题谁来改、预期什么时候改完、改完后由谁跟进复测。竹子没立起来后续就没人管了这套体系也就断了。我个人的做法是把适老化测试-问题修复-回归复测作为一个固定的迭代环节每一到两周循环一次雷打不动。6. 最后再分享一点实操中的心得其实说来说去适老化测试这件事情方法、流程、指标都只是骨架最重要的是你对用户的态度。我做了这么多年测试最大的变化是以前我拿到一个测试数据会说用户失败了现在我会说我们的界面还没能理解用户。同样的数据不一样的视角带来的决策质量完全不同。如果你现在正准备开始做一套适老化测试体系我建议你不要想着一上来就全流程铺开。先挑一个核心业务场景把任务设计好找三五个老人来测跑完一轮把数据整理出来给团队看一遍。这个过程本身就是最好的培训——它让每一个团队成员都亲眼看到自己的产品在一个真实用户手里是怎么被使用的。等这个环节跑顺了再逐步扩展任务数量、增加测试频率、引入更完整的指标体系。适老化不是一次性项目它是一个持续演进的过程。你现在迈出的第一步哪怕再小也是在往正确的方向走。