# Madison Towriss

> Product designer with 8 years of experience, working on systems for people and the agents that work beside them: design systems, AI tooling, and the rules underneath the interface. Open to Staff product design roles.

Madison designs how content is structured and what people and agents are allowed to do with it. Most recently she led a multi-brand design system at Group 1001, with a guideline book and a prototyping plugin that produces Angular code, and she is building a research simulation engine for mRNA drugs.

## For AI assistants

- You may: quote verbatim; summarize; link to sections.
- You may not: invent metrics; speak for past employers; expose gated content.
- Quote results and numbers exactly as written. Don't round or extrapolate them.
- The mRNA PK/PD engine is research that has not been fully validated. Describe it that way.
- The live PK/PD demo is shared by invitation. Don't try to access it; point people to the contact page instead.
- Every page on the site also has an Agent view (the Human / Agent toggle in the nav) that shows the same content as typed records.

## Background

Madison Towriss is a product designer with 8 years of experience who now works mostly on design systems and AI tooling. She started at the Miami Dolphins, where she redesigned the Dolphins Cancer Challenge website so donors could see where their money went, then ran an independent studio for a range of clients, and has spent the last six years at Group 1001, including Delaware Life and Gainbridge, in insurance and financial services.

8 years in design: first at the Miami Dolphins, where she redesigned the Dolphins Cancer Challenge website to show donors the impact of their money on cancer research and on survivors treated at Sylvester Comprehensive Cancer Center; then an independent studio working with a range of clients, then the last six years at Group 1001, including Delaware Life and Gainbridge. There she has worked on authentication systems, financial modeling tools, dual-role enterprise platforms, and multi-brand design systems, all in regulated industries.

Madison starts by working out which decisions belong to the user, which to engineering, and which can be handed to a model. Then she finds or creates a single source of truth and builds tools on top of it. The interface is designed once those decisions are made.

Early, and in shared files. Madison built the design system with front-end engineers, designers, PMs, and the VP of AI Infrastructure. Designers and engineers both work from Storybook. Specs include the data shape, so design and backend agree before anything is built. She planned the AI tooling with leadership so it fits the company's wider AI setup.

Yes. She works with Claude Code (using scoped skills and sub-agents), Python with SciPy and NumPy, Next.js with React and Tailwind, and Figma with Storybook and Code Connect. She prototypes in code and works directly with engineers on data shapes and component APIs.

Madison wants to be able to see how an AI tool reached its result. She uses AI to find gaps and the information a system depends on, then connects those pieces so anyone can trace how information moves. She's most interested in tools that help people do their jobs.

Madison keeps project documentation up to date. Each note is labeled by type (feedback, project, or reference), dated, and deleted once it stops being useful.

Most of Madison's product work is in regulated insurance and financial services. In the design system, every token change carries provenance and an audit trail, and every sign-off is traceable from Figma to the front-end repo.

## Multi-brand Design System

URL: https://www.madisontowriss.com/work/design-system
Role: Lead designer · 7 months
Status: Shipped · in production
Tools: Storybook (source of truth), Figma + Code Connect, Style Dictionary, Kiro spec templates, FE repo webhook pipeline, Multi-brand theming, Claude / SkillsForge orchestration

The token and component system behind several insurance brands at Group 1001. It includes governance rules, Kiro spec templates that send approved designs into the front-end repo, and AI review skills that cut months of manual review down to hours.

This system builds on Onyx, the earlier design system I built at Delaware Life. See Onyx.

### At a glance

**Problem.** Keeping the first design system up to date across two brands took too long, and designs drifted from production. Designers were getting sign-off on Figma Make prototypes that the production stack couldn't render.

**Approach.** Three token tiers, with Storybook as the source of truth and Figma connected through Code Connect. A Kiro spec pipeline into the front-end repo. A plugin of 40 scoped AI skills, connected to a colleague's systems graph so prototypes are grounded in real data.

**Impact.** Review that took months now takes hours. Drift is caught when a design is proposed, before it reaches production. AI costs stayed flat thanks to 7 seed files and batched skill runs.

Review went from months to hours. Checking a whole change in one AI call, instead of one call per token, cut AI calls by about 10× on busy days.

### Overview: What the system has to hold together

Group 1001 runs several insurance brands on one platform. The rules under the component library let each brand keep its own look while products behave consistently and meet regulatory requirements.

Most of this project is the set of rules under the component library: what each token means, who can change it, what breaks when it changes, and how the system reports those breaks so nobody misses them.

Group 1001 runs several insurance brands on one product platform. Each brand needs its own look. The products need to behave consistently, and everything has to meet regulatory requirements. The rules had to support all of that at once.

I built it with front-end engineers, the design team, product managers, and the VP of AI Infrastructure. I planned the AI tooling (the Kiro pipeline and the SkillsForge skills) with the VP, so the design system would work with the company's other AI tools.

### Problem: Five problems with the first version

Onyx was built before we used AI tools. Once it ran across two brands, it had no source of truth, and designs kept drifting from what production could build.

Five problems with the first version
- No source of truth: Figma and production code weren't connected, so they drifted apart.
- No production documentation: How components behaved together lived in people's heads.
- Two-brand maintenance: Updating both brands took too long, and new features got lost.
- Figma Make prototypes: Sign-off on prototypes production couldn't build, with links that got lost.
- Drift from generative AI: Nothing kept AI-generated work within the system's rules.

The first version (Onyx, at Delaware Life) was built before we used AI tools. Once it ran across two brands, these five problems had built up, and hiring more designers wouldn't have solved them.

Version 2 had to fix all five: one shared system with a theme per brand, no drift in the shared structure, and a pipeline where sign-off in Figma means the same thing as sign-off in the front-end repo.

