Designing the Risk Engine With R&D, Not At Them

The Risk Engine on BlackSwan was never going to survive a design-throws-it-over-the-wall workflow. Turning module weights, geographic rules, and PEP/sanctions thresholds into a visual, real-time, auditable decision system meant the design had to respect what the engine could actually compute and how fast. So I worked with R&D the way an engineering leader would want: early, concretely, and with the hard constraints on the table first. Restructuring nested configuration forms into four core engines with drill-down rules was as much a data-model conversation as a UI one. "Real-time" and "auditable" are promises the backend has to keep, so we negotiated where state lived, how changes propagated, and what an audit trail had to capture — before I committed those behaviors in the design. Because I was solo on design, the Design System became our shared contract: consistent components and patterns meant engineers weren't reverse-engineering one-off layouts across five surfaces. The result was fewer surprises at build time. I'd rather hear "that's expensive" in a whiteboard session than discover it in a sprint review, and that's the kind of friction I actively design for.
Related articles

About
Making complicated into easy for users.
Senior product designer with a decade of work across complex systems - financial risk platforms, legal operations, healthcare apps, manufacturing tooling and insurance portals. The common thread is depth: products where the data is rich, the users are expert, and the interface has to disappear into the work.