← Overview

Canva Home and Editor

Two connected programmes with one aim: make Canva predictable, from the moment someone starts a design to the moment they publish it. I led the content strategy and systems thinking for both: the information architecture, the taxonomy, and turning decisions into reusable components.

My role

Senior Design Manager and Content Design Lead, Design Experience

When

2026, Sydney

Team

The Editor System working group, Design Experience

Result

Visual system shipped. Editor strategy finalised.

The context

Canva covers a huge range of design types, from presentations and social posts to videos, print and documents, and dozens of teams build into the same two places: Home, where every design starts, and the editor, where every design gets made. Each addition makes sense on its own. Together, over years, they add up.

Simplifying these surfaces became a company-level goal. Two programmes took it on. Creation flows and the visual system looked at how people start. The Editor System looked at how people edit and publish.

The problem

• Starting took too many steps. Broad category icons bundled many design types together, so it wasn’t clear where a click would lead, and extra screens sat between choosing what to make and making it.
• Surfaces had no clear job. Menus had grown long and mixed file actions, view controls and settings. People looked in several places for the one thing they came to do.
• The same task took a different route. Publishing worked differently on each device, so habits didn’t transfer.
• Everything was shown to everyone. Controls that few sessions used sat on screen for every kind of design.

There was an organisational problem underneath. The most visible spots improve discoverability for whatever sits in them, so every team has a good reason to want one. Without shared rules, each decision was argued from scratch.

Part 1: Starting a design

Agreed the direction first. Before designing anything, we aligned on five things: one click from Home to the editor, a scalable icon system for design types, a protected space on Home for what each person uses most, a “See all” page for exploring, and keeping tools and shortcuts distinct from design types.

One click to the editor. Choosing a design type or a template on Home should take people straight into the editor. We wrote each change as a hypothesis: if we do this, we expect that, because of this. That made every proposal something we could test.

Every design type gets its own way in. We proposed replacing the broad categories with an icon and entry point for each design type, so Home can show the formats that matter to each person. The row is personalised to how someone uses Canva, and starts from what is most popular where they are.

A place for everything else. A full “See all” page organises the whole range into clear categories. People who want to browse can, and Home stays focused.

Three rounds on the visual system. The icons had to work as a system. They needed to stay recognisable on every device, cover the full range of design types, and feel like an evolution of the visual language people already knew. The team explored this over three rounds, testing each direction in the places the icons appear, and carrying one language through from icon to tile to template card.

Named the trade-off. One proposal was to remove the guided step that appears between choosing a design type and reaching the editor. It saves a click. But our own data showed that step was doing real good: fewer people abandoned a blank design, and more started from a template. So the proposal said so, set out what we might lose, and came with a mitigation: offering template choices inside the editor as it opens.

Part 2: Making and publishing

Gave every surface a job. This is information architecture at the scale of a whole product. We mapped the anatomy of the editor on desktop and mobile, then defined what each surface is for and what belongs in it. Once a surface has a job, “where should this go?” has an answer that doesn’t depend on who is asking.

Used principles to make decisions. We applied a shared set of product principles to every proposal: give each surface a clear job, keep familiar controls where people expect them, and stay consistent by default while tailoring only where a different kind of design needs it. Each problem was tagged with the principle it broke, which kept reviews about the principle, not personal taste.

Simplified the header and menus. The header was reduced to file options, document controls and one primary action. The File menu had become one long list, so we split it: File for managing and exporting the design, and a new View menu for how you look at it.

Listened when testing disagreed. We tested the new menus with five existing and five new users. About half couldn’t find some of the items we had moved, and people were confused when controls changed between kinds of design. We didn’t drop the direction or ignore the result. We narrowed what moved, kept more of the layout stable, and designed guidance so that people who had recently used a control were shown where it had gone.

