A / 条件直读
将适用期数与其他期数不适用的规则常驻展示。无需额外查看说明,但默认阅读量较多。
No files here.
为设计师与产品经理提供需求初期的设计探索,依据现有规范构想多个方向,并在 Figma 中形成可继续编辑的页面。
团队已经有页面、组件和规范。这个 Skill 将它们带入设计探索,使设计师和产品经理能围绕同一个需求比较不同组织方式,再在熟悉的 Figma 环境中继续工作。
从需求出发,找到可信的设计依据,明确哪些业务信息与产品语言需要保留,再决定哪些布局和交互值得探索。
每个方向都形成独立的 Figma 设计稿,并附上假设、阅读顺序和取舍。团队可以选择、修改、评审,再进入下一轮设计。
项目围绕“去哪里找设计依据、如何展开方案、如何交付和验证”建立规则。下面对应当前项目中的实际结构。
维护原始 Figma 文件索引、设计系统映射和组件注册表。组件身份、变体和样式都有对应来源;本地 HTML 用来辅助观察。
将设计任务分为 Explore、Generate、Refine、Review。探索模式先比较候选方向,再选择三个具有实质差异的策略,并记录各自取舍。
使用现有组件与产品语言,在独立页面、Section 或副本里生成可编辑设计。保留权威组件库与业务源稿,让后续设计可以继续。
按版本保存需求约定、节点回读、截图评审和检查结果。修改后重新采集证据,确认当前版本的反馈是否落实。
观看从需求到 Figma 三方案的流程。此网页播放既有产出,不会实时调用 AI 或写入 Figma。
此处为 Figma 画面的网页回放,点击手机可放大。真实文件中的页面与组件可继续编辑;网页里的图层列表用于浏览演示方案。
原案例的设计评审推荐 B:保留双券并列比较,并提供完整规则入口。推荐尚待设计师选择,未视为实际用户选择或已验证效果。
这轮案例围绕相同的额度、优惠与期数限制,比较规则常驻、按需说明和横向分组三种方向。每个方向都有明确的假设与代价。
| 方向 | 设计意图 | 需要权衡 |
|---|---|---|
| A 条件直读 | 选择前看到完整适用条件 | 首屏阅读量、卡片高度 |
| B 按需说明 | 先比较优惠,再按需理解规则 | 完整解释需要额外一次点击 |
| C 横向券列表 | 逐券阅读,为条件文字增加宽度 | 纵向扫描与页面占用 |
反馈关联当前版本和目标节点。修改后重新回读 Figma、查看截图,再确认问题是否解决;旧版证据不能代替新版检查。
组件来源正确,还需要确认实际字号、颜色、间距、原型跳转和必要文案。机器检查与视觉判断分别记录。
找出设计稿中可能漏用官方组件的区域,推荐对应组件,并在替换时保留业务文字与状态,减少人工查找和重填。
历史稿复制、手动搭建和解除组件关联,会让页面逐渐脱离规范。设计师需要逐层检查、翻库找组件,再把业务内容填回去。
只看画面难以区分手动图层和官方组件,需要逐层确认。
在组件库与业务页面之间切换,反复比较布局和状态。
默认文字、金额和状态与原稿不同,容易带来重复操作。
以下为实际操作录屏。最后可选择生成副本进行比较,或直接在原位置替换。
采集官方组件并加入审核库,后续按这套规范检查页面。
选择页面或图层,执行审核,查看推荐组件与差异。
从推荐结果跳到组件库,确认具体样式是否适合。
在原稿旁生成组件副本,带入业务内容,方便并排确认。
在原位置应用组件,并保留可对应的文字、金额与状态。
视频暂未加载成功,请点击播放器重试,或刷新页面。
检查图层是否来自审核库,将已使用的官方组件与手动图层分开处理。
比较用途、层级、尺寸和间距,列出相近组件与差异。外观相似只是线索,是否适用由设计师确认。
带入可对应的文字、金额与状态,并检查结果。无法保留关键内容时阻止替换,避免误改。
插件承担重复操作,让设计师把精力集中在组件是否适合当前业务。
| 环节 | 手动复核 | 插件辅助 |
|---|---|---|
| 检查页面 | 逐层查看是否使用了官方组件 | 扫描选定范围,集中查看待复核区域 |
| 查找组件 | 切换文件,搜索并比较不同样式 | 从推荐结果直接定位对应组件 |
| 替换内容 | 拖入组件,重填文字、金额与状态 | 保留可对应的内容,生成副本或原位替换 |
让涉及多家银行的开票申请,范围清晰、进度可查。
面对开票投诉激增,我主负责流程梳理、交互与视觉设计。在监管要求下,围绕借据选择、分银行金额和独立进度重构服务流程,平衡申请效率、批量滥用风险与各银行不同的开票时效。

