Multi-device
content strategy
Meta's wearables portfolio was expanding. Each product had its own content patterns, its own terminology, its own way of referring to devices. As users started owning multiple devices, the experience was going to fracture. I built the strategy to prevent that — before it was on anyone's roadmap.
Not on anyone's roadmap.
But on mine.
Meta's wearables portfolio was expanding: smart glasses, a wrist wearable, and a shared companion app that needed to support both. Each product had its own design team, its own content patterns, and its own way of referring to devices, features, and settings. As users started owning multiple devices, the content experience was going to fracture.
There was no multi-device content strategy. Nobody had written one. It wasn't on anyone's roadmap. I had no dedicated PM support, no engineering resources, and no explicit mandate. I had to prove the value while building the thing.
Build alignment
before the crisis.
I proactively identified the problem and started building alignment before it became a crisis. I facilitated cross-team communication between smart glasses content designers, wrist wearable content designers, engineering, and localization to establish shared standards.
I created a unified strategy for how we refer to devices across the ecosystem — when to use the generic name, the branded name, or a custom/personalized name. I mapped where these references appeared (out-of-box experience, pairing, settings, notifications) and documented the rules for each context.
I worked with localization managers to identify where inconsistencies were already causing problems and built guidance to prevent future drift. I also introduced dynamic copy logic for personalized device names and mapped edge cases across out-of-box experience, pairing, and settings for i18n, privacy, and delight.
Two surface types.
One coherent system.
The core of the strategy was a two-surface model: global surfaces (screens shared across device types) and device-specific surfaces (screens created for a single device). The distinction determined when to use dynamic strings, when to use device-specific language, and when to use a generic fallback.
The overarching standard: always use device-specific language whenever possible. Because the phone is technically also a "device," vague references create confusion — especially in constellation and bundled device scenarios where multiple devices are discussed in the same step.
- Use dynamic strings to specify device type
- Use "device/s" when device isn't yet known
- Use "glasses," "watch," or "band" as device types
- Don't use brand name unless differentiating models
SKU-forward naming.
Consistent across five devices.
As the device portfolio expanded to include Ray-Ban, Oakley, and wrist form factors, naming in device cards became a source of inconsistency. I led the cross-functional alignment on SKU-forward naming — a system where the product SKU name leads (e.g., Wayfarers XXXX, HSTN XXXX) rather than the brand name, with a 18-character maximum to prevent truncation across key surfaces.
The 18-character limit wasn't arbitrary. It was the maximum that avoided truncation across device cards, settings headers, toasts, and push notifications simultaneously. Some surfaces could handle more, but pushing the limit would reduce clarity or break layouts elsewhere.
| Device | Format | Logo |
|---|---|---|
| Ray-Ban glasses | Wayfarers XXXX | Meta | Ray-Ban |
| Oakley glasses | HSTN XXXX | Oakley | Meta |
| Display glasses | Display XXXX | Meta only |
| Wrist band | Band XXXX | Meta only |
| Watch | Meta Watch | Meta only |
Dynamic strings.
A localization problem.
The elegant solution was dynamic strings — a single string template that could swap in the right device name at runtime. The less elegant reality: it didn't work. Not yet.
The variables would cause translation issues. Plural and singular forms, gendered language, and articles preceding device types translate differently across locales. A string like "Unable to find your {glasses|watch|band}" would require a split for grammatical accuracy in French, Spanish, and dozens of other languages. The API couldn't support it.
So we built a localizability check: 25 sample strings with variance in parameters, sent to every supported locale for feedback. The goal was to understand which version was most scalable and uncover any other flags before we committed to an engineering approach.
Impossible de trouver [votre] montre.
A name that's yours.
Not a serial code.
The SKU-forward naming system solved the default state — how devices appear before a user has done anything. But it didn't solve the harder problem: users who own multiple devices of the same style can't tell them apart. "Wayfarer 0011" and "Wayfarer 002F" are technically distinct. They're not humanly distinct.
The solution was personalized auto-naming: users would be able to assign a custom name (up to 18 characters) to each device during out-of-box experience and choose your own adventure onboarding. The custom name would then replace the default name across every surface where the device is referenced — action banners, home cards, notifications, settings cards, and within the Bluetooth OS settings. Future goal: the custom name persists in the companion app even after unpairing or logging out.
One distinction mattered enough to write down explicitly: the custom name and the device category are not interchangeable. "Ashlee's Wayfarers" is a custom name. "Glasses" is a device category. They serve different purposes in the content system — and conflating them would break the localization logic we'd already established for device-type references.
The first multi-device
content strategy in the org.
Covering generic, branded, and custom naming conventions — with rules for every surface where device references appear: out-of-box experience, pairing, settings, notifications.
Logic for personalized device names using profile or account names — so the experience adapts to the user's context without requiring manual content updates.
Alignment documentation to ensure consistency across markets — preventing the same concept from being translated differently depending on which product it appeared in.
"This lays a proper foundation for building robust, scalable experiences. Doing this properly today reduces efforts down the road — one reason being less engineering tech debt."
— Nishil Shah, EngineerReduced tech debt.
Improved dogfooding.
The strategy was adopted across the wearables org and aligned with product marketing standards. It resolved existing content bugs in the companion app that were confusing dogfooders. The naming conventions improved onboarding efficiency and set a precedent for system-wide consistency.
Engineering acknowledged the long-term value directly — calling it a "proper foundation for building robust, scalable experiences" that reduces engineering tech debt down the road. The strategy was piloted in Wearables with a planned Meta-wide rollout.
"Despite not being a part of the H2 roadmap, Ashlee recognized the importance and prioritized efforts to develop guidance on multi-device content support. Her contributions enabled us to resolve the 'glasses' content bugs to improve the dogfooding experience. Longer term, this lays a proper foundation for building robust, scalable experiences. Doing this properly today reduces efforts down the road — one reason being less engineering tech debt."
— Nishil Shah, Engineer