Every product team building in financial services eventually hits the same wall: a compliance requirement that seems to demand an extra screen, an extra disclosure, an extra moment of friction. The reflex is to treat this as a tax on the experience — something to minimise, hide, or apologise for. That reflex is usually wrong.

Constraints are not the opposite of good design; they’re raw material for it. A KYC step framed as bureaucracy feels like an obstacle. The same step framed as “here’s exactly what we’re checking and why” becomes a moment of trust-building, because the user finally understands what the system is doing with their information and why it matters.

“The best fintech teams design with constraints, not around them.”

The teams that get this right treat legal and design as one conversation from the start, not two conversations stitched together at the end. When a compliance officer and a designer sit in the same room early, the resulting flow tends to need fewer screens, not more — because the constraint gets solved once, structurally, instead of being patched over repeatedly.

There’s a pattern I keep seeing in wealth and lending products: the disclosure nobody reads isn’t a UX failure, it’s a sign the disclosure was treated as a legal artifact rather than a product surface. Rewriting it in plain language, breaking it into the moments where it’s actually relevant, and giving people a real choice rather than a single “I agree” checkbox does more for both compliance and conversion than any redesign of the surrounding screens.

None of this means every constraint is secretly a gift. Some are genuinely painful, and part of the job is pushing back on the ones that exist only because “that’s how it’s always been filed.” But the default posture matters. Start from what the rule is protecting, not from how to route around it, and the resulting product is usually both safer and clearer — which, in financial services, is really the same thing said twice.

Related Posts

Privacy Preference Center