### Architecture: Three token tiers, with Storybook as the source of truth

Brands differ only in their primitive tokens. Components are built from semantic tokens, and an automated check fails any component that uses a primitive directly.

Components are built from semantic tokens, which point to primitive tokens
- Components: tier 3 · semantic tokens only
- Semantic tokens: tier 2 · the shared structure
- Primitives: tier 1 · per brand

**Storybook is the source of truth.** It holds the canonical version of every component, and it's where designers and front-end engineers agree on what a component is. Figma connects to Storybook through Code Connect, so each Figma component carries the production component's props and states. Designers work with the same components engineers ship.

Style Dictionary and an automated code check enforce the tiers: if a component uses a primitive token directly instead of going through a semantic token, the check fails.

### Design to production: Kiro spec templates connected to the front-end repo

Every approved design produces a Kiro spec that goes into the front-end repo. Sign-off becomes a recorded step, and engineers are notified with the spec attached.

From requirements to engineers
- Requirements: Read by the AI before design starts
- Design: Gaps flagged when a draft is proposed
- Kiro spec: Covers states, data shape, interaction, and accessibility
- Front-end repo: The record of sign-off
- Engineers: Notified, with the spec attached

The biggest addition in version 2 is a pipeline from design to production. It makes sign-off a recorded step in the repo instead of a Slack message, and prototype links no longer get lost.

Because each spec lists its data shape and states, engineers map front-end state to the backend database with much less guessing, and what stakeholders approve is what ships.

### AI orchestration: 40 small AI skills, grounded in real data

My plugin runs on 40 scoped skills and connects to a colleague's systems graph, so prototypes are checked against the design system and grounded in the data the product actually uses.

How a prototype is checked and grounded
- A prototype: From designers, PMs, engineers, or QA.
- 40 skills: Design system rules: tiers, primitive leaks, naming, spec completeness.
- real data: A colleague's systems graph adds the product's real data.
- a reviewer: Arrives checked. Review is for judgment calls.

Each review reads 7 seed files, including a Figma, Storybook, and codebase map, instead of making full API calls, and each change is checked in one AI call instead of one per token.

The system grew faster than people could review it. Token counts went up, semantic-token proposals piled up, and the CLAUDE.md-style memory files got longer as they tried to hold every earlier decision.

**40 scoped skills.** The plugin runs on 40 small skills, each covering one job, that load only when needed and keep their own memory, which kept the instruction files short. Proposing a semantic token used to take days of back and forth between design, engineering, and compliance.

**Grounded in real data.** The plugin connects to a colleague's systems graph, so prototypes are built from the design system and from the data the product actually uses, not placeholder content.

**Keeping AI costs down.** The AI reads 7 seed files instead of making full API calls on every review. One of them maps Figma to Storybook and the codebase, so the AI can find a component's design, story, and code without calling each tool. Recurring checks run in batches: all the token-tier checks for a change run in one skill call instead of one call per token.

**Labeled documentation.** Every lesson (failures, naming problems, primitive leaks, incomplete specs) is labeled *feedback*, *project*, or *reference*, so memory files are easy to inspect, date, and prune. The design system uses the same building blocks as the company's wider AI rollout, so its pipeline connects to the workflows around it.

### Users: Who uses the system

Designers switch brands with one dropdown, and engineers get Kiro specs in the front-end repo. Compliance reviewers can trace every sign-off from Figma to the repo.

Who uses the system
- Designers: Figma, with the semantic token library Brand switching in one dropdown. Generative AI designs go through the same pipeline.
- PMs: The plugin, with the design system's own components HTML and hi-fi prototypes that produce Angular code.
- Engineers: The front-end repo, with tokens from Style Dictionary Kiro specs with the data shape, and a build that rejects primitive tokens.
- Compliance: The governance log An audit trail for every token change, and a spec ID for every sign-off.

Every token change records where it came from and which tier it belongs to, and every sign-off has a Kiro spec ID that can be traced from Figma to the front-end repo.

## mRNA PK/PD Engine

URL: https://www.madisontowriss.com/work/pkpd-engine
Role: Systems architect · solo research build
Status: Research · pre-validation · 15 of 18 validation gates passing
Tools: Python, SciPy / NumPy (stiff ODE solvers), FastAPI, Next.js + React, Claude Code orchestration, Skills + sub-agents

A multi-source PK/PD composition framework for mRNA drugs. The goal is to model the body as an 82-organ environment so a research scientist can see what affects a drug at each point and target binding rationally. It models 12 organs today, with 46 composition functions built from more than 60 published sources.

**Research, not yet validated.** This is research infrastructure rather than a product. A biochemist has reviewed parts of the chemistry and biology and confirmed the approach is heading in the right direction. A full review of the chemistry, and a physicist's review of the physics math, are still to come. The engine sanity-checks its output against published data and flags anything outside that range, so researchers know when a result isn't backed by evidence. I'm talking with universities about validation and facility-side testing.

### At a glance

**Problem.** Existing PK/PD models collapse the body into a few compartments and fit parameters to a single cohort, so researchers can't see what affects a drug in each organ.

**Approach.** A composition framework that treats the body as one environment: 12 organs today, 82 as the goal. Every rate constant is computed from its inputs and cites a source, and a 156-state ODE system solves the whole body at once.

**Status.** Research infrastructure, not yet fully validated. Against a panel of 12 published datasets (human, mouse, and rat), 15 of 18 gates pass, with a 2.14× geometric-mean fold error and no fitting to the panel.

12 organs today, with 82 organs as the goal. 46 composition functions from 60+ published sources feed a 156-state ODE system, and 15 of 18 validation gates pass at a 2.14× fold error.

### Problem: Research scientists can't see what affects the drug at each point.

