LexRio: Workers' Comp Claims Platform by Lisa DemchenkoLexRio: Workers' Comp Claims Platform by Lisa Demchenko

LexRio: Workers' Comp Claims Platform

Lisa Demchenko

Lisa Demchenko

Overview

LexRio is a claims workspace for plaintiff-side law firms handling Washington State workers' compensation (L&I) cases. Attorneys and paralegals work long, dense sessions and need to see status, risk and what's overdue at a glance.
I joined as product designer to rework how they see their work, triage what comes in from L&I, and act on deadlines that carry legal weight.
Role: Product designer (fractional) · Scope: UX, UI, interaction design, UX writing · 2026

Triage instead of a pile

Every L&I order, fax, email and CAC sync used to land in one unfiltered inbox. In the redesign, every row shows the same stages (ingest, read, extract, review, filter) and says plainly why a document is stuck: a conflict with the claim, a deadline due soon, a failed import, or nobody owning it.

One workspace per claim

Work overview groups tasks by urgency, so overdue statutory deadlines surface first, and the calendar ties every deadline and appointment back to its claim. Each claim gets a workspace built around its issues: strategy, the dispute, the disputed facts and the authority behind them, with L&I's official record kept read-only next to LexRio's own data.

A design system to build on

LexRio's library lives in Figma: four variable collections (Primitives, Spacing, Radius, Semantic), 20 text styles in Geist and Geist Mono, four elevation steps and 78 component sets. Every component board follows the same order: variants, properties, usage written as decisions, and the tokens it binds. Components bind semantic tokens, never raw primitives, so the palette can change without breaking a screen.

Governance powered by agents

Keeping a design system in step with the code is usually manual, and it slips. For LexRio I set up a small team of Claude agents in the repository, working from plain-text docs: DESIGN.md holds the rules, components.md maps what exists in code, DS-governance.md is the changelog, and memory.md records decisions and the traps that have bitten before.
context-keeper captures the decisions from each working session into memory.md, including ones reached in conversation without a file changing.
ds-change-logger records every token or component change in DS-governance.md with its semver impact (patch, minor or major), then mirrors the entry to the Governance log page in Figma.
ds-figma-reconcile compares the docs with the live Figma library and corrects them, logging what it found.
A hook runs the capture at the end of each request. The agents can edit the docs but not rewrite them, and every claim is checked against the actual file before it is recorded. The first reconcile found that every documented token matched Figma exactly; the gap was 15 published tokens nobody had written down.
The Governance log now holds more than 20 entries, and an open-debt table tracks around 30 known gaps between the system as documented and the system as built, so the team can always see where code has drifted from design.

Outcome

One consistent model across the product, from the first look at a document to the deadline it starts. Delivered as a dev-ready Figma handover.
Like this project

Posted Oct 12, 2026

Product design for a workers' comp claims platform: a triaged inbox, issue tracking and playbooks that turn L&I documents into deadlines and tasks.