开票是借款后的基础服务。当申请量快速增长、多家合作机构以不同时效分别开票时,原有处理能力与信息披露难以支撑用户预期。投诉集中到税局,推动流程和前端展示紧急改造。
平均每位开票客户涉及 3.6 家合作机构,工单办结取决于最后一家机构。即使部分机构已完成,客户仍可能处于漫长等待中。
税局已就发票投诉约谈三次,要求压降投诉、优化流程和信息披露。设计需要配合后端提效,让用户能理解真实的办理状态。
设计命题
在监管要求下提升开票服务效率,同时保留防范批量滥用的必要操作,并让客户理解:不同银行分别开票,处理进度与时效也由各银行决定。
我调研了同类信贷产品的开票方式,重点关注申请入口、开票粒度和进度反馈。竞品带来的启发,是让用户既能发起申请,也能持续获取办理信息。
| 产品 | 申请入口 | 开票粒度 | 过程反馈 |
|---|---|---|---|
| 招联金融 | APP 内固定入口 | 可按借据或还款流水选择 | 展示处理进度与开票历史 |
| 小赢科技 | APP 内固定入口 | 按借据开票 | 展示进度、历史及借据下的机构开票情况 |
| 微粒贷方案 | 帮助中心 → 工具与服务 → 开具发票 | 用户勾选借据 系统按机构汇总 | 总额与机构金额、分机构进度 借款明细及历史查询 |
关键取舍:用借据组织需求,用机构解释交付。
借据对应用户要开票的那笔借款;机构对应实际开票的银行。通过“借据选择 → 机构汇总 → 明细回查”衔接两套信息,用户无需在申请前理解复杂的合作机构关系。
从原有开具证明服务,到新版开票申请与查询,重点看申请范围、机构金额与进度反馈如何衔接。
我的 → 开具证明 → 选择服务与时间 → 填写身份及邮箱 → 邮箱确认 → 身份验证 → 提交成功。此处展示原有交易流水服务,作为改造前的服务路径参考。
我的 → 帮助中心 → 小程序授权与身份验证 → 逐笔选择借据 → 核对机构金额及邮箱 → 提交申请 → 查询历史 → 查看各银行独立进度。
这次优化同时处理三个约束
提效与合规:补齐线上申请、信息披露与查询闭环。
滥用防范:支持多笔申请,但保留逐笔主动选择,不提供一键全选。
预期管理:将开票主体与状态对应,帮助用户识别具体由哪家银行处理。
我将申请与查询串成完整路径,把复杂的机构关系放在用户需要核对金额和进度时展开;主流程始终围绕用户的借款任务组织。
借款金额、日期和可开票金额并列展示,让用户能够识别目标借据;底部持续显示已选总额,随时核对本次申请范围。
需要支持多笔申请,同时降低一键发起大量申请被滥用的便利性。
逐笔勾选,逐笔展示金额;说明还款 2 个工作日后可申请。
申请确认时披露开票总额与各银行金额,并说明“发票将由不同机构分别开具”。提交后,用户可在发票详情中按银行回查对应借款明细。
确认页另设邮箱格式校验与二次确认,减少填写错误导致的交付失败。
开票历史承接已提交申请,详情展示每家机构的金额与状态。即使整单仍在处理中,已经完成的机构也能被识别。
工单办结取决于最后一家机构,用户可能把整单等待理解为全部未处理。
在同一详情里分别标记“已完成”和“处理中”,可进入机构明细继续查看。
对暂不支持线上开票的机构,在金额附近直接解释原因并提供客服电话;针对特殊历史利息,单独标出无法开具的金额与原因。
时效按开票主体分别说明:微众银行开票约 10 分钟—3 天;其他银行按各自流程处理,实际时长由对应银行决定。对无法线上办理的情况,提供对应银行的办理指引,帮助用户找到负责处理的机构。
在紧急上线节奏下,我主负责流程梳理和交互/视觉设计,将竞品发现、业务规则与特殊机构场景整理到同一条用户路径中。交付重点是让用户能够提交、核对、查询,并理解不能在线处理的例外。
对标固定入口、借据选择、历史查询;结合多机构履约,明确“借据 → 机构 → 明细”的关系。
围绕勾选借据、按机构汇总、历史记录及机构金额与进度完成设计,承接专项压降需求。
后续完善发票重新发送至邮箱等自助操作,最终设计方案已覆盖重发能力。
我的设计贡献
将投诉中的“慢、少、主体不清”转成具体信息与交互要求;通过“借据选择 → 机构汇总 → 分机构进度”连接用户任务与真实业务;在效率、监管要求和滥用风险之间做取舍,并把不可控的跨行时效转为可理解、可查询、可找到对应机构的反馈。
项目复盘反馈为 0 投诉,项目团队获得三季度即时激励团队奖励。这是流程、信息披露与相关业务改造共同作用的项目成果。
我把提效、合规、滥用风险和跨行履约边界,转化成用户能选择、能核对、能追踪的交互方案。
区分操作负担、信息缺失与实际开票等待,明确设计能改变的环节。
保留逐笔选择,在批量便利性与滥用风险之间做出可解释的决策。
将多银行协作关系转成可核对、可追踪的信息,并提供对应办理指引。
完整保留主流程、机构明细、异常说明、邮箱校验及不同完成状态,便于进一步查看交付覆盖范围。
让审核人员在通话中,更顺畅地查资料、做核查、记结果。
从审核人员访谈出发,围绕复审中的信息浏览、操作空间和重点识别,优化并补充工作台功能,把分散的界面问题转化为有依据的设计调整。

