Admin/Moderator interview guide

[mattly]

When I interview people for the purpose of building tools to help their work, I am typically trying to learn five things:

1. What is their mental model for approaching their work?
2. What parts of their domain data are vitally important to performing that work?
3. What are the operational contexts in which they're performing their work?
4. What does and does not work about their current toolset for performing their work?
5. What are the potential consequences of their actions they are trying to understand?

The latter two questions are I feel fairly direct and straightforward; at least when I am talking to professionals, they're often able to articulate answers with a minimum of coaxing and it's possible to learn a lot without dancing around the point.

The first three questions tend to be the opposite. Few people are introspective enough to be able to give straightforward answers to these questions without a lot of coaxing and guidance.

• Understanding someone's mental model is the most crucial part of technical UI design work, yet it is very rare to find someone who can describe their own mental model sufficiently. Everyone approaches their work differently, but it's important to understand how individual people think about the things they need to accomplish, to get multiple perspectives on this. I've talked to people who've worked together for years who had no idea they each approached their work in radically opposite ways.
• Domain data semantics is a hard one because it suffers from the "what everyone knows" problem; You're trying to find the sorts of things the people you're talking to all know and know that each other knows, and therefore assume that anyone who has to deal with their problem must know, because of course they do. You're looking for the sort of knowledge that someone onboarding to a software engineering project finds missing from the documentation: it's missing from the documentation because the knowledge is taken for granted.
• Operational contexts is a hard one because humans have selective memories. If I ask the typical software engineer to describe their operational environment for deploying code, they'd probably describe the typical case of a mid-day weekday and all normal processes that are designed to keep things running smoothly. What they probably won't describe without some prompting are the product launch all-nighters, the Friday afternoon hotfixes, the Sunday morning 0-day patching, and yet these are just as important to know about as the normal case. Stress increases the need for mistake-proofing.

I don't have a template for these sorts of interviews: my approach as someone with ADHD is to a) be present, and b) to improvise. Everyone is different; they think about their work differently, they'll have different ideas about what's important, what's easy or not, weigh consequences differently, and even use different domain language to talk about their work. Additionally, the more distant someone is from the front-line of the work, the less they typically understand the nuances of the problems involved or the potential for consequences from a mistake to create catastrophe, but sometimes the opposite is true: a manager might have a much deeper understanding of the consequences of mistakes than any of the front-line workers.

Generally my approach is to start by asking them to describe their typical work session. In our case, this is, it's time to do some moderation work. How do they know this needs to be done? What are they thinking about in the space between "oh it's time to put on the moderator hat" and finding out why they need to? If there are multiple things to do, how do they decide what to do first? How do they evaluate claims, make decisions? There will typically be a lot of opportunity to sidestep into particulars. This is also a good point to find out what's frustrating about the workflow, what works well, and hopefully ask about how they know if they've made a good decision.

After this initial pass, and particularly as I proceed through talking with multiple people, I'll typically ask what advice they might give someone new to doing this type of work: what are the important things to watch out for, what are the places they need to be extra careful? As I learn more about the domain from previous conversations, I'll sometimes propose a scenario and potential approach to later participants – this is partly to calibrate how well my understanding is coming along, but also partly to see how their approaches differ. Mostly this is to learn about their mental models and attempt to break into the unspoken assumptions about domain data.

I'll typically close by describing some approaches to problems I've been thinking about and ask for their feedback. In this case, I might mention that I've been thinking about improving the defederation interface, you enter an instance's url and it tells you how many people this would impact: how many people on your instance would be impacted? How many people on the target instance do people on your instance interact with? I might show them a sketch or mockup of such an interface – this is less about validating the idea and more about listening to their response. What does this idea bring up for them? It's another good opportunity to calibrate my understanding of the problem so far and discover the unspoken domain data assumptions.

[jenniferplusplus]

This is great, I think this is exactly the kind of thing I was hoping for.

I wanted to go into the interviews and recruiting with some common understanding of what questions we're trying to answer with the research, and how we would find those answers. And also, at least for myself, some specific strategies that are worth pursuing during the interviews.

[mattly]

Here are some high-level questions I'm hoping we can answer through this research:

• What additional context can we help bring in for individual moderation actions? What's essential context versus what can/should be easy to reach? In short, how can we make it so no one ever has to connect to the database and ask questions via SQL? Are there things we can try to pull in from other instances via their APIs?

