Skip to content

Fundraising redesign — design spec

Status: Approved direction (CEO, 2026-06-14) — build agents target this doc. Scope: the whole manager fundraising area in the AngularJS admin SPA. Relationship: this is the design for Step 2 of the Manager MVC → SPA migration (ENG-87). The campaign create/edit screens are net-new builds; the already-migrated screens (donations, scheduled, settings, list) get restyled to these tokens.

Wireframes (layout/IA only — build with existing admin styles): campaign cockpit + list · campaign builder · area nav + scheduled donations

North star: momentum

A fundraising manager should feel their fundraising is working. Every screen leads with progress, not forms. This single idea drives every decision below: progress-first layout, money-as-hero numerals, a live donation feed, fill/celebrate motion, and color where green means money — nothing else.

The redesign lives inside the existing admin shell (Bootstrap 4 + ui-router). It does not introduce a new brand font or restyle the whole admin. Fundraising earns its face through layout, progress visualization, and motion — not a parallel design system.

Approved refinements (CEO, 2026-06-14)

  1. Suggested amounts carry text. Each suggested amount has an optional caption ("$25 — a warm coat for a child"). Maps to the existing DonationCampaignPaymentButtons (Amount + Description). Show the caption on the donor preview and the cockpit; the builder edits amount+caption pairs.
  2. Descriptions can be long. The description is a long/rich field. Cockpit shows it in full (collapsible "read more"); list cards and the donor preview show the short description only.
  3. One image, auto-thumbnail. Retire the two-image model (separate detail image + listing thumbnail). The builder takes one cover image; the server auto-derives the listing thumbnail. No schema change required — keep ImageThumbnailUrl but auto-populate it from the single cover upload (generate on save, or on the fly). Build agents: consolidate the upload UI to one field and wire auto-thumbnail.

These mockups are WIREFRAMES — build with the existing admin styles

The attached mockups communicate layout, information architecture, and interaction only. The specific colors (green/blue), font (Plus Jakarta Sans), and exact pixel values in them are illustrative, not a target visual system. Build with Raklet's existing admin design system — Bootstrap 4, the existing SPA components, the existing SCSS in Raklet.Backend/Content/styles/. Do not introduce new fonts, a new color palette, or new CSS tokens.

Map the wireframe intent onto existing styles:

Wireframe intent Build with existing
money/progress emphasis (raised amounts, progress bars, donation amounts) the admin's existing success/green and the existing progress-bar component
action buttons/links (Edit, Share, Publish, Donate-CTA) the admin's existing primary button style
cards / panels / sub-nav / tables existing card, tab-nav, and table components
status pills, toggles, inputs, chips existing Bootstrap/SPA form + label components
money figures as hero existing font, just larger + bold + tabular-nums; no new typeface

One principle worth keeping from the wireframe: reserve the money/progress color for money/progress — don't paint non-money buttons in the success color. Use the admin's existing primary for actions.

Typography — money is the hero (within the existing type system)

  • Body/UI: admin's existing sans.
  • Money numerals: large, heavy (700-800), font-variant-numeric: tabular-nums. Raised/goal figures carry the screen. Hero raised amount ~44-46px; card raised amount ~24px; feed amounts ~14px.
  • Apply .num { font-variant-numeric: tabular-nums lining-nums } to every figure (amounts, counts, dates) so columns align.

Spacing / radius / motion

  • Base 8px; comfortable density; cards with 16-24px padding; generous space around the hero.
  • Radius: inputs/cards 9-12px, pills 999px.
  • Motion (intentional, respect prefers-reduced-motion):
  • Progress bars fill from 0 on load (~1.1s ease-out).
  • New donation rows slide in + brief --money-soft highlight.
  • Goal reached → a small, single celebration (no looping confetti).
  • Everything else minimal.

Components

  • Progress hero — status pill, campaign name, money-hero raised amount + "of $X goal", thick progress bar (fills on load), a one-line momentum note ("71% · on track to finish 4 days early"), and a 3-up stat row (donors / days left / avg gift).
  • Progress card (list) — name + meta, money-hero raised/goal, fill bar, a 7-day donation sparkline, status pill. Replaces the plain table row. Uses the auto-generated thumbnail.
  • Donation feed row — avatar, donor name + context ("monthly", "in memory of…", "2 hrs ago"), money amount. Newest row gets the fresh highlight. A "live" pip in the header.
  • Suggested-amount editor + chip — amount + optional caption. Builder edits pairs; donor preview/cockpit render $25 with caption under it. Backed by DonationCampaignPaymentButtons.
  • Completeness meter — "Ready to publish 80%" + mini bar in the builder topbar. Reinforces momentum during creation.
  • Live preview — the donor-facing campaign card, updates as the builder form changes. The creation reward.