One clear way to publish. Most people choose the same end point for a given kind of design. So we proposed one publishing button whose main action reflects what people most often do with that design, a few alternatives beside it, and everything else one step further away. The structure stays the same everywhere, and only the main action changes.

Turned decisions into components. A decision only holds if teams can reuse it. Wherever a pattern was settled, such as the publish button and its menu or the view control, the aim was to make it a component in the component library, so every team gets the same structure and labels by default.

A calmer bottom bar. We kept the controls people rely on, moved the rarely used ones into the View menu, and brought every way of viewing pages into a single control that behaves the same for every kind of design.

What I led

• All content strategy. I led everything content-related across both programmes, working with the Editor System working group in the Design Experience department.
• Information architecture. What each surface is for, what belongs in it, and in what order. The header, the File and View menus, Share and Publish, and the “See all” page are all information architecture decisions before they are visual ones.
• Taxonomy. How Canva’s design types are named, grouped and categorised, so the same thing is called the same thing on Home, in menus and in the editor.
• Systems thinking. I pushed every decision towards something reusable. Wherever we could, a pattern became a component in the component library, so consistency is built in and doesn’t depend on each team remembering the rules.
• One source of truth. The strategy, status, evidence and decisions for the Editor System lived in a single document that was kept up to date, so any team could see what was changing and why.
• Decisions that leadership could make. Options went to senior leadership as a small set of alternatives, each with its benefits, risks and a recommendation, usually starting with the lowest-risk change that solved a real problem.

The outcome

The visual system shipped. For the Editor System, the definitions and decisions in the strategy were finalised, and the current product is being audited against them.

What I learnt

Simplifying is not the same as removing. An extra step can be helping people, and a control few people use still matters to the ones who do. The work is deciding what earns its place, saying what it costs, and giving everyone else a clear way to find what moved.

← Overview

Canva Copy Database

Nobody could see all of Canva’s words in one place, so I built the place. A searchable source of truth for every UI string live in Canva, and a tool for cutting cost and keeping copy consistent: find a string that already exists, copy it straight into the code, and it arrives already translated into 113 languages. I started it on my own and built it with AI coding tools.

My role

Creator. Self-initiated, alongside my role as Content Design Lead

When

2025–2026, Sydney

Built with

Cursor, Claude Code, Git and Canva’s internal prototyping tool

Result

11,590 strings audited. Used by content designers, localisation and engineers

The problem

The words in a product live in code. Content designers write them, but once they ship they are scattered across the codebase, where only engineers can easily look. That causes three problems:

• You can’t see what already exists. Without a way to search live copy, the same idea gets written again in slightly different words.
• Every new string costs money. Each one has to be translated into every language Canva supports, which is 113. Reusing a string that is already translated costs nothing.
• Words lose their context. A string on its own doesn’t tell you where it appears or why it was written that way.

How I built it

Nobody asked for this. I started it on my own initiative for the content design specialty.

Version one: agents. At first I had no access to the code, which is usually reserved for engineers. So I built AI agents to scrape our content from the product. It worked, but it was slow and arduous, and it could only see what an agent could reach.

Getting access. The real source was the monorepo. Getting a content designer access to it took time. I built relationships with engineers and completed the Git and monorepo training, until they were comfortable giving me access.

Version two: the source. With access, I extracted the live copy directly from code and connected the project to Git. I built the database and its interface with Cursor and Claude Code, and used our internal prototyping tool to host it, so anyone at Canva could open it with no setup and no install.

The hackathon. In 2026 I entered it into Canva’s company hackathon with a colleague, as the source of truth for Canva’s UI copy. By then it was already live and in use.

What it does

• Search and filter every live string by product area, string type and language.
• See the context. Each string carries its description, and its developer details for anyone who needs them.
• See every translation, so a string can be reused instead of rewritten and retranslated.
• Find duplicates and similar strings, to see where the same thing has been written more than once.
• Check my copy. Paste the copy you are about to ship and an AI check compares it against our content guidelines and existing strings.
• Needs review. A content audit that flags strings worth a second look.
• Export any string, or a whole set as a spreadsheet.

