How can a small insurer launch a product page without waiting on developers?

Launchpad is a modular page builder for small and mid-sized insurers — the ones who need to move quickly and have no in-house engineering team to move with. Before it, a new campaign or a product update meant a custom build, and a release regularly took more than three months.

Marketing briefed product, product queued behind developers, and even a copy change needed engineering time. Page structure and quality drifted between products and between brands, because nothing was shared.

Launchpad replaces that with a template-driven CMS built specifically for insurance: assemble a page from reusable blocks, configure the forms, upload the assets, publish the whole purchase flow — without writing code. I owned UI and interaction design across the editor, and took over UX for new features as the product grew.

1. Remove the developer from routine changes

   A layout tweak or a copy fix should not need an engineering ticket.
2. Standardise page quality

   One structure, so output does not drift between products and brands.
3. Shorten time to market

   Take a release from months to weeks by removing the custom build.
4. Stay usable by non-technical teams

   The people building pages are marketers and operations staff, not engineers.

Three pain points came back in every internal conversation, and all three trace to the same root: nothing on the page was reusable, so everything was a build.

1. Developer dependency for trivial changes

   Even a layout adjustment or a content update had to be queued through engineering, which put a specialist in the path of routine work.
2. Inconsistent structure and quality

   Page composition varied between products and between brands, because each one had been built on its own.
3. Three months to launch or update — the compounding effect

   Briefing, waiting, building and testing stacked up, and the delay was long enough to change what a campaign was for.

Working without end users

So the evidence came from the people who sat closest to them: business, onboarding and support, all of whom spent their days absorbing the consequences of the current process. Every insight here is second-hand by construction — I have not presented it as anything else, and the design decisions were biased toward reversible, structural choices rather than bets on specific user behaviour.

Task mapping

I mapped what a non-technical user actually has to do to get a product page live: choose a layout, edit the content, configure the forms and steps, then check the result before publishing. Prioritising those four and refusing the edge cases is what kept the editor predictable — a builder that supports everything ends up teaching nothing.

Two things were fixed before design started. The editor could not render a true live preview, and the visual style had to disappear behind someone else’s brand.

Neither was negotiable, and both point the same way: this is not a product that can win on expression. The first version explored a more characterful interface — soft shadows, rounded corners, blur. Stakeholder review made it clear that anything with a personality of its own would fight the insurers’ own brand guidelines, so the style was pulled back to something neutral and structural.

The preview limitation was the harder one. A page builder without live preview asks the user to publish on faith, which is exactly the moment a non-technical user stops trusting the tool. Rather than treat it as a fixed constraint, I proposed a Standard API integration that binds real product data into the editor, so what the user sees while editing is at least structurally the page they will get.

These figures are projections and early partner feedback, not measured results. I left before there was a production dataset to check them against, and I am not going to present them as more than they are.

• A structure the team could extend. New modules inherit the existing atomic components and semantic tokens, so adding one is composition rather than design work.
• Handoff got cheaper. Naming states in the token system meant the specs no longer had to describe them, which removed a whole category of back-and-forth.
• The editing model held. Late-stage features — new flows, deeper module configuration — fitted inside the original interaction model rather than forcing an exception to it.

What I took from it

1. Balance ambition against how teams actually work

   Designing for a traditional industry means calibrating against real workflows and real tooling maturity. An ambitious feature that does not fit how the team operates is not ambitious, it is unused.
2. Domain understanding is the design work

   Insurance business rules are largely undocumented and live in people’s heads. Getting them out through expert interviews, and turning them into a structure a marketer can operate, was the substance of this project — not the interface on top.