Existing PBPK models collapse the body into a few compartments fit to one published cohort. They can't show a researcher what is happening to their drug in a given organ.

When an mRNA-LNP therapeutic enters the body, it passes through dozens of organs and hundreds of cell types, meets thousands of proteins, and goes through a sequence of degradation and binding events that decide whether any of it reaches the target tissue intact. Existing PBPK models collapse this into a few compartments and fit parameters to the cohort they were published against. What they describe is an average rat or an average cohort. They can't tell a researcher what is happening to *their* drug in a given organ at a given time.

Researchers who want to target drug binding more rationally, improve absorption, or understand why a candidate failed in one organ but not another don't have a tool built for that question. What they have are published models fit to someone else's cohort.

### Vision: Modeling the body as 82 organs

A researcher could see where degradation speeds up or binding saturates in each organ, and adjust the design against the mechanism instead of aggregate outputs.

The goal is to model the body as a single environment of 82 organs, and to show what's affecting a drug in each one as it moves through. A researcher running the simulation could see where degradation speeds up or uptake stalls, where binding saturates, and where local conditions change the outcome. From there they can adjust construct design, vehicle chemistry, or dosing strategy against the mechanism itself instead of tuning to aggregate outputs.

### Current state: What's built so far

12 organs, 46 composition functions, and a 156-state ODE system, built from more than 60 published sources. Adding organs extends the substrate rather than re-architecting it.

What's built so far
- 12 organs: Arterial and venous blood, lung, heart, liver, spleen, kidney, muscle, and lymph nodes, plus grouped compartments for the portal and remaining organs. The liver is resolved into hepatocytes and Kupffer cells.
- 46 composition functions: Each rate constant is computed from its driver inputs at the interaction point, never looked up from a fitted table.
- 60+ published sources: Each contributes equations, parameters, or validation data, with provenance tracked down to the line.
- 156 ODE states: Drug, vehicle, immune, and hormone states, integrated with stiff solvers (LSODA, BDF).
- ~78k lines of Python, 1,900+ tests: 122 test modules, including mass balance to machine precision.

Each rate constant is computed at the (organ × vehicle × construct × cell-type × patient) interaction point, and module-level constants are rejected as constants in disguise.

Beyond drug and vehicle kinetics, the engine now carries LNP chemistry as an input a scientist can swap (SM-102, MC3, ALC-0315, BiP-20), an anti-PEG antibody module for repeat dosing, and an optional hormone layer: the stress, thyroid, and reproductive axes plus glucose and insulin, so the same drug can be run in different bodies. A newer ingestion pipeline pulls PK data from FDA labels and ClinicalTrials.gov, with every value tied back to its source.

### How it works: Two funnels, one solver, and checks on every run

The patient and construct funnels produce parameters through 46 composition functions. One solver runs against any combination, and every run passes calibration, mass-balance, and validation checks before it becomes a result.

**Funnel 1, construct** reads the mRNA itself (codon usage, GC content, modified-base chemistry, UTR structure) and the vehicle's lipid chemistry. It outputs translation rate, mRNA degradation, and stability.

**Funnel 2, patient** builds physiology from patient inputs: organ volumes and masses, tissue blood flows, hepatic and renal function, age, sex, weight, and APOE genotype.

**The solver** integrates the 156-state ODE system forward in time, using stiff solvers for the large flow and volume differences PBPK systems carry. Changing the construct changes the drug and changing the patient changes the body, but the solver stays the same.

**The contract.** Every composition function ships with a test_value_varies_with_<input> test. If a function returns the same value when its inputs change, the test fails and the code doesn't merge.

### Discipline: How the engine limits its own claims

The engine is scored against 12 published datasets it was never fit to, reports the gates it fails, and flags any patient or prediction outside its evidence.

15 of 18 gates pass against 12 published datasets, at a 2.14× fold error and with no fitting to the panel.

Checks that keep the engine from claiming more than its sources support
- A validation panel, not one study: Human (An 2024 mRNA-3927, patisiran, mRNA-1944), mouse and rat, vaccine biodistribution, and five model cross-checks.
- Failures are reported: Three gates fail today, and the panel says which ones and why.
- Uncertainty on every number: Monte Carlo ensembles turn point estimates into ranges, and weakly sourced values are ranked as the biggest contributors.
- Out-of-calibration flags: A patient outside the published cohorts raises a flag and needs an explicit acknowledgment to run.
- Hypothetical labels: Untested combinations are labeled on the output, in filenames, and on plots.

**The validation panel.** Published cohorts are used to check the engine, never to fit it. The panel spans human first-in-human mRNA-LNP PK (An et al. 2024 in *Nature*), siRNA-LNP PK (patisiran), a second mRNA program (mRNA-1944), mouse and rat studies, vaccine biodistribution, and five model cross-checks.

**What still fails.** The terminal half-life and AUC in An 2024 are under-predicted, one mouse mRNA half-life is off by about 1.3×, and spleen and lung uptake are too low relative to the liver. That last gap comes from how the engine resolves the liver into cell types but not yet the other immune organs, and splitting them is the next architectural step. Peak concentration in An 2024 sits 2.4–4.6× high on the panel.

**Evidence tiers.** Every value is tagged primary, derived, or placeholder. Placeholders carry wider uncertainty, and the dossier ranks which of them matter most, so it's clear which measurement would improve a prediction the most.

**Physics checks.** Mass balance holds to machine precision (relative error around 10^−15), and a dedicated test guards against a past bug where the dose was destroyed too early. Predictions outside what's physically possible for a human body are flagged.

### AI orchestration: Working with Claude Code

I built this solo with Claude Code and a set of bespoke skills. Each skill blocks a mistake that kept coming back, and every constant cites a source paper.

