A real GiveSmart Donor CRM feature — Transaction Display (Split vs Roll-Up) — taken from an engineering-led PRD to a reframed "Grouped Orders" experience, a reusable component system, and working prototypes.
The same backbone on every complex feature: understand the system first, evaluate it honestly, reframe the mental model, then design and prototype the solution as a reusable system.
In Donor CRM, a multi-item gift from a GiveSmart Events or Fundraise order (ticket + auction + paddle raise) syncs as separate transactions by default — "Split." The new feature lets an admin switch to Roll-Up: items sharing an Order ID consolidate into one parent row.
The "why" is relationship integrity. Split misrepresents giving — a $2,000 gala order reads as "$500 × 4," understating the donor and triggering four thank-you letters for one evening. But the change is constrained and easy to get wrong: it must be UI-only (no backend mutation), forward-only (legacy and CRM-native gifts stay itemized), and it touches legally significant fields — FMV and TDA drive tax receipts and can never appear to be hidden. The real challenge wasn't drawing rows; it was making a financial transformation feel safe to a CRM admin who has never met the donor.
I translated the as-is PRD into explicit user flows so every edge and dependency was visible before any UI existed — the input to design, and the contract for engineering and QA.
End-to-end user flows mapped, including decision branches and edge cases
Surfaces: Settings, Gift Listing, Donor Profile, Data Import, Thank Donors, Search
Eligibility rules: has Order ID · after activation timestamp · from GSE/GSF
Personas weighed — Development, CRM Admin, Events, Finance, Donor
Mapping the flows first surfaced the hardest truth early: the same donor's history can contain grouped, itemized, legacy, and CRM-native rows at once — so hierarchy and trust, not grouping mechanics, were the real design problem.
Before designing the fix, I evaluated the as-is PRD against usability heuristics. A senior team's job isn't to implement a spec faithfully — it's to surface where the spec will fail real people. The audit produced a prioritized risk list; the highest-impact ones drove the redesign.
"Split / Roll-Up / Order ID / forward-only" is system language. Users think in donations, orders, receipts, and giving history.
Two display models, multiple disclaimers, and edge-case education up front made admins fear breaking financial data.
Grouped, legacy, CRM-native, and external rows shared one table with no hierarchy — totals and relationships were easy to misread.
Old gifts split, new gifts grouped — the same donor's history looked broken, eroding trust in the data.
The action menu appeared everywhere but some actions were invalid — users discovered failures only after interacting.
Inline expansion of dense rows made financial reconciliation and mid-size laptops a scanning nightmare.
Plus: hidden grouping rules, surprising search auto-expansion, duplicated patterns across modules, and missing empty / transitional states.
The PRD framed this as "a technical transaction rendering mode." I reframed it as a Grouped Orders View — gifts from the same purchase, shown together. That single shift collapsed most of the heuristic risks at once, and it changed the language across every surface.
| System language (before) | Human language (after) | |
|---|---|---|
| Split Transactions | → | Individual Gifts |
| Roll-Up Transactions | → | Group Orders |
| Parent Row | → | Order Summary |
| Child Rows | → | Included Gifts |
| Roll-Up Active | → | Grouped Orders Enabled |
North-star test for every decision: does this make it easier to answer "who gave us money, how much, and what do I say to thank them?"
Each decision answers a specific risk from the audit — and is defensible to product, engineering, and finance.
Replace inline expansion of 25-column rows with an order row that opens a right-side detail drawer for included gifts, FMV, TDA, and actions.
↳ readability · focus management · tablet supportGroup the table into "New Grouped Orders" and "Other Gifts" so users instantly see why a row is or isn't grouped.
↳ hierarchy · trust · scannabilityAfter enabling, show an impact count on the admin's actual records — "7 transactions → 3 order rows" — not an illustration.
↳ CRM-admin needs proof, not a toastKeep tax-significant fields one clear affordance away inside the order, with the expand control always visible.
↳ legal significance · acknowledgment accuracyOn import/review surfaces, show the sync timestamp so "hasn't run yet" never reads as "something broke."
↳ kills the sync-gap anxietyDonor profile reads "8 Orders · 14 Individual Gifts," not "2 orders + 3 items = 5 gifts."
↳ less cognitive math · more trustRather than redesigning grouping four times, I defined a small set of shared components so Gift Listing, Donor Profile, Data Import, and Thank Donors behave identically — consistent for users, faster for engineering, easier to QA and onboard.
Designing for the large-org case — where the settings admin, the finance reconciler, and the relationship owner are three different people — keeps the system honest for everyone.
I prototype in real code (React / HTML) so interactions, density, and edge cases are validated before engineering invests. Two milestones from this project are live below — open them and click through.
The detailed build across Gift Listing, Client Settings, and Data Import — ORDER badge tooltips, a verification banner with spotlight, expand/collapse all, filter chips with counts, an impact count in the confirmation modal, and a 24-hour undo.
Open prototypeThe recommended evolution: the master → detail drawer pattern, segmented datasets, order-level actions, and human language applied at enterprise data density — the as-built spec, improved.
Open prototypePrototypes run on React / Tailwind via CDN — open in any modern browser.
Clarity over flexibility
Financial trust over feature density
Readability over compactness
Progressive disclosure over nested tables
Human language over technical language
One consistent interaction model everywhere
Research-led redesigns and shared systems aren't process for its own sake — they move the numbers.
Open to Principal and Lead Product Design roles — remote-first, open to relocation, overlap hours for US & UK teams.