Système de signalement d’incidents/Résumé des tests utilisateur du produit minimum viable

Le Système de signalement d’incidents (SSI) vise à rendre plus facile le fait des signaler des violences sans se mettre en danger. C’est une obligation du Code de conduite universel, d’avoir un système de signalement fonctionnel, ainsi qu’une recommandation de la Stratégie du Mouvement.

Plus tôt en 2023, nous avons conduit une étude sur les Wikipédia en indonésien et en coréen pour comprendre le harcèlement, son signalement et le traitement des signalements. En novembre 2023, les contributeurs ont été invités à tester un produit minimum testable (MTP) du Système de signalement d’incidents.

Nous avons désormais une première version du SSI (voir les aperçus des prototypes du MVP plus bas) et nous avons besoin de savoir si nous sommes sur la bonne direction.

Ainsi, en mars 2024, l’équipe Produits pour la confiance et la sécurité a conduit des tests utilisateur du produit minimum viable (MVP) du Incident Reporting System.

Résumé général

“Il y aura toujours des gens sur Internet qui aiment créer des problèmes. Mais s’il existe une manière de les signaler, je crois que c’est une bonne chose.”

Point d’entrée du signalement

Pendant les tests utilisateurs, tous les participants ont trouvé le point d’entrée pour signaler un incident et le parcours utilisateur actuel est bien compris.

Types de signalements

Il y a eu une certaine confusion entre deux possibilités de signalements : « quelqu’un pourrait causer de l’automutilation » et « message public de menace de violence ».

Traitement des signalements et réponses

Deux participant(e)s ont aussi supposé que le système était automatisé. Un ou une participante était gêné par l’automatisation et voulait une réponse humaine, alors que l’autre participant(e) croyait sincèrement que le système vérifiait si l’auteur ou autrice des abus avait déjà commis des violences et supprimait le message agressif en fonction de cela. Tous les participants s’attendaient à une réponse à temps (en moyenne 2–3 jours) après avoir soumis leur signalement.

Objectifs de l’étude

Nous voulions savoir :

1. les utilisateurs savent-ils où aller pour signaler une urgence ?
2. le parcours utilisateur est-il logique et intuitif ?
3. les utilisateurs parviennent-ils à leurs fins sans aide supplémentaire ?
4. quelles attentes les utilisateurs ont-ils quand ils soumettent un signalement ?

Participants et format du test

Un test sans limite fondé sur des tâches utilisant un prototype et un tri par cartes a été conduit sur Userlytics avec les contributeurs des wikis en portugais et en italien.

Participants

• 11 utilisateurs et utilisatrices ont été recrutés.
• Tous les participants étaient des contributeurs actifs (au moins 10 modifications dans les 3 mois).
• Tous les participants avaient interagi avec d’autres sur un wiki.
• 7 participants venaient des wikis en portugais.
• 4 participants venaient des wikis en italien.
• 2 participants n’ont pas pu faire parti de l’évaluation en raison de difficultés techniques.

Tâche et questions

Affichage du prototype	Questions
Capture d’écran d’une page de discussion utilisateur affichant un exemple de message violent.	1. Vous trouvez un message violent sur votre page de discussion, ou celle de quelqu’un d’autre. Que faites-vous dans cette situation ? Qui pourriez-vous contacter pour aider dans ce contexte ? Si vous voyez un message haineux comme dans cet exemple, que feriez-vous ?
Page de discussion utilisateur affichant un exemple de message violent et un menu de signalement.	2. Obtenir de l’aide. Quelles options voyez-vous sur cet écran ? Quelle option va-t-elle vous aider selon vous ? Que pensez-vous qu’il se passe quand vous choisissez cette option ?
Capture d’écran du formulaire de signalement d’incident avec des boutons radio.	3. Signaler un incident. Pouvez-vous nous dire ce que signifie chacune des options ? Quelle option choisirez-vous dans ce cas ?
Capture d’écran du formulaire de signalement d’urgences.	4. Qu’allez-vous signaler ? Quelles informations allez-vous généralement inclure pour signaler ce genre de message haineux ? Qui va être destinataire du signalement selon-vous ? Que ferez-vous ensuite ?
Capture d’écran du message rapportant la réussite de la soumission du signalement.	5. Que se passe-t-il maintenant ? Que s’est-il passé selon vous ? Que va-t-il se passer ensuite selon vous ? Combien de temps pensez-vous que cela prendra ? Comment vous sentez-vous à ce sujet ?

Tri par cartes

We wanted to understand what information and guidance communities need for reporting non-life threatening user behaviour. Participants were presented with a set of cards under the category "User behaviour reporting". Participants were then asked to rank them by importance (1 being most important).

Ranking	Information needed for reporting user behaviour
1. Most important	Instruction on what you should do in this case
2.	Name and contact of the people you can reach out to
3.	Link to pages where you can post about an abuse on your talk page
4.	Guidelines on how to have a discussion with the abuser
5.Least important	Other self help options

Key findings

Summary

• All participants found the entry point for reporting an incident.
• Nearly all participants understood which category to report the incident under.
• Some participants were confused by the categories “someone might cause self-harm” and “public harm threatening message”.
• Some participants said they wouldn’t report minor user behaviour issues.
• For most participants, the ideal time period to receive a response is 2-3 days.The maximum time expected is 1 week and the minimum is within a few hours.
• Most of the participants thought the following would be most important on a community guidance page, when reporting non-life threatening user behaviour:
  1. Instruction on what you should do in this case
  2. Name and contact of the people you can reach out to
• Automation was a theme among two participants. While one participant was concerned about their report not being read by a human, another participant thought an automated system would check if the abuser had any past history of threats and offences, and delete the offensive comment accordingly.

Recommendations

“I'm a little afraid that it will be sent to an automated system and that it won't actually be read by human beings.”

Now

1. Keep the user flow as it is, since all participants understood where to report an incident.
2. Provide more clarity about the categories “someone might cause self-harm” and “public harm threatening message”: either by changing the wording or considering other ways to categorise the types of abuse users want to report.
3. Set expectations that a human will be responding, not an automated system, to alleviate user concerns.

Future ideas

1. Build an intelligent system to reduce the response/action time based on a report.
2. Utilise a ‘user reputation score’ to decide the likelihood of a report being true or false.
3. Use natural language queries from the reporter to identify the best course of action (e.g. “Someone called me a pig on my talk page”, “I see someone outside my door with a baseball bat”...)
4. Allow additional evidence to be added such as images, voice notes etc.
5. A/B test removing an abusive message after it has been reported vs keeping it on the talk page with assurance that it has been reported.