Insurance & InsurTech Design Services

A landing page with a price on it proves little; the test is whether they have designed a real quote. Ask to see how they handled conditional questions, a vehicle that could not be found, a price that changed after an edit, and the moment the quote hands over to purchase. Then ask what they needed from the pricing system, how they worked with whoever owns the question set, what share of their design actually launched, and which designers you would actually get.

A question and logic map, the quote flow with personal, vehicle and cover details, the price and cover options, the handoff to purchase, the states between them, and the finished UI with a prototype. The price depends on the number of products and questions, how much logic links them, the platforms, whether the quote is already live, and what the pricing system returns. We quote each project in its own proposal rather than from a rate card, and set the schedule once scope, access and the pricing API are clear.

Customers quoting for themselves; brokers or agents quoting for a client; and the support and operations staff who pick up a quote when someone calls. The workflows are the questionnaire, look-ups for an address or a vehicle, extra drivers or insured items, the returned price and cover options, saving and returning to a quote, and the step into purchase and documents. Claims journeys and underwriting tools are separate products with their own scope. The customer and the broker answer the same questions for different reasons: a customer quotes once a year and needs each question explained, while a broker quotes all day and needs speed, keyboard entry and every answer on one screen.

A new product or line of cover is InsurTech design from scratch, which is UI/UX & Product Design. Desktop quotes and broker tools belong to Web App Design, and quoting or checking cover on a phone to Mobile App Design. When a live quote already leaks customers, a UX Audit goes first. When the open question is collecting money, refunds or payouts, Payment Product Design fits better.

Your underwriting, compliance and legal teams own the rules and the words; we design how they are asked and shown. That covers which questions must be asked and in what order, where required statements and documents appear, how a refusal to quote is explained, and how a price and its conditions read before purchase. We do not set prices, judge risk or check that a product meets the rules that apply to it. A clearer questionnaire does not make a policy compliant, and our work is never offered as proof that it is.

A live or staging quote with test data that still returns real prices; the full question set, the rules behind it and who owns each rule; any evidence of where quotes are abandoned or corrected; one decision-maker; and time with engineering and whoever runs the pricing or insurer API, so the API's limits are known early. If you can, share recordings or notes from support calls about the quote: they show which questions people misread, and which answers they later ask to change.

Yes. Our insurance work covers quote forms, the price returned by the pricing system, and the handoff to buying the policy, with revisions delivered for desktop. The insurer stays unnamed because the project has no public case study, but we can take you through the work on a call. Claims and underwriting tools we would approach with the same method, without claiming a record in either.

Yes. Most insurance work starts from a quote already in use and a pricing system that will not change. The design follows what that system asks for and returns, lives in your own design files and system, is made together with your product team, and is handed over in full. When the pricing system is slow or strict about formats, the design allows for it — with clear waiting states, answers checked before they are sent, and a way back to the question that caused a problem.