The fundraising area has two distinct navigation levels. The earlier mockups only showed the campaign screens and omitted the area nav — that was a review gap, not a scope cut. Both levels are required for parity.

Level 1 — fundraising area sub-nav (persistent, matches today's _Fundraising.cshtml content header and the live SPA states):

Section SPA state Notes
Campaigns manager.fundraising.campaigns.list (+ .create, .edit, detail/cockpit) default landing when campaigns exist
Donations manager.fundraising.donations all one-off donations across campaigns
Scheduled donations manager.fundraising.scheduleddonations recurring/scheduled donations management
Settings manager.fundraising.settings fundraising settings
(Welcome) manager.fundraising.welcome empty state before any campaign

Render Level 1 as a secondary horizontal nav directly under the "Fundraising" page header, present on every fundraising screen. This is how a manager reaches Scheduled donations — it is an area section, not a campaign tab.

Level 2 — single-campaign tabs (only inside an open campaign cockpit): Overview / Donations (this campaign) / Payment buttons / Photos / Settings, with a back link to Campaigns. These are scoped to one campaign and are distinct from the Level-1 Donations/Settings sections. Do not merge the two levels.

Per-screen layouts

Campaigns list

Progress-first cards, not a table (the full data table stays available for the donations list, not campaigns). Each card: auto-thumbnail, name, donor count + days left, money-hero raised/goal, fill bar, 7-day sparkline, status pill. Empty state invites creating the first campaign.

Campaign cockpit (detail) — manager.fundraising.campaigns.detail

Top: progress hero. Then two columns — left a live recent-donations feed, right a compact campaign summary card (status, dates, payment account, public-donations, payment-button count). Below: management tabs — Overview / Donations / Payment buttons / Photos / Settings. Full (collapsible) description lives in Overview.

Campaign lifecycle actions are separate: Draft/Published controls public/member visibility, while Delete removes the campaign from normal admin/public surfaces. Delete hard-removes campaigns with no donation records. If payments or payment tickets exist, Delete marks the campaign as deleted and preserves donation/payment/reporting history.

Campaign builder (create/edit) — manager.fundraising.campaigns.create / .edit

Left: sectioned form that self-confirms each section (Basics → Goal & dates → Donations → Photo). Basics = name, short description, long description. Goal & dates = goal (money input), currency, start/end. Donations = payment account, suggested amounts with captions, public-donations toggle. Photo = single cover upload (auto-thumbnail). Topbar = completeness meter + Save draft / Publish. Right: live preview of the donor campaign — name, short description, money-hero goal, suggested-amount chips with captions, Donate button. Updates as you type. Fields preserved from the old model: Name, Description, ShortDescription, Goal, StartDate, EndDate, Status (draft/published), PaymentAccountId, PublicDonationEnabled, cover image, payment buttons.

Already-migrated screens (restyle only)

Donations list, scheduled donations, fundraising settings, welcome/empty: apply the tokens above (money-hero figures, green-means-money, card treatment, motion). No behavior change.

Notes for build agents

  • This is design + rebuild, not a straight port. The create/edit SPA screens are currently stubs (campaigns-create.html = placeholder text; no edit state; FundraisingResourceApi/FundraisingService have no campaign write methods). Build the API (get-by-id / create / update), resource, service, controllers, templates, and the .edit state — see the migration plan §5.
  • Preserve all capabilities/fields; the redesign changes presentation + the create flow + the image model, not the donation/campaign data semantics.
  • Keep OAuth/payment-account callbacks server-side (unchanged).
  • Build inside the admin shell; reuse the admin font; verify the grunt bundle (scripts/dev/invoke-backend-grunt.ps1).
  • Sequence (still pending Zafer's prioritization): campaign builder (create/edit) → cockpit/detail → list cards → restyle the already-migrated screens. The donor-facing public donation page is out of scope here (admin only).

Decisions log

Date Decision Rationale
2026-06-14 North star = momentum; progress-first, money-as-hero, green=money only CEO: current fundraising UX weak; make progress feel alive
2026-06-14 Redesign inside existing admin shell, no new brand font Fundraising is one area of a shared admin; avoid a parallel design system
2026-06-14 Suggested amounts carry captions (reuse DonationCampaignPaymentButtons) CEO refinement; storytelling per gift
2026-06-14 One cover image + auto-thumbnail (retire 2-image model) CEO refinement; simplify form + data