通过访谈审核人员,我了解到:一个工单的审核通常需要约 15—30 分钟,审核人员会一边打电话,一边在系统中查阅资料并同步操作。
通话并不会等界面操作结束。审核人员需要在阅读资料、核实信息和填写结果之间持续切换。
审核过程中会重点关注工单信息。这决定了它需要保持在固定位置,方便随时对照,而不是随着详情浏览反复寻找。
先明确哪些信息需要持续可见、哪些资料按需浏览,再安排操作区与提示层级。以审核人员的实际工作顺序组织页面。
结合访谈和旧系统截图,我把影响复审连续性的障碍归纳为信息浏览、操作路径和重点识别三个方面。
横向展开的信息超出可视范围,审核人员需要左右滚动才能看全,打断了通话中连续查阅资料的过程。
右侧操作区较窄,核查选项纵向堆叠;页面中又有多层标签与不同入口,审核人员需要在查看资料和填写结果之间频繁切换。
高频参照信息和需要重点关注的内容混在一起,审核人员需要逐项阅读、自己识别重点。
固定高频参照的工单信息;将资料查阅与电核操作分区,让不同资料通过标签切换、在板块内上下阅读;再通过标签状态和有无信息的展开折叠,让需要关注的内容更容易识别。
根据审核人员边通话、边操作的习惯,将工作台明确分为三个区域:左上固定工单信息,方便持续对照;左下通过标签切换资料板块,在板块内上下滚动浏览;右侧供工作人员拨打电话、填写核查结果、记录备注并处理工单。
按审核人员查阅习惯保持位置固定,通话中随时核对。
通过标签切换信息类别,再上下滚动浏览对应内容。
集中拨打电话、核查填写、备注与工单处理操作。
固定依据是访谈中的高频查阅需求。把持续参照的信息保留在固定位置,把较长的详细资料交给内容区浏览,避免每次核对都重新定位。
通过“申请人信息、征信信息、产品信息”等标签直接定位对应板块,再上下滚动阅读其中的内容。将原先依赖左右移动的信息浏览,整理成按类别定位、沿纵向阅读的路径。
审核人员通常围绕某一类资料完成核查。标签解决“去哪里找”,纵向内容解决“如何连续阅读”,减少为查看同一板块而左右移动的负担。
存在共借人和担保人信息时,对应标签变色,提醒审核人员这里有需要查看的资料;无相关人员时,标签与其他普通标签保持一致。颜色表达的是“存在相关信息”,不代表风险判断。
产品信息按车辆、融资、渠道等分组。有数据的分组展开,便于直接阅读;没有数据的分组折叠,保留标题入口,减少空内容对页面的占用。
把页面空间优先留给当前工单实际存在的信息,同时保留分组结构。审核人员能更快分辨“有内容需要看”和“当前没有内容”,减少逐个进入确认的负担。
通过访谈了解 15—30 分钟的单笔审核过程,识别同步操作、高频参照工单信息,以及旧界面的阅读和操作负担。
以固定工单信息、资料纵向浏览、操作区重组和条件状态展示,回应持续查阅、操作切换和重点识别的问题。
我把审核人员“边通话、边查阅、边记录”的工作方式,转化为页面的信息优先级、区域布局和状态规则,让设计判断能对应到真实使用场景。
用可配置的第二屏,承接开通前的犹豫。
微粒贷欢迎页每天约有 100 万来访量,但仍有大量用户离开页面、没有开通。原有页面以一句产品介绍和“查看额度”为主,对尚不了解产品的用户,缺少进一步解释。
我围绕开通前的决策问题补充第二屏,并将内容拆成可配置模块,让后续调整能够结合数据持续进行。