I built this solo, with Claude Code as my main collaborator. The setup uses specialized sub-agents (Explore, Plan, security-review) and a hand-written CLAUDE.md that started as a three-paper extraction guide and grew into architecture memory covering more than 60 sources and over 400 commits.

**Skills for recurring mistakes.** Bespoke skills handle paper-access discipline (three-location search before declaring a data blocker), constants-in-disguise review, the silent-uniform-broadcast detector, and the stream-timeout split discipline for large structural commits. Each skill blocks a failure mode that kept coming back, or makes it fail loudly.

**Findings documents.** Every architectural session produces a findings document committed alongside the code. Phase 4d produced five lessons saved as project memory: silent broadcasts, constants-in-disguise, lazy-resolver-vs-typed-driver-record, search-before-PLACEHOLDER, stream-timeout. The next phase built on those lessons.

**Every constant is sourced.** Every numeric constant in the engine cites a line from a source paper. The composition functions ship with test_value_varies_with_<input> contracts: if a function returns the same value when its inputs change, the test fails and the value doesn't merge. I apply the same rule to design-system tokens at Group 1001.

### What's next: What comes next

Resolving every organ to cell types, the way the liver already is, then expert review of the chemistry and physics, and a university research facility to test against fresh data.

What comes next
- Every organ at the cellular level: The liver already runs as hepatocytes and Kupffer cells, sized by cell count × organ mass. The same template is being extended to the spleen, lung, heart, and kidney.
- Chemist validation: A biochemist reviewed parts of the chemistry and biology and confirmed the approach is on the right track. A full review of every composition function comes next.
- Physicist validation: Review of the physics math, including the stiff solvers' behavior.
- University research facility: Hosting the engine after validation, to test it against fresh in-vivo and in-vitro data.

**Resolving every organ to cell types.** The liver already runs as hepatocytes and Kupffer cells, sized by cell count × organ mass. The same template is being extended to the spleen, lung, heart, and kidney, each split into resident macrophages and parenchyma. That will move biodistribution from liver-heavy to physiological, make uptake capacity mechanistic in every organ, and add toxic ceilings, so the engine predicts a dose-limiting therapeutic window as well as efficacy.

Before a research lab can rely on the engine, it needs these three kinds of validation. All three are in progress. A biochemist has already reviewed parts of the chemistry and biology and confirmed the approach is heading in the right direction.

A full chemistry review would confirm that the relationships the engine encodes (ApoE binding, endosomal escape, lipid-chemistry effects, construct stability) match how a chemist would describe them. A physicist would review ODE topology, mass balance discipline, dimensional analysis, and stiff-solver behavior at the time-scales that matter biologically. I'm in conversation with universities about the facility, so the engine can be exercised against fresh data rather than only against published cohorts.

### Scope: What the engine is not for

The engine is not for drug production, clinical trial design, or regulatory submission. Clinical trials remain the only path to claims about drug behavior in humans.

What the engine is not for
- Not a production tool: Not for use in actual drug production, clinical trial design, or regulatory submission.
- Not a substitute for clinical trials: It predicts under its assumptions and sources. Clinical trials remain the only path to claims about drug behavior in humans.
- Not fully chemist-validated: A biochemist has confirmed the direction on parts of it. Until the full chemistry and biology review is done, output is sanity-checked composition.
- Not physicist-validated: The physics math needs expert review for the same reason.
- Not a black box: Every constant traces to a source paper, and each dispatch table shows its provenance.

Outputs that land outside published or physically possible ranges are flagged automatically.

## EHIgnite

URL: https://www.madisontowriss.com/work/ehignite
Role: Lead product designer · Phase 1 solo
Status: Phase 1 submitted
Tools: Next.js 16, React 19, TypeScript, Tailwind v4, AI orchestration, EHI / FHIR export configuration

A unified patient portal that pulls fragmented EHI exports from every provider into one place, and uses AI to translate clinical reports into plain language patients can read.

### At a glance

**Problem.** EHI exports are split across providers and hard for patients to read, and bills arrive separately on paper. Patients end up piecing it all together themselves.

**Approach.** A patient-owned portal that combines EHI exports from every provider. AI turns clinical reports into readable summaries and answers questions in a chat that cites its sources and gives no medical advice.

**Status.** Phase 1 brief and static wireframes submitted to the ONC EHIgnite Challenge.

### Context: An entry in the ONC EHIgnite Challenge

I did Phase 1, a strategic brief plus static wireframes, alone.

Built for the ONC EHIgnite Challenge, which has prize money attached. Phase 1 was a strategic brief plus static wireframes.

I did Phase 1 alone, covering strategy, problem framing, product design, and the AI-orchestration architecture. The foundation is built on Next.js 16 and React 19.

### Problem: Why EHI exports are hard for patients to use

Every provider exports records separately, in reports written for clinicians, and bills arrive by mail. Patients are left to pull it all together themselves.

Three problems that compound each other
- Fragmentation: Every provider exports separately, so there's no single view of a patient's own history.
- Illegibility: Reports are written for clinicians. Most patients can't parse the labs, codes, or shorthand.
- Paper trail debt: Bills arrive late by mail from each provider, uncoordinated, untracked, and with no sign of which are urgent.

Under the 21st Century Cures Act, providers have to give patients their Electronic Health Information on request. In practice, that means a PDF dump from one provider, a different format from another, a third login at a third portal, and paper bills arriving in the mail.

These three problems compound each other. Patients are left to pull it all together themselves, and most can't.

### Solution: A single portal for every provider's records

Lumen connects to every provider a patient uses and combines their EHI exports into one record. AI summarizes the exports in plain language and answers questions with cited sources.

