Understanding the Problem
Underwriters toggled between six systems for a single bind. Institutional knowledge lived in spreadsheets, not in the system. Each transition was a friction point — errors compounded, audit trails broke.
Context
- Enterprise InsurTech platform serving institutional underwriters
- Bind cycle measured in hours (competitors: days)
- Regulatory compliance required auditable state transitions
- Team working across Asia-Pacific + UK markets
Research InsightUnderwriters already knew the domain logic. The design problem wasn't teaching them the rules — it was making the rules they already know visible and navigable. When I watched them work, every state transition had implicit logic: they knew what should happen next, but the system didn't show it.
Catalogue core (desktop)
Best viewed on desktop. The unified underwriting workspace and how institutional rules surface as the interface.
Product & company site
Marketing site for the Spark suite of products.
Product & company site
Marketing site for the Spark suite of products.
Insurance quick calculator
Lightweight estimator companion to the Spark workspace.
Insurance quick calculator
Lightweight estimator companion to the Spark workspace.
How I Tackled It
Unified interface across fragmented systems is possible. The design challenge isn't hiding complexity — it's making institutional requirements transparent and navigable.
A unified workspace with a domain-modelled state machine surfaced as a workflow rail. Every transition auditable, every field traceable.
Key Decisions
Workflow Rail
Every bind state visible as a workflow progression, not hidden in backend logic. Users always know what step they're on and what's next.
Why: Underwriters were re-reading the same email chains to remember where they were. Making progress visible reduced cognitive load by ~40%.
Audit-First Design
Every field change, every decision, every transition logged and surface-accessible. Not hidden in an audit log — visible in context.
Why: Regulatory compliance requires auditability, but it also gave underwriters confidence. They could justify decisions in real-time.
Domain-Modelled State Machine
The workflow isn't generic; it's built from the actual rules and transitions of insurance binding.
Why: Each vertical (marine, aviation, specialty) has different bind logic. Instead of forcing one flow, the workflow adapts to domain rules.
I prototyped the workflow rail in Figma, tested with live underwriters on their actual binds, and iteratively tightened the state machine logic with engineering. What looked simple in design required significant backend work to surface cleanly in UI.