• What long-term context can we help preserve across moderation actions for the long term? Mastodon has notes, and while I'm not entirely sure what all you can attach notes to, would formalizing certain things into enums/flags such as this user is often targeted for hate be useful? Is there a need to go beyond "notes" in providing formalized context that can be understood at a glance, instead of reading through text?

• What sort of automated systems can we help setup for proactive, low-hanging fruit? For example, disallowing signups based on patterns in usernames, ignoring reports from user accounts with no visible history, anything you might otherwise think "I could do this with a shell script but it's a PITA".

• What are some specific things we can do to help admins coordinate moderation decisions across instances, and what would implementing that safely look like? What prior art exists in this area? Is there an opportunity to define standards to help these efforts across other instance software such as gotosocial? Like, having a way to coordinate / subscribe to blocklists, but also allow your instance to define overrides or whatnot to ensure certain things never break, or reviewing incoming changes from a subscribed resource and accepting/rejecting individual parts.

• How much mistake-proofing and/or auditing are we going to need to bundle in to specific things? What can't be "undone" because it interacts with the outside world? What actions are moderators most afraid of messing up and losing trust or regretting?

• How can we present lists of things for review in a way that lightens the load a bit? Are there ways to determine what needs the most attention or has higher severity? For example, would it be helpful to group open reports in the list by reporter/reportee?

I'm thinking about more specific questions to ask that will help get at these topics, and will post them separately.

[jenniferplusplus]

This seems great!

One thing I've considered a few times is whether reports are actually the correct abstraction to center for moderator actions. Does it make more sense to organize around something like cases? Something that can encapsulate reports, involved parties, notes, actions taken, and maybe other things? (Are there other things? Is that the right set of nouns?) How often would that framework be more effort than it's worth?

[mattly]

Does it make more sense to organize around something like cases? Something that can encapsulate reports, involved parties, notes, actions taken, and maybe other things?

I like this; it occurs to me as a natural abstraction, one that could be made mostly invisible, would allow for easier linking/cross-referencing between cases and their subject matter (users, notes, etc) and could become polymorphic to encompass thing initiated by items other than reports.

[mattly]

Here are some questions I think would be good to ask moderators in an interview:

• how do you know when it's time to put on the moderator hat?
• what does your typical session of doing moderation work look like?
• how do you prioritize moderation work when there's a lot of stuff to handle?
• what aspects of doing this work do you find most frustrating? do you have any ideas on what could make those things less frustrating?
• what works well about the tools that the mastodon UI provides?
• how do you evaluate the context surrounding something that needs attention? Can you describe your research & decision-making process?
• what kinds of mistakes are you most afraid of making?
• have you taken actions in your role that have been cause for remorse? Can you talk about the circumstances and situations that led to those happening?
• in more complex moderation actions, how do you evaluate if you've made a good decision?
• if you had to hand over your role for a week to a trusted friend, what are the important things you'd make sure they knew before handing over?
• what parts of moderation work could you solve with a script, were it easy to do so?
• what are your hesitations about automatically pulling in programatic behavior from shared moderation resources such as blocklists or bad instances? What safeguards would you want on such a thing?
• have you ever had to deal with recurring issues around a single account (either on your instance or elsewhere) or instance? How do you handle maintaining knowledge about vulnerable or problematic users?

[mattly]

a few more questions for the research findings after today's first (wildly successful) interview:

• Where is the line between retaining materials used for context (bad posts that get deleted) vs not retaining illegal content? Are there things we can do give moderators reasons for why something wasn't kept? Are there heuristics for retaining material vs purging it?
• What are the limits of ActivityPub vs Mastodon for certain things, such as context for "followers only" replies or the like?
• What are the important actionable things we can put in a "dashboard" context? How much customizability should we allow or plan for?
• What types of inter-mod communications does it make sense to facilitate in the app? Does this require any sort of separate "inbox"/notification system for the privileged user?
• How will the tooling need to change as instance grows?

[jenniferplusplus]

And another I'd like to explore:

• Do you think about different kinds of bad behavior differently, and do you have different policies or approaches for them? For example, do you approach bigotry the same way as jerks who make everyone's experience worse? Do you handle illegal content the same way as spam?