AI transformation

Context

Most orgs treat AI as a productivity layer. Adopt the tools, ship faster, move on. The bet I have been running is that AI is two distinct shifts running at the same time. The first is how design gets done, an operating-mode change that touches every part of the team’s day. The second is what gets shipped, a product strategy change that asks the org to figure out where AI creates customer value and where it does not. Each track has its own work, its own pace, and its own failure mode. The mistake is to do one and assume the other follows. They do not.

I led both at Pushpay through FY25 and FY26. This case study is the through-line.

Workflow track: changing how design gets done

Inflect: the thinking move

Inflect is the workshop framework I built and ran with the design team in mid-2025 to set up the workflow shift. It frames AI as an inflection point rather than a tool, walks teams through seven moves from interpretation to transformation, and ships two companion artefacts: Ladders of Value (mapping the work that has the most leverage when humans focus on it) and a leadership diagnostic (scoring the org on ten dimensions of AI readiness).

Inflect did the work that pure tool training cannot: it gave the team a shared vocabulary for the change and a way to talk about identity shifts (executor to orchestrator) without the conversation becoming defensive. Months later, the language was still showing up in design reviews and roadmap conversations. Workshop frameworks rarely survive that long. This one did because the moves and the artefacts produce work people keep using.

(Inflect has its own framework page that goes deeper into the seven moves, Ladders of Value, and the diagnostic.)

Design Forge: the doing move

Inflect set up the why. Design Forge is the how. It sits inside the broader ODAD programme (Outcome Driven Agent Development), which is the org-wide initiative that introduces new methods of using AI assistance throughout the software development lifecycle. Design Forge is the UX slice of that programme: a repo built for designers to use through Claude Code, producing prototypes that publish to Storybook using the team’s real component library. Designers can now explore concepts and ship a prototype that closely resembles the front-end engineering would actually build, rather than a high-fidelity mockup that stops at the design-engineering boundary.

I did not build the repo. My role is the part that decides whether the repo gets adopted: onboarding UX and Product teams, running training, and writing the best practices for using it successfully. The training is the pivot. Most teams can be told about agentic development; far fewer can be coached into a working rhythm with it. Design Forge succeeds or fails on whether designers and PMs find a working pattern that fits how they think, and that pattern is what the onboarding sessions develop.

This is the practical answer to a question that has been hanging over the design-engineering boundary for years: how do you get design output that engineering can extend rather than rebuild? Real components, in code, generated through an agentic workflow the design team owns.

The prototype review tool

The bottleneck after Design Forge was review. Reviewers had been opening the live prototype, taking screen captures, pasting them into Figma, and leaving comments there. The prototype was running in code; the feedback was sitting in pictures of code. The loop was slow, lossy, and it tied the team to Figma for an interaction that did not need Figma.

I built a tool that fixes this. Reviewers open a live prototype and leave comments directly on it, the same way they would in Figma. The comments thread, anchor to elements, and stay with the artefact. The flow is the one designers already know; the underlying system is the one Design Forge produces.

The first-order outcome is a faster review loop. The second-order outcome is that we are now on a path to decrease the number of Figma seats the team needs. Review was one of the last workflows binding everyone to a Figma seat. Removing it is meaningful both in cost terms and in signalling that the team is genuinely operating in a new mode.

Product track: changing what gets shipped

AI dashboard strategy

I contributed to the AI dashboard strategy at the start of FY26, helping the team see how surfacing intelligence from existing ChMS and DM data could differentiate the platform without requiring a separate product line. The contribution was UX framing into a board-level positioning conversation: what AI feels like to the user, where it earns trust, and what tier of insight is worth paying for.

Vision work: Sidekick, Smart Search, NaLa

Three pieces of vision work moved from concept into validated direction during this period:

• AI Sidekick vision (June 2025), a three-day cross-functional COS workshop output. Concept artefacts now shared externally with customers as part of validating product direction.
• Smart Search and chat-based retrieval vision (June 2025), the companion COS session focused on natural-language access to ministry data.
• NaLa user testing and research synthesis (FY26), running a complete test plan through to synthesis so the team had a clear signal before deepening the engineering investment.

The pattern is consistent: AI product directions need to be tested with customers earlier than non-AI directions, because trust is the differentiator. Customers need to know what the system gets wrong, not just what it gets right.

AI style guide

The AI style guide is an in-progress artefact that establishes shared patterns across nine areas, including entry points and trust signals, for AI features across the platform. It is the next-generation companion to the regular design system and is the artefact most likely to make AI feel coherent across the product surface rather than like a series of isolated experiments.

Industry fluency

To support this work, I completed the AWS AI Practitioner learning plan (eight trainings, around eight hours, including Fundamentals of ML and AI, Essentials of Prompt Engineering, and Security, Compliance, and Governance for AI Solutions). Course completion, not formal certification. The point was not the credential. It was making sure the AI architecture conversations with engineering were grounded.

Reflection

The most important decision in this work was running both tracks at the same time. There is a strong instinct in design orgs to wait: get the workflow change embedded first, then take on AI product strategy with a transformed team. That sequencing is comfortable and wrong. The teams shipping AI products learn fastest about how AI changes the design work, and the teams shifting their workflow are the most credible voice on what AI products should feel like. Holding both tracks open creates feedback between them.

If I were starting again, I would invest earlier in measurable signals on the workflow track. Inflect created the language; Design Forge created the artefacts; the review tool created a real cost lever. That is a good arc, but a more deliberate set of leading indicators (review cycle time, review volume per designer, prototypes hitting code review without rework) would have made the case for the operating-mode shift land faster with leadership.

The piece I am proudest of is not any single artefact. It is that two years from now, the question “how do designers work with AI?” at Pushpay will not be a debate. It is already an operating mode the team is in.