[Case 02]
From ~6 hours to minutes: In-app incident communication for Credit
I reframed a “maintenance screen” request into a scope-based incident UX system, powered by SDUI + feature flags - enabling fast activation and consistent routing across mobile + web.
[Industry]
Fintech
[My Role]
Product Designer
[Platform]
Mobile + Web
Context
Credit is a high-trust domain: contracting, payments, renegotiation. During incidents, customers don’t think “bug” - they think risk: Did I lose access? Will payments fail? What still works?
Between Sep ’24–Mar ’25, Credit had 120 incidents (16 critical) impacting ~36k customers (Looker Studio). The cost wasn’t only downtime - it was ambiguity, which erodes trust and increases operational pressure.
Problem
The original request was “design a maintenance screen.” But Credit wasn’t one flow - it was a system with:
Multiple products (Giro Fácil, Capital de Giro, Renegotiation)
Multiple entry points (home grid, Credit hub, top card, deep links)
Multiple failure levels (credit-wide vs product vs action)
Before, incident communication was fragmented and slow: customers hit generic errors (or no guidance), retried in loops, and escalated to Support. And because many surfaces depended on mobile/web releases, comms often arrived late even when the incident was already known internally.
Before
Different entry points collapsed
into the same dead end
After
My contribution
Led end-to-end UX/UI for incident communication across mobile + web (Credit)
Reframed a “maintenance screen” request into a reusable incident system
Mapped 50+ scenarios (scope × entry point × eligibility) to avoid happy-path gaps
Shipped with Engineering via SDUI + feature flags, enabling activation in minutes (no release dependency)
Process
What started as “design a maintenance message” became a system. I anchored the solution on two levers:
Scope (what’s affected): credit-wide vs product vs action
Entry point (how users arrive): which defines the right friction level (quick check → deep dive)
In quick Support check-ins, the recurring questions were always the same:
Is this temporary or did I lose access? What’s affected? How fresh is this info?
So I designed the surfaces to answer those consistently - using “Last updated” instead of unreliable ETAs.
Solution
To make the system consistent at scale, I reduced incident UX to two levers:
1) Scope - what failed
Credit-wide · Product-level · Action-level
Scope defines what must be blocked vs what stays available - and what the details page must clarify.
2) Entry point - how the user arrived
Home grid · Credit hub · Top card · Inside-flow · Deep link
Entry point defines friction: quick status for “just checking,” deeper explanation only when needed.
From there, I shipped a reusable set of surfaces:
Quick status (bottom sheet) for silent checking behavior
In-context message at the point of failure (without blacking out the whole product)
Entry intercept when the incident is broad and unavoidable
Canonical details page with trust requirements (scope + last updated + next steps)
Why no ETA: we rarely had a reliable “back at X time,” and keeping that updated in UI would be costly and risky. Instead, we used “as soon as possible” plus a “last updated” timestamp to give reassurance with information we could actually keep fresh.
Impact
Speed: Engineering reported time to publish in-app incident comms dropped from ~6 hours to minutes (engineering metric - comms/publish time).
Leverage: This became a reusable SDUI incident pattern other teams could replicate - not a one-off Credit fix.
What we set up to measure (post-launch): incident UI reach + user actions; support contact rate among exposed users; and publish speed during incidents.
Learnings & next steps
Reliability communication is a product system — not an error message. At scale, scope + entry point are what keep UX consistent without over-blocking.
If I had more time, I’d improve two things:
Operational autonomy: enable Support/Comms to update status + “last updated” via a lightweight admin control (less dependency on Engineering).
Company-wide consistency: validate this pattern across other domains beyond Credit to cover a broader set of error/incident scenarios with the same system logic.