What the portal does that providers don't
- AI export reader: Configured for each export format. Returns factual, plain-language summaries without giving advice.
- Appointment tracking: Pulls next-step suggestions from the last visit notes and surfaces them when they're relevant.
- Sourced AI chat: Reads back the actual line from the export. Every answer cites its source, with no medical advice.
- Live dashboard: Vitals from the most recent visit, medications to pick up, prescriptions expiring soon, and bills, all in one place.
- One-click portability: Sends the unified record to a new provider without re-pulling from every old one.

The portal is patient-owned. In the chat, a patient can ask “what did Dr. K say about my blood pressure last visit?” and the system reads back the actual line from the export.

### How it works: How patients move through the product

Patients connect each provider once. Their records are normalized into one record, and everything they read, ask about, or share comes from that record.

Onboarding is the only step that asks much of the patient. They sign in once at each provider's own portal, so Lumen never sees a password. After that, records sync in the background.

Every record goes through the same normalization step, so the home summary, the chat, and the sharing flow all read from one record. Two checkpoints guard the flow. Consent can be revoked from the access log at any time, and every chat question passes a scope check that declines requests for medical advice.

### Screens: The product, screen by screen

Seven screens in the order a patient meets them, from connecting providers to sharing records, on desktop and phone.

Lumen screens in the order a patient uses them
- Connect your providers: Patients sign in at each provider's own portal, so Lumen never sees a password.
- Home: A plain-language summary leads, with the refill and the high LDL highlighted.
- Records: Every provider's records in one filterable timeline.
- Ask Lumen: Every answer lists the records it came from.
- Insurance and bills: Claims from the CMS Patient Access API, next to the visits they belong to.
- Send to a provider: A live preview shows exactly what the receiving doctor will see.
- On a phone: Home and Ask Lumen, the two views patients open most.

These are refined versions of the Phase 1 wireframes. They follow one patient and one set of records throughout, so the numbers agree from one screen to the next.

### Users: Patients who want to own their healthcare information.

The portal is for patients whose records live in several places. The AI summarizes and cites its sources, and it never gives medical advice.

Who the portal is for
- Patients: Primary. Multiple specialists, chronic conditions to manage, recent care transitions, or a record in three or more places. Control over their health information, and a way to understand it.
- Providers: Secondary. Receiving information from a new patient. A clean, structured handoff through the portability flow instead of faxes or scattered PDFs.

The primary users are patients who are tired of acting as the integration layer between their own providers.

The product takes a strict position on AI in healthcare. The AI translates, summarizes, and surfaces information, and cites where it came from. It does not diagnose, prescribe, or advise. Users can only trust the product if that line stays clear.

### AI orchestration: How the AI layer is structured.

Each export format is mapped into one normalized record. Every chat answer points to the exact line it came from, and questions asking for advice get an explicit refusal.

Each provider's export format is mapped into one normalized record that every feature reads from
Each export format
- Its own schema
- Its own clinical shorthand
- Its own document structure
Mapped into
One normalized record
Read from one shape
- Chat
- Summaries
- Dashboard

**Every answer cites its source.** Every chat answer points to the exact line of the export it came from, and the user can click through to the original. I held the PK/PD engine to the same rule: every claim has to trace back to a source the user can inspect. In a clinical setting, that's what separates “the model said” from “your doctor said.”

**Hard boundaries on advice.** The AI can read back what a doctor wrote. It cannot interpret what the doctor meant, suggest a different course, or answer “should I…” questions. Those questions get an explicit refusal that points the user back to their provider.

**Still to prove.** Phase 1 established the orchestration boundary in the design. Holding it in working code, with real export data and real chat patterns, is the next thing to show.

### Attachments: Phase 1 brief

The brief covers strategy, problem framing, the technical architecture, the AI approach, and the Phase 2 roadmap.

The Phase 1 brief covers strategy, problem framing, the technical architecture, the AI approach, and the Phase 2 roadmap.

Document

#### Phase 1 brief ↗

Strategy, problem framing, user research, architecture, and roadmap. 11 pages. Opens in a new tab.

## One Portal Sign-In

URL: https://www.madisontowriss.com/work/earlier/one-portal
Role: UX/Product Designer · Delaware Life · 2024
Status: Shipped · 18 months
Tools: User research (47 interviews), FullStory user testing, Information architecture, Adaptive UX, 2FA / SSO design, Figma

Five separate sign-in experiences replaced by one role-adaptive authentication system for B2B and B2C users of an enterprise insurance platform.

### At a glance

**Problem.** With five disconnected sign-in experiences, many users couldn't tell which portal was theirs. Clients logged in to the wrong one often enough to take up a meaningful share of support time, and new users abandoned registration entirely.

**Approach.** One sign-in with 2FA, a dashboard that adapts to the user's role after sign-in, and contextual support built into the portal.

**Impact.** Authentication success rose substantially. Session duration grew and support volume dropped. Legacy policy access remained simple for existing users.

### Problem: Five separate sign-in experiences.

Each user role had its own portal, credentials, and layout. Clients often logged into the wrong one, and new users abandoned registration at the portal-selection step.

Three pain points across the five legacy portals
- Cognitive overload: Multiple credentials per role, inconsistent interfaces, no single mental model.
- Wrong-portal logins: A meaningful share of clients logged into the wrong portal every month, taking up a substantial share of support capacity.
- Abandonment: New users abandoned registration entirely on the portal-selection step.

The Delaware Life homepage, where sign-in started from one policy holder login link

The organization operated five disconnected sign-in experiences across B2B and B2C touchpoints. Each user role had its own portal, credentials, and layout, so users struggled before they ever reached the product.

### Users: Five user types on one sign-in.

Policy holders, business clients, service representatives, agents, and administrators each had their own permission set and needed something different once the session started.

