RequiemOS User Research
Updated 2026-07-20

User Personae

Seven archetypes representing the people who will use RequiemOS daily. Understanding them is essential to building a product that serves the entire funeral home team — from tech-hesitant owners to digital-native directors.

Who uses RequiemOS?

These aren't fictional characters — they're composites drawn from real discovery sessions with funeral home operators. Each persona represents a distinct pattern of tech comfort, workflow needs, and change-management requirements.

Margaret Patterson
Owner / General Manager
Age 58 28 years in funeral service
Tech: 4/10 — Low
Background

Built/inherited a 2-3 location funeral home. Thinks about succession planning but hesitant about handing over to her tech-native daughter.

Current Tech Stack
  • QuickBooks Desktop (not Online)
  • Excel for task tracking
  • Paper calendar on office wall
  • Leather journal for "important stuff"
Top Pain Points
  • Staff coordination nightmare
  • Financial blindness
  • Regulatory anxiety
  • Succession risk
What Makes Her Say YES
  • Proof from a peer
  • Clear ROI
  • One flat price
  • In-person training
David Chen
Senior Funeral Director
Age 52 22 years in funeral service
Tech: 3/10 — Low
Background

Licensed funeral director. Client-facing. Works primarily days. Has been doing things the same way for 20 years. Deeply suspicious of software.

Current Tech Stack
  • 3-page paper intake form (handwritten)
  • Whiteboard for daily tasks
  • Phone calls and text messages for coordination
  • His memory for family promises
Top Pain Points
  • Information loss on shift change
  • Family disputes what was agreed
  • Cremation authorization delays
  • Mental load (40 cases in his head)
What Makes Him Say YES
  • Mobile app (not web browser)
  • Simplicity (<5 clicks to log a conversation)
  • Offline capability
  • Peer respect from another senior FD
Jessica Rodriguez
Administrative Staff / Case Coordinator
Age 31 4 years in funeral service
Tech: 7/10 — High
Background

Second career. Previously in office administration. Tech-native. She SET UP Google Drive and Slack because funeral home has no IT.

Current Tech Stack
  • Word templates for invoices
  • Excel for payment tracking
  • Google Drive (she set this up)
  • Slack (installed unofficially)
Top Pain Points
  • Data re-entry hell
  • No centralized information
  • 30 minutes per invoice
  • Blamed for errors she wasn't in the loop on
What Makes Her Say YES
  • Auto-generated invoices
  • Integration with Gmail/Slack
  • Real-time collaboration
  • She'll self-onboard via YouTube tutorials
Robert "Rob" Sullivan
Prep Staff / Embalmer
Age 44 16 years as licensed embalmer
Tech: 1/10 — Very Low
Background

Learned through 3-year apprenticeship. Works 3pm-11pm shifts. Doesn't have regular computer access. Has a flip phone.

Current Tech Stack
  • Paper task list on clipboard
  • Handwritten notes on prep request
  • Whiteboard status updates
  • Phone calls for questions
Top Pain Points
  • Unclear task priority
  • Communication gaps
  • Redo work (family changed their mind)
  • Feels disrespected, last to know things
What Makes Him Say YES
  • Paper-first hybrid (printed task list)
  • SMS notifications
  • Simple language, no jargon
  • Acknowledgment of his value
Sophie Dupont
Young Funeral Director
Age 28 3 years as funeral director
Tech: 8/10 — Very High
Background

Chose funeral service for meaningful work. Interested in modernizing grief experience. Considering leaving for larger, more tech-forward chains.

Current Tech Stack
  • Gmail (personal/work mixed)
  • Notion (personal, wishes work used it)
  • Instagram/TikTok
  • Slack (installed with Jessica)
Top Pain Points
  • Frustrated with legacy processes
  • Families text her personally
  • Ideas rejected by older leadership
  • Retention risk (might leave)
What Makes Her Say YES
  • Cloud-native, mobile-first
  • Modern UX (looks like 2025)
  • Roadmap transparency
  • User community with other young FDs
Nadia Kowalski
Scheduler / Dispatch Coordinator
Age 36 8 years at the funeral home
Tech: 6/10 — Medium-High
Background

Dedicated dispatch/capacity function. Owns weekly scheduling for services, prep, attendants, vehicles across every location. Single point of failure. Not client-facing.

Current Tech Stack
  • Two large Excel workbooks (90 tabs of archive)
  • Wall-mounted monitor for visibility
  • Outlook for [AN READY] bundles
  • Microsoft Teams for urgent follow-ups
Top Pain Points
  • Everything is manual re-entry
  • Capacity invisible until it's a crisis
  • Attendant availability lives in her head
  • She is a single point of failure
What Makes Her Say YES
  • Dispatch board showing capacity at a glance
  • One source of truth (stops parallel boards)
  • Attendant availability as first-class concept
  • She can still print for attendants
