Building in one product.
Learning the whole ecosystem.

App Studio wasn't the glamorous product squad. Small team, often overlooked, sitting at the intersection of every other product without being fully claimed by any of them.

When I joined, end-user knowledge was almost nonexistent. We understood church admins — the people who built the app — but the congregants using it were largely a blind spot. No structured research, limited usability data, and a design system that reflected the problem: hardcoded values, components built in isolation, nothing reusable.

I chose to see it as an opportunity. Being at the edges meant I had to understand everything — Giving, ChMS, Resi, admin and end-user. That forced cross-product literacy became the foundation of how I think about design systems today.

One of the first things I pushed for was end-user focus, not just admin knowledge. I worked closely with Pushpay's UX Research team — advocating for and conducting usability testing, interviews, and synthesis that App Studio hadn't previously prioritised, then sharing it across the wider UX org.

The Church App is where community lives for congregants — events, groups, giving, media, communication. People building a sense of belonging through a digital product. We couldn't design well for them without understanding who they were.

Highlights from a broader two-year body of work. Every feature required working across product boundaries — teams with their own roadmaps, constraints, and definitions of "done." That's where the design work actually happened.

StudioC brings a third-party personalisation model into the Church App. The auth model available at the time meant log-in happens on the church's side — so I designed a pragmatic pattern around that constraint: anonymous content shows by default, with an invitation to log in, not a wall.

Working at the intersection of Giving, ChMS, Resi, and the app layer meant developing fluency across the whole Pushpay portfolio. I couldn't design Events without understanding ChMS. I couldn't design media without understanding Resi. I couldn't design giving without understanding the Donor Portal.

That forced breadth is exactly what made me effective when the opportunity came to lead Design System work. You can't build a system for 7 products if you only understand 1.

The inconsistencies I encountered in App Studio — hardcoded values, components built in isolation, no shared token architecture — weren't unique to that team. They were systemic.

As Design System Lead, I'm leading an atom-level audit across the full UI library and component library (Storybook). The premise: get the atoms right, and every molecule and organism built on top inherits the improvement — without blocking other teams or creating dependencies.

Claude runs cross-channel audits between Figma, Storybook, and GitHub — surfacing variable mismatches, hardcoded values, and component health, then generating Jira tickets directly from findings. Weeks of manual audit, now hours.