01 Featured Wrist wearable · Staff · Governance · 0-to-1

Content design lead on an
unreleased wrist wearable

Meta's first wrist wearable had dozens of engineers, multiple PMs, and a full design team. It had one content designer. I built the systems that made that sustainable — and shipped with zero content blockers at code freeze.

150+
Artifacts delivered
~99
Eng-reviewed copy changes
0
Content blockers at code freeze
73→82%
Task success rate
1,665+
Standards hub views, month 1
34
Office hours sessions, H1

One content designer.
An entire product.

When I joined the wrist wearable team as the sole content designer, the product was already in motion. There were 10+ product managers, a full design team, engineering squads across multiple surfaces, and a launch timeline with real stakes. There was no content playbook. No terminology standard. No process for how content decisions got made, reviewed, or communicated.

The role wasn't just "write the UI copy." It was: figure out what content infrastructure this product needs to ship well, build it, and do it fast enough to actually matter.

I was promoted to Staff mid-cycle during this work, after earning a "Significantly Above Expectations" rating — the only person on my team to receive that rating in that cycle.

The challenge
How do you make one content designer's work scale across a product with the complexity of a full operating system — and ship without a single content blocker?

"Your documentation serves as a gold standard for cross-functional partners, effectively reducing churn and empowering Product Design and Engineering to move faster."

— Najwa Smith, Manager, H2 2025

The infrastructure model

I approached the role as a systems problem, not a writing problem. The question wasn't "what copy does this screen need?" — it was "what systems does this team need to make good content decisions at scale, with or without me in the room?"

01
Terminology governance from scratch
Three separate terminology systems existed across hardware, health, and UX teams — each with different rules, different owners, and no cross-reference. I converged them into a single governance model: 90+ terms, FDA-aligned health language, localization-ready definitions, and a decision tree for edge cases. Engineers could resolve terminology questions without filing a ticket.
02
Standards hub: 1,665+ views in month one
I built a content standards hub that became the canonical reference for the product team — covering voice and tone, UI copy item formatting, error states, settings patterns, and accessibility requirements. It wasn't a document dump. It was designed to be navigable, searchable, and actionable. Cross-functional partners cited it in reviews. PMs linked to it in specs. It traveled without me.
03
44 settings UI copy items standardized
Settings are one of the highest-trust surfaces on a device. I audited every settings UI copy item across the product, identified inconsistencies in labeling, hierarchy, and tone, and standardized 44 UI copy with documented rationale. The taxonomy became the model for future settings work across the org.
04
Office hours: 34 sessions, 18 cross-functional partners
I ran structured office hours throughout H1 — not as a drop-in help desk, but as a scalable way to build content literacy across the org. Engineers learned to write first drafts. PMs learned to spot content issues before they became blockers. The OH digests became reference documents in their own right.
05
Wallet naming: Legal, Trademark, Product Marketing, international markets
The product needed a name for its payment feature that cleared Legal, didn't conflict with existing Trademark registrations, worked in international markets, and landed clearly with users. I led the naming process across all four stakeholder groups, built the decision framework, and secured exec approval — on a timeline that didn't slip the product.

150+ deliverables across the product

The 150+ deliverables weren't just UI copy. They were the full content infrastructure of a product — from first-run experience to error states, from health data displays to payment flows.

out-of-box experience First-run experience — device setup, pairing, permissions, health onboarding Multi-PM surface
Health Health data displays, alerts, and FDA-aligned terminology Regulatory review
Payments Wallet feature — naming, flows, error states, confirmation patterns Legal + Trademark
Settings 44 standardized settings UI copy with taxonomy documentation Cross-product model
Notifications System notifications, alerts, and wrist-optimized microcopy ~99 copy changes
Standards Content standards hub, terminology governance, error framework, accessibility specs 1,665+ views, month 1

Task success: 73% → 82%

Content decisions weren't made on instinct — they were validated. I partnered with UX research to run usability studies on key flows, using task success rates as the primary metric for content effectiveness.

The 73% → 82% improvement in task success rates across tested flows wasn't a coincidence. It was the result of iterating on copy based on where users got stuck, not where we assumed they would.

