Designing a Program & Plan Configuration System for Embedded Protection Products
Category
InsurTech / Embedded Insurance
/
/
A zero-to-one self-serve tool that let Ops teams launch partner insurance programs without developer dependency.
Project Snapshot
Role: Product Designer, end-to-end ownership
Timeline: ~2-3 weeks (design phase)
Team: Product Manager, Engineering, Business Ops
Context: Assurekit's ops platform helps internal teams configure and launch protection offerings for business partners. Programs and plans were previously set up directly in the backend by developers, invisible to the Ops team.
Problem: Ops teams were accountable for launching partner offerings but had no control over the configuration process. Every setup required engineering involvement.
Goal: Give Ops teams a self-serve way to create and manage programs and plans directly in the platform, without increasing the risk of errors in a financially sensitive domain.
Outcome: Ops teams can now configure and launch offerings independently. Roughly 45 minutes of engineering time saved per program. More importantly, the process has clear ownership, structured inputs, and built-in safeguards for a domain where mistakes aren't easily undone.
Project Snapshot
Role: Product Designer, end-to-end ownership
Timeline: ~2-3 weeks (design phase)
Team: Product Manager, Engineering, Business Ops
Context: Assurekit's ops platform helps internal teams configure and launch protection offerings for business partners. Programs and plans were previously set up directly in the backend by developers, invisible to the Ops team.
Problem: Ops teams were accountable for launching partner offerings but had no control over the configuration process. Every setup required engineering involvement.
Goal: Give Ops teams a self-serve way to create and manage programs and plans directly in the platform, without increasing the risk of errors in a financially sensitive domain.
Outcome: Ops teams can now configure and launch offerings independently. Roughly 45 minutes of engineering time saved per program. More importantly, the process has clear ownership, structured inputs, and built-in safeguards for a domain where mistakes aren't easily undone.
The Premise
The Domain: What Business Are We In?
Assurekit is an Embedded InsurTech Platform. Embedded protection lets businesses offer coverage directly inside their own product without the customer ever leaving the platform. A fintech might offer merchant protection. A logistics company might offer shipment coverage. The partner doesn't build any of it, Assurekit's infrastructure and insurer partnerships handle that.
A few parties make this work: the partner who distributes, the insurer who underwrites the risk, service providers for additional services, and Assurekit providing the infrastructure and claim support.
The stakes are real. Configuration decisions affect pricing, claims eligibility, policy validity, and how money flows between everyone involved. A wrong setup doesn't just cause a bug, it can trigger policy disputes, financial leakage, or break a partner's trust in the platform.
The Product: What Assurekit Built
Assurekit's ops platform is where the internal team manages the full ecosystem: partner onboarding, product configuration, plan setup, claims processing, policy lifecycle, and financial tracking.
Everything inside the platform follows a three-level hierarchy:
Partner → Program → Plan.
Partner, the business distributing the protection product to its customers. Program, the configured setup built for that partner, tying together the partner, the selected product, and relevant stakeholders into one operational unit. Plan, what the end customer actually sees and buys, pricing, coverage conditions, exclusions, tenure, and value-added services all live here.
Think of Programs as the container, Plans as what lives inside it. Before this project, the platform could show data and surface analytics, but creating or configuring a program required backend intervention from developers. The Ops team had no visibility into that process, let alone control over it.
The Users: Who This Was Designed For
The primary users were internal Business Operations teams, measured on speed of partner launches, accuracy of program setup, and coordination across stakeholders, but without ownership of the backend system. Every configuration change, even small ones, required a developer to implement it.
The core tension: they were accountable for getting things right, with no direct control over how things got implemented.
Three pressures they worked under: Irreversibility risk, once policies were sold under a configuration, certain fields couldn't be changed. A mistake had real financial and reputational consequences. Information ambiguity, configuration details came through conversations and documents, not structured systems. Missing fields meant incorrect setup, often discovered too late. Cross-team dependency, launch timelines depended on developer availability. Ops owned the outcome, Engineering owned the execution.
Their mental model was partner-first and launch-oriented: which partner, which product are they selling, what plans are live. That gap between accountability and control became the foundation for the design direction.
The Overall Problem
When Assurekit started, the number of partners and offerings was small enough to manage manually. Developers handled configuration directly in the backend. Ops gathered the details, passed them to engineering, and validated the setup after the fact. It worked, until it didn't.
As the company grew, more partners came on, more product variations, more plans per program. The operational load scaled up, the process didn't.
A typical launch: business finalized details with the partner, Ops collected configuration inputs over calls and email, information was consolidated and handed to developers, developers implemented the configuration in the backend, Ops validated the setup after implementation. Five steps, no structured input framework, no direct visibility for the people accountable for the outcome.
Every step introduced a potential failure point. Details got lost between calls and emails. Configurations were built on assumptions when inputs were unclear. The whole process sat in a developer queue, meaning launch timelines were never fully in Ops hands.
This wasn't one broken feature. It was the accumulation of manual steps, scattered information, and dependency chains across teams. The goal wasn't just to remove the engineering dependency, it was to give Ops real control without increasing the risk of getting things wrong.
My Role
I was the sole designer on this initiative, working directly with a Product Manager. This was a zero-to-one project with no prior design decisions to build on. The work started with understanding how the backend was structured and why, before a single screen was designed.
My ownership covered the full process: mapping entity relationships and configuration logic, defining user flows, designing high-fidelity interfaces, and iterating with stakeholders before anything went to development. I worked across three teams, Product for business rules and prioritization, Business Operations for workflow validation, Engineering for feasibility and system constraints.
The core design challenge wasn't visual, it was translational. Taking a complex backend structure and a high-stakes operational workflow, and turning it into something an Ops team could use confidently without developer support.
Constraints & design problem
Defining the Constraints
Before any wireframes, I needed to understand what the design couldn't do. These weren't edge cases, they were hard boundaries set by regulation, existing architecture, and financial accountability.
Compliance came first. Certain fields aren't optional, regulatory requirements mean a program or plan simply cannot be created without specific information captured upfront. The interface had to enforce this, not just suggest it.
The entity structure was already defined. A Program must exist under a Partner. A Plan must exist under a Program. Stakeholders must be associated at the program level during setup. This wasn't a constraint to work around, it was the logic the interface needed to make legible.
Plan configurations lock at activation, permanently. Once a plan goes live and policies are sold under it, core fields, pricing, coverage, benefits, none of it can change. If a structural change is needed, a new plan has to be created. The design had to make this boundary visible and prevent accidental edits, not just block them after the fact.
Working within these boundaries wasn't a limitation, it was the brief. Every interaction pattern had to account for what couldn't be undone.
Navigating These Constraints
Four design problems emerged from the constraints.
Matching the interface to how Ops teams actually think. Ops teams don't think in database entities, they think in partners, offerings, and launches. The interface had to present information in the language they already used, while staying true to the underlying system structure.
Making the line between setup and live feel real. Core plan details lock once policies are sold. The design needed to make that transition impossible to miss, a clear felt distinction between a plan being configured and a plan that's active.
Catching mistakes before they become policy errors. Plan setup involves a lot of sensitive information filled in across multiple steps. The design needed natural review points built into the flow, not friction for its own sake, friction that served a purpose.
Enabling reuse without silently inheriting errors. Ops teams frequently launch similar offerings across different partners. Cloning saves time but carries risk, outdated details, wrong stakeholders, incorrect pricing. The system needed to support reuse while making sure each new setup was deliberately reviewed before going live.
Exploration & Iteration
Version 1 — Getting the Structure on the Table
The first version wasn't meant to be perfect. It was meant to make the full configuration flow visible so product and business stakeholders could react to something real.
The first version established the base model: Programs under a partner, plans within each program, financial distribution at the program level. Covers, exclusions, and value-added services all in a single configuration screen. Plans saveable as drafts, but only as a whole.
📷 V1 plan configuration screen
Two structural assumptions turned out to be wrong. Financial distribution was in the wrong place, putting it at the program level assumed all plans within a program would follow the same revenue allocation. Real examples showed that wasn't true, a base plan and a premium plan with additional services naturally have different distribution rules. Financial distribution moved to the plan level before development began.
Coverage triggers weren't structured clearly. Each coverage is activated by a specific condition or event. V1 had no structured way to define when a benefit applies or what triggers a claim. That required rethinking how covers were defined in the interface entirely.
Version 2 — Making It Safer and Easier to Use
Section-by-section saving. Plan setup involves a lot of information, completing everything at once increases mistakes and creates anxiety around losing progress. V2 broke configuration into clear sections, each saveable independently.
📷 Plan configuration with section tabs
Managing multiple plans without losing context. Programs typically contain multiple plans, basic and premium variants, for example. Instead of stacking them in one long scrollable page, each plan became viewable and editable separately while staying visible within the same program.
📷 Program page showing multiple plans
Supporting reuse through cloning. The system allows users to clone an existing program or plan, copying all configurations, plans, and financial distribution rules, then adjust details before saving.
📷 Clone program modal
The system went from a basic representation of configuration logic to something that reflected how Ops teams actually work, not by adding more, by correcting the assumptions that didn't hold up against real scenarios.
Validation
Once the refined design was ready, it was reviewed with product and business teams before moving to development. Because this system directly affects financial records and policy history, validation focused on logic and workflow correctness, not visual styling.
Validating the Configuration Logic
We ran walkthroughs working through real examples: creating a program for a new partner, setting up multiple plans within that program, configuring financial distribution across different plans, defining coverage conditions and benefit triggers.
📷 Program creation flow overview
This is also where we validated the financial distribution change, confirming that plans within the same program could carry different configurations independently, that revenue distribution reflected actual plan variation, and that the program structure above remained intact.
Reviewing Activation and Plan Stability
The difference between a plan being configured and a plan that's live needed to be impossible to miss, not just labelled. We reviewed how the system handled all three states: Draft (still being configured, all fields editable), Active (live and selling, core fields locked), Inactive (no longer offered, historical data intact).
📷 Program page showing plan states, Draft / Active / Inactive
Reviewing the End-to-End Flow
We reviewed the complete journey from starting a new program to having a plan ready to go live, checking for clarity across steps, meaningful review points, and whether the interface stayed manageable as complexity increased. The flow held up for day-to-day operational use, not just as a concept, but as something the Ops team could see themselves working in. Not just impressive in a demo but Practical on a Tuesday morning.
Final Flow
The final system follows the natural hierarchy of the business model:
Partner → Program → Plan.
Selecting a Partner
Every program starts with the partner. This keeps all programs, plans, and policies organised under the correct business entity from the beginning, and keeps launches traceable.
📷 Client lists / Partner detail page
Create a Program
Users define the product type, stakeholders, and required operational details. The interface reveals inputs progressively, one group at a time, rather than presenting everything at once, reducing the chance of something being missed or assumed.
📷 Create Program modal
Configuring Plans
All plans sit within the program page, visible together. This keeps the relationship between variants clear and makes it easy to manage them without losing context of what else exists under the same program.
📷 Program detail page with multiple plans
Defining Plan Details
Plan configuration is broken into distinct sections, each saveable independently. Users can complete what they have, step away, and return without losing progress.
📷 Plan configuration interface
Setting Financial Distribution
Configured at the plan level, not the program level. Different plans under the same program can each define their own distribution rules, reflecting how offerings actually vary in practice.
📷 Transaction / financial distribution section
Defining Coverage and Conditions
Each coverage entry specifies what benefit is provided, what condition triggers it, and any associated rules or limits. How coverage is defined here directly affects claims eligibility downstream.
📷 Cover configuration screen
Activating the Plan
Activation is the point of no return. Once a plan is live, its core configuration is locked, pricing, coverage, benefits. That's not a system limitation, it's a deliberate safeguard.
📷 Program page showing plan states, Draft / Active / Inactive
Reusing Existing Structures
Cloning copies the full configuration, financial distribution, coverage setup, all of it, so teams can start from a working structure and adjust details before saving.
📷 Clone program modal
Outcome
Faster launches, less engineering load. Before, every new program required a developer. After, Ops handled it directly, removing roughly 45 minutes of engineering time per program and the scheduling dependency that was quietly slowing every launch down. At scale, that compounds fast.
Fewer errors, lower risk. Configuration mistakes in this domain aren't just annoying, certain fields can't be changed once policies are sold. Structured inputs and clear required fields reduced the ambiguity that caused those mistakes.
Ops could scale without pulling in engineering. As partner volume grew, engineering involvement didn't have to grow with it. Programs were structured consistently, launched independently, and tracked clearly.
A clearer sense of ownership. The Ops team went from submitting requests and waiting, to running the process themselves. Accountability became clearer because control became clearer. The guardrails were built into the tool, so autonomy didn't come at the cost of correctness.
Reflection
The biggest thing this project reinforced: designing for complex domains isn't about simplifying the complexity. It's about organising it well enough that people can work through it confidently and safely.
The financial distribution change, catching it during the design stage, before development, is the kind of thing that's easy to underestimate. A structural assumption that seems reasonable in the abstract can fall apart quickly against real scenarios. The earlier that happens, the cheaper it is to fix.
Operational safety was the other lesson. It's not a feature to add at the end. It has to be designed into the flow from the beginning, because the consequences of getting it wrong aren't recoverable.
This system handles program and plan creation well. What it doesn't yet address is what comes after, managing a growing library of programs at scale, and giving teams visibility into how plans are performing once they're live. Those are the next real problems, worth solving properly.
