Designing an ecosystem to capture frontline care issues and convert them into structured, governed, risk-focused improvement initiatives.
View Slide Deck
Context:
This project didn’t start with a product idea.
It started with a pattern I kept noticing.
In healthcare systems, clinicians experience breakdowns every day:
confusing tools, broken workflows, unclear information, unsafe handoffs, slow processes, unreliable systems.
But most of these problems don’t become real improvements.
They become:
tickets that get closed
complaints that disappear
workarounds that become normal
“that’s just how it works” behavior
local fixes that don’t change the system
I wasn’t interested in designing another tool.
I was interested in designing a translation layer.
Something that could take frontline reality and turn it into structured change.
Problem:
On the product end, once problems are raised, healthcare technology teams start projects with execution frameworks, not readiness frameworks.
Most healthcare technology projects start the same way:
a request, a ticket, a Jira epic, a backlog item, a roadmap entry. Workflows get organized. Tasks get tracked. Sprints get planned. But risk, governance, readiness, and system safety usually show up later.
Teams often start building before:
regulatory impact is understood
clinical risk is mapped
governance is defined
ownership is clear
readiness is assessed
approval paths are established
system impact is structured
Platforms like Jira are good at managing workflows.
They are not designed for execution readiness, system change, governance, or risk routing.
As a result, teams frequently run into:
late-stage compliance issues
unexpected approval gates
blocked releases
governance conflicts
rework
redesign
stalled initiatives
last-minute risk mitigation
I wasn’t interested in designing another planning tool.
I was interested in designing a system that forces structure before execution.
Research:
Within the certification program, I approached this as a structured design investigation rather than a product build. I studied healthcare operations, safety frameworks, and change governance through coursework and mentorship, then applied those models through scenario modeling and system mapping. The project relied on guided synthesis and mentor feedback instead of field research or user testing, keeping the work aligned with real healthcare constraints and certification boundaries.
What I observed:
Clinicians describe problems in human terms:
“This is confusing.”
“This slows care.”
“This feels unsafe.”
“This workflow breaks.”
“This system isn’t reliable.”
Technology teams organize work in system terms:
epics, tasks, backlogs, dependencies, releases.
These two languages don’t connect naturally.
And governance usually enters the process too late.
Findings:
Healthcare teams use tools like Jira to manage delivery, but not readiness, governance, or system change
Risk, compliance, and governance are introduced too late in projects, causing rework and stalled execution (a problem i noticed during my time at CVS Health)
Clinician-reported problems remain isolated issues instead of becoming patterns or system insights
There is a structural disconnect between how clinicians describe problems and how product teams design solutions
Organizations are better at executing work than structuring safe, governed change
How do real problems in care become real system change without creating risk?
AND
How can we design a system that allows technology teams to build products with risk and governance in mind, and get them execution ready?
I sought out to map out user flows for different scenarios that displays the current problem and redesign a new flow that supports an ecosystem between product teams and clinicians.
Use Case 1: Confusing Test Results
Clinician flow:
Review results → can’t quickly identify critical info → spends extra time interpreting → checks other systems → asks colleague → delays decision → moves on to next patient → issue becomes normalized
Technology team flow:
Informal feedback or ticket → logged as UI issue → added to backlog → prioritized against roadmap → small UI fix shipped → ticket closed → root cause remains
Use Case 2: Workflow Breakdown in Care Coordination
Clinician flow:
Patient handoff → missing or unclear information → manual follow-up → calls/messages → workaround created → care delayed → frustration → problem accepted as normal
Technology team flow:
Issue reported → treated as ops/process problem → unclear ownership → no product project created → no system change → stagnation
Use Case 3: Safety Risk in Clinical System Design
Clinician flow:
Unsafe workflow noticed → reports to supervisor/safety channel → incident logged → local mitigation applied → no system redesign → risk remains → repeat incidents
Technology team flow:
Incident escalation → compliance/risk review → short-term fix → governance satisfied → system unchanged → learning lost
High Level Existing Flow:
Clinicians:
Experience breakdown → adapt → workaround → normalize → absorb friction → move on
Technology teams:
Report issue → ticket → backlog → patch → close → repeat
I then ideated key features that would solve the problems that technology teams and clinicians face and map them to the user flow.
Used by Technology Team (specifically project managers and product owners)
Starting a New Project
Structue a new initiative into a safe, executable plan.
Used by Technology Team (specifically project managers and product owners)
Making Workflow Changes
Structure everyday updates, workflow changes, and operational adjustments.
Used by Clinicians
Reporting a Care System Issue
Flag problems that affect care, safety, workflow, trust or reliability.
Atoms (Buttons, Text Fields, Status Cards, Etc)
Molecules (categorized entries, loading states, item cards, navigation nodes, status badges)
Organisms (Header System, Intake System, Execution Plan System, tables, etc)
Prompt Engineering the Final Screens
I then created a design system architecture for building a working clickable prototype.
