Making data
speak plainly.

Church administrators manage complex giving data — transactions, recurring schedules, lapsed donors, campaign performance, fund allocation. Making sense of it historically meant manual exports, spreadsheet work, or relying on a data team. The opportunity: AI-powered analytics in the hands of the people who needed it most.

The integration used AWS QuickSight to surface giving insights — but before any interface could be designed, the data itself needed to be structured so AI could reason about it accurately.

Most UX work on AI products starts at the interface — how the user asks the question, how the answer is displayed. This project went a layer deeper: working with data engineers to ensure the AI had the context to answer correctly in the first place.

That meant reviewing every field in the giving data model — transactions, recurring schedules, donor records — understanding what each field meant to an administrator, how they'd talk about it, and what kind of queries they'd expect it to answer.

Labels, descriptions, and semantic context gave the AI the right framing — so when an administrator asks "show me lapsed donors from last quarter," the system understands what "lapsed" means in church giving, not just as a generic data concept.

I also worked on calculated fields — experimenting with custom metrics and suggesting them to the data engineering team based on how administrators actually think about giving performance. UX knowledge informed the data model, not just the other way around.

Before designing the interface, I conducted user testing and interviews with church administrators to understand how they thought about giving data — not how the system stored it. The gap between those two things is where most data tools fail.

The research shaped both the taxonomy and the interface — ensuring the queries the AI could answer matched what administrators actually asked.

The biggest UX learning wasn't about the interface — it was about confidence. Administrators were willing to use AI for queries, but only if they could verify the output before acting on it.

It's an underaddressed problem in AI product design. When the answer is a number tied to a financial decision, "trust the AI" isn't good enough. The design had to surface enough context that an administrator could sanity-check the result without re-running the query.

While the QuickSight integration handled transaction data, the "Ask AI" exploration went further — designing what fully conversational giving intelligence could look like with more control over the AI layer.

The vision: a Claude-like experience for giving data — administrators having a real conversation with their numbers, following up, saving queries, building on previous answers, and getting proactive insights instead of reactive reports.