Research that turns messy reality into decisions.

When a multi-item order from an event syncs to the CRM, should each item land as its own transaction (split) or roll up into one parent row? The "obvious" answer changed completely depending on which staff member I asked.

The conflict was structural, not cosmetic. Development directors saw split transactions as misrepresenting donor giving — "$500 four times" reads weaker than a "$2,000 order" at recognition time. Finance staff often preferred split, because item-level GL codes and FMV/TDA drive tax receipting and reconciliation. Events coordinators just saw 47 rows for a 15-order night and assumed something broke. Same record, three irreconcilable needs.

The risk wasn't the toggle — it was trust after the toggle. The CRM admin who flips a system-wide setting needs proof it worked on their real data, not an illustration. That reframed the design around a verification moment: an impact count like "7 transactions → 3 order rows" on their own records.

Research drove a roll-up model that protects legally-significant FMV/TDA at the item level, preserves Finance's reconciliation needs, and gives Development the relationship-accurate view — validated across six CRM surfaces. Tested with 8 CRM admins across pilot orgs; the verification flow cut roll-up–related support tickets by ~40% in the first quarter after launch.

List Builder lets staff segment donors for appeals, acknowledgments, and major-gift tracking. But which segments do they build over and over — and where does the tool make them fight the data?

The recurring jobs were narrower than the filter set implied: lapsed donors, recurring-gift donors due to fail, donors above a recognition threshold, and event attendees who hadn't given since. Staff weren't exploring — they were rebuilding the same five lists from scratch every campaign, because saved segments didn't map to how they actually think about their donors.

Segmentation power wasn't the gap — repeatability was. The job to be done was "give me my people again," not "let me construct a novel query." That pointed design toward named, reusable segments built around real fundraising moments rather than raw field-by-field filtering.

Reframed List Builder from a query tool into a segment library aligned to the fundraising calendar. The path from "I need lapsed majors" to a ready list dropped from 12 clicks to 3, with 6 named segments adopted across the development team.

Leadership needed a clear view of where the platform was competitive and where rivals were pulling ahead — without the noise of feature-checklist parity arguments.

Ran structured teardowns of three direct competitors, mapped feature and experience gaps to actual user value, and translated findings into prioritised opportunity areas instead of a flat feature list.

Produced a decision-ready view of the landscape that informed roadmap conversations and sharpened where design effort would move the needle — surfacing 9 prioritised opportunities, 4 of which moved onto the active roadmap.

Members and admins kept opening tickets to ask where things were, not how they worked. Was the information architecture inherited from the product's history, rather than from how the work happens today?

The IA grouped features by internal product modules, not by the admin's job. Renewals, member records, and reporting lived three clicks deeper than they should have — and the labels carried legacy terminology unfamiliar to newer association staff.

Reorganised the top-level IA around the admin's day, with destination labels that matched member-facing language. Renewal-related tickets fell ~35% in the first quarter; members reached key functions in roughly half the clicks.

Admins were switching between multiple pages to complete the same recurring task. Was the workflow genuinely multi-page, or had the product fragmented information that belongs together?

Critical information for the most common admin job — running renewals — was spread across five pages, each one updated by a different team over the years. The fragmentation was an artefact of product history, not user need.

Consolidated the journey into a single dashboard surfacing the right data up front, with drill-downs only where they earned their place. Common tasks went from 5 pages to 1, and were about 30% faster in usability testing.