Work

The Story

An enterprise property management organization was modernizing a decade-old API ecosystem with hundreds of external vendors. The system worked technically, but nobody could reason about it — who consumed what, what was safe to change, or who owned what when things broke. I led product strategy and design to build a platform that made API dependencies, lifecycle states, and ownership visible and trustworthy across engineering, operations, vendor, and leadership teams.

The first design challenge was semantic. Teams used language inconsistently — "it's kinda active," "technically configured," "mostly approved." The same word meant different things to different roles, and no one could trust what they were seeing.

We introduced explicit lifecycle states and aligned technical status with business meaning. Configured ≠ Approved ≠ Active. Each state had a specific definition that everyone could rely on. This semantic layer became the foundation for trust — teams could make decisions based on clear state, not interpretation. The reframe that unlocked this work: we weren't designing an admin panel, we were designing a shared mental model.

Teams needed to understand how changes or failures propagated through the system. We designed the platform to make relationships legible: which vendors consume which APIs, what upstream systems feed each API, and what downstream impact a change would have. For example, if an engineer proposed adding a field to the Background Check API, the system showed that three downstream consumers — the Rental Application System, the Vendor Screening Portal, and Employee Onboarding — would all need code changes to handle the new field. The goal was enabling reasoning before making changes, not reacting after failures.

The same underlying system state was surfaced differently depending on role. Vendors needed clarity on readiness and next steps — their view showed integration status, action steps, and support contacts. Engineers needed confidence in what was safe to change — their view showed dependencies, consumer counts, environment badges, and impact analysis. Operations needed early warning signals — their view showed health indicators, ownership info, uptime metrics, and migration status. Leadership needed aggregate risk visibility — their view showed API counts, adoption trends, and risk summaries.

The governing design principle: not to show everything to everyone, but to show the right depth in context. Each role got the information density appropriate to their decisions.

Rather than burying signals in raw log output, we surfaced system state in ways that non-platform experts could understand. This meant differentiating configuration issues from runtime failures, highlighting early risk indicators, and making health and readiness visible at the right moments for the right role. The design principle: surface system state in ways that enable reasoning, not just monitoring. Before, an engineer would need to parse timestamped log entries to find a config validation error. After, they saw a card that said "Property API — Config issue — Missing: owner field." The cognitive cost of understanding went from minutes to seconds.

The most telling shift was conversational. Engineers stopped saying "I think this is safe to change" and started saying "I know what this affects." Vendors stopped asking "When can we go live?" and started tracking their own progress. Operations stopped firefighting failures and started preventing them.

The Integration Hub didn't just organize information — it created shared understanding that enabled confident decision-making at scale. Trust, speed, and predictability followed.