You can try the idea here:

How it cuts cost

The saving comes from reuse, and the tool makes reuse the easy option:

• Search before you write. If the words already exist, you find them in seconds.
• Copy the string straight into the code. Each result has a Copy button and its developer details, so reusing a string is a copy and paste.
• Skip the translation. A reused string is already translated into every language, so there is nothing new to send for translation, review or testing.
• Remove what is duplicated. The Duplicates view shows where the same thing has been written more than once, so those strings can be merged.

What that is worth. Canva changes fast: at least 1,000 copy changes a week. Each new string has to be translated into 113 languages. Here is an illustrative estimate using a public list price. Lokalise, a widely used localisation platform, lists professional translation from US$0.07 a word.

One 5-word string, 113 languages

About US$40

1,000 strings a week

About US$39,500 a week

Over a year

About US$2 million

If 20% were reused

About US$411,000 saved a year

The target was for 20% of copy changes to be reusable strings. At that rate, the estimate above comes to about US$7,900 saved every week. Try your own numbers:

Consistency, in every language

Cost is the argument that gets attention. Consistency is the one customers feel.

• One name for one thing. When people reuse a string, the same action is called the same thing everywhere it appears.
• Consistent in 113 languages at once. A reused string carries its approved translation with it, so the product stays consistent in every language without each translator having to match earlier work.
• Checked before it ships. “Check my copy” compares new copy against our content guidelines and existing strings, so inconsistencies are caught while they are still cheap to fix.
• Visible drift. The Duplicates and Needs review views show where wording has already drifted, which gives the team a list to work through.

What’s next

The database was the first step. The plan was to turn it into an internal content management system:

• Edit copy at the source. Change a string in the database and have it update in the product.
• Run and track experiments. Set up A/B tests on copy and see the results next to the string.
• Keep the decisions. A record of past decisions about each string, so the reasoning stays with the words.

What I led

• The idea and the build. I saw the gap, designed the tool and built it with AI coding tools, without waiting for engineering time.
• Access for the specialty. Getting into the codebase showed what content designers can do when they can reach the source of their own work.
• One tool for three teams. Content designers use it to check whether copy already exists, for inspiration or to reuse it. The Localisation team reuses translations. Engineers reuse strings that come with their translations. All three save money and keep the product consistent.

The outcome

Strings audited

11,590, across 15 product areas

With translations

7,967 at first, across 8 languages

Then expanded to

All 113 languages Canva supports

Flagged for review

1,043

The Copy Database went live and is used by content designers, the entire Localisation team and engineers. Every string they reuse is one that never needs translating again, and one more place where the product says the same thing the same way.

What I learnt

The hard part wasn’t the code. AI tools made building fast. The hard parts were getting access to the source and deciding what the tool should be. A content designer who can prototype can show an idea working, which is far more persuasive than describing it.

← Overview

Canva AI Pass for Admins

When a team runs out of AI credits, the admin decides what happens next. I designed the content and information architecture that shows admins how their team uses AI, and offers more only where it helps them.

My role

Content Design Lead. Hands-on: content, information architecture and narrative

When

2026, Sydney

Team

A product designer, a product manager and the growth team

Result

Live for admins on Business and Enterprise plans

The context

Canva’s AI features run on credits. Everyone on a team gets a monthly allowance, and some people need more. Canva offered two ways to get it: an AI Pass for individual people, bought online, and an AI Shared Pass, a pool of credits for a whole organisation, bought through sales.

In both cases the person who decides is the admin. This work was about them.

The problem

An admin can’t make a good decision about AI credits without three things. We framed them as the jobs the experience had to do:

• Understand credit usage. See who on the team is getting blocked.
• Gather proof to justify a purchase. See what the team uses AI for, so there is evidence to take to finance or leadership.
• Manage usage. Make sure everyone gets the right amount of credits.

