Page MenuHomePhabricator

Research & Design: Improve Tone Suggested Edit (WE1.1, FY25-26)
Closed, ResolvedPublic

Description

User story & summary:

As a newcomer to Wikipedia, I want to receive suggestions that help me identify and improve non-neutral language in articles so that I can make constructive contributions that align with Wikipedia’s MOS, encyclopedic tone, and neutrality standards.

Guiding Key Result: WE1.1: Increase constructive edits (edits that are not reverted within 48 hours of being published) for editors with less than 100 cumulative edits.

Dependency: T392283: Q1 FY2025-26 Goal: Apply the Tone Check model to published articles, to learn whether we can build a pool of high-quality structured tasks for new editors

Project description:

This project aims to support newcomers by introducing a Suggested Edit that focuses on identifying and improving non-neutral language in articles. Specifically, it will highlight sentences that contain peacock terms, puffery, promotional language, or other wording that conflicts with Wikipedia’s policies on neutrality and encyclopedic tone.
Powered by the Machine Learning “Tone” model (formerly called the “Peacock” model), with UX that builds upon the Edit Check UI, this Suggested Edit will highlight instances of biased language and offer in-context guidance to help users rewrite a sentence in a more encyclopedic tone. The goal is to encourage constructive, policy-aligned contributions while helping newcomers build confidence and awareness of core content standards.
This work builds on the Growth team’s broader strategy to lower barriers to editing through Structured Tasks. In Q1, we aim to release a beta version to lay the groundwork for future experiments evaluating the task’s impact on newcomer contributions and the scalability of Edit Check as a foundation for Suggested Edits.

Project-level Hypothesis:

If we provide newer editors with a Suggested Edit that highlight instances of non-neutral language or improper tone, and offer built-in guidance to rewrite with a more encyclopedic tone, then newer editors will be more likely to make constructive contributions that align with Wikipedia’s policies, while building confidence and awareness of core content standards.​​

Background & research:

Writing in a neutral tone is a pillar of Wikipedia. Writing in a neutral tone is also a practice many new volunteers find to be unintuitive. An October 2024 analysis of the new content edits newer volunteers published to English Wikipedia found:

  • 56% of the new content edits newer volunteers published contained peacock words.
  • 22% of the new content edits newer volunteers published that contained peacock words were reverted

New content edits containing peacock words were 46.7% more likely to be reverted than new content edits without peacock words
Edit_check/Tone_Check#Background

Suggested Edits help new account holders get started editing:

Questions:
  • How can we extend the existing Edit Check UI so that this Suggested Edit feels cohesive with the Visual Editor experience and visually consistent with the Edit Check feature set?
  • What UX patterns can help ensure that the “Improve Tone” suggestion is clearly understood by newcomers as a proactive, constructive editing opportunity rather than a warning or error?
  • How might we balance clarity and guidance with simplicity, to avoid overwhelming new editors while still helping them learn Wikipedia’s tone and neutrality standards?
  • What design elements (icons, labels, in-context prompts) can reinforce that this is a Suggested Edit supported by a LLM and the suggestion may be incorrect.
Acceptance criteria
  • Conduct initial desk research and heuristic review to inform the design strategy, including a review of how tone-related guidance is handled in other writing tools or platforms.
  • Collaborate with the Editing Team to co-develop initial design concepts for a simple user flow that evolves the current Edit Check UI into a proactive Suggested Edit experience.
  • Ensure the proposed designs align with existing design systems and accessibility standards used across Visual Editor and Structured Tasks.
  • Publish early design concepts on Wikimedia Commons to enable discussion with pilot wikis and experienced editors, facilitating early feedback and iteration.
  • Create clickable or interactive prototypes to support usability testing with newcomers and experienced contributors.
  • Incorporate feedback from design reviews, Growth team discussions, community input, and user testing to refine the concepts for an initial beta implementation.

Event Timeline

KStoller-WMF lowered the priority of this task from High to Medium.
AAlhazwani-WMF changed the task status from Open to In Progress.Aug 11 2025, 12:49 PM
AAlhazwani-WMF added a subscriber: dchen.

sharing some updates afte the first few weeks of work:

  • Conduct initial desk research and heuristic review to inform the design strategy, including a review of how tone-related guidance is handled in other writing tools or platforms.

we've reviewed the existing suggested edits, and the existing guidance systems. we learned how the current easy-medium-hard difficulty framework came to be, and we reviewed past research, eg.

  • Collaborate with the Editing Team to co-develop initial design concepts for a simple user flow that evolves the current Edit Check UI into a proactive Suggested Edit experience.

as we move forward with the designs, we’d like to provide a consistent experience from when newcomers open their homepage and/or suggested edits to what they will experience in VE with edit checks.

to achieve this, we've invited the editing team to share their feedback on our first flow proposal (internal google doc link)

  • Ensure the proposed designs align with existing design systems and accessibility standards used across Visual Editor and Structured Tasks.

our overall design approach has been to curate an experience that relies as much as possible on existing (growth) components, patterns, and flows + the existing (editing/edit check) components, patterns, and flows.

  • Publish early design concepts on Wikimedia Commons to enable discussion with pilot wikis and experienced editors, facilitating early feedback and iteration.

we shared a (figma) prototype with movement communications specialist, and growth/editing product ambassadors to prompt feedback.

  • Create clickable or interactive prototypes to support usability testing with newcomers and experienced contributors.

we've built a first prototype (figma link) where we experimented with different flows, copy, and guidance solutions.

we started to work on a usability protocol with the support of @dchen (internal google doc link)

  • Incorporate feedback from design reviews, Growth team discussions, community input, and user testing to refine the concepts for an initial beta implementation.

we started to popularize early ideas within the design group (during design reviews), the growth team (on slack, and in a 1:1 with the tech lead). next up is a round of usability test and/or community discussions.

@AAlhazwani-WMF from my perspective you've completed all of the associated acceptance criteria outlined in this task. I'm sure design and UX questions will emerge as we complete the remaining engineering tasks, but I think it makes sense to answer those in the related tasks rather than in this "epic"-sized design task.

Let's mark this task as resolved, and we can always open smaller tasks if specific design work or requests emerge.