首屏清楚地告诉用户“可以借钱”,但没有进一步展开服务背景、费用规则和常见顾虑。对于还在了解产品的人,页面提供的信息不足以支持下一步判断。
历史分布中,约六成已访问用户只来过一次。访问一天、两天、三天用户的开通率分别为 25.2%、16.6%、12.6%。这提示我:既要抓住首次了解的机会,也要给重复访问用户新的信息价值。
保留首屏直接开通的效率,在第二屏补充产品理解与疑问解答;再根据访问阶段调整内容重点。
上述为历史分布,不等于页面跳出率;人群差异也不能直接解释为访问次数造成开通率下降。
在有资金需求的调研样本中,“知道微粒贷但没申请”的用户占 74.4%(n=2,278)。这一群体反馈的问题集中在利息理解、机构熟悉度与安全顾虑,支持第二屏优先解释费用与可信度,而不只是重复强调开通入口。
对照京东金条、美团借钱、度小满、闪电贷、招联和借呗,分析它们如何在申请前呈现服务背景、费用规则与操作说明。
| 未申请人群的调研发现 | 竞品中的信息组织 | 我的设计响应 |
|---|---|---|
| 26.1% 对机构不熟悉,25.9% 担心正规性与安全性。 | 以服务机构、产品特点或保障信息建立理解。 | 用“了解微粒贷”解释服务背景与产品特点,回应信任顾虑。 |
| 26.4% 不知道利息多少、担心利息高;20.5% 不清楚利息怎么算。 | 前置利率、期限等规则,并补充产品详情。 | 用“产品规则”说明基本规则,以“利息计算”帮助理解借款成本。 |
| 12.7% 不知道在哪里申请,7.5% 提到需要查询征信。 | 通过步骤说明、帮助入口降低理解与操作门槛。 | 保留清晰的开通入口,用常见问题解释征信与授权相关疑问,补充视频和帮助入口。 |
调研用于确定要回答的问题,竞品用于参考信息组织方式;具体模块的有效性继续结合 A/B 测试验证。
有明确意愿的用户可以直接查看额度;需要继续了解的人向下阅读介绍、规则和问答,再决定是否开通,避免在首屏集中堆叠信息。
将第二屏拆为六个模块,支持展示开关与顺序调整;模块内的标题、文案、条目和问答也可维护,后续可根据数据调整内容,无需反复重做整页。
了解微粒贷、产品规则、利息计算、常见问题、视频介绍、帮助中心,共六个基础模块。
首访侧重产品理解,再访可前置规则与疑问解答。通过配置切换内容重点,让每轮反馈都有可执行的调整入口。
项目目前处于 A/B 测试阶段,对照组与实验组各覆盖约 10 万名用户。上线观察一周后,实验组开通率较对照组相对提升约 1%。当前继续观察增长的稳定性,再决定后续内容调整与推广范围。
将进入欢迎页、符合开通条件且尚未开通的用户,随机等量分为两组:A 组看原页面,B 组保留相同首屏、增加第二屏。同一用户重复访问始终看同一版,首访与再访人群分别观察。
主指标:开通率=统一观察周期内开通成功人数 ÷ 进入实验的去重用户数。辅助观察第二屏触达、查看额度点击和问答展开,了解用户在哪一步继续或离开;未滑到第二屏的实验用户也计入分母。
比较两组同期的开通率,避免直接用改版前后数据下结论。先核对分组与记录是否正常,在达到预设样本量和观察周期后,通过统计检验判断差异是否超出随机波动,同时检查页面加载和错误率是否变差。
以同期对照组为基准,当前结果作为初步增长信号;是否达到统计显著性、能否持续,仍需结合后续数据确认。下一轮结合模块触达与使用反馈,调整内容及展示顺序。