The Readers teams are planning to test out some ideas to see whether they would be helpful to readers on Wikipedia. We’re focusing on two broad areas:

1. Showing newer readers that Wikipedia is useful, accessible, and enjoyable
2. Supporting existing readers in deeper engagement and ways to begin contributing.

For most of our history, we didn’t have to worry about attracting readers. People searched for something, landed on Wikipedia, and some became editors. But with the rise of AI chatbots and social media, the way people search for information is changing, and this influx of traffic to our projects is no longer guaranteed.

We’re seeing the effects of this now, with the percentage of the world that uses Wikipedia decreasing – ultimately leading to a stark drop in the number of accounts created and new editors contributing.

By encouraging closer connection to Wikipedia for both new and existing readers, we are working towards our mission of bringing knowledge to more people worldwide, while also bringing in tomorrow’s editors and contributors.

The way people learn online looks different today than it did 25 years ago. Today’s readers balance text with images and multimedia on the platforms they use, and increasingly turn to options that offer personalization and curation.

We want to experiment with ways to support these reading styles and habits, while maintaining the core values of the Wikipedia experience.

A growing need for experimentation

To meet the needs of a rapidly evolving and diverse global audience while retaining the quality of our content and happiness of our communities, we are shifting our experimentation approach to be more lightweight, iterative, and adaptive.

Over the years, much of our work has come from direct community requests, industry best practices, and high-confidence internal ideas. But in today’s context of rapid change, we need to instead embrace experimentation, specifically:

• Remaining open to creative ideas and having the ability to quickly try them out
• Being comfortable with accepting any results, whether indicating they were good or bad ideas
• Learning from data to decide whether to scrap, adapt, or implement findings

Before, we committed more time into features upfront, and only showed them to users when we had a medium to high level of confidence. Often these features were too big to fail and it would be difficult to change paths even when concerns were flagged.

We sought community feedback too late in the process, making it harder for communities to shape the future of a project.

We want to change the way we experiment to test sooner, and discuss sooner, allowing communities to actively influence features from the beginning.

The cycle below describes our plan for approaching this experimental work.

Not every idea becomes a feature and we will try many ideas which will fail.

If an experiment shows problems – maybe it’s not useful to readers, burdens editor workflows, or cannot be built equitably across all Wikipedias – a project will not be released.

Stopping is an expected and valuable outcome of this process that allows us to learn and improve for future experiments.

We will document our experimentation extensively, including and especially those ideas that fail.

Communicating experiments

In the summer of 2025, we held a series of discussions with PTAC about how we can improve our communication and center community feedback earlier in our process.

They published these recommendations.

We will use these recommendations as the basis of how we build, discuss, and communicate experiments together. Specifically, we want to focus on:

• Frequent conversations: We’ll continue to have discussions on-wiki, but increase their frequency and add more additional discussions on other channels like Discord, Telegram groups, at community events, etc.
• Discussions before experimentation begins: We will come to you for input before starting to run any experiments.
• Central overview of experimentation: We’ve put together this page for experiments currently for Readers.
• Definition of labeled phases: We’ve put together this page which marks the different phases of an experiment, including the moments when we decide if an idea should be continued, or paused.
• Better prepared feedback sections: We’ll ask specific questions for input on areas we need feedback on.
• Inspiration from community ideas and the wishlist: We will review community requests and wishlist ideas during the problem identification part of our experiment cycle.

Phase 0: Problems

Here, we identify what Readers are struggling with right now.

• Collect qualitative and quantitative feedback from readers and communities on a regular basis through user research, metrics, external trends.
• Use this data to identify the problem we need to solve. What? For whom? How long? Why?

Phase 1: Experiment

1.1 Hypothesis on how we can help with the problem

In this stage, we try to come up with ideas for how we can help with the identified problem.

• Brainstorm solutions, discuss with communities, review user research, and come up with candidate ideas that could address the problem we identified in Phase 0
• Create a set of hypotheses for how these ideas could solve the problem
• Create some early designs and discuss with communities

1.2 Build a prototype

At this stage, we go from one problem with multiple ideas for solutions to a specific solution "idea".

• Create a lightweight version of the concept (just enough to test with readers and get useful data).
• Make it clear what the prototype can and can’t do. Many times, prototypes might take shortcuts which would not be acceptable in a full feature.

1.3 Run experiment

Here, we gather data to see if our idea is any good.

• Run the experiment (A/B test) with a small subset of readers on wiki on various projects
  • Currently, experiments run on up to 10% of all logged-out readers on a given project (with the exception of English Wikipedia, where we focus on 0.1% of readers). For logged-in users, we can test with more users.
• Collect data, evaluate the hypothesis, and discuss the results with communities
  • Was the hypothesis supported? Do communities see value in this feature for readers?
    • ✅ If yes → continue
    • ❌ If no → stop the project and document what we learned. Return back to phase 1 to evaluate other possible solutions to the problem.

Phase 2: Build

2.1 Build a production version

Here, we take our early prototype and build it for real.

• Discuss experiment results with communities. Identify any feature changes needed based on community feedback.
• Build the feature up to a quality appropriate for everyday use.

2.2 Release

Here, we deploy the new idea to a full wiki, or to all wikis for the first time.

• Release to interested communities first.
• Monitor and discuss.
• If all goes well, release to everyone.

Phase 3

3.1 Measure and iterate again

Here, we take what we’ve learned from how people use our new feature, and change the parts that are not working well.

• Track how the features are used in practice
• Receive feedback from communities on long-term use
• Continue improving based on feedback