CD 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 branch cut.
One content designer.
An entire product.
When I joined the Malibu 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 strings." 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 (IC6) 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.
"Your documentation serves as a gold standard for XFN partners, effectively reducing churn and empowering PD/ENG to move faster."
— Najwa Smith, Manager, H2 2025The 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?"
150+ artifacts across the product
The 150+ artifacts weren't just strings. They were the full content infrastructure of a product — from first-run experience to error states, from health data displays to payment flows.
Task success: 73% → 82%
Content decisions weren't made on instinct — they were validated. I partnered with UXR 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.
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 string 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 2025Zero content blockers at branch cut
Branch cut 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 branch cut with zero content blockers — every string 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.