The risk with any growth work is that it turns into selling. An upsell shown in the wrong place, or without evidence, is noise to a busy admin. The challenge was to make the offer useful.

What I did

Shaped the growth strategy. I worked with the product designer and product manager on the strategy, and with the growth team on where an upsell made sense. The rule we worked to was that an offer appears where the admin can see the need for it: next to the usage that shows people are running out.

Decided where everything lives. This was mostly an information architecture problem. AI usage touches several admin pages, and each had to play a clear part:

• Billing carries a short AI usage summary, because that is where admins think about cost.
• People shows usage for each person, sorted from highest to lowest, because that is where admins think about individuals.
• A dedicated AI credit usage page brings monitoring and management together in one place.

I mapped how these pages relate to each other and to the rest of the admin experience, so an admin can move from the summary to the detail to the action without losing the thread.

Wrote one narrative for different plans. The story had to hold across plans that work differently. A Business admin buys online and sees “Manage team usage”. An Enterprise admin buys through their account contact and sees “View usage”, with a summary of how many members are near their limit or at it. The names, labels and next steps change with the plan, and the structure stays the same.

Chose words that inform. “Members near limit” and “Members at limit” tell an admin what is happening on their team in four words. That framing is the upsell: it describes the admin’s situation and leaves the decision with them.

What I led

This was hands-on work that I was directly responsible for: all the content, the information architecture, where each piece appeared, how it related to the other admin pages, and the narrative that ties it together. I was also the link between the product team and the growth team on where an offer would be welcome and where it would get in the way.

The outcome

The experience was delivered and went live for admins on Business and Enterprise plans shortly before I left Canva.

For teams on Business plans, the launch figures were:

Top-ups purchased

19,000, by 13,000 teams

Conversion

38% of people who saw the upgrade prompt bought

Repeat buyers

23% of teams bought a second time

What I learnt

Growth and usefulness don’t have to pull against each other. The most persuasive thing we showed admins was their own data, in the place they were already looking, in words that needed no explanation.

← Overview

Canva Classification Labels

Large organisations need to mark how sensitive a design is. A request from Disney in a user testing session became a product for every enterprise. I led the content, information architecture and narrative, where the words carried legal weight.

My role

Content Design Lead. All content, information architecture, narrative and content strategy

When

2026, Sydney

Team

Product design, product management, compliance and legal

Result

Built and launched for Enterprise organisations

The context

Large organisations classify their information. A launch plan, a new product or a restructure is treated differently from a social post, and most companies have a framework that says how.

Canva had no way to show that. People couldn’t tell which designs were sensitive, so teams doing sensitive work moved to other, approved tools. That kept whole teams out of Canva.

The project began with a specific request from Disney, one of Canva’s largest enterprise customers, during user testing. As we looked into it, the same need came up with other customers, and it grew into a product for all enterprises.

The problem

Three things made this a content problem as much as a product one:

• Every organisation’s framework is different. Some have three levels and some have many more, each with its own names. The labels had to be the organisation’s own. Canva couldn’t be seen to tell a company how to govern its information.
• A label informs. It doesn’t restrict. In the first release, a label tells people how to handle a design. It doesn’t stop them sharing it. People used to other tools might assume it does, which would give them a false sense of security. Legal raised the same risk: customers over-relying on something that reads as protection.
• Admins need to set up before they switch on. An admin has to build their labels, check them and tell their company before anyone sees them. That means several states, and each one needs a name people understand.

What I did

Chose names that set the right expectation. The feature is called “Classification labels”, and the text that goes with each label is called “Label guidelines”. Guidelines describe how to handle a design. The word doesn’t promise enforcement, which is the expectation we needed to set. The introduction does the same job: labels help your team “identify and properly handle designs in line with your organization’s policy”. The policy belongs to the organisation. The example guidelines follow the same rule. “Please avoid sharing this design outside the company” asks people to act a certain way. It doesn’t claim the product will stop them.

