Forum Spaces
Designing and governing a platform of 200+ live global initiative sites
World Economic Forum | Internal SaaS platform | 2023 – present
Forum Spaces began as a bet: that World Economic Forum initiatives could run their own public presence (reports, case studies, events, member communities) without an agency, without engineering time, and without breaking the institution's brand or governance rules.
The bet paid off. Two pilots became more than 200 live spaces, and the platform became the default digital operating system for initiatives across WEF.
I joined in 2023, during the phase where it had to prove it could scale. I now lead Forum Spaces design strategy alone. Which means the question I work on is no longer whether the platform can grow.
It's whether a system this large can stay credible, stay on-brand, and still let each initiative sound like itself.
What Forum Spaces is
The Forum runs hundreds of initiatives such as coalitions on plastics, initiatives on ocean health, quantum economy, clean mobility, AI governance, regional innovation centres and much more. Each produces research, convenes members, runs multi-year programmes, and needs somewhere public to live between the moments when the world is paying attention.
Forum Spaces gives them that home: a public site, a member community, event and knowledge publishing tools, built in a no-code editor with Salesforce as the back end. Access runs in tiers — public, followers, members — so an initiative can be open to the world and closed to its community in the same space.
My role
Design Strategist for Forum Spaces
Design discovery and information architecture: requirements research with initiative teams, translated into site structure, navigation and tiers of access
Content strategy and UX writing: narrative structure, page copy, calls to action
Prototyping: working mockups built directly in the platform's site editor, with real content
Design QA: pre-publication review against accessibility, usability, brand and governance standards
Governance and design operations: platform-wide auditing, intake process, documentation
The problem
The platform was designed to make launching easy and it succeeded. What it needed next was a system it didn't yet have: one for what happens after 200 initiatives have launched.
Consistency starts working against character. Templates are what made scale possible. They're also what makes an arts programme look like a trade initiative.
Precedent travels faster than guidance. Teams look at what's already live to work out what's possible, and whatever gets built first tends to get built again.
And there's one design strategist. Every discovery call, mockup, review and revamp across the live estate runs through one person. Anything that doesn't scale with that constraint doesn't happen.
The work is two things at once: building and improving the platform, and keeping it from losing the quality that made it worth building in the first place.
The work: a discovery call
Every space starts with a thirty-to-forty-five minute conversation. The initiative manager arrives with a launch date already in mind, content in a deck or a one-pager, and a mental model of a website. What they're getting is a governed node in an institutional system: Salesforce records, tiers of access, legal constraints on data and imagery, and content someone will have to keep current long after launch.
My job in that call is to close the gap between those two things without losing the person. That means checking the foundation before designing anything, converting constraints into design decisions and protecting the story which is the part the platform can't template: how you tell the public about an invitation-only event, or how an arts programme reads as itself inside an economics institution.
Most needs can be met with what the platform already does. When they can't, and the initiative is significant enough to justify it, I take the requirement to the product team and we build the feature designed from the start to be reusable, so the next initiative with the same problem finds it already there.
Four discovery calls, anonymised. In each, the initiative arrived asking for one thing and left with something smaller and more durable: a landing page instead of a new space, a story about a roadmap instead of an event invitation, four pages instead of eight. Where the same problem turned up twice, the fix went into the process rather than the project.
Three decisions
1. The process is part of the product
Design was absorbing problems that belonged upstream. Calls spent establishing back-end fundamentals, content arriving in fragments, scope agreed verbally and remembered differently. With one strategist, that's the difference between delivering and drowning.
So I moved two things earlier. A Content Brief that settles scope before design starts, with the handover email that carries it. And pre-discovery as a hard gate, run with the engagement team, which resolves governance and tier of access before anything reaches design — and answers the question nobody was asking: does this initiative need a Forum Space at all? Sometimes the honest answer is a single landing page, and building less is the right outcome.
The Content Brief is now standard practice across the team. It documents scope, speeds up delivery, and holds up as volume grows. The internal process was rebuilt around it, and alignment between engagement, design and the initiative improved as a result.
2. Content and narrative are the deliverable, not only the layout
The builder produces consistent pages whatever you put in them. Teams assumed the design was the site and treated copy as something to fix later. At scale, that's how 200 spaces end up sounding identical.
So content structure became the centre of discovery. Mission statement, focus areas, what belongs on a homepage versus buried in About, how much a page can carry before it stops being scannable. Where an initiative has a distinct identity, I look for it in what they already own rather than sourcing something generic. One space uses the hero image the team had been using across their own decks for a year.
The trade-off: discovery takes longer, and it puts me in editorial territory that isn't formally in my remit.
3. Governance is a design surface, not only a compliance exercise
The obvious response to inconsistent quality across 200 spaces is a compliance review: check every space, list the gaps, send it to the teams responsible. That work has to happen: spaces that don't meet the guidelines get updated, and that isn't optional.
But a review that only tells teams what they did wrong finds the same problems again six months later. So I audited 180+ live spaces and wrote it up twice from one body of evidence. For the initiative teams: what needs updating in their space, and why. For product managers, marketing and engagement leads: the patterns underneath the fixes, where the interface pushes people into bad decisions, what teams keep redoing by hand, which guardrails are missing. Asset governance, UI fixes, access controls, collaboration tooling, onboarding.
The trade-off: two audiences means two documents and a lot more work than a list of what's non-compliant, and the product side of it depends entirely on other teams choosing to act. But a fix applied to one space corrects one space. A fix applied to the platform stops the problem recurring across the next two hundred.
Impact
The platform: 200+ initiatives live, from two pilots. 10M page visits, 3.8M unique visitors, 18K sign-ups, 30M search impressions.
Most recent full year of growth: 4.2M page visits (+31%), 1.8M unique visitors (+33%), 8,400 sign-ups (+35%).
My part in it: on the platform since 2023 and leading design strategy since May 2026. Over 110 design discovery calls, across health, climate, trade, finance, technology, culture and regional centres. Design review before every publication. Ongoing point of contact for revamps, edits, maintenance and governance compliance across the live estate.
What the maintenance taught me
Handover isn't the end of the relationship. I'm the contact point for every revamp, edit and compliance question after launch, which means I see the same failures repeatedly. The same widgets misused. The same content going stale. The same guardrail missing. No individual project reveals that. Two hundred do.
That's where the audit came from, and why it reads as a roadmap rather than a report. The lifecycle is the loop: discovery, build, handover, maintenance, what maintenance teaches, product improvements, better discovery.
What I'd do differently
That loop runs entirely through one person. It works, and it doesn't scale past the capacity of whoever is holding it. Nothing about it is documented in a form someone else could pick up.
Making it a system rather than a habit is what I've been working on since: structured intake, automation of the repetitive parts, and a way for patterns from live spaces to reach the roadmap without depending on me noticing them.
What this work is really about
A template is a form of institutional voice.
When 200 initiatives publish through one system, design decides something on all of their behalf: how formal they sound, how much personality they can carry, what counts as a credible way to present serious work. Nobody sets out to make that decision. It arrives as a side effect of building something consistent.
Consistency is usually right. It's what makes an institution legible, and legibility is most of what makes it trustworthy. Protecting that is a large part of my job. But every team arrives with something particular, and the template can't hold all of it. An arts programme wants to look like an arts programme. A technical initiative wants its data to lead.
Deciding which of those is worth accommodating is judgement, and most of the rest is translation: someone describes what they want their initiative to be, and I work out what that means structurally and what the platform can actually deliver. What one team is asking for has usually been asked before by someone who doesn't know they have the same problem. A good part of the work is noticing that, and knowing who needs to be in the room before anything gets built.
I came to design through journalism and culture studies, which is probably why I read a template as an editorial position rather than a set of components. Every structural decision is also a decision about voice.
Screenshots and examples are limited to public outputs and redacted visuals. The platform is internal, so the work itself — mockups, audits, documentation — isn't shown here. Happy to talk through it.
