Sue Long
Content Design Portfolio
Wrong password, try again
Content Design Portfolio
Wrong password, try again
I make complex products feel simple, at scale, for billions of people. I have 13+ years experience shaping content strategy, UX writing and scalable content systems for complex, global products.
At Meta, I've turned ambiguous, high-stakes user problems into clear experiences - and built the systems that keep them that way.
I influence product direction, lead and mentor content design teams. My work spans accessibility leadership, AI conversation design and cross-functional strategy - including using AI tooling to accelerate workflows and raise the quality of AI outputs for users.
Experience
 |
Meta
Content Design Manager
|
Sep 2025 - present |
|
Meta
Senior Content Designer → Content Design Lead
|
Oct 2021 - Sep 2025 |
 |
Transport for London
Content Designer → Content Lead
|
May 2018 - Oct 2021 |
 |
University of Essex
Web and Digital Communications
|
2008 - 2018 |
|
BSc Psychology, First-Class Honours
University of Essex
|
Specialisms
Building scalable content frameworks, design principles, and pattern libraries across complex, multi-surface products. Solving content problems once, at the system level.
Managing and mentoring content designers, raising content's strategic influence across organisations, and building the culture, frameworks, and standards that make teams work better together.
Writing clear, user-centred interface copy that helps people move through complex products with confidence. From microcopy and error states to onboarding flows, education content and longform copy.
Structuring content and navigation so users can find what they need without thinking about it - designing the underlying logic that makes complex products feel intuitive.
Designing how AI communicates at scale - from evaluation frameworks and prompt engineering, to agentic tool design and system-level content standards for LLM-generated responses.
Writing the instructions that govern how AI systems behave - system prompts, evaluation criteria, tool descriptions and agent skills that make quality consistent and scalable.
Defining what "good" looks like for AI-generated content and building the scoring criteria, judge prompts and evaluation pipelines that measure quality at scale, without human review of every output.
Designing content that scales across languages and markets - building systems that make localisation a quality lever, not an afterthought, and ensuring meaning holds across cultures.
Designing inclusive experiences from the ground up - and helping teams embed accessibility quality and compliance into their design and development process, not retrofit it at the end.
Real work. Real problems. Real impact.
Building the evaluation frameworks, judge prompts, conversation design principles and agentic tool descriptions that shape how Meta's AI Business Assistant supports millions of advertisers.
Workrooms was Meta's enterprise collaboration platform. I mapped a 4-surface ecosystem, unified content standards across 15 content designers, and rebuilt the onboarding experience.
Shifts was Meta's workforce scheduling tool used by 326 organisations globally. When it shut down, I created a 6-month content system, balancing compliance vs comprehension.
Building the CD × i18n collaboration model, terminology systems, and country-specific content strategies that scaled international product quality across Meta.
Writing content that works for everyone – including how I embedded accessibility requirements into content strategy from day one.
How I built capability, gave direction, and helped content designers grow - across multiple teams at different levels.
Writing and strategy for Meta's annual Connect event, spanning games design content and VR product experiences.
A cross-surface events product spanning multiple Meta platforms - designing consistent content for a fragmented experience.
Content strategy and UX writing for Transport for London's fares website and TfL app - making complex fare information clear for millions of users.
Meta · B2B · AI assistant for advertisers
Meta's AI Business Assistant was generating responses to advertisers across multiple products - helping users understand ad issues, answer questions, and take action. The volume was enormous. No human team could review every response individually.
To solve this, the product relied on an AI Judge: an evaluation model responsible for reviewing AI-generated responses and determining whether they met quality standards. The problem was that nobody had defined what "good" actually looked like. Responses were long, dense, difficult to scan, and often buried the answer the advertiser needed.
The judge was flagging some issues, but inconsistently - because it was working from instinct, not principles. I was brought in to fix content quality. After auditing the system, I realised the first real challenge wasn't the responses themselves. It was creating a scalable system for defining, measuring, and improving AI-generated communication.
Rather than writing a list of rules, I approached the problem through the lens of conversation design. I audited a sample of AI responses looking for patterns - not individual errors. From that audit and competitor research, I developed a set of principles the AI judge could apply consistently to any response, regardless of topic, product, or advertiser type. The principles weren't preferences. They were testable, repeatable, and transferable.
Principles alone don't create adoption. I took real responses - the actual content the team was working with - and ran them through the principles, before and after, side by side. The transformation was immediate and visible. I got buy-in across the team in that session.
To check if your catalog is connected to your website you need to view the catalog's data sources in your business settings. Whilst I can see that your campaign [campaign name] is using the [catalog name] [ID:0000], the specific website connection is managed within the Commerce Manager in the business settings.
How to check the connection
Catalog overview
[Catalog name] [ID:0000] [Product count] [Business name]
If the website in Commerce Manager is incorrect, you can update the connection there. However, keep in mind that for [specific] campaigns, the catalog and its associated tracking are often set during campaign creation.
Would you like me to help you list all your available website links so you can link the correct ID?
Further actions:
The AI assistant now calls a tool to check catalog connection status automatically, so it already knows the answer before the user has to do anything. If the catalog is connected, it says so immediately. If not, linking a pixel is a quick task - and one the assistant can actively guide the user through.
The original response buries the answer behind four manual steps. The after version front-loads the result, carries one idea per message and gets the advertiser to resolution in two actions. The suggested prompts make the next step obvious rather than leaving it open-ended.
The automation works because of the clear tool description I wrote for check_catalog_connection - giving the model the context it needs to act on the result, not just surface it.
The goal was never for me to be the quality gatekeeper. I worked with the team to embed the principles into the AI judge - so every response generated at scale would be held to the same standard, automatically. This required designing the judge prompt itself: the instruction set the evaluation model uses to assess each response.
The original prompt asks the judge to evaluate against qualities that aren't defined anywhere - "helpful", "accurate", "appropriate" are subjective. Two evaluators would reach different conclusions. At scale, that inconsistency compounds.
The after version gives the judge the same principles I defined, translated into scoreable criteria. Each one has a clear pass condition and a specific failure mode - so the judge isn't interpreting, it's applying a standard. The binary scoring (1 or 3, no middle ground) removes ambiguity: a response either meets the bar or it doesn't.
The verdict system maps directly to action. A FLAG routes to human review. A FAIL stops the response from reaching the advertiser. This means quality decisions happen automatically, at every response, without a human in the loop.
Meta's AI Business Assistant is built on a ReAct pattern - the model alternates between reasoning about what to do and calling tools to get real information. Tool descriptions are the natural-language instructions that tell the AI when to use a tool, what it returns, and how to behave with the output. I wrote these descriptions. If they're vague, the agent guesses. If they're precise, the agent acts correctly at scale.
This tool can be used to look up catalog connection information when an advertiser has questions about their catalog. It may be helpful for troubleshooting product delivery issues.
If the advertiser hasn't already checked their connection status, ask them to do the following before calling this tool: open Commerce Manager, select their catalog, go to Events, and check whether their Pixel appears under Tracking.
Once the advertiser has confirmed whether the Pixel is present or not, use their answer to decide how to respond. If they say it's connected, reassure them. If not, provide steps to fix it.
| Parameter | Type | Required |
|---|---|---|
| catalog_id | string | No |
The before version breaks four principles in the tool description alone: it makes the advertiser do the tool's job, signals the call is optional, makes it conditional on user effort, and the optional parameter lets the model skip the call entirely.
The instruction "do not ask the advertiser to check this manually" is what removes the 4-step manual flow from the original response - not the response itself, but the tool description. Content design happened at the tool layer, not the output layer - the work that had the most impact wasn't writing better responses. It was writing better instructions.
Working on Meta's AI Business Assistant clarified something important about how Content Design's role changes in AI products. When an advertiser asks "How is my campaign performing?", the answer flows through a chain - data layer > agentic context layer > evaluation layer. Content Design owns critical parts of all three.
The persona, tone, and formatting rules I define are injected into the AI's instructions at runtime. My content standards doc becomes a skill the agent reads.
I can't manually review every response. Defining what "good" means across 30+ dimensions - precisely enough for a model to score - is a content skill.
The instructions I write for each tool determine whether the AI acts or asks. One sentence in a tool description changes the conversation the advertiser has.
Cross-cutting concerns - language, tone, formatting - live at the orchestrator level. A content incident happened when a subagent launched without language rules.
Meta's AI Business Assistant launched with use significantly above target. More advertisers were getting support, task completions increased, issue resolution improved and cost per result dropped - proving that putting Meta's AI Business Assistant in front of people works.
The responses reaching advertisers became shorter, clearer, and faster to act on - not because content design reviewed them individually, but because the standard for "good" had changed at the system level. My principles became transferable: usable by any future team working on AI-generated content at Meta. What started as a content improvement initiative became a reusable quality system for both people and AI.
Teach from principles, not preferences. "This is too long" is feedback. "Conversational AI responses should front-load the answer, use one idea per message, and match the user's effort level" is a principle. Feedback fixes one thing. Principles fix everything.
The worked example is the bridge. Principles alone feel theoretical. Showing people content transformed through the principles makes them concrete and immediately actionable.
Content Design in AI isn't downstream - it's structural. The most impactful work wasn't editing responses. It was writing the judge prompt, the tool descriptions, and the principles that defined quality across the whole system.
Meta · Horizon Workrooms · Enterprise collaboration
Workrooms was Meta's enterprise collaboration platform - a virtual office spanning VR, web, desktop and mobile. It was the first work product to bridge 2D and 3D experiences: teams could meet, chat, share files, and whiteboard together in a persistent shared space. Everything lived in one team Workroom, so people didn't need to jump between Zoom, Slack and Google Drive.
The product goals were to remove friction in remote collaboration, improve human connection in hybrid work, make 2D and 3D experiences more equitable, and drive adoption of VR as a work surface. There was also a strong competitive angle - the video calling market was saturated, Zoom was focused on meetings rather than persistent collaboration, and Meta saw an opportunity to innovate with a richer, always-on workspace.
Poor onboarding
Only a small percentage of new users successfully onboarded and launched Workrooms. Users didn't understand what it was or how it would help them work. The product needed redesigning to be simpler, more engaging and value-prop led.
New mental models
2D and 3D work collaboration were new concepts with no existing mental models to borrow from. Each surface had different content constraints, interaction patterns and user needs - all had to feel like one coherent experience.
UX inconsistency
Workrooms spanned 4 surfaces with 15 content designers and no shared content standards. Every experience had its own terminology, content debt was building, and CD was operating as a service rather than a strategic function - reactive, with limited visibility into how term decisions rippled across the product.
15 CDs. 1 product. No shared language.
The product had seen little innovation until this project kicked off. I was asked by my CD Director to join the Workrooms product team alongside a group of new content designers - due to the complexity of the product, my senior level of content design expertise, and my ability to ramp up quickly on new products.
The challenge was that although everyone was contributing to the same user journey, nobody had a complete view of the ecosystem. I started by getting buy-in from teams, then audited every content touchpoint across all surfaces in one large Figma file. I documented end-to-end flows across all 4 surfaces and all content types (notifications, errors, help articles), which CD owned which experience, where users jumped between surfaces, where the same concept had different names, user needs and research feedback, which teams influenced decisions, and where content design could have the most impact.
This immediately surfaced gaps: experiences with no clear ownership, missing content, duplicated work, and terminology conflicts across surfaces. The ecosystem map became the first cross-functional single source of truth for the product - used by different teams to understand the whole, not just their piece of it.
Rather than jumping into individual screens, I zoomed out and built the infrastructure needed for 15 content designers to work and collaborate more effectively:
I drove the direction for content design, but the best decisions were built on expertise other people had. Getting the right buy-in at the right time was how content design scaled across the org. My approach: understand what each stakeholder cares about, show how content can solve a problem they have, ask explicitly for the expertise I don't have, and build something - a tracker, a process - that keeps working without me in the room.
Key touchpoints from the onboarding journey - each showing the original content, what was wrong with it, and how I improved it.
workplace
workplace
Your team just got a new meeting room
[ORGANISATION] has given you access to Workrooms – a space where remote meetings actually feel like you're in the same room.
What makes Workrooms different:
[NUMBER] of your teammates are already using Workrooms (it takes 2 minutes to join).
"It's the closest thing to being together in the office. Our standups went from 'cameras off' to fun."
Get started with
Workrooms
Connect, collaborate and meet with coworkers.
What do Meta accounts mean for Workrooms, your data and social accounts? See our FAQ
You're in. Let's get
you set up
Join [ORGANISATION]'s Workrooms. Then you can start your first meeting.
Your Workrooms data is separate to personal Meta accounts. About Workrooms data
Design owned by the authentication team, so changes were constrained - but even small fixes made a meaningful difference to clarity and accessibility.
Enter email address
Forgot password?
Enter your work email address and password
Forgot password?
Read this important information
Before you continue, here's some important information you must read:
Workrooms is a different product to Workplace. Information in the mobile app store, at workplace.com, or other publicly available information related to Workplace (e.g. blogs) does not apply to Workrooms.
By continuing, you acknowledge that you have read the Supplemental Privacy Policy, and you agree that your use of Workrooms is governed by the Supplemental Terms of Service.
Read Workrooms terms
Take a moment to read this important information about Workrooms.
Workrooms is separate from Workplace. These terms apply specifically to Workrooms.
By continuing, you agree to the Terms of Service and Privacy Policy.
Users are now in the Workrooms product and see a new user experience with a lightweight walkthrough of all the key features, for the first time.
Map before you write. The ecosystem map wasn't a deliverable - it was the foundation for every content decision that followed. Without it, 15 CDs would have shipped the org chart.
Content risk is product risk. Reframing poor onboarding as a metric problem - not a content problem - was the move that got PM investment. The language changed; the outcome didn't.
Standards outlast individuals. The most durable work I did wasn't any single screen. It was building the systems that meant every CD, on every surface, could make consistent decisions without me in the room.
Meta · Workplace · Enterprise product deprecation
Shifts was Meta's frontline workforce scheduling tool in Workplace - the digital equivalent of a shift schedule pinned to a staffroom wall. It was used by 326 organisations globally, including large enterprises like McDonald's.
The audience was unlike any typical Meta product user. These were frontline workers - not knowledge workers or consumers. They checked their shifts in the few seconds they had spare between tasks, phone in hand, in a high-stress environment. They had lower digital literacy, were multilingual, mobile-only, and often in roles with almost no time to read anything carefully. That completely changed how I wrote content for them.
A strategic decision was made to deprecate the product due to product-market fit at scale, alongside increasing competition from specialist scheduling tools. My job was to communicate the shutdown of an entire product - which is a trust event as much as a product event - and build the content infrastructure to manage that at scale, across six months.
The goals: zero major escalations from any of the 326 organisations, legal sign-off for all comms, a high percentage of Shifts data downloads, and complete clarity on the deprecation schedule - from first announcement through to data download, read-only period, and full product removal.
What's happening and when?
Shifts had a 6-month wind-down with multiple key dates and actions for users who had very little time. Content had to sequence the timeline clearly, reduce panic, and work at a glance - with minimal information so it didn't cause confusion.
What happens to my data?
The highest-anxiety question for people accountable for scheduling records. Content had to answer what data exists, what happens if you do nothing, and how to download - all in a constrained format.
What do I use instead?
326 organisations across different industries, sizes and compliance needs - no single answer. Content had to be helpful without being prescriptive, and without making any recommendation that could create liability.
Why wasn't I told sooner?
Full details of the deprecation reasoning couldn't be shared externally, especially in the limited real estate available in-product. Content had to lead with what users needed to do, not over-explain the business rationale.
Can I trust Workplace won't do this again?
No content could answer this directly. But poor deprecation messaging would have eroded trust. Every decision here was also a decision about the Workplace brand confidence at scale.
I ran a user needs exploration - not new research, but a synthesis of what already existed. I looked at support queries and help centre traffic from previous product deprecations. The signal was consistent: data, timing, and "what do I do now" came up every time something people relied on disappeared.
I worked closely with Product Marketing, who had market research on how enterprise customers respond to product deprecations, and with Legal, who had flagged the specific sensitivities around what could and couldn't be said externally. Both told me a great deal about where the anxiety points were before I'd written a word.
I mapped the user journey from the perspective of each audience separately. A frontline worker and a manager have fundamentally different needs in a deprecation - the worker needs to know their schedule is safe, the manager needs to know how to export data and stay compliant.
I then pressure-tested all five user problems against the legal messaging constraints - to make sure I'd actually be able to answer them, not just identify them.
Concerns ranked by user research and help centre queries
Help centre traffic tracked before deprecation began – same themes, different order
The brief I was given was: "we need notifications across web and mobile, work with legal." What I identified it to be was a trust and reputation risk affecting 326 enterprise relationships, a six-month communication system, and a chance to set the standard for how Meta handles deprecations at scale. That reframe shaped everything - how I prioritised stakeholders, what went into the content plan, and what I treated as non-negotiable in the messaging.
I also built a plan B into the strategy from the start: if usage wasn't dropping off fast enough and data wasn't being downloaded at the expected rate, we would need a more prominent, disruptive design that interrupted the user experience to drive action. Having that scoped in advance meant the team could move quickly if we needed it. We didn't - but the plan existed.
I wrote the content plan before touching Figma. Decisions about tone, sequencing, audience needs, and what to say in each channel were locked down in one document - and I didn't create a bottleneck for Legal, who weren't familiar with Figma. I included design examples so they could see text constraints, but the strategic decisions lived in the doc.
My doc was the single source of truth where Legal and Product could review and comment together. It covered: principles, approach, risks, constraints, key messages, audience mapping, and content for every key date and touchpoint across the six months. A deprecation affecting hundreds of enterprise organisations is a reputational risk as much as a product decision. The content plan made that risk visible and manageable - by defining the principles upfront, sequencing the communications, and giving every team a shared reference point before anything went into design.
The language gets shorter and more direct as the deprecation deadline approaches.
Early = informative and supportive. Late = urgent and more action-focused.
Legal was the most important stakeholder in this deprecation, because organisations were contractually using the product. They had genuine concerns about liability and wanted the messaging to be unambiguous about what was happening, why, when, and what it meant for customers.
When their suggested copy came through, it was legally thorough - but three times the length of my draft. It led with liability language, buried the key dates, and used terms like "discontinuing" where users had seconds to understand what was happening. Unintentionally, it was hitting the wrong side of every user problem I'd built the plan around: it created anxiety instead of reducing it, eroded trust instead of building it, and made the next step invisible.
I didn't push back with a redline. I went back with visuals. I mocked up both versions in Figma - rendered as they'd actually appear in product, real size, real Workplace feed - and walked Legal through the user's mindset at each touchpoint. At the persistent banner stage, an admin is seeing this mid-workflow, probably on mobile, for the first time. They have about one sentence before they scroll past. I showed them that their version didn't answer the three things a user in that state is actually asking - is this urgent, what do I need to do, do I have time - until line four or five.
I also reframed the risk in their own terms: if admins can't quickly understand the timeline, they won't act early. If they don't act early, we get a spike of panicked escalations at 30 days. That's a worse legal outcome, not a better one.
I took both versions to CRIT with other content designers - not framed as Legal vs. me, but as a genuine question about which version served the user at that moment in the journey. The signal was consistent: Legal's version produced higher anxiety and less clarity on next steps. I brought that back to Legal as evidence, not opinion.
We landed on a version that restructured the content so the human need came first, with compliance detail below the fold or in the Help Center article. Legal got their requirements met. Users got clarity.
Product Marketing's priority was protecting the Workplace brand - they didn't want the deprecation to read as Meta abandoning its customers. My priority was making the content direct enough that admins would actually act on it. Those two things are easy to let drift apart.
I brought Product Marketing in early - before copy was drafted - and shared the full content plan so they could see the entire communication arc across six months, not just individual pieces in isolation. When they pushed for softer language in the in-product notification, I could show them the sequencing: the notification was doing a specific job at a specific moment in the journey, and softening it would shift the burden onto later touchpoints.
We agreed on a shared principle - honest but not alarming - and used that to arbitrate every subsequent copy decision. It meant fewer rounds of feedback because we had a shared frame, not just competing instincts.
There was no time to run dedicated user research for the deprecation. So I worked with UXR to identify what we already had. There was existing data on how Workplace admins responded to system changes - their anxiety triggers, their mental models around product continuity, and where they typically dropped off in help content. We also did internal user testing with employees.
I used that to pressure-test the content plan before anything went to Legal or Product Marketing. It confirmed two things that directly shaped the final copy: admins needed the timeline front and centre, and they needed a clear owner to contact if something went wrong. UXR didn't need to run new studies - I needed to ask them the right questions about what they already had, and translate the answers into content decisions.
Two touchpoints from the deprecation - the announcement email and the in-product notification. Both show the original content, what was wrong with it, and how I improved it.
Important notice regarding changes to Shifts on Workplace
Hello [admin-first-name],
We want to inform you that all functionality, as part of the service you are subscribed to under the Shifts on Workplace product, will be deprecated in [DATE].
Timeline of changes
Your obligations
You are responsible for ensuring that any employee data exported from the Shifts feature is handled in accordance with applicable data protection regulations, including but not limited to the General Data Protection Regulation (EU) 2016/679.
Got questions?
Contact your Customer Success Manager or submit an enquiry through the Workplace Admin Help Centre. For technical questions regarding data export, please refer to the developer documentation.
We appreciate your continued use of Workplace and apologise for any inconvenience this change may cause.
This notice is in accordance with Section 14.2 of the Workplace Customer Agreement and the Meta Enterprise Products Modification Policy.
Shifts on Workplace is shutting down on [DATE]
Hello [admin-first-name],
We want to let you know that on [DATE], Shifts features can no longer be used, because we're shutting down the product.
We know your team relies on shift scheduling, so we want to give you plenty of time and support to move to a new tool.
What you need to do
Right now, you can still use all the Shifts features as normal. From [DATE + 3 months], you can only view shift schedules. You can't create, edit or offer cover for them.
From [DATE + 6 months], Shifts will be shut down. You should download your data by this date, including shift schedules, history and employee records.
We suggest you stop using Shifts on Workplace as soon as possible. Take a look at other [shift management tools] you can use.
Why are we shutting Shifts down?
Workplace is making this change to focus on building the future of work and to improve features that help companies connect all their employees, such as Events and Live Broadcast.
We're here to help
Thank you for using Shifts, we know moving tools is disruptive so we want to make this as smooth as we can for your team.
I followed my notification pattern: [What's happening] + [When] + [What to do]. Front-loaded so it works at a glance, without requiring a tap.
Radically simple
If a 16-year-old on their first shift can't understand it, rewrite it
Glanceable
Workers check shifts in seconds. Every word must earn its place
Complete in isolation
Every notification must work alone. No tap required
Transparent
What's changing, when, what to do. Answer all three, every time
Tone matches moment
Informative at 3 months. Urgent at 1 week. Supportive on the day
Make the problem visible, not theoretical. Mocking up both versions in product was the move that shifted Legal. A side-by-side in context is harder to argue with than a comment in a doc.
Reframe the risk to both sides. Legal wanted compliance. I showed them that unclear messaging created the compliance failure they were trying to avoid. Finding the shared risk is what gets you to a shared solution.
Plan the content system, not just the content. The 6-month plan - with principles, tone ladder, and touchpoint mapping - is what made this manageable. Individual comms are easy. Consistency across six months and 326 organisations is a systems problem.
Turn a hard project into a reusable standard. Rather than treating the Shifts shutdown as a one-off, I documented the principles so any team facing a deprecation later wouldn't start from scratch. That's how I think about my role as building systems, not just solving one content problem.
Meta · Workplace · Shifts · Workrooms · International
At Meta, every piece of content I worked on was built with a localisation lens from the start: is this term translatable? Will this UI pattern break for right-to-left languages? Does this emoji land the same way in Germany as in the US? I ran localisability checks proactively, brought i18n partners in at discovery – not just pre-launch – and built the systems (terminology trackers, content briefs, the CD × i18n collaboration model) that made this scalable across the whole organisation.
Localisation isn't something I add on top of content. It's part of how I define quality.
When I joined Meta, there was no structured way for content designers to work with i18n teams on 0-to-1 products. The partnership was ad hoc. CDs involved localisation late, causing translation quality issues, broken language experiences, and near-misses at launch. The problem wasn't individual mistakes. It was a systemic gap nobody had addressed.
As Content Design Lead on Workrooms, I saw this problem directly and decided to fix it – not just for my team, but for all CDs at Meta working on international products. I audited how CDs and i18n LPMs were working together across multiple product teams, identified gaps at every stage, and mapped the entire product lifecycle.
I published my CD × i18n collaboration model based off my work on the 0-to-1 product Workrooms. This was recognised as the advanced level of i18n collaboration and I was named as the go-to expert for teams launching international products. What started as one product team's approach became a company-wide standard – and is now referenced in training material across Meta.
Discover and define
Contact i18n LPMs as soon as you have timelines. Agree language scope upfront – this is a strategic decision, not a translation task. Identify cross-surface interdependencies and locale coverage gaps early. Define translation devices (mobile, web, desktop, Quest) – each adds scope and needs to be agreed before design begins. Set up a group chat between CD and i18n for every product and maintain regular contact throughout – timelines, devices, and org structures all impact translation workload.
Design
Share Figma designs with i18n before they're final – walk them through the product, content decisions, and key flows. Include error messages, NUXs, and accessibility labels. Run localisability checks on terms, icons, colours, and emojis. Flag truncation risks before engineering builds anything.
Development and post-development
Add i18n to product playtesting. Connect i18n with engineering so strings are coded in the right projects. Write clear string descriptions for every string – stating UI location and what parameters will be replaced. This is the single highest-impact thing a CD can do for translation quality. Create a detailed content brief: show translators how the product looks and the space available in the UI. Include error messages and confirmations. I created the content brief template for Workrooms which became an example that the i18n team shared Meta-wide as best practice by CD.
Launch and beyond
Be available to answer translator questions in real time. Update translator term browser when content is final. If you change content post-launch, tell i18n immediately.
"When CDs bring i18n in early, they don't just translate – they do real cultural adaptation. That's how we build products that feel native to each market, not like they were designed somewhere else and shipped over. We always need to bake in locale-aware design from the start."
Across Workrooms products, terminology was inconsistent – the same concept had different names across surfaces. Translators were working without definitions, context, or source string references. Translation quality suffered, and the problem compounded as the product grew. My CD Director asked me to lead 15 other content designers across the Workrooms team.
I created a terminology tracker covering all Workrooms features, designed from the ground up so every term was localisable – choosing words and structures that would translate well across languages. Every term was co-designed with other CDs, validated with i18n Language Managers, and tested through UX research with real users to ensure chosen terms would work for international markets.
Workplace by Meta was expanding Shifts into European markets, and Italy was a strategic priority – Italian hospitality (hotels, restaurants, cafes) is one of the largest shift-work sectors in Europe. The product had been built with an English-speaking, US-centric mental model of scheduling. When I looked at what existed for the Italian market, it was translated – but it wasn't adapted.
Italian hospitality has fundamentally different conventions, terminology, and working rhythms. A direct translation was not going to be enough.
I partnered with the Italian i18n LPM to run a discovery phase. The question wasn't "how do we translate this?" – it was "what does a shift look like in an Italian hotel or restaurant, and how do workers actually talk about it?" I worked with UX Research to design a research plan targeting Italian hospitality workers across different roles (front-of-house, kitchen, hotel reception) and establishment sizes, because their mental models and content needs differed significantly.
I identified that "turno" (shift in a general work context), "orario" (schedule/hours), and "servizio" (service – a lunch or dinner cover) are distinct concepts the product was collapsing into a single generic "Shift" type. I also identified that Italian hospitality is governed by sector-specific CCNL (national collective labour agreements) that shape how workers understand their hours and what a "shift" means legally – content that ignored this felt alienating and untrustworthy.
I revised the product's core terminology to map to how Italian hospitality actually structures the working day:
I adapted notification and confirmation content for Italian workplace communication norms – specifically the manager-to-employee register, which differs meaningfully from peer-to-peer. A schedule change notification in the wrong register felt either too casual or too cold. This was a content design decision, not a translation decision. I partnered with the Italian country manager to pressure-test the approach against direct knowledge of Italian hospitality businesses, and coordinated with the Product Marketing team to align product content and marketing messaging on the same terminology.
Notification – translation only
English (source)
Shifts
Dear [Name], your Saturday shift has been updated. You are now scheduled to work from 1:00 PM to 9:00 PM. Go to the Shifts app to view your shift details.
Italian (literal translation)
Turni
Caro [Nome], il tuo turno di sabato è stato aggiornato. Sei ora programmato per lavorare dall'1:00 PM alle 9:00 PM. Vai nell'app Turni per visualizzare i dettagli del turno.
Italy became one of the stronger-performing European hospitality markets for Shifts. The content felt – to Italian users – like it had been designed for them, not translated for them. That difference showed in onboarding completion and early retention.
The terminology framework I built became the foundation for subsequent Italian localisation work across other Workplace products. The approach of starting with "how do workers in this sector in this market actually talk about this?" became the template for other market-specific expansions.
The case I made to PM and engineering – framing terminology adaptation as a business risk, not a translation nicety – shaped how the team approached every new market after Italy. Higher support ticket volume, onboarding abandonment, and word-of-mouth damage in a sector where reputation travels fast were the costs of not adapting content properly.
The Shifts product used 12-hour AM/PM formatting. For international users, this was a direct usability problem – 12-hour AM/PM is not universal, and forcing it for locales that natively use 24-hour time would be confusing and wrong.
I flagged this early in the design process – before engineering built it – and submitted a formal localisability check to the i18n Content Standards group. The result came back as "hard" for multiple locales using 12-hour format, confirming the risk and validating the need for a locale-adaptive solution.
I partnered with i18n engineers to come up with a solution – locale-adaptive time formatting. The format shown adapts based on the user's locale rather than applying one global setting. I coordinated this change across mobile and web platforms.
My work here updated Meta's content standard for date and time formats across products.
Before – 12-hour (US default applied globally)
After – locale-adaptive (24-hour for relevant markets)
Company-wide standard
My CD × i18n collaboration model was formally adopted across my org and is referenced in Meta training material. I was named go-to expert for teams launching international products.
Updated Meta content standards
The locale-adaptive time formatting work I led updated Meta's official content standard for date and time formats across products, and became an example of best practice for other CDs.
Reusable systems at scale
The terminology tracker, content brief template, and Italy market approach were each adopted as templates by other teams across Meta – turning single-product work into org-wide infrastructure.
15 CDs aligned
The Workrooms terminology tracker aligned 15 content designers across 4 surfaces on consistent, localisable language – reducing translation back-and-forth and improving quality for international users at launch.
Italy market performance
Italy became one of the stronger-performing European hospitality markets for Shifts. Improved onboarding completion and early retention – because the product felt designed for Italian users, not translated for them.
Template for market expansion
Starting from "how do workers in this sector actually talk about their work?" became the established approach for subsequent market-specific expansions across Workplace products.
Setting standards is product work. The CD × i18n collaboration model wasn't a nice-to-have document. It was product infrastructure – without it, teams were building features that would fail international users at launch. Creating that standard was the same as building a reusable component: it saved time and increased quality across the whole organisation.
Localisation quality starts upstream, not in translation. The single highest-impact thing a CD can do for translation quality isn't proofreading – it's writing clear string descriptions, building a consistent terminology system, writing thorough content briefs and flagging localisability issues before engineering builds anything.
Market-specific content is a research problem first. The Italy work only succeeded because I asked the right question at the start – not "how do we translate this?" but "how do Italian hospitality workers actually talk about their work?" Without that research, we would have shipped a product that felt foreign to the people it was designed to serve.
The role of a staff CD is to make this scalable. Building the tracker, creating the collaboration model, writing the content brief template – these were things I identified as missing and built myself because I knew other teams would need them and it would improve our products.