I also used the research findings to build the case for content changes that required cross-functional alignment — translating user behavior data into the language of product risk.

73%
Task success, baseline
82%
Task success, post-iteration
3→1
Terminology systems converged
44
Settings UI copy standardized

The structural challenges

Being the sole content designer on a product this complex isn't just a workload problem — it's a structural one. Every content decision was also a cross-functional negotiation. Every UI copy item had a PM who owned it, an engineer who implemented it, a Legal partner who reviewed it, and a localization team who had to translate it.

The absence of a playbook was the hardest part. There was no prior art for how content should work on a wrist wearable at Meta. I was writing the rules while also executing against them — which meant every governance decision I made had to be defensible, documented, and durable enough to survive my absence.

I also had to manage the political complexity of a product with 10+ PMs, each with their own surface priorities and launch pressures. Getting alignment on a single terminology decision sometimes meant three rounds of stakeholder review. I built the process to make that sustainable.

"Ashlee is the sole content designer on a product that has the complexity of an entire operating system. She has built the systems, the standards, and the relationships that make that sustainable."

— Peer review, H1 2025

Zero content blockers at code freeze

Code freeze is the moment in hardware development when the software is locked for manufacturing. Any unresolved content issues at that point become a product risk. We hit code freeze with zero content blockers — every UI copy item reviewed, every terminology decision documented, every edge case resolved.

That outcome wasn't luck. It was the result of building the infrastructure early enough that the team could operate it without me needing to be in every room. The standards hub, the terminology governance, the office hours — all of it was designed to make "zero blockers" the default, not the exception.

What this proved
"One content designer can own a product this complex — if they build the systems that make their judgment scalable. The use isn't in the hours. It's in the infrastructure."
0
Content blockers at code freeze
150+
Artifacts delivered
Staff
Promoted mid-cycle, SAE rating
18
Cross-functional OH partners

The game plan

When I stepped into the Content Design Single-Threaded Leader role for the wrist wearable, I wrote a game plan that documented every active workstream, every risk, and every gap — not as a status update, but as a strategic operating document. This is a condensed version of that plan.

Weekly updates as a leadership practice

One of the structural challenges of being the sole content designer on a product this complex is that your work is invisible by default. Engineers don't see the terminology decisions. PMs don't see the standards work. Leadership doesn't see the cross-functional alignment happening in the background.

I solved this with a weekly update post — a digest I published every week to the product team on Workplace. Not a status report. A communication artifact: synthesizing what happened, what was decided, what was coming, and what the risks were. Eleven consecutive weeks. Every week, on time.

This is what Staff-level communication looks like in practice.

Weekly update post header image for July 28 — branded hero image with post title
July 28, 2025 Mood: "Malibu" — Miley Cyrus (the song)
  • Completed listening tour across 7 cross-functional partners — engineering, product, Product Marketing, UX research, and design leads
  • Identified key risks: no shared terminology system, no content owner for cross-device UX, OOBE scope still undefined
  • Launched weekly update cadence to surface progress and decisions asynchronously
7 partners interviewed 3 structural risks identified Week 1 of 11
Weekly update post header image for August 18 — branded hero image with post title
August 18, 2025 Mood: "Go Your Own Way" — Fleetwood Mac
  • Got a device — first time experiencing the product as a user
  • Collaborated with eng and PM leads on short-term permissions strategy; drafted recommendations post
  • Drafted error message standards: tone, structure, categories, and do’s/don’ts based on prior audit
  • Completed listening tour — confirmed coverage across PM, PD, PMM, and UXR leads
Wallet content pass wrapped Error standards drafted Week 4 of 11
Weekly update post header image for September 29 — branded hero image with post title
September 29, 2025 Mood: "Under Pressure" — Queen & David Bowie
  • Shared the official product name with CDs — a milestone that had been months in the making
  • Delivered a voice & tone presentation at the Wearables OOBE sprint
  • Escalated permissions gaps with PM and PD leads to drive teams to address them before content lock
  • Wrapped content standards for components; building the reusable permissions/consents template
  • Working on codename replacement framework — when to use “device,” “watch,” default name, or product name
