Our Work

The Challenge

Operating room emergencies are rare, fast-moving, and high stakes. In pediatric anesthesia, clinicians must diagnose, treat, and coordinate as a team while managing weight-based dosing and rapidly changing conditions. Printed references were too slow, and even experienced providers miss steps when cognitive load spikes. The question was how to get the right information in front of the right person at the right moment without adding friction to an already pressured environment.

What We Designed

A system that guided clinicians through a repeatable emergency workflow: select the crisis event, enter patient weight, confirm recognition criteria, follow staged treatment steps, review medication dosing, and arrive at a shared end-of-algorithm review. The structure supported rare but life-threatening pediatric events including anaphylaxis, bradycardia, hyperkalemia, airway fire, hypoxia, transfusion reactions, and cardiac arrest.

The design problem was not making it look clean. It was making sure clinicians could navigate it correctly under stress, on a tablet, while coordinating with a team. Every structural decision was made with that context in mind.

Key Design Decisions

• Translated paper crisis protocols into interactive algorithm flows clinicians could follow in real time without having to interpret or remember
• Structured each event around the same repeatable pattern: event selection, recognition, treatment, dosing, escalation, and resolution
• Designed weight capture as a persistent system input so medication guidance stayed accurate throughout the workflow without requiring re-entry
• Used checklist interactions and progressive disclosure to reduce cognitive overload without hiding information clinicians needed
• Maintained the same clinical workflow across iOS and Windows 8 while adapting to each platform's interaction model

How the System Worked

• Converted paper checklists and treatment pathways into interactive Yes/No treatment flows
• Kept patient weight visible and editable throughout so dosing stayed accurate as conditions changed
• Added a crisis timer to track elapsed time once an algorithm began
• Created cross-links between related algorithms for escalation and differential diagnosis
• Standardized a shared end-state screen prompting team review, therapy options, ICU transfer decisions, consults, and procedure cancellation
• Included action logs, settings, hotline information, and support features for real-world clinical use

Cross-Platform Design

iOS and Windows 8 required different UI conventions, but the clinical workflow had to remain consistent. We adapted the interface to each platform while preserving the same underlying algorithm structure, navigation logic, and treatment sequence. Clinicians could rely on the same mental model regardless of which device was available.

Process and Collaboration

Algorithms were revised through ongoing collaboration with clinical stakeholders to improve symptom ordering, simplify navigation, standardize medication units, merge related pathways, and clarify escalation logic. That collaboration shaped not just the screens but the decision model itself.

Design Principle

Do not ask clinicians to remember the protocol. Put the protocol in the interface, keep it structured, and make the next step obvious.

The Challenge

Providence absorbed over 100 cyberattacks daily. That threat level required keeping the entire clinical desktop inside a Citrix security perimeter. It was the right call. But it meant that Epic, ServiceNow, and a patchwork of other systems inherited from acquired hospitals all lived as separate applications inside a walled garden with no shared layer connecting them.

Administrators bore the heaviest cost. Approving or denying routine requests—a new computer for cardiology, a schedule change, a supply order—meant navigating between multiple applications for tasks that should take seconds. Providers had the same problem. Everyone interviewed said the same thing: they wanted one place to handle this, and the constant switching was eating their time.

The Approach

The director who originated the initiative had prior experience at Citrix and identified a widget feature that could serve as an aggregation layer inside the secured desktop. The idea was to surface consolidated request workflows from Epic, ServiceNow, and other systems inside a single Citrix dashboard, available on login, without requiring users to launch separate applications.

I hired and led the development team, conducted discovery interviews with administrators and providers, and designed the workflow model. Our first test case was administrator request approvals: one interface, one click per request, no app switching.

Where It Broke Down

Two constraints converged and closed off the path.

The only sanctioned build tool for the Citrix widget was a low-code environment that couldn't support what we were designing. The workaround was to surface a web application inside the widget space, but that created security vulnerabilities the Citrix perimeter existed to prevent. We couldn't use the sanctioned tool and we couldn't safely use the workaround.

While we were working through this, Citrix engineers began signaling informally that the widget feature itself was not long for the platform. Shortly after, it was sunsetted entirely. The one mechanism that could aggregate inside the security boundary was gone.

