Every complex claim decided the same way
Designed a decision support system for complex case management, enabling structured, data-driven decisions at scale.
Representative interface: Counsel, a working decision-support surface I designed and built end to end. Actual Verisk visuals are under NDA.
- Role
- UX Designer
- Product
- Verisk Nordics DSS
- Focus
- Decision Support System
- Status
- In Progress
- Team
- PM · PO · Developers · Design
Extending an existing platform under shifting requirements
I joined an existing decision support platform mid-flight. The mandate: ship features under shifting requirements and tight deadlines, picking up AI tools fast enough to maintain stakeholder momentum. The work wasn't about building from scratch. It was about extending what was already there in a way that earned trust.
Two constraints shaped the work: the platform already existed, and requirements moved while I was designing. I picked up AI tooling quickly to compress the design-validate-adjust cycle, kept new patterns aligned with the existing system, and brought stakeholders along by showing concrete moves rather than abstract direction.
Reading the platform came first. Before proposing changes, I mapped what was already there: patterns, conventions, the reasons behind decisions that weren't obvious at first. That groundwork made every subsequent proposal an extension instead of a contradiction. (Specifics under NDA.)
The delivery ran on an : product intent to structured design prompts, prompts to working prototypes, kept safe by design review. More on this soon.
Joining an existing system mid-flight under shifting requirements meant two competing pulls: respect what was already there, or push for the structural changes the user group actually needed. The answer was rarely "replace," almost always "extend with intent."
- Extended an existing platform, didn't replace it. Every new feature respected the established patterns; new primitives only entered the system when the user group genuinely needed them.
- Preserved system consistency under change. Even as requirements shifted, the design language stayed cohesive. New surfaces felt like the existing system, not stapled-on additions.
- Picked up AI tooling fast without losing review rigor. Speed of adoption didn't replace validation. AI accelerated ideation, human review validated every output before anything shipped.
- Read the platform before proposing changes. Asked what existed, what worked, and what users actually needed, before suggesting new patterns. We don't reinvent the wheel; we see what users need and make the simplest way.
- Treated shifting requirements as signal, not noise. When stakeholders changed direction, I adapted scope quickly without re-platforming. New asks were absorbed into the existing system, not used as excuses to break it.
- Drove stakeholder buy-in by shipping concrete moves. Showed working features early to align stakeholders on direction, rather than long-form proposals. Momentum carried the rest.
- Knew what would ship vs. balloon. HTML/CSS/JS and front-end library competency informed component decisions, including page-load and render-performance implications. The "should we build this elaborately?" question came up early, not at code review.
Joining an existing system mid-flight taught me to read the platform before proposing changes. The team had history, conventions, and reasons for the choices already in the system, even when those reasons weren't visible at first. Next time I'd front-load that learning even more aggressively before suggesting structural moves.
Picking up AI tools fast was the easy part. Building review discipline around them was the harder one. Speed of adoption made it tempting to skip validation. I'd codify the validation pattern earlier next time: AI generates → human reviews → only then does it ship.