Defined the language for every state. There are three ideas an admin has to hold: whether the feature is on or off, whether a label is active or archived, and which label is the default. I worked through the model with product design, product management and engineering until each state had one name and one meaning. The status is written into the heading, with the consequence underneath: “Classification labels are on. Members can see and apply active labels to designs.”

Wrote for the edge cases. The moments where an admin could get stuck each say what has happened and what to do next:

• “You’ve reached the limit of 20 active labels. Archive a label to add a new one.”
• “You don’t have any active labels. Members are not able to apply labels to designs.” It goes on to say that labels already applied stay visible, so nobody assumes their history has gone.
• “To start using labels, turn classification labels on.” It also explains that labels applied earlier won’t show until then.

Decided where it lives. For admins, classification labels sit under Security in settings, beside data and privacy and audit logs, because that is where the people responsible for governance already work. For everyone else, the label appears next to the design’s name in the editor, where it can be seen without getting in the way of the work.

Made it work on mobile. The same model, states and messages carry across to a phone, where the table becomes a list and the filter does more of the work.

What I led

I was responsible for all the content, the information architecture, the narrative, where the feature was introduced in the product, and the content strategy decisions behind them. I worked closely with compliance and legal, so that nothing we wrote claimed more than the product did, and with the product designer and product managers on the model itself. My content recommendations became the agreed language for the whole feature.

The outcome

Classification labels was built as designed and launched for Enterprise organisations. Every word in the screens above is mine, from the headings and messages to the example guidelines.

What I learnt

In security and compliance, a word is a promise. “Guidelines” and “restrictions” describe different products, and choosing between them is a decision about what the company is prepared to stand behind. That is why content design belonged in the room with legal from the start.

← Overview

IKEA Product Availability

Furniture is deceptively complicated. I rewrote and restructured how IKEA tells customers whether a product is in stock, ready for Click & Collect, or available for delivery.

My role

Lead Experience Content Designer

When

2022–2023, Amsterdam

Team

Product owner, designers and developers

Result

Key metrics improved by 3–43%

The context

IKEA has spent decades perfecting how people shop in its stores. Its digital side was much younger: the hub set up to audit and rebuild the online shopping experience was only two years old, and I was the second UX writer to join IKEA anywhere in the world. (The team later grew to five.)

That made it a rare opportunity. More customers were choosing to shop online after Covid, the range runs to thousands of products, and some of the most important pages had never had a content designer work on them.

The problem

You find a product on IKEA’s website and try to add it to your basket. Then you notice there is no “Add to basket” button. Or it can’t be delivered to your area. Or it’s only available for Click & Collect, or out of stock everywhere, with no explanation.

These were common pain points in our user interviews. Behind them sits a complicated fulfilment system: several ways of getting a product to a customer, each depending on where they are, when they buy, and what stock is where. The product page was passing that complexity straight on to customers.

When I audited the existing statuses, I found the copy was:

• Unclear. “Click & Collect at Amsterdam” could mean the service exists there, or that this product is ready to collect there.
• Not yet in IKEA’s voice. Parts of it had been machine translated, so it didn’t have the simplicity people associate with IKEA.
• Inconsistent. Delivery was “available”, but Click & Collect used different terms for the same idea.
• Not accessible. Click & Collect status relied on a coloured icon alone, which excludes customers with colour blindness.
• Not scalable. There was no pattern other teams could reuse, which also made it hard to scan.
• Not built for localisation. It was already long in English, before translation into other languages.

What I did

Mapped every possibility. I started by mapping every availability status in Figma, working with the product owner and designers to cover every possible customer journey across IKEA’s fulfilment methods.

Questioned every word. I annotated the statuses with the questions each one raised. Does “info” fit our tone of voice? Is “See options” inclusive language? Is checkout the right moment to give this information? How long will this be in other languages? And if we decide something here, where else does it need to change?

