Stream
An integrated Property & Casualty insurance platform unifying Underwriting, Claims, Billing, and Agency under a single login, shared data model, and design system — transforming a fragmented legacy ecosystem into one coherent, quietly powerful experience.
Context & Background
Stream was the kind of design challenge that does not compress into a single screen or a polished prototype GIF. It unfolded over years, across dozens of whiteboards, through conversations with actuaries, claims adjusters, underwriting managers, and independent agents — and through the slow work of turning a fragmented ecosystem of legacy tools into something coherent and usable.
StoneRiver, a Fiserv business unit, served Property & Casualty carriers with policy administration, claims, billing, and agent management software built over decades. By project kickoff, each module had evolved independently — different architectures, data models, and interfaces. Agents context-switching between tools described the experience as "changing gears in a different car," with errors spiking at every handoff.
The impetus came from two pressures: competitive InsurTech players raising the UX bar, and Fiserv's internal push to modernize insurance as a genuine differentiator. The vision was ambitious — Policy, Claims, Billing, and Agent services under one consistent experience. That product was named Stream.
The Brief
I joined three months after initial product strategy was scoped. Engineering architecture decisions were largely in place. My mandate was threefold: define the UX vision and design principles, build the design system from scratch, and lead UX across all four modules through phased delivery over roughly three years with a team of two additional designers.
The charter looked manageable — four modules, three years, phased delivery. What it did not communicate was the density inside each module. Commercial policy origination alone involves branching underwriting questionnaires hundreds of questions deep, document generation, appetite checking, premium triggers, and state-specific compliance across every licensed jurisdiction. Within six weeks of domain immersion, I recalibrated complexity estimates with product sponsors — not as pushback, but as an honest reframing of what MVP meant when clients run live business from day one of deployment.
Discovery & Research
I spent the first six weeks in structured immersion before generating a single wireframe — reading product documentation, sitting through client onboarding modules, and walking through existing screens with business analysts to understand embedded logic and where users fought the tool.
Research across three carrier client organizations included:
- Contextual inquiry with underwriters and billing specialists in the existing system
- Semi-structured interviews with claims adjusters on task frequency, pain points, and workarounds
- Shadowing independent agents navigating agent-facing tools
- A survey of ~140 active users for task difficulty ratings and feature prioritization
Key findings that shaped the strategy:
- Navigation fragmentation — no consistent model across modules; context-switching caused cognitive load and errors
- Search & retrieval — finding a policy or claim required knowing which module to search first; high-volume users pivoted dozens of times daily
- Invisible conditional logic — users could not tell why fields appeared, greyed out, or invalidated prior answers
- Agent needs differed fundamentally — external agents needed transparency and self-service, not just functionality
"I know this system better than almost anyone on the team. And I still make mistakes in it every week. That should tell you something." — Senior Underwriter, carrier client
Design Strategy
The first major deliverable was a user architecture document — who our users were, what they needed to accomplish, and how goals mapped to platform scope. Primary user types: Underwriter, Claims Adjuster, Billing Specialist, Independent Agent, Supervisor/Manager, and Implementation Consultant.
Four design principles governed every decision:
1. Clarity Before Efficiency
Make system state and workflow position legible before optimizing for fewer clicks — especially when decisions carry real financial consequences.
2. Progressive Disclosure
Surface information relevant to the current task; allow depth on demand rather than overwhelming everyone for edge cases.
3. Consistency as Productivity
Navigation, interaction patterns, and terminology must work the same across modules — a functional requirement, not aesthetics.
4. Trust Through Transparency
Make status, progress, automated decisions, and errors visible in terms that help users resolve them.
We reframed modules to match user mental models: Underwriting (not Policy Administration), Claims, Billing, and Agency — requiring sustained push-back against engineering defaults that exposed data as stored, not as users think about their work.
Building the Design System
I front-loaded a four-week design system sprint before any module work — color (WCAG AA), typography, 8pt grid, component library, icon set, and the application shell including global search and notifications. The persistent left navigation rail won user testing: narrow enough to preserve screen space, module identity clear at a glance, expanding labels on hover.
Designing the Modules
Underwriting
The centerpiece — submission through binding and policy issuance. The underwriting questionnaire, with hundreds of conditional questions, was redesigned as a section-based, progress-tracked experience. Sections showed explicit completion states; conditional sections were announced rather than silently activated; downstream impacts from answer changes flagged sections for re-review. Seven major iteration cycles before UX and underwriting SMEs aligned.
Claims
Organized around the claim lifecycle from First Notice of Loss through closure. A tiered detail model served both supervisor portfolio scans and adjuster deep-dives. The coverage confidence indicator embedded relevant policy coverage in the claim record — eliminating the most friction-heavy cross-system navigation step. Shipped Phase 2 after engineering negotiation on new API integration.
Billing
Built around an attention queue — accounts requiring action, prioritized by urgency and exception type. Imminent cancellation deadlines surfaced first; disputed payments separated from routine runs. Replaced the informal spreadsheets and sticky notes specialists used to track their work.
Agency
Designed for three dominant use cases covering ~80% of agent interactions: checking submission/policy status, pulling certificates and documents, and reviewing renewal actions. The dashboard organized around time — what needs attention now, next 60 days, and what recently changed — matching how agents manage their book of business.
Navigating Complexity
Stream had a complex stakeholder map — Fiserv program leadership, StoneRiver product, engineering leads, and carrier clients. Design frequently translated between product feature requests and engineering phasing constraints, anchoring discussions in research evidence rather than opinion.
I maintained a living assumption log flagging unvalidated domain decisions by risk level, formalized a component champion model pairing designers with engineering leads, and ran sprint-end component audits. Legacy backend constraints were accommodated gracefully — save-and-resume on questionnaires deferred to Phase 2 when the policy system lacked a clean in-progress state.
"Constraints are not the opposite of good design. They are the material good design is made from."
Testing & Validation
Usability testing was continuous — conceptual wireframe validation, task-based prototype testing, and staging validation before each phase release. Task scenarios reflected real work: "you've received a new commercial lines submission for a manufacturing business in Texas…"
Key changes driven by testing:
- Questionnaire progress redesigned after users jumped sections non-linearly, creating dependency problems
- Claims timeline gained "assigned to me" filtering as default for adjusters
- Agent dashboard horizon extended from 30 to 60 days for commercial renewal planning
- Global search changed to cross-module default based on user expectations
Outcomes & Results
Stream delivered in four phased releases over three years. The design system was subsequently adopted by two other StoneRiver product lines. StoneRiver's product leadership began using UX as a competitive differentiator in client conversations after Phase 1.
Reflections
Domain fluency is not optional on complex enterprise work. Consistency is underrated — enterprise users want productivity, not surprise. And the quality of stakeholder communication determines how much design thinking actually ships.
The highest compliment came from Phase 1 users who described Stream as "just works" — when people stop noticing the platform because it does not get in their way, speaks their language, and surfaces what they need without making them think about where it is.