Life Story Work Technology for Care Providers: A Practical Evaluation Checklist
A practical checklist for care providers evaluating life story technology, with person-led consent, private capture, account ownership, and safe handover.

Care providers should evaluate life story technology as a person-led storytelling aid, not as a shortcut to a clinical record or a generic engagement activity. Begin with purpose and consent, test the workflow with the person, define who owns the account and devices, keep sensitive material private, and plan continuity outside the app. StoryBank may support an individual-led project, but it is not presented as a care-record system, staff workspace, approval platform, or compliance solution.
This checklist is for care-home managers, activity leads, dementia-support teams, and independent life-story practitioners. It is operational guidance, not clinical or legal advice.
What life story work is for
The Alzheimer's Society explains that life story work involves a person with dementia making a personal record of important experiences, people, and places, with help from a family member or care professional where appropriate. The result might be a book, photo album, or digital record.
That definition keeps the person at the centre. A useful life story can help others understand identity, relationships, preferences, achievements, routines, and subjects that invite meaningful conversation. It should not reduce a person to a list of facts or be assembled about them without their participation simply because staff find it convenient.
Write a one-sentence purpose before selecting a tool. For example:
Support Margaret to record six stories about places and people she chooses, for private use with her daughter and named key workers.
That is clearer than “digitise residents' life stories,” which leaves scale, ownership, access, and consent undefined.
Use a purpose-and-risk screen
| Question | Low-risk starting point | Warning sign |
|---|---|---|
| Who leads the content? | The person chooses topics and may stop | Staff fill gaps without consultation |
| Who will use it? | Named family or carers for an agreed purpose | Undefined future audience |
| What will be recorded? | Chosen memories and supplied photos | Sensitive third-party details collected by default |
| Where will it live? | Account and backup ownership are documented | Shared passwords or an unowned communal device |
| Will anything be public? | Private pilot; separate later decision | Public sharing bundled into initial consent |
| What happens on discharge or death? | Handover and deletion paths are agreed | No one knows who controls the account |
If the warning signs cannot be resolved, pause the digital project. A paper album or conversation prompt may be more appropriate.
Consent is a continuing conversation
Consent is not a single checkbox captured at admission. The person may be comfortable recording a childhood holiday but not a marriage, bereavement, health event, or family conflict. They may agree to let a daughter read a story but not to make it public.
The Oral History Association's core principles describe an interview process based on transparency, ongoing participation, consent, and engagement. Care providers should adapt that spirit to the person's communication needs and local legal obligations.
Before each session, explain in accessible language:
- Why you are asking.
- Whether audio is being recorded or speech is being transcribed.
- What the app will do with the answer.
- Who can see the draft.
- Whether the person can change or remove it.
- That they can pause, skip a topic, or stop.
Record the decision in the organisation's appropriate system, not only inside the storytelling app. If capacity, best-interest decision-making, safeguarding, or legal authority is in question, follow the provider's policies and obtain qualified advice.
Separate the app from the care record
A story archive and a care record serve different purposes. A story might describe someone's first job, favourite beach, or family recipe. A care record documents information required to deliver and evidence care. Do not assume that storing something in one satisfies obligations for the other.
StoryBank currently provides personal accounts, stories, images, dates, tags, visibility, transcription, narration, and related memory features. It does not prove:
- Staff roles or organisation-wide account administration.
- Approval or audit workflows.
- Integration with care-planning systems.
- Clinical documentation controls.
- Enterprise retention policies.
- Organisational data-processing terms tailored to a provider.
Use StoryBank only where its actual individual account model fits. If a procurement brief requires those controls, evaluate a specialist platform.
Decide who owns the account
Avoid accounts registered to a departing employee, a shared reception email, or credentials written beside a communal tablet. Agree ownership before capture begins.
For an individual-led StoryBank project, the cleanest model is usually an account owned by the person or an appropriately authorised representative, with the person's content choices respected. The care provider can facilitate sessions without claiming ownership of the personal archive.
Document:
- Account holder and recovery email.
- Who may help operate the device.
- Which relatives may receive shared material.
- Where source photographs and recordings are backed up.
- What happens when the person leaves the service.
- Who can request correction, export, or deletion.
StoryBank's privacy policy describes account data, story content, voice processing, public sharing, retention, and user choices. The organisation must separately decide whether its proposed use is appropriate under its own responsibilities.
Start with private capture
Public sharing creates a much larger audience and may expose information about relatives, former colleagues, neighbours, or other residents. Begin every care-supported story as private unless a separate, informed decision supports publication.
Use a two-stage review:
- Content review: Is the story represented in a way the person recognises and accepts?
- Access review: Who may read or hear it, and does it identify anyone else inappropriately?
StoryBank lets users keep stories private and publish selected entries. Public stories can appear on the web and may be indexed or copied. Changing visibility later cannot retrieve screenshots or copies already made, so “we can remove it afterwards” is not a complete safeguard.
Plan sessions around the person
Short, successful sessions are usually more useful than forcing completion. Define a stop rule before starting.
Session checklist
- The person knows what the session is for.
- The device is charged, updated, and on a stable connection.
- Notifications are silenced and the setting is calm.
- The prompt and photograph have been chosen with the person.
- Recording or transcription is clearly indicated.
- The person can pause or stop without pressure.
- The draft will be reviewed later if fatigue appears.
- Private visibility is confirmed before the session ends.
- Source files and session notes have an assigned backup route.
Do not use a person's distress, confusion, or desire to please as a reason to continue. The goal is participation, not content volume.
Understand voice features before enabling them
Voice input, original recordings, generated narration, and voice cloning are different processes. In StoryBank:
- Speech can be transcribed to support story capture.
- Written stories can be played with narration.
- A user may optionally create a clone of their own voice from a consented recording.
- The app can use that voice model for own-voice story playback where enabled.
StoryBank's terms prohibit uploading another person's voice for cloning. A staff member or relative must not use a resident's old recording to create a clone on their behalf. The privacy policy also explains that the voice provider processes the sample and resulting model.
If authentic voice is part of the life story brief, make a separately consented original recording and preserve it as source material. Generated narration should be labelled as generated playback, not described as the historical recording.
Run a controlled pilot
Pilot with one willing participant, one named staff facilitator, and one family contact where appropriate. Create three stories:
- A place-based memory.
- A photograph-led memory.
- A skill, tradition, or piece of advice.
Keep all three private. Review the person's experience, staff time, image handling, account recovery, backup, and handover. Do not scale because the pages look attractive; scale only if the operational model is sustainable and respectful.
Pilot review questions
| Area | Evidence to collect |
|---|---|
| Participation | Did the person choose topics and remain comfortable? |
| Usability | What help was required at each step? |
| Accuracy | How were names, dates, and transcription errors reviewed? |
| Privacy | Could staff explain and verify the visibility state? |
| Continuity | Can the account and backups be handed to the person or family? |
| Workload | How much preparation, capture, editing, and review time was needed? |
| Value | Did the person and intended audience find the stories meaningful? |
Conclusion
Good life story technology supports the person's voice, choices, and relationships. It does not replace consent, skilled facilitation, care records, source preservation, or organisational governance.
StoryBank may be a useful home for an individual's private-by-default stories when account ownership, voice use, backups, and handover are clear. Review how StoryBank works, its privacy policy, and the life story app buyer's guide before running a small, private pilot. Do not scale until the person-led workflow—not merely the software—has been proven.