2 weeks to content lock Components standards wrapped Week 11 of 11
Weekly update post header image for October 21 — branded hero image with post title
October 21, 2025 Mood: "Under Pressure" — Queen & David Bowie
  • PDs heads down on demo flows; demo reviews in progress up the leadership chain
  • Posted date/time/timestamp standard to the wrist wearable designers group to align all instances before cut
  • Tracking terminology flags: product name attribution in flows, voice notes (not voice memos), widgets vs. live activities, TTS strings referencing wrong device type
  • Content decisions log now includes every decision made — what, why, and supporting context. If you're asking “What did Ashlee do?” — the answer's probably there.
  • Began audit of ~1,800 string instances to identify device-type updates needed post-cut
7 days to branch cut ~1,800 strings audited 0 content blockers

These are internal Workplace posts, shared weekly with the wrist wearable product team. Internal product names have been removed. 11 consecutive posts, July–October 2025.

Term briefs: governing the vocabulary of a new product

When a product doesn't have shared language, every team invents their own. I wrote term briefs for the most contested and consequential terms on the wrist wearable — documenting the recommended term, the reasoning, the context, and the rules for use. These aren't style guide entries. They're governance decisions with rationale.

Term brief · Internal term

Activity panel

Ashlee Phillips  ·  Oct 15, 2025
Collaborators: Laura Osfield, Caroline Sukovich
Recommendation
Adopt "activity panel" as the internal term for the swipe-up surface that houses both widgets and live activities. Keep internal-only — use descriptive language externally ("Swipe up to view your widgets"). Define in the UI terminology doc as an internal-only term.
On the watch, users access four main system surfaces: swipe down (notification center), swipe up (activity panel), corner button (control center), side button (app launcher). The activity panel dynamically changes based on context — showing live activity session controls when active, pinned widgets when not.
"Activity" can misleadingly sound fitness-specific. "Panel" is a structural term, not a user-facing one. The name breaks the "center" pattern established by other system surfaces. Despite these drawbacks, activity panel best reflects internal architecture and aligns with panel widgets.
Term brief · Internal term

Live activity indicator

Ashlee Phillips  ·  Oct 15, 2025
Collaborators: Laura Osfield, Caroline Sukovich
Recommendation
Adopt "live activity indicator" as the internal term for the small visual element (icon, dot, or pulse) showing an ongoing live session. Keep internal-only — use descriptive language externally ("Music is playing," "Workout in progress"). Add to terminology and accessibility labeling docs.
Appears when a live activity (music, call, workout, timer, Live AI) is active. Can appear in the status bar, watch face, or activity panel. Tapping the indicator may open the corresponding live activity view.
Documentation and UI copy sometimes called this the "status indicator," causing confusion with other exclusive states (airplane mode, do not disturb). Distinguishing "live activity indicator" ensures clarity for content, engineering, and accessibility labeling — and provides a scalable naming convention for other device types.
Term brief · Internal term

Panel widget

Ashlee Phillips  ·  Oct 15, 2025
Collaborators: Caroline Sukovich, Joshua Fruhlinger, PMM, Product Design
Recommendation
Continue using "panel widget" internally to differentiate from face widget (which lives on the watch face). Avoid surfacing "panel widget" in user-facing copy — refer to all widgets generically as "widgets." Add to Acrolinx after confirming final term alignment on "panel" vs. "center."
Widgets exist in two main spaces: face widgets (fixed on the watch face, configurable) and panel widgets (live in the activity panel, configurable and rearrangeable, contextually dynamic). Without a scoped definition, it's unclear which surfaces support pinning or dynamic behavior.
"Panel widget" keeps the taxonomy parallel to "face widget." The name works regardless of whether the surrounding space is eventually renamed. Provides designers and engineering clear logic for when widget persistence applies.

"Ashlee's work has stepped up both the quality and coverage of our Design System. I really admire her ability to identify areas of opportunity and develop frameworks around them: that's the systematic thinking that's gonna make our system one of the strongest in the entire company."

Scott Gary, Product Design Lead, AI Wearables