From Developer → UX Team Lead
Building a UX practice and modernizing clinical workflows for point-of-care use.
OPIE Anywhere was already being built when I joined. No designer. No research process.
Just a product already in motion and a chance to change what it could be.
OPIE Software • Healthcare SaaS • 2018-2021
B A C K G R O U N D
From Desktop to Anywhere
Orthotics and prosthetics is the specialized healthcare field focused on designing, fitting, and delivering custom devices like prosthetic limbs and orthotic braces to patients with physical disabilities or injuries. OPIE Software is the platform O&P practices run on, managing everything from patient scheduling and clinical documentation to billing compliance and device delivery.
The Challenge
For most of OPIE's history, practitioners managed everything from a desktop computer at the office. But O&P care doesn't happen at a desk, it happens at hospitals, rehabilitation centers, skilled nursing facilities, and patient homes.
Practitioners were seeing patients in the field with no way to access the system they depended on.
OPIE Anywhere was the answer: a full cloud and mobile rebuild of the platform, putting every workflow in a practitioner's hands, on any device, wherever they were seeing patients.
Eight months in, I decided to do something about it. I started designing improvements on my own time and brought them to sprint planning. It worked. They wanted more.
T H E P I V O T
Developers had designs to build from.
Fewer surprises, less guesswork.
Design moved ahead of development.
One to two sprints ahead. Less rework, better planning.
A new role was created. I pushed to own it fully.
I pushed for design only. The director of development backed it.
M Y S T A R T I N G P O I N T
From Developer to Design Lead
I joined OPIE as a front-end developer, hired to help build OPIE Anywhere from the ground up.
The team was rebuilding the legacy desktop experience as-is, same workflows, same logic, just on a new platform.
No UX designer.
No research process.
No design system.
The rebuild was already underway.
01
02
03
M Y C O N T R I B U T I O N S
I led UX across the full patient journey, from scheduling to device delivery.
I used bi-weekly all-hands meetings to bring leadership and the broader org into the design process. In a dev-focused culture, making 'what does the user need?' a standard question in every room
Designing for clinicians in an active product, with no existing research practice and a team still warming up to UX, meant every decision had to be right for the user and credible to the org at the same time.
01
Building the Foundation
I built the research practice from scratch, synthesizing legacy feedback, running user interviews, developing personas, and moderating usability sessions directly with clinicians. Every design decision built on that foundation.
02
Creating the Standards
I built the component library progressively, starting with what the team needed immediately and expanding over time. The system included permission-based patterns, error and validation states, responsive behavior across devices, and documented standards for when and why to use each component.
03
The Patient Journey
From the moment a patient walks in the door to the moment their device is delivered, I designed for every phase of the patient journey: scheduling, insurance, medical profile, Rx, billing, HIPAA compliance, dictations, and signature capture. End to end.
Code Selection
~
Code Justification
~
Delivery Receipt
~
Patient Profile
~
Appointments
~
Insurance
~
Prescriptions
~
Schedule
~
Medical History
~
Visit Notes
~
Patient Chart
~
Dictations
~
Code Selection ~ Code Justification ~ Delivery Receipt ~ Patient Profile ~ Appointments ~ Insurance ~ Prescriptions ~ Schedule ~ Medical History ~ Visit Notes ~ Patient Chart ~ Dictations ~
20+
Workflow areas designed end-to-end
100+
Individual features across the platform
200+
Feedback submissions analyzed
30+
Remote usability sessions with clinicians
A C L O S E R L O O K
A billing workflow that directly affects patient care.
"Setting up templates is a tedious process. I can see it being a pain for people starting out, this could be a reason not to use the feature."
— Practice manager and practitioner, multi-office prosthetics facility
In O&P, getting a patient their device requires more than delivering it. A practitioner must select the correct billing codes, justify each one for insurance compliance, deliver the device, capture a patient signature, and initiate a claim.
The Challenge
The software wasn't making the right action obvious at each step. A missed justification delays authorization. An incomplete delivery receipt delays billing. A billing delay means a patient waits longer for the care they need.
B I L L I N G W O R K F L O W
→ Select the correct billing codes → Justify each for insurance compliance → Deliver the device → Capture patient signature → Initiate a claim →
01
Code Selection
Every insurance claim starts with code selection. Practitioners must identify the correct billing codes for a patient's prescribed device. But the search was so difficult to navigate that practitioners kept physical handouts of keywords just to use it. And when alerts appeared, resolving them meant navigating away, losing context, and making errors.
"We even make our own training videos to teach the workarounds."
— Practitioner, multi-office prosthetics & orthotics facility
02
Code Justification
Before a claim moves forward, every code must be "justified" in writing: documented proof that each device component is medically necessary for that specific patient. The software had a template feature for this. It was so tedious to set up that some practitioners stopped using it and maintained their own Word documents on SharePoint instead.
03
Delivery Receipt
Every device delivery must be formally documented and acknowledged by the patient before a claim can move to insurance. But the form was desktop-only. Practitioners in the field were remoting into their office computers just to complete it. And when they got there, they had no way to know which codes had already been sent to billing. Getting it wrong meant rework, resubmission, and a patient waiting longer.
“When software tries to do everything, it gets too complicated. The less I have to do, the better.”
— Practitioner and business owner, multi-location practice
K E Y D E S I G N D E C I S I O N S
01
Alerts needed actions, not just information.
When selecting billing codes, the system checks for potential issues: codes that conflict, codes that require companions, codes with limited coverage.
The risks were real: compliance audits, denied claims, and rework after submission.
B E F O R E
All alerts collected in a single modal, disconnected from the codes that triggered them. Practitioners had to close it, remember the required action, navigate back, and resolve it manually for every alert. Practitioners learned to close the modal without reading it. When a new alert appeared alongside familiar ones, it went unnoticed.
A F T E R
Each alert surfaced inline with the code that triggered it, making it immediately recognizable and diagnosable. Distinct icons communicate alert type at a glance. Resolution available directly within the alert. Add or remove a code without navigating away or losing context.
If it requires action, make it visible.
02
Templates needed automation, not manual steps.
Before a claim can be submitted, every billing code must be justified in writing, documented proof that each device component is medically necessary for that specific patient. Practitioners used templates for this, but every dynamic tag inside them had to be manually translated before the justification was complete.
The risks were real: every manual click was an opportunity for an error that affected reimbursement.
B E F O R E
Tag translation required two manual clicks per code, every time. With multiple codes per patient, this added up quickly. The form offered no shortcut. Each code required the same two clicks, every time.
A F T E R
Each alert surfaced inline with the code that triggered it, making it immediately recognizable and diagnosable. Distinct icons communicate alert type at a glance. Resolution available directly within the alert. Add or remove a code without navigating away or losing context.
Repeated manual steps are a design problem, not a user problem.
03
Practitioners needed visibility, not guesswork.
When creating a delivery receipt or reviewing a code selection, practitioners needed to know the current status of that claim. Whether codes had been sent to admin, sent to billing, what the claim number was, and when the device had been delivered were all critical to making the right decision at each step.
The risks were real: duplicate billing, administrative errors, and compliance violations from decisions made without the full picture.
B E F O R E
Status information existed but lived elsewhere in the system. Practitioners had to navigate away from the form they were in the middle of completing to check whether codes had been sent to admin, what the claim number was, or when the device had been delivered. Mid-task navigation broke context and created errors.
A F T E R
Six critical status fields surfaced directly into the form: Codes Sent to Admin, Codes Sent to Billing, K-Level, Claim Number, Delivery Visit Date, and Code Selection Type. Available at a glance, without leaving the form. The same status bubble carried through to the Delivery Receipt, the same information available wherever practitioners needed it.
The right information, at the right moment.
O U T C O M E
By the time I left, OPIE had a shipped product, a design practice, and a team. None of those existed when I arrived.
01
02
03
Clinical workflows moved from the office to wherever care happened.
Practitioners could focus on patients, not software.
Design went from a missing function to an organizational mindset.
OPIE Anywhere launched in 2019, not as a 1-to-1 port of the legacy desktop system, but as a clinical workflow experience redesigned for point-of-care use.
Existing workflows were redesigned from the ground up, including the ability to link an appointment inline without leaving the form. New features like delivering codes on the same visit and designating who was signing on behalf of a patient were built directly from what practitioners told us was missing. Code selection, justification, delivery receipt, patient signature: all of it available on any device, wherever care was happening.
The goal was never to build a better interface, it was to make the interface invisible, so practitioners could focus on what they came to do: deliver patient care.
Alerts surfaced inline so practitioners could act without losing context. Tag translation became one action across the entire form. Status information appeared directly where practitioners needed it. Workflows that once required training videos and physical handouts worked without them.
When I joined there was no design function, no shared language for design decisions, and no process for involving users in product direction. By the time I left that had changed fundamentally.
Engineers building from a shared component library, design working 1-2 sprints ahead of development, other departments asking for UX involvement in their workflows. I hired and onboarded two junior designers into a practice that already had structure, language, and precedent. None of it left when I did.
Every decision came back to the same question:
What is the software asking users to remember that it could remember for them?
More Work →
Evergy Native Mobile App Design
Designing a scalable native utility platform supporting multi-account management, billing, outage reporting, and high volume self-service workflows critical to payments and service continuity.
Improving Checkout Clarity and Completion for Republic Services
Focused, approachable, and driven by results, our sales manager is all about building strong relationships. They help connect people to the right solutions—with clarity and care.