Files
lehuo/docs/07_UI_UX.md
T

7.7 KiB
Raw Blame History

07 UI/UX 与适老化规范

1. 视觉原则

关键词:

  • 温暖
  • 可信
  • 简洁
  • 清楚
  • 不商业化
  • 不花哨

不得做:

  • 密集 Banner
  • 过多卡片
  • 首页十几个同级入口
  • 小字号说明堆叠
  • 复杂渐变和强动画
  • 倒计时/诱导点击式设计

2. 小程序首页优先级

P0:

  1. 我需要帮助
  2. 帮他人申请

P1:3. 四大服务类别 4. 我的服务进度

P2:5. 公益项目 6. 公益活动 7. 我要做公益

宣传内容不能挤压服务入口。


3. 适老规范

建议基线:

  • 正文字号尽量 >= 16px 等效视觉;
  • 主要按钮文字 >= 17px 等效视觉;
  • 主要点击区域高度约 48px 以上;
  • 按钮间距足够;
  • 一屏只做一个主要决定;
  • 错误提示紧贴字段;
  • 表单支持保存草稿(较长时);
  • 不用颜色作为唯一状态表达;
  • 图标同时配文字;
  • 返回动作清晰;
  • 网络失败可重试;
  • 提交后明确“已成功”。

具体像素可在设计系统中统一,不以本建议替代微信设备适配。


4. 表单原则

一页最多 5~7 个核心输入。 复杂申请拆步骤:

  1. 需要什么帮助
  2. 帮谁申请
  3. 联系方式与地区
  4. 需求描述
  5. 确认提交

可选信息放“补充信息”。


5. 文案

使用:

  • “我需要帮助”
  • “帮家人申请”
  • “工作人员正在联系您”
  • “还需要继续帮助”
  • “重新提交”

避免:

  • “创建工单”
  • “状态流转”
  • “Beneficiary”
  • “Record Not Found”
  • “非法参数”

6. 空状态

例如没有服务申请: “您还没有提交过服务申请。如果您或家人需要帮助,可以从这里开始。”

提供明确按钮。


7. 错误恢复

提交失败不能清空已填表单。 上传失败允许单文件重试。 网络失败保持本地草稿。 重复点击提交不应生成多个申请。


8. 管理后台

后台目标:让工作人员每天打开工作台就知道做什么。

表格:

  • 默认显示业务必要列;
  • 手机、地址默认脱敏;
  • 常用筛选固定;
  • 详情采用清晰分区;
  • 状态颜色+文字;
  • 危险操作二次确认并说明影响。

禁止为了“企业感”做过密 Dashboard。


9. 无障碍

  • 合理对比度;
  • 图片提供语义说明(可用场景);
  • 表单 label 明确;
  • 键盘操作兼容后台;
  • focus 可见;
  • 不用仅 hover 才出现核心操作。

10. Phase 5 页面落地

  • 小程序首页仍保持“我需要帮助/帮家人申请”为最高优先级,在其后增加公益项目、公益活动和志愿者中心入口。
  • 项目和活动使用列表→详情的单一主任务结构;活动详情明确显示状态、时间、地点、报名截止、名额和不可报名原因,不加入捐赠或诱导分享入口。
  • 志愿者中心只收集姓名、手机号、地区、可参与时间、固定技能和服务意向,并明确资料使用同意;同页展示资格状态、报名进度与核定服务分钟。
  • 管理端新增志愿者审核、公益项目、活动与报名三个独立导航;危险状态推进二次确认,手机号列表脱敏,所有主要按钮保持至少 44px 点击高度。
  • 沿用已批准的橙色主色、系统字体和功能型布局;采用高对比、可见焦点、文字+状态、加载/空/失败反馈与渐进披露,不引入复杂动画、密集仪表盘或新品牌方向。