Gordon MacLeod
Service Attendant
Age 68 5 years in attendant pool
Tech: 1/10 — Very Low
Background

Retired middle-school principal. Recruited through Knights of Columbus. Works part-time — a few funerals a week. Doesn't need the income; enjoys the structure and community.

Current Tech Stack
  • Shared phone (SRS scan app can't be on personal phone)
  • Personal iPhone (calls, texts, banking)
  • Email checked once a day at home
  • Paper copy of weekly schedule on wall
Top Pain Points
  • Finds out about assignments late
  • Directions and logistics are word-of-mouth
  • Shared-phone friction (login painful)
  • Can't easily flag scheduling conflicts
What Makes Him Say YES
  • Printed day-sheet the evening before
  • SMS reminders (not app)
  • Scan interface without login step
  • No personal-device requirement

What each persona needs

One size does NOT fit all. Here's what RequiemOS must deliver to serve the entire team successfully.

For Margaret (Owner)

  • Executive dashboard with high-level metrics
  • Large text (accessibility)
  • Printable reports (she wants paper)
  • ROI metrics visible on first page

For David (Senior FD)

  • Mobile app is primary interface
  • Offline capability (no WiFi in prep room)
  • 2-click lookup for family preferences
  • Silent sync (no "connecting..." messages)

For Jessica (Admin)

  • Email integration (Gmail)
  • 1-click invoice generation from case data
  • Search/filter (she loves finding things quickly)
  • Automation options (template emails, auto-calculations)

For Rob (Prep Staff)

  • Print-friendly task lists (generated daily)
  • Large fonts, high contrast
  • SMS notification option (not app push)
  • Simple, plain-English language (no jargon)

For Sophie (Young FD)

  • Mobile-first design
  • Clean, modern UX (doesn't feel outdated)
  • Roadmap visibility
  • User community (connect with peers)

For Nadia (Scheduler)

  • Schedule-grid dispatch board (confirmed/pending/conflict states)
  • Capacity indicators per resource class
  • Backward-from-service scheduling
  • One-click printable daily schedule

For Gordon (Attendant)

  • Printed day-sheet the night before (primary deliverable)
  • SMS reminders (not app)
  • Scan interface without login on shared device
  • No personal-device requirement
The Bottom Line

If you optimize for Margaret, you lose Sophie.

If you design for Sophie, Margaret feels overwhelmed.

If you ignore Rob's need for paper, he resists adoption.

If Nadia's dispatch board doesn't reduce her clicks, she reverts to Excel — and nobody else can operate the scheduling surface.

If Gordon has to install anything on his personal phone, or log in on a shared device, chain-of-custody scan integrity fails at the field-attendant boundary.

Your MVP must have persona-specific paths — different entry points, different primary interfaces. This is how funeral homes actually adopt software. And the paths must compose — small operators layer multiple personae onto the same person, and the UI cannot insist otherwise.

The funeral industry has 72% of workers over age 40 AND a growing influx of tech-native directors. You MUST serve both, or adoption stalls.

Change Management Reality

Not everyone adopts at the same pace. Here's the realistic timeline for each archetype.

Fast Adopters (Week 1-2)

Sophie: Wants modern tools, frustrated with paper

Jessica: Tech-native, sees efficiency immediately

Nadia: If the dispatch view is right, she is the earliest and most vocal advocate; if it isn't, she reverts to Excel and doesn't come back

Moderate Adopters (Week 3-4)

Margaret: Sees business ROI, trusts peer advice

David: Influenced by peer success, sees family benefit

Slow Adopters (Week 5+)

Rob: Needs paper alternative, supervisor support, respect

Gordon: Needs paper day-sheet, SMS, no personal-device requirement, and a chain-of-custody scan model that survives shared devices

Multi-Hat Operators

The seven personae above reflect a multi-role operator at Kearney's scale — a two-to-six-location cluster with enough headcount for role specialisation. Not every RequiemOS customer will look like this.

At the smallest end, a single-location independent funeral home may have one to three staff carrying most of the personae above simultaneously. A director there is often David + Sophie + Jessica + partly Nadia at the same time — they meet families, they schedule the attendants, they invoice, they order caskets, they update the calendar.

This is not a new persona — it is a role-flexibility axis the UI must accommodate. Specifically:

  • • Role assignment cannot be a hard invariant. A single user account may need to hold the FD role, the scheduler role, and the case-coordinator role simultaneously without the UI insisting they are three different people.
  • • Persona-specific views must not be persona-exclusive views. A director at a small operator needs Sophie's mobile case-detail view, Nadia's dispatch board, and Jessica's invoice generation on the same device without switching accounts.
  • • The "primary interface" concept is aspirational at scale. At a small operator, the primary interface is the one they happen to be looking at right now.

This shape argues for a role-based permission model layered over a shared UI, rather than persona-specific applications. The persona set above defines the design targets; the multi-hat operator defines the composition rules.