Problem
Configuring a large healthcare ops platform was traditionally painful: multiple windows, deep tab stacks, and domain-specific admin UIs that taught nothing reusable. As care management, assessments, and program models grew, each new entity risked a new configuration silo—raising training cost, error rate, and engineering load for multi-tenant (carrier / umbrella) setups.
The design goal was explicit: one interface pattern that can accommodate any configuration the product needs, while staying safe for non-engineering administrators.
Role
Principal Product Designer for the configuration layer that enables care management and the universal survey tool. Defined IA, object model presentation (lists → detail → sub-resources), and patterns for enablement, preview, and save that apply across care plans and assessments.
Design principles
- Same shell, different objects: left nav groups (care plans, goals, interventions, programs, assessments, question libraries) share chrome, search, and create affordances.
- Tenant-aware context: breadcrumb and carrier scope (e.g. Best Northwest) make multi-tenant edits explicit—what you configure is always for a known client.
- Enable without deploy: configuration-enabled toggles and save / cancel / preview keep admin changes deliberate and reversible.
- Author → runtime loop: preview assessment and weighted answers connect configuration directly to the survey runtime operators use.
Care plan configuration
Care plans are first-class configurable products: name, default risk, description, default care manager (or team), and carrier associations. Tabs separate concerns—general, goals, tracking data, services, assessments—so complex programs stay navigable.
- Program list as primary inventory (Anxiety Management, Program A–F…).
- Goals and interventions reusable across programs rather than copy-pasted screens.
- Carrier table for multi-payer rollout of the same care-plan definition.
Assessment configuration
Assessment authoring reuses the same shell with a three-column builder: available question types and libraries, active question order, and question detail (type, required, weights, conditions).
Authoring decisions
- Libraries vs. one-offs: default types plus named libraries so common clinical and demographic questions are reused, not retyped.
- Order as first-class: drag handles and remove controls treat sequence as product behavior, not a secondary preference.
- Weights & conditions: answer weights can drive local or assessment-level conditions—scoring and branching without custom code.
- Preview: admins can validate the instrument as end users will see it before publishing to production workflows.
Systems thinking
Universal configuration is the control plane for operational UX: care plans define what programs exist; assessments define how risk and needs are measured; the survey runtime and care-management views consume those definitions. Designing the admin once reduced the need for bespoke settings pages as new program types landed.
Outcomes
- Unified configuration IA across care plans and assessments in a multi-tenant CIM environment.
- Gave plan admins a predictable path: select entity → edit sections → preview → save, instead of hunting across disconnected tools.
- Unblocked care-management delivery that depended on configurable plans and instruments (design progressed in parallel with those programs).
Related work
Universal survey tool is the runtime this configuration powers; care management is the member journey those plans and assessments enable; CIM UX & design system provides the product shell and component language.
Stack & craft
Vue · Quasar · multi-tenant admin IA · design system · care-plan & assessment domain models