接到这个需求的时候上一个交付物还是2048小游戏的小程序源码包说实在的从做游戏到做适老化老人健康预警跨度非常大。2048的核心是动画、计分、本地存储而老人健康预警的核心是数据采集、异常判断、告警送达以及最容易被技术人忽略的一件事——让七八十岁的老人真正“用得动”。这个项目最终的形态是Python 编写后端服务uniapp 编写前端逻辑最后打包成微信小程序运行。后端负责健康数据的存储、分析和预警触发前端负责适老化交互和展示微信小程序则借助微信生态解决了“老人不用额外装App、子女能实时收到通知”这两个最关键的痛点。这篇文章不是晒代码而是把整个项目从需求拆解到选型、从核心功能实现到上线踩坑完整过一遍。如果你正准备用 Python uniapp 做微信小程序或者在做任何面向老年用户的健康类产品这篇内容里踩过的坑和想明白的设计逻辑应该能帮你少走不少弯路。1. 项目定位与整体设计思路1.1 为什么是 Python uniapp 微信小程序先回答一个很多人会问的问题为什么不用原生微信小程序非要绕一圈用 uniapp答案不复杂这个项目不是只做微信小程序后续大概率还要上支付宝小程序、抖音小程序甚至打包成安卓和 iOS 的 App。uniapp 一套代码多端编译虽然性能比不上原生但在这种以表单、列表、图表、消息通知为主的业务场景里完全够用。Python 的角色同样清晰。健康预警不是一个“展示型”需求它需要持续的规则判断、趋势分析、历史数据统计。这些用 Python 做实在太顺手了。微信小程序的云开发也能写云函数但业务逻辑一旦复杂起来调试、测试、扩展都绕。尤其后续要引入更智能的预测逻辑比如心率变异性分析、血压趋势预测Python 的生态优势会越来越明显。微信小程序则是天然的载体。对老年人来说“下载一个App并注册账号”本身就是一道极高的门槛。但微信几乎人人都有子女帮老人打开小程序、点一下授权整个链路就通了。微信生态还提供了订阅消息能力老人端不需要做任何操作子女手机上就能收到健康预警。这种“老人零学习成本、子女及时响应”的双用户模型是这个项目里我最满意的一个设计决策。1.2 适老化设计把“给年轻人用的App”反过来想适老化这个词听起来很专业实际操作起来就是三个字反着来。年轻人喜欢信息密度高、一屏展示尽量多内容老人恰恰相反。年轻人能接受“设置”藏在三级菜单里老人不行他找不到就是找不到。第一是字体和按钮的物理尺寸。我在设计稿里定的是正文字号不低于 34rpx核心操作按钮高度不低于 88rpx可点击区域不小于 80×80rpx。这个尺寸不是我拍脑袋定的微信官方的无障碍设计指南里对触控目标有建议值而我从实际测试中发现老人手指的触控精度明显低于年轻人误触率很高所以最终比官方建议值还放大了一档。第二是信息层级必须极浅。首页直接展示老人的整体健康状态正常、关注、异常三个大字状态下面就是测量记录、SOS按钮和子女联系方式。所有二级页面控制在两次点击以内能返回首页。我见过很多健康类App把首页做得像股票行情看板这对老年用户来说是灾难。第三是“反悔”必须简单。老人误触的概率就是比年轻人高所以凡是涉及确认操作的弹窗按钮位置必须固定取消按钮和确认按钮的间距要拉大颜色要有明显的冷暖区分。SOS 这种高风险操作还要二次确认并且提供 5 秒内可撤销的机制。这里要特别说一个我总结的经验字号调大只是适老化的入门真正决定体验的是“认知负担”。页面上一屏只讲一件事功能入口不超过四个文案用“测量血压”“查看报告”“呼叫子女”这种大白话不用“健康档案”“数据洞察”这类营销味词汇。和老人交流需要用他们习惯的词语而不是产品经理习惯的词语。1.3 预警链路从测量设备到子女手机整个预警系统的数据链路可以拆成五层采集层、传输层、分析层、告警层、响应层。采集层是这个项目里最现实的部分。老人测血压有两种方式一种是使用带蓝牙功能的电子血压计小程序通过蓝牙接口读取测量结果另一种是老人在小程序里手动录入数值。我在实际调研中发现很多老人的血压计是老款没有蓝牙功能所以手动录入不是备选方案而是必需方案。前期开发时我一度把精力都放在蓝牙对接上后来被现实教育了对于适老化产品手动录入的优先级反而更高。传输层和数据存储由 Python 后端统一负责。小程序通过 HTTPS 接口上报数据后端校验数据合法性写入数据库。这里有一个很重要的设计决策健康数据不在小程序本地长期存储统一走后端。一是因为小程序本地存储容量有限且容易丢失二是健康数据涉及隐私合规数据链路必须收敛在服务端管理。分析层是 Python 后端的主场。我实现了三层预警逻辑阈值预警、趋势预警、漏测预警。阈值预警最简单但最可靠比如收缩压超过 140 或低于 90 就触发趋势预警关注的是短期波动比如连续三天血压持续走高即使还在正常范围内也要提示漏测预警则是每天早上 9 点前如果没有收到测量数据后端会自动提醒子女“今天老人还没测血压”。这个设计源于真实场景很多老人不是数据异常而是干脆忘了测。告警层通过微信订阅消息触达子女手机。这里要提前说明微信的订阅消息分一次性订阅和长期订阅健康预警类目基本只能申请到一次性订阅消息每次发送前都需要用户主动授权。这不是微信故意刁难而是防骚扰设计。所以我在项目里做了“授权引导”机制子女首次进入小程序时系统会引导他们授权血压异常通知和 SOS 通知两种消息模板授权成功后后端才能调用发送接口。响应层则是预警闭环的最后一环。告警推送后子女可以从小程序里直接查看老人的实时定位、最近一次测量数据并提供回拨电话按钮。如果是 SOS 求助后端还会通过短信接口给紧急联系人发一条包含位置链接的短信防止子女微信消息被折叠而错过关键信息。整套链路跑通之后逻辑就非常清晰了不是做一个“给老人看的数据面板”而是做一个“老人只用按一个按钮剩余的事情自动流转”的闭环系统。2. 关键技术选型与核心难点2.1 Python 后端为什么选 FastAPI 而不是 Flask选后端框架的时候我在 Flask 和 FastAPI 之间犹豫过。Flask 我也用了很多年生态成熟资料多绝大多数 Python 开发者都熟悉。但最终我还是选了 FastAPI核心原因有三个。第一FastAPI 原生支持异步。健康数据上报是一个典型的 I/O 密集型场景后续还要并发处理多个老人的数据上报、调用微信接口发送订阅消息。异步编程在高并发上报场景下优势明显而 Flask 默认的同步模型做这类事情需要用线程或者额外挂 Celery复杂度会上去。第二FastAPI 自带的 Pydantic 数据校验非常适合健康数据的场景。老人录入的血压值有可能填错比如收缩压填成 30、心率填成 1000这些非法数据在后端入口直接被拦截比在业务逻辑里到处写 if 判断要优雅得多。我在项目里对每条健康记录都定义了数据模型字段类型、数值范围、单位枚举全部由 Pydantic 统一处理。第三FastAPI 自动生成 OpenAPI 文档这在小程序端联调时非常省事。前端同事包括我自己不用再另外维护接口文档直接打开 /docs 页面就能看到所有接口的请求参数和返回结构还能在线调试。下面是我在项目里定义的健康数据上报接口精简掉了一些业务字段保留了核心结构from fastapi import FastAPI, Depends from pydantic import BaseModel, Field from datetime import datetime from typing import List, Optional app FastAPI(title老人健康预警后端服务) class HealthRecord(BaseModel): elder_id: int Field(..., description老人ID) record_type: str Field(..., pattern^(blood_pressure|heart_rate|blood_glucose)$) systolic: Optional[int] Field(None, ge50, le250, description收缩压mmHg) diastolic: Optional[int] Field(None, ge30, le150, description舒张压mmHg) heart_rate: Optional[int] Field(None, ge20, le250, description心率bpm) blood_glucose: Optional[float] Field(None, ge1.0, le35.0, description血糖mmol/L) measured_at: datetime Field(..., description测量时间) app.post(/api/v1/health/record) async def upload_health_record(record: HealthRecord): # 写入数据库然后送入预警分析模块 result await analysis_service.process_record(record) return {code: 0, message: ok, alert_triggered: result.alert}简单补充一句关于 Python 部署的实践开发阶段直接uvicorn main:app --reload跑起来就行生产环境不要用 uvicorn 单进程扛流量前面挂一个 Nginx 做反向代理用 systemd 或者 Docker 托管服务进程。我这边最开始的 demo 就是在自己电脑上跑的数据量小完全够但一旦接入了订阅消息推送就必须保证后端公网可达。2.2 uniapp 工程搭建与微信小程序打包uniapp 的开发环境我建议直接使用 HBuilderX虽然很多前端同学习惯用 VS Code 或 WebStorm但 HBuilderX 对 uni-app 的编译支持是最直接的内置了运行到微信小程序模拟器的能力遇到编译层问题也好排查。创建项目时我选了 Vue 3 版本配合 TypeScript 支持后面维护起来心态会好很多。如果你想在已有工程上引入 TypeScriptHBuilderX 的“创建项目-默认模板”里勾选 TypeScript 即可不用手动折腾 tsconfig。项目创建后有一个文件必须逐项确认manifest.json。微信小程序的相关配置都集中在这里。最常出问题的几个点微信小程序 AppID如果是测试阶段可以用测试号但要用到订阅消息和定位接口就必须换成真实的小程序 AppID并在微信公众平台后台开通对应权限。基础库最低版本不要设得太低否则一些新 API 用不了也不要设得太高不然很多用户手机打不开。我这边选的是 2.30.0 左右覆盖绝大多数活跃用户。权限声明定位、蓝牙、相册用于上传头像这些都要提前在 manifest 里声明否则真机调用会直接失败。打包路径应该是所有 uniapp 开发者共同的记忆菜单栏“发行” → “小程序-微信”编译产物生成在dist/dev/mp-weixin或dist/build/mp-weixin。然后用微信开发者工具“导入项目”指向这个目录就能在开发者工具里看到和调试小程序了。实际项目中我遇到的最大问题是包体积。uniapp 编译产物天然比原生小程序大因为框架运行时本身就占了不少体积。后面专门用一节来讲这个问题这里先记住一个结论只要用到图表、UI 组件库这类重依赖一次编译出来的主包大概率超过 2MB。2.3 微信小程序适老化的几个硬指标这一节想专门把适老化的“硬指标”说透因为很多人对适老化的理解停留在“字调大一点”的层面实际标准远不止这些。触控尺寸是第一道物理门槛。苹果的 HIG 和 Google 的 Material Design 都建议触控目标不小于 44×44pt对应到微信小程序的 rpx 单位以 750rpx 设计稿、iPhone 6 为基准大约是 88×88rpx。我对核心按钮的执行标准是高度不低于 88rpx宽度不低于 120rpx且相邻按钮间距不小于 24rpx。间距这个细节很重要我实测过按钮做大了但挤在一起误触率反而更高。字体规格上我把页面字体分为三个层级核心数据展示字体不小于 64rpx用加粗正文说明文字不小于 34rpx辅助信息不小于 30rpx。同时行高要控制在 1.5 到 1.8 之间行间距太小老人阅读容易串行。颜色对比度也需要注意正文和背景的对比度至少要达到 4.5:1灰色系文字在老年人屏幕上很难看清我基本放弃使用 #999 以下的浅色文字。语音能力是容易被忽视但老人非常依赖的功能。我实装了结果播报老人测完血压后小程序用语音读出“高压 138低压 85心率 76一切正常”这类结果。语音比任何视觉反馈都直观尤其对视力下降的老人。TTS 方案可以使用微信小程序插件市场的“同声传译”插件也可以直接调用小程序内置的语音合成能力或者在后端合成好音频返回给前端播放。我个人推荐在后端合成前端只负责播放音频这样便于统一管理语音风格。另外还有两个细节值得提一是所有可交互组件尽量使用原生 button 而不是 view 模拟点击这样微信的无障碍服务能正确识别二是每个页面的 title 要设置为老人能理解的语言比如“测量血压”而不是“数据录入页”。3. 核心功能实现与实操拆解3.1 健康数据采集与展示数据采集是整个项目的地基。我在调研阶段跑了好几家养老社区发现一个共性老人对“每天测血压”这个动作本身不抗拒抗拒的是“测完还要在手机上做一堆操作”。所以采集端的交互设计必须做到“一个字都不用打”。录入界面我用的是步进器和默认值结合的方式。收缩压默认 120舒张压默认 80心率默认 75老人只需要根据自己血压计显示的数字做微调最多按两下就能完成录入。日期默认当天时间默认当前时间不需要老人选择。表单顶部用大号字体显示“收缩压”“舒张压”“心率”三个关键字段每个字段配一个实物示意图帮助老人理解。下面是小程序端手动录入页面的核心逻辑这里只列关键片段// 录入血压 onSystolicChange(e) { this.systolic e.detail.value }, onDiastolicChange(e) { this.diastolic e.detail.value }, async submitRecord() { const record { elder_id: this.elderId, record_type: blood_pressure, systolic: Number(this.systolic), diastolic: Number(this.diastolic), heart_rate: Number(this.heartRate), measured_at: new Date().toISOString() } const res await request.post(/api/v1/health/record, record) if (res.code 0) { uni.showToast({ title: 保存成功, icon: success }) this.playVoice(测量结果已保存) } }蓝牙测量是另一个思路。现在市面上支持蓝牙的血压计品牌很多但协议差异极大不是所有品牌都开放对接。开发前我建议先确认你的目标设备是否支持标准协议通常厂商会提供 SDK 文档如果只是最基础的 GATT 读写uniapp 的蓝牙接口uni.openBluetoothAdapter、uni.startBluetoothDevicesDiscovery、uni.createBLEConnection这一套组合拳是能搞定的。但血压计的数据解析往往涉及厂商私有协议这里需要做一层数据解析适配。我这里给的实用建议是如果预算允许血压计优先选欧姆龙等支持本地数据导出的型号并提前向厂商索取蓝牙协议文档。如果是个人开发者做 demo不妨直接用手机摄像头 OCR 识别血压计屏幕数字这个方案做兜底比蓝牙适配省事得多效果还稳定。数据展示我用的是 ucharts 插件。这是 uniapp 生态里用得最多的图表库支持折线图、柱状图。需要注意的一点是ucharts 在 renderjs 模式下性能更好但配置项比较琐碎建议封装一个通用的图表组件只接收数据和颜色配置避免每个页面重复写一大段 chartConfig。3.2 预警判断与微信订阅消息推送预警判断的逻辑全部放在 Python 后端这是整个项目最核心的部分。我把规则设计成可配置项而不是写死在代码里因为血压阈值这种医学指标需要参考权威指南而且很可能根据医生建议调整。核心判断逻辑用伪代码表达是这样的async def process_record(record): alerts [] # 第一层阈值预警 if record.record_type blood_pressure: if record.systolic 140 or record.diastolic 90: alerts.append(high_blood_pressure) if record.systolic 90 or record.diastolic 60: alerts.append(low_blood_pressure) if record.record_type heart_rate: if record.heart_rate 50 or record.heart_rate 100: alerts.append(abnormal_heart_rate) # 第二层趋势预警对比最近7天数据 trend await analysis_service.get_7day_trend(record.elder_id, record.record_type) if trend.is_rising_fast: alerts.append(rising_trend) # 第三层漏测预警由定时任务触发不在本函数内 return alerts订阅消息推送的实现要单独说一下。微信订阅消息的接口调用必须由后端完成每次推送前都需要先获取用户的 access_token。access_token 有效期两小时不能每次推送都重新获取要做缓存。我在项目里用一个简单的 token_manager 模块管理。有一个非常容易踩坑的点订阅消息的模板 ID 在使用前必须在微信公众平台申请而且模板关键词的字段和类型要严格按照平台的示例填写。比如“老人姓名”这个关键词平台类型可能是“人名”字段值必须和类型匹配否则调用接口会报错。我一开始图省事把姓名拼在“备注”字段里接口直接返回 47003 参数错误。发送订阅消息的请求大体是这样async def send_subscribe_message(openid, template_id, data): token await token_manager.get_access_token() url fhttps://api.weixin.qq.com/cgi-bin/message/subscribe/send?access_token{token} payload { touser: openid, template_id: template_id, page: pages/health/detail, data: { thing1: {value: 血压偏高}, time2: {value: datetime.now().strftime(%Y-%m-%d %H:%M)}, thing3: {value: 收缩压145请及时关注} } } async with httpx.AsyncClient() as client: resp await client.post(url, jsonpayload) result resp.json() # result.errcode 0 表示成功43101 表示用户拒绝对该模板授权 return result这里必须正视一个现实一次性订阅消息意味着用户每授权一次只能接收一条消息。对于每天可能要推送多条预警的场景这远远不够。我的策略是把预警消息合并成每天最多一条“健康日报”当天如果有多次异常汇总成一条发送。如果发生 SOS 这种紧急事件则走短信通道不依赖订阅消息。这个策略虽然牺牲了实时性但保证了每条消息都能触达。3.3 SOS 一键求助与定位上报SOS 按钮是适老化设计里最需要重视的交互。我把它放在了首页左下角因为老人习惯左手持机左下角是拇指最方便触达的区域。按钮用红色底、白色十字图标加“求助”两个大字按压时会有明显的触感反馈通过 CSS 按压态模拟和语音提示“正在呼叫紧急联系人”。按下 SOS 按钮后弹出确认弹窗确认后进入倒计时撤销界面5 秒内如果老人再次点击“取消”则撤销求助。这个设计非常重要实测中老人误触 SOS 的概率远高于真实求助需求如果没有撤销机制子女会被频繁的假警报折腾到麻木。确认求助后小程序需要把老人的位置信息上报给后端。定位使用uni.getLocation获取经纬度然后调用天地图的逆地理编码接口将经纬度转换为文字地址。选择天地图而不是其他位置服务主要是因为它的商用授权政策更清晰而且在小程序场景下有官方适配方案。位置上报后后端同时触发两条消息链路微信订阅消息通知子女短信通知紧急联系人。定位权限是这个环节最容易出问题的地方。微信小程序从某个版本开始对地理位置接口做了严格管理开发者必须在公众平台后台申请“位置信息”相关接口权限并在小程序页面里通过接口声明隐私保护指引。如果漏了这一步真机上uni.getLocation会直接失败而且开发者工具里还未必能复现。这个坑我修了很久后来发现是隐私协议没配置。SOS 流程中还有一个容易被忽略的细节定位失败时的降级方案。老人在室内、GPS 信号弱的情况下定位可能失败这时我会引导老人确认“当前所在小区”从预设的几个快捷地址里选择。这个预案在养老社区场景里实测很管用因为老人日常活动范围有限几个常用地址基本能覆盖。4. 开发过程中踩过的坑与排查实录4.1 小程序包体积超限2612kb 2MB 的处理方法这个问题我印象太深了。第一次把项目提交微信审核时编译产物直接报source size 2612kb exceed max limit 2mb整个人都愣住了。uniapp 项目随便带两个组件库和图表库主包超过 2MB 是家常便饭。解决思路我梳理成四个步骤。第一步是看分包配置。这是最有效的方案我把页面分成主包和分包主包只保留首页、健康状态展示、SOS 三个核心页面其他如历史报告、设置、帮助等页面全部放进子包。微信小程序的加载机制是打开时只加载主包进入分包页面时才加载分包代码所以主包体积直接砍掉了一大半。第二步是压缩和转移静态资源。我的项目里图片资源是大头血压计示意图、操作引导图、各种图标加起来体积不小。我把大部分图片先压缩再用图床或后端存储换成网络地址。图标全部换成字体图标或者 SVG而不是 PNG这一步能省出不少空间。第三步是检查依赖。devDependencies 里可能有不少调试工具被一起打包了发布前要确认是否按需引入。uniapp 的 uni_modules 目录里如果引入了整个组件库建议改为官方推荐的按需引入模式或者手动 copy 只用到的组件文件。第四步是使用“发行”模式的压缩选项。HBuilderX 发行小程序时选“压缩代码”选项能再省一点体积。这一步对包体已经压到 2.1MB 左右的边缘情况有奇效。最后强调一个大家容易忽略的点微信小程序总包体上限是 20MB主包 2MB 分包总和 18MB所以分包不是万能药但从 2612kb 压到 1800kb 这个量级分包加压缩基本就能解决。4.2 uniapp 小程序里不打印日志的问题开发过程中我遇到过 console.log 在小程序里完全不输出的情况。排查下来原因有两个层面。第一个层面是编译模式。如果你运行的是发行版/生产版编译产物HBuilderX 或微信开发者工具里默认会把 console 输出过滤掉。解决办法是运行开发版在 HBuilderX 点击“运行到小程序模拟器”不要用“发行”模式的产物去调试。第二个层面是微信开发者工具的日志过滤。开发者工具的控制台默认只显示当前页面的日志如果你的日志是在页面加载前打印的很可能被过滤掉。这时候在控制台右上角把日志级别切换到“All”或“Verbose”就能看到。还有一个隐藏坑真机上部分 Android 系统会把 console.log 吞掉尤其是在 release 包中这种情况直接改用uni.showToast或者上报到自己的日志系统更靠谱。我的经验是页面关键节点打日志后端接口请求和响应必须打日志其他琐碎日志全部删掉免得干扰排查。真机调试遇到问题时用 vConsole 插件小程序里注入一个虚拟控制台能直接在手机页面上查看 console 输出这是最实用的真机调试手段。4.3 页面加载更多与顶部导航栏适配“页面列表加载更多”是微信小程序开发里绕不开的基础功能。老人健康记录的历史列表就是典型的无限列表场景。我的实现思路是使用onReachBottom生命周期监听页面滚动到底部触发加载下一页请求同时维护一个 loading 状态防止重复请求。分页参数用 pageNo/pageSize后端返回 total前端判断是否还有更多数据。onReachBottom() { if (this.loading || this.pageNo this.totalPages) return this.loading true this.pageNo this.loadRecords() }这里有一个比技术更重要的交互细节适老化场景下列表底部应该显示“没有更多记录了”而不是简单的图标结束老人看到明确提示才知道数据加载完了。另外每次加载更多后如果页面滚动位置掉了老人会以为数据没更新。我最后用uni.pageScrollTo把位置保持住了这个小体验很加分但技术上很容易被忽略。顶部导航栏适配是另一个高频问题。uniapp 默认的导航栏高度在不同机型上不一样尤其采用自定义导航栏方案时需要手动计算右上角胶囊按钮的位置来避让。核心代码是利用uni.getMenuButtonBoundingClientRect()获取胶囊按钮的位置和尺寸const menuButton uni.getMenuButtonBoundingClientRect() const systemInfo uni.getWindowInfo() // 导航栏高度 (胶囊顶部 - 状态栏高度) * 2 胶囊高度 const navBarHeight (menuButton.top - systemInfo.statusBarHeight) * 2 menuButton.height这个方法是从众多真实项目里验证过的经验公式自定义导航栏的时候直接用即可。不要用固定的 44px 或 48px不同机型差异很大。4.4 蓝牙连接、隐私协议及其他零碎问题蓝牙设备连接不稳定是健康采集场景的通病。我实测下来有几个规律连接前必须先调用uni.openBluetoothAdapter初始化蓝牙适配器扫描到设备之后不要立刻连接先 stopDiscovery 再 createBLEConnection否则容易连接失败连接成功后要设置 MTU 为 512否则传输大数据时会断读取数据用uni.onBLECharacteristicValueChange监听而不是轮询拿数据。隐私协议这个问题值得单独拎出来强调。微信小程序对用户隐私的保护是持续加强的特别是位置、相册、蓝牙这些敏感接口。项目发布上线前必须在微信公众平台配置《用户隐私保护指引》把会用到的接口类型全部声明清楚。如果不配置在真机上调用uni.getLocation、uni.chooseImage等接口都会静默失败开发者工具里可能一切正常一上真机就暴露排查起来非常抓狂。还有一个细节是关于uni.getSystemInfo的兼容性问题。在 Vue 3 uniapp 新版本里部分 API 改成了同步调用或者拆分到uni.getWindowInfo、uni.getDeviceInfo老的uni.getSystemInfoSync在某些基础库版本下会告警。我在项目里统一封装了设备信息获取的工具模块后续升级基础库不会被 API 变更拖累。5. 写在最后的一点体会这个项目做下来我在技术上的收获不小但最大的体会反而不是技术。适老化健康预警小程序难的不是 Python 接口怎么写不是 uniapp 组件怎么调也不是订阅消息怎么接而是我们很容易用年轻人的使用习惯去揣测老人的需求。我前后找了几位老人做试用观察他们操作时的真实反应。有一位老人看到大按钮、大字体很开心但到了确认弹窗就犹豫了他不敢点怕点错了没得挽回。后来我加上了 5 秒可撤销设计他才愿意尝试。这个改动不在任何需求文档里是我陪着他实际用了一遍才发现的。如果让我给后来者一个建议开发过程中尽早把原型给目标用户试哪怕是最粗糙的版本。你会发现那些在模拟器上看起来完美无缺的交互到了老人手里会暴露出各种意想不到的问题。适老化产品的验收标准不应该是“功能是否实现”而应该是“老人能不能在无人指导的情况下独立完成一次完整操作”。最后分享一个小技巧把老人在页面上的点击位置埋点记录下来。你会清楚地看到哪些按钮老人根本找不到哪些区域容易被误触。这些数据比任何可用性测试报告都诚实而且是持续优化适老体验的宝贵资产。