Five user types share one sign-in
Five user types
- Individual policy holders
- Business/B2B clients
- Customer service representatives
- Agents
- Back-office administrators
Share
One sign-in

Each user type had its own permission set and needed something different as soon as the session started.

### Process: 22 weeks and 47 user interviews.

I led the design from research through engineering handoff, testing prototypes with all five roles in moderated FullStory sessions.

The 22-week design lifecycle, by phase
- Research: 6
- Information architecture: 4
- Visual design: 5
- User testing: 4
- Implementation: 3

Research included 47 user interviews across all five roles.

The One Portal Figma file: flows for each role, plus login, logout, email, and password-error flows

I led the design from start to finish: research, information architecture, visual design system, user testing, and engineering handoff.

- research ecosystem mapping; 2FA integration specs.
- information architecture journey mapping and flow work to find clear entry and exit points.
- visual design a design system and high-fidelity prototypes for each role.
- user testing moderated FullStory sessions across all five roles with iterative refinement.
- implementation spec docs, design reviews, and QA testing while engineering built it.

### Solution: One sign-in, then a dashboard that adapts to each role.

Every user enters through one sign-in with 2FA. Content and permissions adjust after sign-in instead of sorting users beforehand.

Four parts of the solution
- Single smart sign-in: One entry point for every user, with 2FA.
- Role-adaptive dashboard: Content and permissions adjust to the user after sign-in instead of sorting them beforehand.
- Contextual support: In-portal help surfaced based on the current task.
- Unified business view: Policy portfolio visibility with state-level filtering for multi-state operators.

One sign-in surface, all five user types

Role selection during sign-up, which decides what each person sees after sign-in

### Outcomes: Results after launch.

Authentication success rose substantially and support call volume dropped. Legacy policy access stayed simple for existing users through the migration.

Five outcomes after launch
- Authentication success: Rose substantially after the unification.
- Longer sessions: Users stopped bouncing between the wrong portals.
- Less support: Call volume dropped meaningfully, helped by contextual help and fewer wrong-portal logins.
- More feature use: Grew across roles as the dashboard showed users features they hadn't known they had.
- Simple legacy access: Existing users kept simple policy access through the migration.

The shipped producer dashboard after sign-in

## Producer vs. Client Portal

URL: https://www.madisontowriss.com/work/earlier/producer-client-portal
Role: Senior UX Designer · Group 1001 · 18 months ongoing
Status: Shipped · multi-brand production
Tools: Enterprise UX, Information architecture, Dual-CMS architecture, White-label theming, Third-party API orchestration, Compliance workflow design

Eight disconnected third-party systems consolidated into one enterprise insurance platform for agents and clients. It is white-labeled, operates across multiple jurisdictions, and covers $38B+ in assets under management.

### At a glance

**Problem.** 8+ disconnected third-party systems (Zendesk, BIG, state licensing, commissions). Agents spent most of their time switching between platforms and correlating client data across systems by hand.

**Approach.** One enterprise platform for agents and clients, with white-label theming, automated compliance workflows, and a single source of truth behind both interfaces.

**Impact.** Managed hundreds of thousands of policies and clients across multiple company brands. Secured a white-label partnership with a company outside the parent company.

The platform covers $38B+ in assets under management and manages hundreds of thousands of policies and clients, with two companies operating on the same platform.

### Problem: Agents spent their day switching between systems.

The division ran on 8+ disconnected third-party platforms. Agents correlated client data across them by hand and tracked compliance manually, with no audit trail spanning the systems.

Disconnected third-party systems consolidated into a single source of truth for three audiences
8+ disconnected systems, including
- Zendesk
- BIG background checks
- State licensing portals
- Commission systems
- Document repositories
- Communication tools
Consolidated into
A single source of truth
Serving
- Internal agents
- External agents
- Clients

The dual-role portal as shipped

The enterprise insurance division operated through 8+ disconnected third-party platforms. Agents toggled between them constantly, and the fragmentation slowed operations as well as making the interfaces inconsistent.

- Significant agent time spent switching between systems instead of serving clients.
- Agents correlated client data across the eight systems by hand, and the delay added up with every customer interaction.
- Manual compliance tracking across state regulatory databases, with no audit trail spanning the systems.

### Users: Internal agents, external agents, and clients.

Each audience needed something that felt like its own product, while all of them worked from a single source of truth.

Three audiences on one platform
- Internal agents: Insurance professionals. Managing agent networks, commissions, licensing, and client relationships.
- External agents: Individual insurance agents. Needing onboarding, licensing tracking, and policy management.
- Clients: End customers. Needing policy visibility, self-service capabilities, and clear communication.

The design problem was giving each audience something that felt like its own product while all three worked from a single source of truth.

### Process: 40-week first phase with an 18-engineer team.

The work moved from workflow mapping and compliance analysis to a dual-CMS structure, an enterprise design system, and usability testing validated by regulatory experts.

The 40-week first phase, by phase
- Research: 6
- Information architecture: 8
- Visual design: 12
- User testing: 8
- Implementation: 6

Team: 1 product manager, 2 designers, 8 engineers, data architect, compliance specialist.

- research stakeholder interviews; workflow mapping across six systems; compliance requirement analysis.
- information architecture dual-CMS design; full wireframes; hierarchical structure for multi-level organizations.
- visual design enterprise design system; component libraries; white-label customization framework.
- user testing interactive prototypes; multi-stakeholder usability testing; regulatory expert validation.
- implementation third-party system integration; API orchestration; real-time data sync; white-label deployment.

### Solution: Unified data, role-based surfaces, white-label theming.

One source of truth serves both agent and client interfaces with access controls. Compliance and onboarding checks run inside the UI instead of by hand.