Decided what customers need to know. We had to understand the back end in full. Customers didn’t. Most of that detail would only confuse them, so I reduced the map to the statuses that were useful to someone trying to buy something.

Found the pattern. Every status came down to three things: store stock, Click & Collect stock, and delivery. I worked with designers and developers to restructure the page around those three, each with its own header and a consistent line of copy.

Chose words from research. For stores I used “in stock” and “out of stock” in place of “available” and “unavailable”, because our research showed customers in English-speaking countries were more familiar with that retail language.

Made it accessible. The coloured icons stayed, because they communicate quickly, but every status is now also stated in text.

What I led

I turned the new statuses into reusable copy components with guidelines, and shared them with developers so other teams could use the same patterns. I also set the information hierarchy with the product owner so the order of the page reflected business priorities, and kept a weekly rhythm of user sessions running through the whole project so each decision was checked with customers before it shipped.

The outcome

This is one of IKEA’s highest-traffic pages, so we tested the changes thoroughly:

• A/B tests of the English copy with Western European, US, Australian and UK audiences, measuring whether people took the next step that matched their intent. This showed a 37% improvement.
• Weekly user sessions with at least 20 people a week, and more than 150 sessions across the project.
• Behaviour tracking before and after the product page, to see whether people went on to the basket, wishlist or saved products.

Customer support calls, direct store calls, and basket, purchase and wishlist conversions all improved, by between 3% and 43%. Wishlist conversions improved most, at 43%, driven by customers asking to be notified when a sold-out product came back.

What I’d do next

The copy still says “Out of stock at IKEA Amsterdam”, which carries grammatical baggage into every translation. My next step was a design change to “Out of stock • Amsterdam”, removing the grammar problem and making the pattern easier to scale across languages.

← Overview

IKEA Electricity Subscriptions

Bringing clean energy to the everyday customer. I set the language foundations for taking IKEA’s electricity subscription from Sweden to new markets: a glossary, reusable copy components and localisation guidelines, tested with customers in Germany.

My role

Lead Experience Content Designer

When

2022, six-month timeline

Team

Product owner, designers and UX researchers

Result

Clarity scored 8.5 out of 10 in usability testing

The context

IKEA is one of Europe’s largest investors in renewable energy, and it wanted to make that investment available to customers: monthly electricity plans from 100% renewable sources, with no lock-in. That product, STRÖMMA, already existed in Sweden. I was asked to join the taskforce getting it ready for other markets, mainly Germany and the Netherlands, where the appetite for renewable energy is strong.

There were two plans. Fixed gives a predictable monthly bill, with the price held for 12 months. Flex follows the spot market, so customers pay the market price with no markup and can save by using electricity when prices are low.

The problem

Electricity is full of jargon, heavily regulated, and a little intimidating. Most people don’t know how tariffs are calculated, and I didn’t either when I started. Customers needed to trust that the price was fair, that they wouldn’t be locked in, and that IKEA would handle the switch.

For these markets we were starting the experience from scratch. The brief was to align with other IKEA products and keep the experience simple. We had three things to deliver (a landing page, an onboarding flow, and an app for tracking usage) and six months to do it.

What I did

Started with research. Working with the UX research team, we looked at how customers saw the electricity products already on the market: what they liked, and what they wished they had. That fed into competitor mapping and early concepts for the landing page.

Built a glossary. A fast-growing product needs its words settled early. I created a glossary of the terms we would use from then on, and tested alternatives with users to find out which they preferred. It covered everything from tariff names to small choices such as “details” over “information”.

Wrote in variants. With a new product I write several versions as I go, with different terminology and different information architecture, then test them. It also lets product owners and designers see how each version serves different business goals. When the team liked the top of one variant and the bottom of another, we prototyped the combination and tested that.

Tested with research. Each round had clear questions. Do people understand Flex and how it differs from Fixed? Do they have enough information about cost? Does the page feel simple, green and fair?

