Framing the problem, together
One concept, one risky placeholder word
Content design was in from the concept stage — shaping the idea with product management and engineering, not receiving a finished spec. The goal we set together: let someone in OneDrive choose a person to inherit their files and photos if they died or lost access to their account.
The logic worked. The wording didn’t. The team’s working shorthand for that person was “beneficiary” — a legal, estate-planning word that most people don’t use and that quietly signals death and paperwork at the exact moment a product should feel reassuring. Content design flagged it early as the first thing to solve.
The shared goal Keep the flow, lose the jargon. Find language for the person, the permission, and the wait period that’s plain, humane, and consistent across every screen and email.
- “Beneficiary” reads as legal, not personal
- No reassurance up front
- Death is implied but never gently framed
- Terms drift between screens and emails
In the room: product management · engineering
Add a beneficiary
Assign a beneficiary to manage your OneDrive content if you’re unavailable. This beneficiary is required to have a Microsoft account.
When you add a beneficiary, they will receive an email to accept your request and you must securely provide them with a one-time code to access your OneDrive. You will have 72 hours to deny their access request before they gain access to your content.
The starting draft of the first screen: “beneficiary” appears five times.
Competitive research
What does everyone else call this?
Before writing a word, I looked at how the rest of the industry names the same idea — passing data on after death or inactivity. Each product makes a different trade-off between plain and precise.
What we examined
- Apple — Digital LegacyLegacy Contact plus an Access Key; access requested with a death certificate.
- Google — Inactive Account ManagerTriggered by inactivity, not death; uses plain “trusted contacts” language.
- Bitwarden — Emergency AccessTrusted emergency contacts request access after a wait period.
In the room: design · branding (brand voice)
A first glossary
The research produced a small, shared vocabulary to design against:
- Digital legacy
- The digital assets you leave behind when you’re gone.
- Legacy contact
- The person who gets the content when you’re gone.
- Access request
- How people get access to another’s digital legacy.
Apple’s “Legacy Contact” and an “Access Key” shaped early drafts — but the research flagged that Google’s plainer “trusted contacts” language tested as more approachable. That tension set up the next stage.
The working space: terminology & story flow
Working the words
This is where the craft happens — and where collaboration was tightest. Two problems ran in parallel: choosing one name for the person, and writing an explainer that could carry a hard idea gently. Branding weighed in on the term, legal on the 72-hour wait and deletion language, and engineering on the access-code mechanism. Below are the actual artifacts — pick a candidate term to see how it was weighed, then step through how the explainer copy evolved.
Choosing the word: an evaluation
Six candidates were weighed on plain-language clarity, tone around death, and the risk of being confused with account-recovery features. Select one:
Evolving the explainer
The opening paragraph was rewritten many times — including a peer rewrite from a fellow content designer — to sequence reassurance, mechanism, and the 72-hour safeguard. Step through the versions and watch the changes:
How the flow iterated
Content design worked the end-to-end flow in dated passes, reviewing each with partners — legal on the wait period and deletion, engineering on the access code, branding on naming:
- StartStarting point — new terminology on the setup page
- 5/13Invite contact & accept invitation, revised
- 5/13Get-code flow laid out
- 5/13Enter-code flow, in progress
- 5/14Respond to access request, in progress
- ShipPolish after release
The final flow, agreed by design, product & engineering
One story, two people
The flow everyone signed off on is a matrix: every scenario written from both sides — the account owner setting things up, and the trusted contact receiving and acting on the request. Design, product management, engineering, legal, and branding all reviewed it together. Pick a scenario to read the shipped copy, and toggle to compare it with the earlier “beneficiary” draft.
The agreed flow at a glance
| Scenario | Account owner | Trusted contact |
|---|---|---|
| Add a trusted contact | Sets up digital legacy and invites someone | — |
| Accept the request | Gets the access code to share | Receives the email invitation |
| Provide the access code | Shares the one-time code | Receives the code out of band |
| Respond to an access request | 72-hour window to deny | Requests access, then waits |
| Periodic reminder | Confirms the contact is current | — |
Signed off together by design, product management, engineering, legal, and branding.
What changed, and why it matters
The outcome
One plain-language term, used consistently across every screen, email, and notification.
The safeguard the user controls. Reframed from a buried condition into a clear, repeated promise: a wait period to deny access.
Personas, one consistent story. Owner and contact copy written as a matched pair, scenario by scenario.
Principles that drove the writing
Content design’s job here wasn’t decoration. Working across product, design, engineering, legal, and branding, it was choosing a word people trust and sequencing a hard idea so the product feels like care, not paperwork.