Enterprise B2B · Insurance · 2025
Turning a multi-role insurance platform into shared, role-aware infrastructure
Underwriters, brokers, and customers work the same policies with very different stakes. I moved the product from three forked experiences to one shared data model with role-aware surfaces - and used an AI-assisted design-to-build workflow to change how the whole team shipped, not just what I drew.
Overview
Assureful is an embedded, usage-based commercial insurance platform. The product has to serve three fundamentally different users - an underwriter managing risk and approvals, a broker submitting and tracking business, and an end customer being guided through onboarding - all working over the same underlying policy data. The existing product had drifted toward three loosely-related experiences that duplicated logic and diverged over time. My job was to make it coherent, faster to build on, and better for every role at once.
Problem & context
Multi-role enterprise platforms have a trap built into them. Design one experience for everyone and you get the lowest common denominator - a UI that technically serves three roles and delights none. Fork the experience per role and you get short-term fit but long-term divergence: three codebases, three sets of patterns, and a team that slows to a crawl every time the domain changes.
Assureful was sliding toward the second failure mode. Each role's surface was evolving on its own, the same concepts were modeled differently in different places, and the cost of every new feature was multiplying across roles. The real problem wasn't any single screen - it was the absence of a shared foundation underneath them.
Why it mattered
Underwriting is high-stakes and regulated; a broker's submission and an underwriter's approval and a customer's onboarding are the same transaction seen from three sides. When those views quietly disagree, you don't just get UX friction - you get mistrust, rework, and risk. Getting the shared model right was the difference between a platform that could scale to new lines of business and one that would ossify.
My role
I led design for the platform and acted as the design-engineering partner on the system itself. That meant owning the interaction and IA work across all three roles, but also co-owning decisions that usually sit outside "design": the shape of the shared data model, the component contracts, and the API boundaries where design and data had to evolve together. I worked directly with engineering and underwriting SMEs to make those calls, and set up the working practices the team used to stay aligned as we went.
Key decisions
Treat the schema as the single source of truth; make role surfaces projections over it.
Instead of three products that referenced each other, one canonical model of policy, risk, documents, and approvals - with each role's screen defined as a filtered, RBAC-driven view over that model. Role variance lived in props and view filters, not forked screens.
Co-design the API contract with engineering, early.
The unlock wasn't a design artifact - it was aligning the design system and the data layer at the same time. When the contract was co-owned, the component library and the schema could evolve together instead of drifting, which is what had caused the divergence in the first place.
Build an AI-assisted design-to-build loop the whole team could use.
I prototyped role-aware flows as working React + Tailwind, with Claude and Cursor in the loop, so we could feel real interactions - approval states, document handling, edge cases - before committing to polished mocks. That collapsed the design-to-engineering conversation from a stack of handoff comments into "here's the shape, here's where it broke," and gave the team a faster, shared way to validate decisions. The reusable pieces - role-aware form components, an approval-state pattern, and an onboarding flow template - became defaults the team kept building on.
Tradeoffs & constraints
A shared model is more upfront work and more coordination than shipping a quick role-specific screen - the payoff is deferred. I had to make the case for that patience against near-term feature pressure, and keep the abstraction honest: a shared foundation is only worth it if each role still feels like the product was built for them. Where a role genuinely needed to diverge, I let it - the goal was a coherent whole, not forced uniformity. The AI-assisted prototypes were deliberately disposable; treating them as production code would have traded speed for a different kind of debt.