Healthcare · Clinical Workflows
Nurse Registrar Workflows
At a glance: Researched and designed for a new user group on a clinical platform. Registrars thought in due dates, not tasks, so I built a registry screen around submission deadlines and onboarded all 20 pilot sites.
The Hawkeye platform coordinates care for patients who've had Left Atrial Appendage Closure (LAAC) surgery. With the platform in pilot at 20 sites and primary workflows built for nurse coordinators, my objective was to research, understand and design for a second user group, nurse registrars, so their partnership with coordinators could be better streamlined.
We knew registrars were already using Hawkeye, but not what they were doing in it or whether their needs were met. Most managed their work through custom spreadsheets and notebooks, making it hard to understand their workflow through remote research alone.
Pilot sites with nurse registrars onboarded after launch
20 / 20
User interviews across a two-week research sprint
12
Two-week sprints: research, then design
2
Understanding a new user
I ran a two-week research sprint with 12 user interviews. Scheduling was a constraint from the start: most nurse registrars only dedicate one or two days a week to registry work, so fitting interviews into a compressed timeline took flexibility.
From the interviews, I synthesized findings into a persona, completed a task and workflow analysis and identified the top pain points, then shared insights with stakeholders and the agile team to build understanding and buy-in before moving into design.
- Registrars organized their work around patient submission deadlines, not tasks.
- Their workflows were more complex than anticipated, driven by multiple patient milestones and registry requirements.
- Despite being highly organized, they felt consistently overwhelmed by the volume and detail they tracked.
- Quick visual reference was critical: they leaned on patient initials, status indicators and deadline proximity to get through the day.
Designing for how registrars actually work
I ran a two-week design sprint with the agile team and stakeholders around the two themes from research: findability and time savings. I led ideation and built two prototypes for user feedback.
What we learned
- Our hypothesis that registrars would prefer a task-based workflow (like coordinators) didn't hold; they thought in terms of patients due
- A registry screen organized by submission quarter was the right direction
- Early designs lacked detail: users needed to know whether a milestone appointment had already occurred, not just that it was due
What I changed
- Reorganized the screen by submission quarter and milestone due date
- Added appointment-status indicators using color and text labels together
- Surfaced patient initials prominently, a detail users flagged as essential for quick reference
Findability
Organize patients by the quarter their registry entry is due, and let registrars navigate directly to the milestone that needs attention.
Time savings
Patient initials, color-plus-text status labels and automatic backend placement into the right quarter and milestone, so registrars can scan and act at a glance.
Bringing the team along: because this was a new user group, I built the persona before we moved into design, both to align the agile team on who they were designing for and to support user-story writing during implementation. Engineers were involved from research through testing, so by the time we reached build the problem space wasn't new to them. That shared context cut back-and-forth and made collaboration smoother.
Designing the connective tissue between two roles
Hawkeye isn't a set of isolated screens; it's a shared system where coordinators, registrars and patients all move through one care-coordination process. Adding registrars wasn't bolting on a feature; it was designing the connective tissue so two adjacent roles could hand work back and forth without friction.
Mapping the ecosystem surfaced the dependencies: a registrar's deadline depends on coordinator milestones, which depend on patient appointments, which roll up to registry requirements outside the org entirely. Designing for one role meant tracing how every change rippled to the others.
A change anywhere in the chain ripples to every role downstream.
A registry screen built around due dates
Patients are organized by the quarter a submission is due and the milestone that's next. Each card surfaces the patient's initials for instant recognition, with color-plus-text status labels showing where things stand: scheduled but not submitted, completed and submitted, or not yet scheduled. Backend calculations keep every patient in the right quarter and milestone automatically. It wasn't perfect, and we knew it, but shipping a validated first version kept the feedback loop open.
Outcome & reflection
Following the release of the nurse registrar workflow, we onboarded registrars at all 20 pilot sites. To keep the feedback loop open after launch, I invited registrars to the bi-weekly pilot meetings already running with nurse coordinators, and began tracking usage metrics to understand adoption and the value delivered.
With nurse registrar workflows now in the application, Hawkeye moved closer to becoming a single shared digital space for the full care-coordination team, making the product more complete and more attractive to prospective customers.
What I took away
- Don't assume shared mental models. Registrars and coordinators do adjacent work but think about it differently. Validating that early saved us from shipping something that didn't fit how registrars actually worked.
- Bring engineers along early. Including engineering in research and ideation meant they understood the problem before build started: less friction, faster decisions, easier mid-build adjustments.
- A persona is an alignment tool. More than an artifact, it gave the team a shared reference for a user they'd never worked with, and it paid off when we wrote user stories.
- Ship, then iterate. The final design wasn't perfect, and that was okay. Getting something validated in front of users mattered more than holding for a complete solution.