43% Less Admin Time: Patient Registration Redesign for Busy Clinicians

Business Context

Five-minute data entry per patient was a direct barrier to practice adoption and renewal.

OrthoLogIQ competed within surgical practices where clinician time is acutely constrained. Workflows taking five or more minutes created friction that discouraged usage and justified switching. Reducing administrative burden was simultaneously a usability improvement and a commercial retention lever: practices that found the platform efficient expanded usage, practices that found it inefficient contracted it.

What I Did

Redesigned both Add Patient and Edit Patient flows with a step by step wizard and tabbed layout.

Without a dedicated research team, I conducted informal interviews and live observations with clinicians over video calls. These real time sessions gave me insight into their mental models and where the current design created friction , even a small number of observations surfaced the key structural problems clearly.

I created multiple layout concepts (2-step and 3-step flows) for stakeholder review. A key structural decision: the existing success modal was a dismissal risk at the most critical moment. I repurposed it as a dedicated third step, a summary and confirmation screen, giving clinicians an unhurried view before submission.

I worked closely with Engineering from the start to align on Angular Material's stepper component, saving build time. I defined analytics custom events for Azure dashboard tracking and delivered detailed flow documentation covering every interaction, edge case, and unhappy path.

What I Found

The same layout was failing two fundamentally different tasks.

Four core problems shaped the design approach. The first two were about the workflow itself, the second two about navigating real project constraints.

• 01

  Cognitive overload

  Clinicians spent 5+ minutes on a task that should take under 2. All fields crammed into three dense columns required excessive scrolling just to locate the right field, no structure, no guidance, easy to miss or mis-enter data under time pressure.

• 02

  Modal dismissal risk

  The success modal could be dismissed before confirmation details were registered. In a high-pressure clinical environment, this created real risk of missed information at the most critical moment.

• 03

  Add vs Edit mismatch

  Add Patient (guided data entry) and Edit Patient (targeted correction) are fundamentally different tasks. Applying the same step-based wizard to both was the wrong solution for editing.

• 04

  Dev and sprint constraints

  Some directions conflicted with existing UI components and sprint timelines. Early alignment with Engineering on Angular Material's stepper prevented rework and kept delivery on track.

How I Designed

Three steps for Add Patient. Two tabs for Edit Patient. One dedicated confirmation moment.

Refining the step structure based on clinician feedback.

Early wireframes explored a three step structure: Personal Details, Surgery Details, and MotionSense. Clinician feedback highlighted that separating Personal and Surgery information created unnecessary fragmentation, they were comfortable scrolling through related fields as long as content was clearly structured. I merged Personal and Surgery into a single General step to reduce cognitive load, while keeping MotionSense as a distinct second step due to its unique wearable setup requirements and technical constraints.

Edit Patient, exploring the right structure for a different task.

The original Edit Patient screen mirrored Add Patient, reusing a multi step wizard. But editing is a targeted, corrective task , it benefits from speed and direct access, not a guided flow. I developed three wireframe concepts: a three column layout (reduced scrolling but felt cramped and caused overflow issues), a two column layout (cleaner but still not direct enough), and a more visual tabbed approach inspired by a Stryker design pattern. Developer feedback indicated the tabbed approach aligned best with existing component libraries, reducing build complexity within the sprint timeline. We aligned on a clean two tab layout , General and MotionSense, giving clinicians immediate direct access to the fields they needed to correct.

Component decisions and design system.

Shipped Add Patient wizard.

The final shipped flow, step 2 (MotionSense) of the wizard running on the OrthoLogIQ platform.

Outcomes

Clinicians completing entries faster, with more confidence and fewer errors.

What Shifted

The same structure failing two different tasks was the root problem, not the individual screens.

Add Patient and Edit Patient are different tasks that need different solutions. Once that distinction was clear, the right structure for each became obvious. The step-based wizard was right for guided data entry under pressure. The tabbed layout was right for targeted, fast correction.

What I Learned

Adopting existing component libraries earlier frees capacity for what actually differentiates the design.

Exploring custom component options before committing to Angular Material's stepper took time that could have been spent on the confirmation step, validation patterns, and edge case handling , the parts that actually made the experience better. I'd make the build-versus-adopt decision with Engineering in the first sprint, not after wireframes are in progress. I also defined custom Azure analytics events to track post-launch behaviour , Step 2 showed higher exit rates after launch, giving the team a clear data signal for the next sprint iteration.