Before we designed a single screen of the Undwrlyft Workbench, we spent months watching underwriters work. Not demos. Not requirements interviews. Actually sitting next to underwriters at their desks — sometimes literally — as they processed submissions in the normal course of their day.
What you observe in those sessions doesn't match what underwriters say when you ask them about their workflow in a meeting room. People describe the idealized version of their process. What they actually do involves workarounds, heuristics, and patterns of information access that developed over years of working around inadequate tooling. Designing useful software for an experienced professional means understanding the workarounds, not just the stated requirements.
The five principles below emerged from that observation process. They're not exhaustive, and they're not theoretical — each one represents something we got wrong in an early prototype and fixed after watching it fail in use.
Principle 1: The submission is the primary object, not the task
Most enterprise workflow software organizes around tasks — a to-do item to be completed, checked off, and closed. Insurance underwriting doesn't work that way. A submission is an object with a lifecycle: it's received, evaluated, possibly returned for more information, priced, quoted or declined, followed up on, and eventually bound or closed. At any point in that lifecycle, multiple people may need to interact with it — the assigned underwriter, a senior reviewer, a support analyst looking up prior carrier data, an underwriting assistant handling documentation.
The early Workbench prototype organized around tasks, and it immediately fell apart when an underwriter needed to find a submission they'd partially worked and return to it. The submission had become a completed task (information review) with a pending task (pricing) and a blocked task (awaiting loss runs from broker), none of which made it easy to see where the submission actually was in its lifecycle.
Redesigning around the submission as the primary object — with a persistent view of the submission's current state, its history of interactions, its outstanding information gaps, and its queue position — is what made the Workbench actually usable as an underwriting tool rather than a generic task manager with insurance field labels.
Principle 2: Surface anomalies, don't make decisions
Early discussions about underwriter workbench design in the insurtech space often conflate "AI-assisted" with "AI-decides." The systems that use AI to tell underwriters what decision to make misunderstand how experienced underwriters work — and they misunderstand why those underwriters are valuable.
What underwriters want from an automated system is anomaly detection, not decision support. "The NAIC code on this submission is 23731 (Roofing Contractors) but the description of operations includes residential painting — these may not match" is useful. "This submission should be declined" is not useful — it provokes distrust and bypasses the judgment the underwriter is supposed to apply.
The Workbench flags anomalies in a dedicated review panel: NAIC code mismatches against description of operations, loss frequency patterns that are statistical outliers for the class, missing policy periods in the loss run history, attachment point changes relative to prior carrier coverage terms, large individual losses that exceed a configurable threshold. The underwriter decides what to do with each flag. Some flags are explainable and don't affect the decision. Some change the pricing. Some trigger a referral.
The design principle — surface, don't decide — requires restraint in what gets flagged. A system that surfaces thirty anomalies on every submission trains underwriters to ignore the flags. The effective ones surface three to five high-quality signals that the underwriter actually learns to look for.
Principle 3: Information access should match how underwriters think, not how data is stored
Underwriters approach a submission with a mental model of what they're looking for: operations description, prior losses by year and type, current limits and retention structure, any unusual conditions or exposures. They don't think in terms of database tables or document sections.
Standard SaaS design patterns organize information by its storage structure — fields in a form, tabs for different data categories, a navigation hierarchy that reflects the database schema. That works fine for data entry applications. For an underwriter reviewing a complex submission, it creates constant friction as they search for the next piece of information they need in a structure that doesn't match their mental model of the risk.
We're not saying our design perfectly solves this — it's an ongoing problem and we iterate on it. What we learned is that the layout of the review panel should match the sequence in which an underwriter typically evaluates a submission: insured identification and operations first, then exposure summary, then loss history with year-by-year breakdown, then current coverage structure and terms being requested. That sequence isn't universal, but it matches how specialty lines underwriters approach most risk classes, and organizing the display to match that sequence reduces the cognitive load of finding the next relevant piece of information.
Principle 4: The pre-fill and the source document need to be visible simultaneously
When an automated system pre-fills a pricing model field, the experienced underwriter's instinct is to verify it against the source. This is correct and appropriate — extraction accuracy is high but not perfect, and the underwriter's name goes on the quote. The design question is how much friction the verification process creates.
In early workbench designs, verification meant opening a separate PDF viewer, finding the relevant page, and visually confirming the extracted value against the document. For a pricing model with twenty-five pre-filled fields sourced from multiple documents, this verification process was prohibitively slow — slower, in some cases, than just re-entering the values from scratch.
The design solution is side-by-side display: the pre-filled pricing model on the left, the source document rendering (with the relevant extracted region highlighted) on the right. When the underwriter clicks on a pre-filled field, the source panel jumps to the page and location where that value was extracted. Verification becomes a one-click action rather than a search-and-scan process. Extraction accuracy above roughly 90% becomes a usable baseline when verification is that fast; the same accuracy with a cumbersome verification workflow produces rejection of the automation tool.
Principle 5: Queue management is not a support function — it's underwriting strategy
The queue is where underwriting resource allocation happens. Which submissions get worked in what order, by which underwriters, with what time constraints — these decisions are underwriting strategy expressed as operational choices. Senior underwriters and underwriting managers care deeply about queue management and feel the effects of queue problems immediately in their workload and their broker relationships.
Standard workflow tools treat queue management as a scheduling or ticketing function — submissions are prioritized by receipt time, due date, or some automated score. That's fine for help desk tickets. For a specialty lines underwriting operation, the prioritization criteria are more nuanced: broker relationship value, risk class expertise of available underwriters, information completeness (incomplete submissions should be held rather than consuming underwriter analysis time), renewal proximity, and market conditions affecting specific classes.
The Workbench queue management panel exposes these controls explicitly to underwriting managers rather than implementing a fixed prioritization algorithm. The manager can see the queue segmented by information completeness, risk class, broker, and time in queue. They can reassign submissions, hold incomplete ones pending information arrival, and set flags for submissions that need senior review. The queue is treated as a management tool, not a background process.
Eighteen months of observation before design produced a system that experienced underwriters actually want to use, rather than work around. That distinction — useful versus tolerated — is the difference between a technology investment that changes how a team operates and one that adds cost without changing behavior. The design principles aren't clever engineering choices. They're what happens when you pay attention to how people actually work.
