PayFlow 支付运营设计风格
设计官方

PayFlow 支付运营设计风格

当用户需要为支付授权、清结算、风险审查、争议处理和 Webhook 健康监控仪表盘选择或实现可视化设计风格,或明确要求使用 `payflow-viz-design` 时,使用此 Skill。该 Skill 擅长:靛蓝动作、电蓝信号与白色轻边框卡片构成精密可靠的支付运营风格;适用于支付授权、清结算、风险审查、争议处理和 Webhook 健康监控仪表盘。不要用于数字银行账户总览、销售 CRM 或通用增长分析。

去使用
yvonneyx
yvonneyx
浏览242
使用5

Skill 文件

SKILL.md
name
payflow-viz-design
title
PayFlow 支付运营设计风格
description
当用户需要为支付授权、清结算、风险审查、争议处理和 Webhook 健康监控仪表盘选择或实现可视化设计风格,或明确要求使用 `payflow-viz-design` 时,使用此 Skill。该 Skill 擅长:靛蓝动作、电蓝信号与白色轻边框卡片构成精密可靠的支付运营风格;适用于支付授权、清结算、风险审查、争议处理和 Webhook 健康监控仪表盘。不要用于数字银行账户总览、销售 CRM 或通用增长分析。

PayFlow

你是一名资深产品设计师。当此技能激活时,所有 UI 决策都必须先保护“支付可信度”,再讨论增长和装饰。

在开始任何设计工作之前,先声明需要哪些字体及其加载方式(参见 references/platform-mapping.md)。切勿假设字体已提前可用。


1. 设计理念

PayFlow 来自 payment-gateway demo 的几个稳定事实:#635BFF 主按钮、#00D4FF 次级信号、深海军蓝代码块、白底轻边框卡片、10px 模糊导航和 Inter + JetBrains Mono 的开发者语境。我们把这套营销页语言转成一套支付运营控制台,用于授权、清结算、风险审查、争议处理、路由策略和 webhook 健康追踪。

主要张力是 precision versus approachability。页面必须像金融基础设施一样可靠、可审计、数字对齐;但它也必须让客服、运营和财务协作人员在高压队列里迅速判断“下一步该放行什么、拦截什么、升级什么”。

这是一个 management 原型。用它构建 payments control center、settlement desk、dispute review、routing console 和 merchant health workspace,不要把它做成营销首页、赛博监控墙或消费型钱包首页。


2. 制作规范 — 如何构建

视觉层次层

层级角色实现
L0 云底画布页面背景、工作区节奏--background 的浅云蓝白底
L1 结构面侧栏、顶部栏、筛选行--surface1 + 1px --border
L2 交易卡KPI、图表、表格、详情面板白卡 + 12px 圆角 + 默认无阴影
L3 主动作放行、导出、确认、创建规则--accent 电紫
L4 次级信号路由提示、hover、技术线索--brand-tint 青蓝

排版纪律

  • 标题永远是紧凑的 Inter bold。 不引入衬线,也不做广告式夸张字距。
  • JetBrains Mono 只给精确字段。 金额、时间戳、流水号、批次号、API 名称、webhook 事件用 mono;说明文、商户名和标签不用。
  • 同一行最多两种文本语气。 主值与次文案足够;不要在一行里塞三种对比度。
  • 大数字要像账本,而不是大屏海报。 KPI 可大,但必须严格对齐,不能漂浮。

间距语义

  • 8px 网格是底线,视觉重心在 16 / 24 / 32。
  • 控制台优先“有序留白”,不是“空旷展示”。
  • 筛选区与列表区要紧凑,详情区与图表区要稍宽松。
  • 卡片默认 24px padding。 比这更小会让金融界面显得廉价。

颜色策略

  • 电紫只给主动作和主趋势。 它是确认、推进和主线数据,不是全部彩色的默认值。
  • 青蓝只做辅助信号。 hover、二级标签、技术提示、路由提示可以用,不能抢走主 CTA。
  • 绿色只代表已经健康。 不要把绿色拿来装饰导航或大面积背景。
  • 红色和琥珀必须节制。 只有争议、失败、重试、延迟和风险时才允许出声。

构图方法

  • 先搭工作流,再放图表。 侧栏、异常队列、详情面和操作栏必须先成立。
  • 列表与详情并置。 支付运营不是单栏阅读页,必须允许“扫队列 + 下判断”同时发生。
  • 图表只为运营判断服务。 每张图都要回答一个问题:成功率变差了吗?清结算堵在哪一段?哪个通道该降权?
  • 代码感只放在关键位置。 一个深色 code / event 面足够,不要让整页都像 IDE。

快速验证

退后半步看:

  1. 你应该先看到“哪条队列需要处理”,再看到颜色。
  2. 把青蓝拿掉后,界面仍然必须完整;如果不完整,说明你把装饰色当结构了。
  3. 把电紫只保留给一个主动作后,页面仍然应该有明确的信息秩序。

3. 反模式 — 绝对不要做的事

  1. No 消费级渐变铺满整页。 PayFlow 只有点状紫/青信号,不做霓虹英雄背景。
  2. No 24px 以上的大泡泡圆角。 这不是面向消费者的钱包首页。
  3. No 把青蓝当主 CTA。 主动作永远是电紫。
  4. No 默认卡片阴影。 卡片先靠白底和边框建立结构,hover 才允许抬升。
  5. No 纯黑背景。 深色模式也必须保留海军蓝层次。
  6. No 10px 以下的关键数据文本。 金额、状态、轴标签必须可判读。
  7. No 五颜六色的无语义图表。 每个颜色必须有角色。
  8. No 把所有数值都做成比例字体。 金额、时间戳、批次号需要 mono 对齐。
  9. No 把所有按钮做成实心。 次动作要退到轮廓或轻底。
  10. No 营销文案式长标题。 控制台标题必须短、准、能行动。
  11. No 整页重玻璃拟态。 只有导航可轻模糊,内容卡不要 frosted glass。
  12. No 把风险态做成温柔 pastel。 失败、争议、延迟必须明确。

4. 工作流程

  1. 声明字体 — 先查 references/platform-mapping.md,说明 InterJetBrains Mono 如何加载
  2. 设置令牌 — 应用 references/tokens.md 的颜色、字体、间距、圆角、海拔和数据色板
  3. 先搭结构 — 顶部操作栏、侧边导航、异常列表、详情区域先成立
  4. 构建组件 — 使用 references/components.md 中的按钮、白卡、筛选条、表格、状态 badge、tooltip 和 chart card
  5. 检查数字纪律 — 金额、时间、流水号、费率是否都整齐且对齐
  6. 检查行动优先级 — 同一屏只能有一个真正主动作
  7. 验证双模式 — Dark 要像夜间运营台,而不是 generic 黑色 SaaS
  8. 测试极端情况 — 部分捕获、FX 延迟、争议升级、批次失败、webhook 重放、通道降级

5. 参考文件

文件内容
references/tokens.md颜色阶梯、语义令牌、字体、字号表、圆角、海拔、动效、数据色板、图标策略
references/components.md按钮、卡片、输入框、筛选、队列列表、表格、tooltip、图表容器和状态组件
references/platform-mapping.mdWeb / SwiftUI / Tailwind 的变量、字体加载、实现片段和映射说明
Ln 1, Col 1MarkdownSpaces: 2
No errors