What compliance taught me about design

Early in my career, I treated compliance requirements the way most designers do: as constraints that got in the way of good design. Rules to work around. Boxes to tick.

That changed.

Working closely with legal, risk, and compliance teams — not just handing off to them — gave me a different view. Constraints aren’t the enemy of good design. In regulated contexts, they often are the design.

Constraints as design inputs

When a regulation requires that users be shown a specific piece of information at a specific point in a journey, the design question isn’t “how do we satisfy this?” It’s “how do we make this genuinely useful?”

Those two questions produce very different outcomes.

The first produces bolted-on disclaimers, buried in legal language, that nobody reads. The second produces moments of real clarity — where the user understands something they needed to understand, because the design made it possible.

What working with compliance taught me

Precision matters. Legal language is precise for a reason. Good design in regulated contexts finds a way to preserve that precision while making it accessible. This is hard. It’s also worth doing.

Risk appetite is a design input. What a business is and isn’t willing to accept shapes what can be built. Understanding those trade-offs — not just as blockers but as context — makes for better decisions.

The audit trail is the experience. In regulated products, the record of what happened is as important as what happened. Designing for auditability — what was shown, when, to whom, what they confirmed — is part of the job.

The broader point

Regulated environments make certain design failures very visible, very fast. That’s uncomfortable. It’s also clarifying.

It’s taught me to ask earlier: what could go wrong here? Who is most at risk if this doesn’t work? What does the system need to protect against?

Those are good questions in any design context. In regulated ones, they’re not optional.