11. 公众端视觉重设计落地(2026-08-13)

  • 底部导航固定为“首页 / 服务 / 公益 / 我的”,分别承担首要入口、求助闭环、社会参与和个人事务;协作任务按权限在“我的”中显示,不另设同级导航。
  • 首页保持“我需要帮助 / 帮家人申请”为最高视觉权重,六类服务入口次之;服务进度使用独立横幅,宣传内容不挤占求助任务。
  • 暖橙 #F05A28 为主色,绿色表示志愿参与与正向状态,蓝色表示进度和消息;颜色始终配合文字、标签或图形,不作为唯一信息来源。
  • 全局使用 16/24/32rpx 级圆角、低强度暖灰阴影、至少约 96rpx 的主按钮/主要点击高度和系统字体;不使用闪烁、强动画、玻璃拟态或科技大屏视觉。
  • 项目、活动和志愿者页面只展示 API 返回的真实事实;封面缺失时使用轻量公益图形占位,不生成虚构人物、捐赠额、服务人数或活动成果。
  • 参考图中的公开捐赠交易、证书、培训和团队入口不属于当前 V1 已实现能力,不在公众端显示;项目详情明确不提供公开募捐交易。

12. 参考界面全端还原范围(2026-08-13)

  • 小程序端采用参考图的品牌头、暖橙主视觉、四列服务入口、公告、项目大卡、绿色个人中心、图文服务选择、项目事实卡和统一底部导航。
  • 管理端采用深色固定侧栏、浅灰工作区、真实 KPI、月度趋势、服务类型分布、快捷入口、标准筛选表格和工单横向步骤条。
  • 生成的人物图片均为虚构品牌场景素材,仅作服务类别与项目视觉,不作为真实服务对象、服务现场或项目成果证据;素材已压缩进入小程序本地包。
  • 捐赠支付、自动捐赠、捐赠记录/金额、物资订单、志愿者培训/证书/团队不展示入口;代码只保留禁用的集中能力登记和组件/导航扩展边界。
  • 图片中的金额、满意度、捐赠人数等示例值不得复制;所有运行时数字必须来自已批准接口,缺少事实时使用明确空状态。

13. 财务公开文档体验(2026-08-13)

  • 管理端新增独立“财务公开”导航,支持空白新建、10MB 以内 DOCX 导入、标题/摘要、基础标题与段落、加粗、下划线、列表、对齐、撤销/重做和接近小程序宽度的预览。
  • Word 的复杂浮动对象、页眉页脚、分页和高级样式允许在导入时简化,发布前必须人工预览确认;首版重点保障段落、标题、列表和表格。
  • 小程序“公益 → 了解乐活”新增财务公开入口;列表展示置顶、标题、摘要和发布时间,详情使用 rich-text 展示,宽表可横向滚动,加载失败可重试。

14. 首页帮扶服务入口调整(2026-08-15)

  • 首页取消关爱老人、困境儿童、妇女帮扶和残障救助四个群体快捷按钮,避免与帮扶服务中的六类真实服务分类重复。
  • 功能区改为一个高权重“帮扶服务”横向主入口,下方四列展示志愿服务、公益项目、公益动态和旧物善用;主入口包含用途说明,保持适老化点击区域和清晰层级。
  • 小程序公众文案将“服务申请”统一改为“帮扶服务”,将提交动作描述为“提交帮扶需求”;内部数据库、API、权限及状态机仍保留 ServiceApplication 语义,不做破坏性改名。
  • 帮扶服务分类页六个类别均使用本地品牌场景图。新增图片中的人物和场景均为 AI 生成的虚构视觉素材,仅作类别识别,不作为真实服务对象、服务过程或项目成果证据。

15. 首页主功能区与便捷入口调整(2026-08-15)

  • “帮扶服务”下方主功能区使用 3×2 六宫格,依次提供志愿服务、公益项目、公益动态、旧物善用、财务公开和服务进度,单项保持清晰文字标签及适老化点击区域。
  • 财务公开直接进入已发布文档列表,服务进度直接进入本人帮扶服务列表;两项均复用现有真实页面和权限边界,不新增空白占位页面。
  • 服务进度从便捷入口上移至主功能区,避免同页重复;便捷入口取消旧物善用,仅保留公益活动,以及有权限用户可见的协作任务。