Wearables content
standards
Meta's wearables org had no single source of truth for content. Every team was making the same decisions over and over. New hires had no onboarding. Cross-functional partners were guessing. I built the infrastructure to stop that — and ran it like a product.
The same decisions,
made over and over.
Meta's wearables org was growing fast — multiple products, multiple device form factors, multiple content designers working in parallel. And every week, the same questions came up in office hours: How do we refer to Settings in product copy? What's the standard for notifications? How do we write for the display on Hypernova? Nobody had written it down. Or if they had, nobody could find it.
New hires were getting dropped into products with no onboarding onto device-specific content patterns. Cross-functional partners — product designers, engineers, PMs — were making content decisions without a content designer in the room, and without any guidance to reference. The same debates were happening on every team, independently, producing inconsistent results.
This wasn't a content quality problem. It was a content infrastructure problem. And infrastructure problems don't get solved by writing better copy. They get solved by building systems.
Not documentation.
Product infrastructure.
The first thing I did was reframe the problem. Standards work has a reputation for being a documentation exercise — a thing you do when you have spare time, that lives in a wiki nobody reads, and that gets stale within six months. That framing kills standards programs before they start.
I positioned this differently, to leadership and to the team: this was product infrastructure. The goal wasn't to document what we knew — it was to build a system that let teams move faster, make better decisions, and stop reinventing the wheel. A standard isn't a rule. It's a best practice and a starting position. It's the thing you point to when someone asks "how do we do this?" so you don't have to have the same conversation again.
I made the case to our design director, Tizzy: the standards hub would serve two goals. First, help the content design team move faster — write it down, point people to it, stop making the same decisions over and over. Second, help teams without a content designer get to clearer, tighter experiences without slowing down. That framing got buy-in. It also gave us a clear success metric: adoption, not just publication.
A contributor system.
Not a solo project.
I co-led the build with Christina Choi, with Rob Ronan as team driver. But the scope required the whole org. I ran the information architecture sprint — mapping which surfaces needed standards, who owned them, what the gaps were, and how the IA should be structured to reflect the new org chart. I created the contributor template: every standard needed a purpose, a scope, guidance with examples, and cross-links to related standards. That template became the "standard for standards."
I coordinated across two org structures — Najwa's team and Anjelica's team — to assign ownership, set deadlines, and run two rounds of review. I ran office hours before each deadline to unblock contributors. I aligned with the design systems team (Morgan, Phil) and the GenAI content team (Shiva) to reduce duplication and ensure standards were consistent across Figma components and app surfaces.
The timeline was tight: first drafts due April 11, second drafts May 2, final standards in Dim Sum by May 28, hard launch May 30. We hit it. Fourteen standards docs submitted by the first deadline. Twenty-plus contributors across the org. Phase one — app surfaces — live at launch. Device standards coordinated with the Neon Design System for phase two.
A single source of truth
for an entire product ecosystem.
The Wearables Content Design Standards hub covers every major surface in the wearables ecosystem — from UI components to device-specific patterns to AI and health content. It's organized by component, feature, and surface area, with each page following the contributor template: purpose, scope, guidance with examples, and cross-links.
What a standard
actually looks like.
The Settings language standard is one of the most-referenced pages in the hub — and one of the clearest examples of what a well-scoped standard does. Before it existed, teams were inconsistently referencing Settings sections in product copy, using possessives where they shouldn't, and pointing users to internal navigation labels that weren't actual destinations.
The standard resolved four recurring debates with clear rules: refer to top-level destinations only (not section headers), use the name users see in the product, respect the platform when referencing phone settings, and use "in" for navigating within an interface and "on" for the physical device. Forty-four strings were updated across the app and Hypernova to reflect the new standard. Within weeks of publication, a content designer wrote: "Already using Settings language standards! Yay!"
Built to run
without me.
Publishing the standards was phase one. The harder part was making them stick. I built a governance plan for the post-launch window: monthly "just added" updates to keep the hub visible, a quarterly contributor check-in to keep standards fresh, adoption tracking through Dim Sum analytics and qualitative signals (mentions in design crits, PRDs, office hours), and a "Standard of the Month" to surface high-traffic pages and give contributors visibility.
The governance model was designed to be lightweight. The goal wasn't to create a maintenance burden — it was to create enough momentum that the standards became the default reference, not an optional resource. By August 2025, Rob Ronan took point on driving standards expansion while Christina and I shifted into support roles. That transition was the proof of concept: the system was running without its original leads.
| Month | Action | Purpose |
|---|---|---|
| June | CD survey + wrap-up post with quotes | Prove value, close the loop |
| July | "Just added" update (new TL;DRs, updates) | Keep site visible, reinforce that it's living |
| August | Light contributor check-in to review owned standards | Keep governance alive without a full re-run |
| September | Standard of the Month (3x max) | Low-effort engagement, contributor visibility |
| Oct–Nov | XFN survey + impact proof for end-of-year review | Show cross-functional value, support promo materials |
The operating system
teams use without us.
The standards hub launched May 30, 2025. In month one: 1,665+ views, 18+ unique users, active engagement from product designers, PMs, and engineers. Top-hit pages — Notifications, Terminology, Settings — directly supported in-flight product work. By March 2026, the hub was logging 521 page loads in a single month, with 30+ unique users and consistent traffic across 20+ pages.
The qualitative signals were just as strong. Twenty-six cross-functional team members confirmed they'd used standards and found them helpful. Standards were being referenced in design crits, PRDs, and office hours. When a question came up in a team channel, people were linking to the hub instead of asking the same question again. The system was working.
The standards work was cited in my mid-year review as a key factor in my promotion to Staff: "Repositioned standards from community documentation to a strategic system that accelerates product design and implementation across the app." That framing — standards as product infrastructure, not documentation — was the whole point from the beginning.
Documentation as product.
Infrastructure as impact.
The governance model, contributor system, and handoff to Rob were all designed to make the standards hub self-sustaining. The goal was never to own it forever — it was to build something that runs without its original leads.
Aligned contributors across Najwa's and Anjelica's teams, coordinated with design systems and GenAI content teams, and ran two rounds of review across 20+ contributors — without a formal mandate to do any of it.
Repositioned standards from "documentation exercise" to "product infrastructure" — and got buy-in from design leadership by tying the work to concrete goals: team velocity, product quality, and cross-functional self-service.