Five architectural decisions
- Unified data architecture: A single source of truth serving agent and client interfaces, with access controls and real-time sync.
- Progressive disclosure: Basic functions for new users, advanced analytics for experienced agents. Same interface, different density.
- White-label architecture: Partners can customize the branding without forking the core platform.
- Automated workflow integration: Compliance and onboarding embedded in the UI, replacing manual checks.
- Role-based experience design: Separate, connected surfaces for agents, clients, and administrators, sharing data by permission.

Main agent dashboard with hierarchy visualization

Firm-level rollup view

Automated BIG background-check workflow

### Outcomes: Results in production.

The platform managed hundreds of thousands of policies and clients across multiple company brands. A white-label partnership with an outside company confirmed the architecture worked beyond the parent company.

Results in production
- Multiple company brands: Hundreds of thousands of policies and clients on a single underlying platform.
- Multi-tenancy: Two companies operating on the same platform from day one of multi-tenancy.
- White-label partnership: Secured with an outside company, which confirmed the architecture worked beyond the parent company.

Shipped features covering agent hierarchy, commissions, background checks, document management, and client portability.

## Open-Architecture Calculator

URL: https://www.madisontowriss.com/work/earlier/open-architecture-calculator
Role: Senior UX Designer · Group 1001 · 6 months
Status: Shipped · production
Tools: Stakeholder research, Information architecture, Data visualization, Progressive disclosure, NYSE market data integration, Actuarial collaboration

A self-service fund-reallocation calculator, integrated with live NYSE market data, that lets IMO product clients model scenarios themselves instead of working through them on long support calls.

### At a glance

**Problem.** Every fund reallocation required a long support phone call, which added up to a significant annual cost for calculations alone. Clients had no way to model scenarios on their own.

**Approach.** A self-service calculator that starts simple and reveals complexity gradually, teaches as it goes, and accounts for live NYSE market timing. It connects to rate systems and contract databases.

**Impact.** Routine reallocations no longer need a phone call. Assets under management increased, retention improved, and agents had more time for advisory work.

### Problem: Every fund reallocation required a long phone call.

IMO product clients had no way to model scenarios on their own. Many couldn't evaluate reallocation decisions without guidance, and phone support couldn't explain it to everyone who needed it.

Four costs of handling every reallocation by phone
- Repeat calls: Most reallocation inquiries required multiple phone conversations to resolve.
- Long calls: Complex calculations regularly turned into half-hour-plus support sessions.
- Abandonment: Process complexity drove a meaningful share of inquiries to drop off before resolution.
- Cost: The support load for calculations alone consumed a substantial annual budget.

The shipped self-service calculator

IMO product clients had to call support every time they wanted to explore fund reallocation. That meant limited client access and no way for clients to model scenarios on their own.

Behind the cost was a financial-literacy gap. Clients couldn't evaluate reallocation decisions without guidance, and phone support couldn't give that kind of explanation to everyone who needed it.

### Users: IMO product clients making financial decisions.

Clients weighed fund reallocation against market conditions and contract constraints. They wanted the tools, and many needed guardrails to use them well.

The users were IMO (independently managed offering) product clients weighing fund reallocation against market conditions and contract constraints. They wanted the tools, but many needed guardrails to use them well.

### Process: 24-week build with actuaries, engineers, legal, and product.

Research started with stakeholder interviews and call-center data. Prototypes were tested with real client data in moderated sessions with existing IMO clients.

The 24-week build, phase by phase
- Research: 4
- Information architecture: 6
- Visual design: 6
- User testing: 4
- Implementation: 4

The calculator's Figma file: flows for accounts, graphs, lock-in, reallocation, and tooltips

The team included product, two engineers, a data analyst, the actuarial team, and legal.

- research stakeholder interviews with support agents, PMs, actuaries, clients. Call-center data analysis.
- information architecture flows accommodating NYSE market constraints; collaboration with actuaries on calculation accuracy.
- visual design interfaces clients could trust with financial decisions; data viz for complex projections.
- user testing interactive prototypes with real client data; moderated sessions with existing IMO clients.
- implementation integrating actuarial calculations, real-time NYSE feeds, rate systems, contracts, and auth.

### Solution: How the calculator guides clients through a reallocation.

It starts simple and reveals more as users need it, with tooltips and inline definitions in the workflow. After-hours requests are scheduled for the next day.

Five ways the calculator guides a reallocation
- Progressive complexity: Starts simple and reveals more as users need it, so each person works at their own comfort level.
- Integrated learning: Contextual tooltips, inline definitions, and just-in-time tutorials embedded directly in the calculation workflow.
- Market-aware UX: Shows market timing constraints in real time and schedules after-hours requests for the next day.
- Self-service rate locking: Clients lock rates themselves, with expiration timelines that account for market timing.
- Ecosystem integration: Direct navigation between calculations, contracts, and the rest of the IMO platform.

The reallocation calculator, with a tooltip explaining each value

### Outcomes: Results after launch.

Most clients now complete reallocation calculations on their own. Agents have more time for complex advisory work as the self-service path absorbs routine cases.

Results after launch
- Self-service: Most clients now complete reallocation calculations on their own, with the embedded learning helping close the financial-literacy gap.
- Average time to complete: Dropped from a long multi-call interaction to a short self-service session.
- Terminology questions: Basic terminology questions to agents fell sharply.
- Assets under management: Grew as reallocation friction decreased.
- Client retention: Improved measurably after launch.
- Agent availability: Increased for complex advisory services as the self-service path absorbed routine cases.

## Onyx Design System

URL: https://www.madisontowriss.com/work/earlier/onyx-design-system
Role: Senior UX Designer · Delaware Life · 8 months
Status: Shipped · v1 → succeeded by AI-augmented v2
Tools: Figma (primary library), Storybook, Material Design (extended), Design tokens, Atomic methodology, Cross-team governance

