PNC | Leadership & Operating Model

• Designed the operating system: intake/triage, Definition of Ready, and decision mechanisms.
• Scaled consistency: pattern governance + shared components + UX standards.
• Stayed hands-on: supported key workflows with prototypes, specs, and implementation guidance.

At enterprise scale, UX quality problems usually aren’t caused by “bad designers” — they’re caused by system gaps:

• Requirements mature late → designs change after engineering starts.
• Teams optimize locally → patterns diverge across services.
• Decisions aren’t visible → repeated debates, circular reviews, inconsistent outcomes.
• UX involvement varies → some teams use UX early, others treat UX as a “UI step.”

Goal:

• Create a repeatable process that makes work “ready” before design & build.
• Improve cross-team alignment without slowing delivery.
• Reduce late-stage rework and review cycles by increasing clarity earlier.

My leadership operates on two connected tracks: enabling product teams to deliver efficiently today, while continuously evolving shared patterns so the platform improves over time.

The output of Track B feeds back into Track A — updated patterns, contracts, and standards make future delivery faster and more consistent.

When patterns require enhancement, proposals move through an experimentation and validation gate. This includes prototype exploration, A/B testing where appropriate, and user sessions to assess impact before standards are updated. Executive alignment is built through evidence, not preference, ensuring changes scale safely across the platform.

To make the operating model real, I used a small set of repeatable mechanisms:

• Definition of Ready checklist: required inputs before design/build begins (states, data, edge cases, entitlements).
• UX intake rubric: helps Product teams understand effort + risks early (simple vs complex vs platform-level).
• Pattern decision log: record “why we chose X” so future teams reuse instead of reinvent.
• Reusable specs: interaction requirements, component guidance, and acceptance criteria templates.
• Design system governance: standards for navigation, tables, modals, dashboards, filters, empty/error states.

Two examples of how leadership mechanisms turned into delivery outcomes:

Example 1 — Dashboard widget framework

• Created a shared widget contract (header/footer/states/constraints) so teams could contribute consistently.
• Reduced ambiguity by defining “what belongs in a widget vs full service,” and how deep interactions should go.
• Enabled parallel delivery while preserving a coherent dashboard experience.

Example 2 — Workflow modernization patterns

• Standardized filtering, table behavior, and exports for trust-heavy workflows.
• Documented reusable patterns and ensured teams implemented them consistently.
• Used review checkpoints + specs to prevent drift late in development.

What changed after implementing the operating model:

• Fewer review loops: clearer requirements and decisions reduced back-and-forth in late stages.
• Less rework: edge cases and states were defined earlier, reducing redesign after build starts.
• More consistency: teams shipped with shared patterns instead of reinventing UI across services.
• Higher throughput: designers spent less time re-litigating and more time delivering.
• Better collaboration: Product/Engineering had a clearer path from problem → decision → implementation.

Note: Many details are intentionally generalized to respect enterprise confidentiality while conveying leadership impact.

• Clarity beats charisma: decisions stick when the rationale is visible and reusable.
• Guardrails enable speed: teams ship faster when they know the rules of the road.
• Leadership is leverage: the goal is multiplying the output of many teams, not owning the pixels.