How the Paperbark Funerals demo was made

Concept

Paperbark Funerals serves families arranging a funeral this week — often at 2am, often for the first time — people comparing direct-cremation prices under grief and time pressure, and over-60s arranging their own pre-paid plan. The page has one job: get the 24-hour line called, or the itemised ledger requested by email. The name is the WA tree that sheds its bark in soft layers — loss, held gently.

The art direction is a Cannington arrangement room at 9am: morning light, a linen table, one folder open with every cost written down, tea made. Calm, plain, zero salesmanship-theatre — the transparency is the sell.

Palette

The wave's only green-led light site — argued from the tree, not from a template: cream is bark, not linen-brand cream; the green draws lines, it doesn't shout.

Type

• Lora 600 (display) — a humanist serif with warmth that never shouts; the masthead and the ledger's italic “The honest total” are its moments.
• Karla (body, UI) — a plain-spoken grotesque for copy, chips and forms.
• Overpass Mono — every dollar on the page, tabular and even, because the argument is bookkeeping: figures should look audited, not advertised.

The signature — the Arrangement Ledger

Package chips (direct cremation / chapel farewell / graveside burial), coffin chips ($850 / $1,450 / $2,400) and add-on toggles (viewing +$350 / livestream +$300 / flowers +$260) drive a procedural SVG ledger page that writes itself: each included line inks in down the paper — label, a dotted river-gum leader, the figure in mono — then a hand-drawn double sum rule and the honest total. The whole ledger is built in JS (SVG DOM, no libraries): geometry lives in attributes, animation runs through a single rAF timeline writing style.opacity and attribute positions — never CSS-animating a property an element also sets as a presentation attribute (LEARNINGS W16/W17). Leaders are clipped between the measured end of each label and the measured left edge of each figure (getComputedTextLength), drawn with butt caps so zero length shows nothing (W15).

The first write is paced slow (930ms stagger) so the 7-second thumbnail catches the ledger about two-thirds written — inked through celebrant, the add-ons still arriving, sum rule undrawn — then it completes and holds. Every subsequent chip/toggle rebuild redraws snappy (~0.7s, 32ms stagger) behind a firstDraw flag (W21), and window.__funeral exposes the state with a settled flag so QA gates on state, never seconds. Reduced motion renders the ledger complete immediately. A visually-hidden list mirrors every line for screen readers, and a noscript block carries the rest arrangement in plain text.

Honesty mechanics: for direct cremation, livestream and flowers disable with their reasons printed on-card (“there’s no service to stream…”) while viewing stays live — a control either changes the price honestly or visibly explains why it can’t (W18). For graveside burial the ledger prints a line with no number: cemetery fees, set by the Metropolitan Cemeteries Board, passed through at cost — the at-cost line is the honesty signature, and inventing a figure there would be the exact dishonesty the page argues against. The chosen arrangement pre-fills the enquiry form’s notes field (W12), backing off the moment the visitor types their own note.

Second-read details: the ledger’s stamp reads “prepared live at [the visitor’s actual clock time] — before anyone asked” (true, since it is), and faint paperbark layers peel down the paper’s left margin.

The pricing model, measured

The model’s shape: the package defines the line list (not a multiplier) — direct cremation carries transfer, coffin, crematorium fee and certificates; chapel farewell adds the chapel hour and celebrant; graveside swaps the crematorium fee for graveside coordination and the celebrant, and appends the at-cost cemetery line. All-in anchors, no after-hours loading — flatness by the hour is a deliberate, stated pricing statement (“the 3am price is the 3pm price”), not an omission. Every displayed figure below was verified against an independently reimplemented oracle in the QA harness — all six spec examples measured exact, zero corrections.

The cemetery line deliberately has no number anywhere on the page — MCB fees vary by cemetery and by lawn/monumental/wall section, so the honest render is the at-cost declaration plus the offer to show the current schedule.

Conversion decisions

• Call is the primary CTA everywhere — this trade converts by phone at 2am. The header, hero, ledger panel, sticky mobile bar and footer all carry the 24-hour line, with “a person answers” doing the trust work a “24/7!” badge can’t.
• The ledger request is the second path — for the many visitors comparing under pressure who aren’t ready to speak. The signature pre-fills the form, so the enquiry arrives warm.
• No date field on the form — grief doesn’t book ahead. Name, phone, a relationship select whose third option is “just comparing, honestly” (lowering the threshold to enquire), suburb for the transfer, and an optional notes field.
• Confirmation copy stays in the demo’s lexical contract — “Thank you — received … would call you back within the hour, any hour” — with the demonstration stated plainly, no faked network round-trip.
• Above the fold at 375px: name, value proposition, the call CTA and the trust line — the ledger panel follows one swipe below, and shares the 1200×750 thumbnail fold on desktop.

Local SEO we’d implement for the real business

This demo page emits only WebPage schema naming it a demonstration — fictional structured data in a real index is dishonest markup. For a real funeral home we’d ship the precise schema.org subtype with real NAP, hours and review feed:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FuneralHome",
  "name": "Paperbark Funerals",
  "telephone": "+61-8-9000-0281",
  "url": "https://paperbarkfunerals.com.au",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Cannington",
    "addressRegion": "WA",
    "postalCode": "6107",
    "addressCountry": "AU"
  },
  "openingHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday","Sunday"],
    "opens": "00:00", "closes": "23:59"
  },
  "areaServed": "Perth metropolitan area",
  "priceRange": "$2,800–$6,500",
  "aggregateRating": {
    "@type": "AggregateRating", "ratingValue": "4.9", "reviewCount": "180"
  },
  "review": {
    "@type": "Review",
    "reviewRating": { "@type": "Rating", "ratingValue": "5" },
    "author": { "@type": "Person", "name": "A real family, with consent" },
    "reviewBody": "The ledger came by email an hour after the first call…"
  }
}
</script> // would-ship only — never emitted on this demonstration

What would change for the real client

• Arrangement records in a funeral-management CRM (FuneralTech / Osiris-style), with the ledger generated from the live price file and emailed from the first-call workflow.
• BDM (Births, Deaths and Marriages) registration workflows and Metropolitan Cemeteries Board booking.
• Pre-paid fund administration against the registered fund, with the fund’s name disclosed on-page.
• Florist and celebrant coordination calendars; Xero for the itemised invoicing the ledger promises.
• A quiet review flow — funeral homes ask gently, weeks later, never at the wake.
• Their photography of the arrangement room — this build proves the design carries without it.

Iteration log