What We Proposed Instead

We came back to leadership with an alternative. A standalone web application dashboard with broader scope, designed to span not just the original use cases but the full patchwork of systems across every hospital Providence had acquired. It was technically stronger and more scalable than the original widget approach.

But it couldn't meet the one non-negotiable requirement: available on login, inside the perimeter, without adding another application to the stack. Leadership made the right call and shut the project down. The team was reassigned.

What This Shows

The problem was real and validated. The approach was sound given the constraints available at the time. The technical path was closed by an external vendor decision, not a design failure. When it closed, we identified an alternative that would have worked in a different environment and were honest about what it couldn't do.

Designing inside a hostile constraint environment, where every integration decision carries a security implication and the vendor landscape can shift under you, is a different discipline than designing for a clean greenfield product. This project was that discipline.

Design Principle

Know which constraints are load-bearing before you build against them. When the foundation changes, stop, assess what's still possible, and say clearly what isn't.

The Challenge

T-Mobile leadership needed a scalable business intelligence platform that could serve current reporting requirements while remaining adaptable to future data structures they could not yet fully specify. Multiple access levels required different views of the same underlying data without creating a maintenance burden as the organization's needs evolved.

Key Design Decisions

• Determined user needs across all access levels through stakeholder interviews with leadership before any design work began
• Designed a UI architecture flexible enough to accommodate both current and anticipated data structures
• Implemented MVC architecture using Angular for clean separation of concerns and long-term maintainability
• Built the platform as a reusable foundation for future internal applications, not just the immediate use case
• Led the first team in the department to adopt Agile Scrum methodology, which became the standard across the organization

What Made It Last

The platform ran in active production for four years. That longevity came from design decisions made early: an architecture that could absorb changing requirements, a UI that gave different user levels what they needed without constant customization, and a codebase that other teams could build on. The pattern was reused for subsequent internal tools.

The Challenge

Care team needed a redesign that maintained T-Mobile's fun, enthusiastic culture while giving employees clear visibility into bonus calculations. Management needed aggregated statistics organized by location. The challenge: make complex performance metrics feel approachable and motivating.

Key Design Decisions

• Worked with Java developer to realize dynamic tile function possibilities (interactive gauges, real-time updates)
• Designed predictive interface allowing employees to model "what if" scenarios for bonus optimization
• Created enthusiasm-driven UI matching call center culture without sacrificing data clarity
• Built hierarchical views: individual performance → team → location aggregations

Design Philosophy

Turned dry performance metrics into an engaging, game-like experience. The UI celebrated achievements while providing actionable insights for improvement—reflecting T-Mobile's unique approach to employee motivation.

The Challenge

Tracking information for salmon recovery projects required serving vastly different user needs: scientists wanting raw data tables, policymakers needing summaries, and students requiring educational context. Database queries returned massive tables of scientific data that needed progressive disclosure.

Key Design Decisions

• Designed familiar webpage interface with intuitive navigation
• Built progressive disclosure: summaries in graphics/charts for general users, full scientific data access on demand
• Integrated with Oracle database using APEX (HTML/CSS front-end)
• Created visualization layer that made complex conservation metrics accessible to non-scientists
• Also designed commercial fisherman trading app with regulatory compliance built-in

Design Principle

Don't hide the complexity—layer it. Scientists got their tables, students got their charts, everyone got value from the same underlying data.

The Challenge

2013 site launched with bugs due to deliberately obfuscated JavaScript. Lead programmer was fired, leaving company scrambling for 2014 deployment. Brought in late in the game to rebuild entire site with weeks to deadline.

Key Design Decisions

• Threw out previous year's code completely
• Rebuilt from scratch using Bootstrap, jQuery, and Greensock JS for animations
• Optimized for performance under massive traffic spikes
• Built fully responsive (kids use whatever device they can access)
• Created maintainable codebase using well-supported libraries

What I Said No To

Clever code. No custom animation engines, no framework reinvention, no showing off. Used battle-tested libraries and clear documentation so the next person could actually maintain it.

Fun Fact

When NPR ran the headline "NORAD Tracks Santa Begins with a Typo" for the 2014 launch, I nearly had a heart attack before realizing they meant the 1953 origin story.