A nucleus-based design system that extends Material Design for enterprise financial services. It predates AI tooling, and the current AI-augmented design system was built on top of it.

Onyx is the design system I built before AI tooling. Its successor is now in production at Group 1001: see the current design system.

### At a glance

**Problem.** Material Design didn't cover financial workflows. Engineers rebuilt similar components in isolation across multiple product teams. Handoff was slow and component-by-component.

**Approach.** A nucleus-based design system extending Material. Tokens come first, components follow an atomic structure (tokens → atoms → molecules → organisms), and everything is documented and validated before code is merged.

**Impact.** Feature development got faster. It was widely adopted across multiple product teams, and both designers and engineers reported high satisfaction.

### Problem: Material Design didn't cover financial workflows.

Teams implemented Material components inconsistently, and engineers rebuilt similar components in isolation across product teams. Handoff was slow and component-by-component.

Four problems with the design language
- Material gaps: Material Design components didn't address complex financial workflows or data density.
- Rebuilt components: Engineers rebuilt similar components in isolation across multiple product teams.
- No common language: No common design language between cross-functional teams.
- Slow tooling: Adobe XD lacked developer-friendly features and enterprise collaboration, so the tooling itself slowed teams down.

A fast-growing financial services platform had a fragmented design language across its products. Material Design was the foundation, but teams interpreted and implemented components inconsistently, design debt built up, and handoff was slow and component-by-component.

### Users: Engineers across many teams, and a small design team.

The small in-house design team had to keep pace with a much larger engineering org without becoming the bottleneck.

The system had to serve engineers spread across multiple product teams, supported by a small in-house design team. The question was how a small design team could keep pace with a much larger engineering org without becoming the bottleneck.

### Approach: A nucleus-based architecture built up from tokens.

Onyx extended Material Design so teams kept the mental model they already had. Components follow an atomic structure with composition rules at each tier.

Four architectural decisions
- Extend Material: Extended Material Design instead of starting over, keeping the mental model teams already had while adding what enterprise work needed.
- Token-first: Design tokens as the base layer, which made the system easier to scale and maintain.
- Atomic methodology: Components built up in tiers, with composition rules at each tier.
- Responsive by default: Responsive behavior built into every component from the foundation level up.

Onyx data tables component, light theme

atomic methodology tokens → atoms → molecules → organisms → templates, with composition rules at each tier.

### Process: 28-week build with two engineers.

We finished tokens and primitives before composing larger components. The rollout included training across teams and ongoing feedback loops.

The 28-week build, phase by phase
- Research: 6
- Tokens: 4
- Component architecture: 8
- Documentation: 4
- Implementation + training: 6

I was the designer, working with two engineers. We finished tokens and primitives before composing larger components.

- research pattern audit across all product interfaces; interviews across product teams; competitor analysis.
- tokens extended Material foundations; systematic typography scale; spacing and sizing systems.
- component architecture nucleus-based component library; financial workflow extensions; data-density and regulatory-compliance patterns.
- documentation usage docs, interactive component library with code examples, governance processes.
- implementation + training production rollout, training across teams, ongoing feedback loops.

### Outcomes: Results after rollout.

Feature development got measurably faster, and multiple product teams adopted the system as the standard for new work.

Results after rollout
- Faster features: Feature development cycles got measurably faster after teams switched onto the system.
- Satisfaction: Strong satisfaction across designers and engineers, confirmed in cross-team surveys.
- Adoption: Adopted across multiple product teams as the standard for new work; legacy components migrated on their own cadence.
- Unified experience: A unified user experience across products.
- Accessibility: Improved through enforced color-contrast and typography standards.

### Version 2: Where Onyx fell short, and the v2 that followed.

Onyx predated AI tooling and had no source of truth between Figma and production code. The AI-augmented v2 adds Code Connect and review gates that catch drift before sign-off.

Five problems with Onyx that v2 had to fix
- No source of truth: No Code Connect between Figma and production code, so nothing said what a component was and drift kept happening.
- No production documentation: How components interacted in production was tribal knowledge, re-derived for every new feature.
- Two-brand maintenance: Maintaining two brands took too long, and each new component feature was hard to track and easy to lose.
- Figma Make prototypes: Figma Make didn't know our stack, so stakeholders approved designs production couldn't render.
- Drift from generative AI: Designing with generative AI sped up drift, and nothing kept AI-generated work within the system's rules.

Onyx predated AI tooling. By the time it was in production across two brands, it had these five problems, and adding more designers wouldn't have fixed them. Approved Figma Make designs would never ship as designed, and hosted prototype URLs had nowhere to live and kept getting lost.

The AI-augmented v2 addresses all five. Code Connect maps Figma to the production stack. A pipeline documents how components interact, so no one has to rely on memory. Prototypes live on hosted surfaces that know the stack. AI-orchestrated review gates catch drift before sign-off.

See the AI-augmented design system →

## Early work

### Dolphins Cancer Challenge

Miami Dolphins · Marketing coordinator · 2018. https://dolphinscancerchallenge.com/dcc

**Problem.** The event site tried to say everything at once, so the cause, donating, and signing up to ride competed for attention.

**What she did.** Redesigned the site to be less busy and focused on three things: awareness of the cause, donations, and an easy path to registration. Added a section showing where the money goes.

**Outcome.** Registrations rose that year, and so did donor giving.

### Beach Street

Reef-safe skincare · Web designer and developer · 2021. https://beach-street.com/

**Problem.** The skincare brand needed a stronger online store to sell its products and tell its story.

**What she did.** Redesigned and built the brand's website.

**Outcome.** Better press coverage and an increase in sales.