Aligning a large team before product design
How object-oriented thinking aligned a product team on a shared system model in three days.
Making scheduling easy
A healthcare system aimed to design its mobile appointment scheduling so users could book appointments with providers across various locations. With a tight timeline, they sought a clear plan for long-term success.
To get there, I co-facilitated a multi-day object-oriented discovery sprint—a structured discovery workshop based on Object-Oriented UX, a method for designing systems around the real-world objects users interact with. The workshop brought together over 15 team members, including development leads, product owners, executive directors, data specialists, developers, and contractors, creating shared understanding across every role before a single screen was designed.

Mapping the system together
With such a diverse group in the room, the workshop surfaced assumptions and requirements that would have otherwise emerged as costly surprises mid-development. Together, we identified the core objects of the system: User, Location, Provider, and Appointment. The Appointment object quickly revealed hidden complexity—different states, different stages, different contexts—and became the focus of our three-day effort.
By the end, everyone understood not just what we were building, but why the system needed this design. That shared language became the foundation for everything that followed.

Designing with complete context
Going into the design phase with that foundation made all the difference. As the designer, I had everything I needed to create a strong, reusable Appointment card component that accounted for every variation from the start. The development team understood why an "upcoming appointment" looked different from a "past appointment" or an "available appointment slot," because they'd been part of defining those distinctions from day one.

That early alignment translated directly into a smoother build: fewer revision cycles, no daily check-in calls to address forgotten edge cases, and no last-minute mockup updates due to requirements surfacing weeks into development.
What this meant for the project:
Long-term plan and alignment, improving future discussions.
Better user experience—appointments were clearly recognizable no matter their state
Faster design and development phases without endless back-and-forth
More articles

Documenting a legacy system before a re-build
How object-oriented thinking helped a team understand a complex legacy invoicing system no one could fully explain.

Aligning terminology before a website re-design
How object-oriented systems thinking cleared up conflicting internal language before the website was built