One product model, three role-based experiences

InsureBid began as a business model without a digital product foundation. The founder understood the insurance opportunity and the operating model, but the company had no brand, product architecture, customer experience, broker workspace, administrator tooling or shared design system.

My responsibility was to turn that model into a coherent product serving three audiences with different goals. Customers needed to understand coverage and complete high-stakes tasks with confidence. Brokers needed visibility into clients, sales, policies and commissions. Administrators needed efficient tools for monitoring and resolving work across the platform.

The design problem was therefore larger than a set of screens. I needed to define which information belonged to the product, how the same records changed by role, where actions entered and left each workflow, and which patterns could be reused without making the three experiences feel identical.

A policy illustrates the challenge. A customer needs to understand what it covers and how to make a claim. A broker needs to see the customer relationship and the commercial activity around it. An administrator needs to monitor its status, investigate exceptions and take operational action.

The underlying policy is the same. The information hierarchy, permissions and available actions are not.

I worked directly with the founder and owned the design from product definition through handoff. The role combined strategy and execution because the product, the brand and the component foundation all had to be established at the same time.

The main constraint was the absence of live users. Discovery relied on the founder’s domain knowledge, competitive analysis and established UX principles. Those inputs were useful for defining an initial model, but they could not confirm how prospective customers or brokers would behave — so I treated behavioural statements as hypotheses rather than findings.

The three-month timeline also forced prioritisation. Rather than designing every possible insurance edge case, I focused on the structural decisions that would be expensive to reverse later: the shared data model, role-specific navigation, primary workflows, management patterns, brand direction and reusable components.

I compared the original design rationale with external evidence. These sources are directional benchmarks — not proof that InsureBid’s users would behave the same way. They help explain which assumptions were reasonable and which still require product-specific research.

Before designing individual screens, I mapped the records that move through the insurance lifecycle: users, quotes, policies, claims, transactions, commissions and service requests. That gave the three products a common vocabulary and removed the risk of defining the same concept differently in each interface.

The customer product was designed around two high-value journeys: selecting and purchasing suitable coverage, and getting support when a claim is needed. In both, the interface had to explain insurance concepts without making the user feel responsible for understanding internal insurance operations.

The initial concept could have placed every quote input in one long form. I divided the journey into five stages, each centred on a different decision — supported by W3C guidance on splitting long forms and communicating progress, and GOV.UK guidance on focused question pages and a review step before submission.^[4][5][6]

A claim is a high-consequence moment: the customer must understand eligibility, provide evidence and wait for a decision. I structured the flow around one primary action per step, visible progress, document upload and explicit confirmation. W3C also requires status information to be available to assistive technologies when an action succeeds, fails or remains in progress.^[8]

I removed the permanent File a Claim button from the primary dashboard hierarchy. The intention was to keep routine policy management from being visually dominated by a stressful event that many users would rarely need. This was a prioritisation decision — not evidence that the action was unimportant.

Brokers needed to move between customer context and commercial activity without reconstructing the relationship from separate systems. The dashboard prioritised earnings, active policies, conversion activity, client activity and verification status.

The client area worked as a lightweight CRM workspace, bringing together customer details, policy history and account status so a broker could see what had happened and what required attention. The objective was to make the next useful action apparent — following up with a customer, reviewing a policy, or checking a commission state.

The channel decision is supported directionally by EIOPA’s 2025 survey: only-online, only-agent-or-phone and mixed purchasing all remained meaningful behaviours in the EU sample.^[1] For InsureBid, that justified designing customer self-service and broker workflows as complementary parts of one system. It did not establish which channel the target market would prefer — that remained a research question.

Administrators needed a denser operational workspace. Instead of inventing a different interaction model for every data type, I used one recurring management pattern: a table or queue, filters, visible status, contextual actions and a detail view. It was a pattern rather than a fixed sequence — each module adapts the same structure to its data and decisions.

Consistency mattered because operational work means switching between policies, claims, transactions, users and requests. Reusing the same interaction logic was intended to reduce relearning and implementation drift — an intended effect that should be validated through task time, error rate and administrator interviews rather than stated as a measured outcome.

The role model also required clear access boundaries. Using NIST’s role-based access control model as an architectural checkpoint,^[7] each administrative action needed an owner, a permitted role, a visible state change and an audit expectation. Detailed authorisation and security rules still required validation with engineering and the relevant compliance owner.

The design system connected the three products at the interaction level: navigation, forms, tables, cards, buttons, modals and status indicators, with reusable patterns for data management, progress, selection, confirmation and detail views.

The system did not require every screen to look identical. Customer screens could use more guidance and space; broker and administrator screens could carry more information. The shared layer defined behaviour, hierarchy, terminology and component logic so the products felt related and developers did not have to reinterpret common interactions for each surface — consistent with the U.S. Web Design System’s emphasis on continuity across services, clear multi-step processes and shared solutions.^[9]

The brand needed to feel credible without becoming cold. Structured layouts and calm colours were the default visual language, with friendlier elements reserved for onboarding and low-risk moments. The mascot and illustrations were deliberately limited during payments and claims, where precise information and clear feedback matter more than playfulness — treating trust as an outcome of behaviour rather than decoration.^[1][3]

The homepage moved from a catalogue of services toward an explanation of why a prospective customer should consider the platform. The change did not remove product discovery — it changed the order of information, so identity, credibility, coverage categories and common objections appeared before a broad feature inventory.

At the end of three months the project had moved from a founder’s business concept to a design foundation prepared for implementation. The delivered scope included the brand identity, marketing website, authentication experience, customer insurance platform, broker management platform, administrator operations platform, reusable components and prototypes for developer handoff.

The project demonstrated breadth and systems thinking, but its largest limitation was the lack of behavioural evidence. The next step is to test the riskiest assumptions by role — not to ask participants whether they liked the interface.

InsureBid required me to work across product strategy, service architecture, interface design, brand and implementation planning. The most important contribution was not the number of surfaces designed — it was defining a shared system that could present the same insurance lifecycle differently to customers, brokers and administrators.

The project also clarified the difference between a coherent design and a validated product. The design established a credible starting point; research with representative users, accessibility testing, production data and operational feedback would determine whether it actually improved understanding and performance.

These sources support the retrospective design rationale. They are not research conducted with InsureBid’s own users, and regional regulatory guidance is used as a design benchmark rather than a compliance claim.