Purpose of this ticket

The reader experience team is planning to roll out the ReadingList feature to all account holding users in early July 2026. This ticket is to align on an approach for introducing Reading Lists on the web alongside Watchlists before the release timeline.

Background

The Reading List feature aims to provide a lightweight and intuitive way for readers to collect and return to content they saved for reading or referencing later on web. The solution for introducing reading lists must coexist with the existing Watchlist functionality, which serves a different but important audience with established usage patterns.

This ticket documents the existing challenges, design explorations, community feedback, and presents various ideas related to introducing a Reading List feature alongside the current Watchlist functionality.

Reading list is currently in beta and the goal is to align on an approach we can use to to scale Reading List to everyone.

Problem statement

How might we introduce a Reading List feature for all users on Wikipedia in a way that is easy for readers to discover and understand the functionality, while ensuring the existing Watchlist functionality remains easily accessible for users who depend on it.

Key challenges

1. Iconography

• The current Watchlist star icon is interpreted by users as a “favorite” or “save for later” action rather than its intended purpose of monitoring article changes. Reference study
• In a recent new editor research a participant also commented on how icons (such as bookmark/heart/star) connoted different things and the watchlist one was confusing in that they'd only want to add the favorite/most important articles for a star menu.
• Because of that confusion, a Bookmark icon (for adding to reading list) and Star icon (for adding to watchlist) placed side-by-side can create cognitive overload or ambiguity for the users. Especially readers and new editors would struggle to distinguish between the two functionalities.
  
  
  

2. Limited interface space

• Space constraints, especially on mobile web, significantly limit how many actions can be surfaced directly in the article toolbar and header.
• Even if icon confusion is successfully addressed, both “bookmark” and “watch” compete for highly valuable UI real estate above the article. This creates difficult prioritization decisions around:
  • Which action should remain directly visible in the action bar or in the header
  • Which feature should move into the overflow menu
  • How discoverable each feature remains after de-prioritization
• As a result, surfacing one feature more prominently may require the other to become less immediately accessible, potentially impacting the feature discoverability.
  
  
  

Direction proposed originally

Readers

Users with 0 edits and 0 articles on watchlist see Save/Bookmark as a primary action both above article and in the header. Watch actions are moved to the overflow menu. This would result in all the new accounts to be opted into this version.

Editors

Users with >0 edits and >0 articles on watchlist continue to see the Watch function but have access to Save/Readinglist in the overflow menu.

Preference

A potential preference to switch the spots for users who may want to use other options more than the defaults.

Concerns with above direction

Reader -> Editor path

• A key concern raised by the community is the importance of the reader → new editor funnel. There is a concern that moving Watchlist functionality into the overflow menu could reduce discoverability for users transitioning from reading to editing, making contributor workflows harder to find and adopt.

• We are currently exploring how much of a role watch functionality plays in the reader → newcomer editor journey. Our assumption was that while watch functionality is useful for established editors and moderators who already understand the value of contributing, it is unclear whether discovering watch functionality actually drives readers to become editors. We need more research to understand this area.
• We also looked at recent usage data of the Watchstar button, and we noticed that while editors with more than 100+ edits have the highest usage rate, new users with 0 edits are also using it at a higher rate than novice editors. This may suggest that newcomers are treating the Watchstar as a way to favourite articles instead of the intended Watch functionality.

Preferences

• Another concern raised was around using Preferences as a way to let users customize or swap feature placement. While this could provide flexibility, Preferences are often difficult to discover and may be inaccessible or overly cumbersome for many users.

• We agree with this concern and that relying on Preferences to resolve core UX conflicts is not considered a scalable or sustainable solution, particularly as similar feature placement and prioritization challenges may continue to emerge in the future.

Revised proposal

Desktop

Given that:

• the community feels strongly about making the Watchlist easily discoverable by potential editors and new account holders
• many community members are eager to try Reading Lists alongside their existing contributor-focused tools

...we are exploring a proposal that allows Reading Lists and Watchlists to coexist on Desktop in a way that minimizes confusion.

In this proposal, both Reading Lists and Watchlists would remain consistently visible and accessible to all users on Desktop, rather than prioritizing one experience over the other. This approach ensures that neither workflow becomes hidden or difficult to discover on Desktop, while also supporting users who may rely on both simultaneously.

• Adding a label to star adds clarity to what it means, as star is often confused with favouriting.
• Allows us to keep using star as an icon for watch functionality, as editors are familiar with its various states (empty, partially-filled, filled in.)
• Making it look like a link button ensures that editing features such as “Watch”, “Edit”, “View history” are visually grouped together.
• This approach would make having both lists accessible from the header a natural choice. Note: The current icon used for accessing Reading Lists is temporary. If this direction moves forward, we will further explore a more suitable icon. The icon for accessing "Saved pages" has been updated in the mock above to differentiate it from Watchlist.
• This also allows for a consistent experience between Article page and Talk page where Watch is always available in the same location.

Mobile

Mobile phones face space constraints, and showing both Watch and Save actions prominently would either require replacing an existing action or overcrowding the interface with an additional icon.

• We also do not recommend introducing both actions as unlabeled icons, as this could create considerable confusion for users.
• Usage data suggests that many users with 0 or fewer edits are using watchstar and watchlist on Minerva, indicating that Watch functionality on mobile might be used by some users as favouriting an article already.
• Based on this assumption, we propose surfacing the Save action on article pages, while placing Watch within the overflow menu on mobile.

Talk page on mobile:

• To maintain consistency and reduce confusion for newer editors, we also recommend keeping Watch in the same location across different views, by surfacing it in the overflow menu on Talk pages as well.
• We also propose moving the Subscribe action onto the page itself in place of star, positioning it as a more lightweight and approachable way for readers to engage with discussions, thereby creating more approachable pathways for readers to engage behind the scenes and become editors.

Tablet

Next steps

Review the revised proposals with stakeholders and community, and use this ticket as a space for constructive feedback and discussion.

For the revised proposal we’re specifically looking for feedback on:

• The proposed visual treatment for Watch on Desktop
• If the placement of Watchstar within the overflow menu across all views is acceptable.
• What are the thoughts of moving Subscribe above the article on Talk pages. [Please refer to the design rational mentioned in the revised proposal]

Also feel free to share other ideas not already explored here and which addresses the challenges mentioned earlier.

---

Appendix:

Other ideas explored that were not pursued due to a number of challenges:

• Progressive introduction to features based on user behaviours/signals
• Unified "Add" action with separate lists
• Single unified list
• Icon changes

Read more about the above ideas in this comment