Reviewed constantly. A product that hasn’t launched yet keeps moving: legal requirements, leadership goals, scope and time all changed along the way. I ran copy reviews after every change, logging each observation next to a recommendation.

Designed for localisation. My focus was Germany and the Netherlands, but the product was meant to travel further. I treated the copy like a jigsaw: reusable components and templates for the information architecture, plus guidelines on how to put the pieces together for each region. That kept the copy flexible without losing the local detail each market needed. In a regulated industry, it also meant knowing where legal wording had to stay as it was.

What I led

The glossary and guidelines became the shared foundation for all three deliverables, so the landing page, onboarding and app spoke the same language. I ran large workshops with colleagues from other departments to pressure-test our thinking, and worked with neighbouring product teams, including smart home and sustainability, to keep terminology consistent in case the products came together later. I also made the case for building for scale from the start, so the work wouldn’t need redoing for each new market.

The outcome

The landing page centred on a price calculator that had to be clear and feel like IKEA.

In the second round of usability testing in Germany, overall understanding and usability improved on the first round. In the survey that followed, “The information is clear and simple” was the highest-rated statement at 8.5 out of 10, and trust that IKEA would treat customers fairly scored 8 out of 10.

IKEA plans years ahead, so most of this strategy was set long before release. In January 2026, IKEA Germany launched a dynamic electricity tariff with its partner Svea Solar: renewable electricity at market prices, managed through an app and cancellable monthly. It is the idea we were testing as Flex in 2022, and Germany is the first IKEA market in the world to offer it.

What I learnt

Making the difficult easy is the job. Before this project I didn’t know how electricity plans worked. That turned out to be useful, because I had to turn the jargon into something I could understand before I could do it for customers.

← Overview

CityBook by Booking.com

I joined as the only UX writer on a five-person team and ended up leading content for a 26-person, company-wide project. The taxonomy and content system I built for Booking.com’s personalised city guide were adopted well beyond it.

My role

UX Writer, and the only one on the team

When

2018–2020, Amsterdam

Team

Started as 5, grew to 26

Result

78% retention, and a taxonomy adopted across the company

The context

In mid-2018, five of us were chosen to form a new product development team at Booking.com: a UX writer (me), a senior designer, a principal product owner, a front-end developer and a back-end developer. Our brief was to create a personalised, dynamic product that would change how people experience travel.

With Booking’s data and insights team, and user research sessions held around the world, we found a clear gap. Travellers wanted the authentic side of a city, a mix of local favourites and the must-sees, and an itinerary that fitted them. Guidebooks went out of date too quickly to give them that.

The problem

For the business, the challenge was to bring several Booking products and their back ends together into one inspiring travel companion, in a competitive space where we had to move fast. Whatever worked would also need to feed back into the main Booking.com app.

CityBook was going to be content-heavy, and I was its one writer. That put five problems on my desk:

• No content management system. We had nowhere to gather travel content about a city, show it in different forms, and connect it to machine learning for personalisation. It had to be built in-house, and be reusable by the rest of the company.
• Translation and localisation. Different cultures experience the same city differently. A visitor from China and a visitor from the US want different things from London, so content, recommendations and presentation all had to flex, with translations that kept the quality of the English.
• Tone of voice. CityBook had to carry the excitement of travel, which called for a warmer, more personal voice than Booking’s usual neutral one.
• Complex flows. Booking and payment needed to feel effortless, so travellers could get on with their trip.
• One writer. I had to prioritise hard and manage stakeholders constantly to keep everything moving.

What we built

CityBook was an app for iOS and Android, with mobile web and desktop versions. It learned from what each person did: the attractions, restaurants and activities they liked shaped what it recommended next. It covered attractions, events, shopping and food, and people could book tickets and tables without leaving the app.

The home screen was a personal feed. It took into account the traveller’s preferences, the destination, and outside factors such as weather and public holidays. If it was raining, the feed left out outdoor activities and suggested museums and food.

We launched in eight cities: London, Amsterdam, Paris, Rome, Barcelona, New York, Tokyo and Berlin. Every place was curated and had to pass quality checks. Tourist traps weren’t featured, and places with consistently bad reviews were removed.

What I did

Made everything a component. To keep CityBook flexible, every piece of UI copy and every design element became a reusable component. That kept the product consistent, made it easy to scale, and let us arrange content in the order that made sense for each traveller.

Created the taxonomy. Bringing all of Booking’s travel products into one place meant rebuilding how we categorised the world. I created a new taxonomy for it. Because every input in the back office was a single copy component, we could tag copy with categories and feed that into the machine learning platform. The more components and tags we added, the better the personalisation became.

Shaped the back office. The component approach led to the first version of a new content management system and content back office, built for our team and designed to be reused by others.

Found a warmer voice. I wrote everything in English myself, in a voice with more personality than people expected from Booking.com. Sections had names like “Let’s do lunch” and “Cheap eats: wallet feeling a little light?”. Place descriptions were short and opinionated, collections had a point of view, and accessibility had its own section with guides from locals.

Kept booking simple. We wanted people focused on the excitement of travel, so booking had as few obstacles as possible: a two-tap process with linked payment. I gave bookings context in relation to the trip, using words such as “today”, because nobody knows the date when they’re on holiday.

Defined what success meant. CityBook was set up to move faster than Booking’s usual experimentation process, so we needed our own measures. I defined them with the team: retention by type of returning user, time spent with long-form content, bookings of attractions and restaurant tables, reasons for contacting customer support, use of the bucket list and favourites features, search against navigation as a test of the taxonomy, and user error rates.

I also kept my own checklist for every piece of copy. Is it the fewest words possible? Is the user aware of every step, with no dark patterns? Is it free of jargon, especially in error messages? Is it consistent with our glossary? Is it written for translation?

What I led

What started as five people became a company-wide collaboration, and my job grew from writing into leading content and managing stakeholders.

• Scaling the content. I sourced and wrote all the content for our first city, Amsterdam, myself. To scale, I wrote the guidelines and processes that let Booking’s internal content agency bring in more writers, then localise and translate the long-form content. In effect I became the project manager for everything content-related.
• Working across the company. We partnered with as many product and tech teams as we could, which spread what we learned and brought in the best people. I also worked closely with user insights, who helped us go beyond standard A/B testing, and with the platform team on the machine learning behind the feed.
• Earning leadership support. As CityBook gathered press coverage and good reviews, leadership invested more. A quiet launch became a public one, with a marketing campaign and more resources.
• Raising standards in person. When content quality dipped as we scaled, I ran workshops with the colleagues submitting places. It lifted their enthusiasm for the project, and the standard of their work.

The outcome

Adoption

Around 10,000 new sign-ups a month

Retention

78%

User testing

69 sessions in one year

Cities

8

CityBook was always an experiment: a way for Booking.com to learn quickly. The app itself didn’t continue, but the work did.

• The taxonomy I created was adopted across the company as Booking.com’s foundation for describing the world of travel.
• The content management system and back office we built continued in use.
• The components we introduced fed into a company-wide design system.
• The team grew from 5 to 26, and its work led to four product teams, continuing the machine learning and taxonomy, content management and design system work.

What didn’t work

A payment flow that was too simple. Booking an attraction took two taps, and the developers had made the back end so fast that it happened instantly. That didn’t delight people. It worried them. Without a processing message, they assumed something had gone wrong and called customer support to check. I fixed it by adding a “processing payment” message and a short loading screen. People were happier when taking their money took a few seconds longer.

Quality under pressure to scale. Every place in Amsterdam was collected with care. As the project grew, speed took priority and later cities got less attention. I refined the guidelines, clarified the quality checks, and ran the workshops described above.