Copy-paste beats CSV
When you build a tool where admins enter a list of blocked keywords, the obvious input method is CSV upload. Admins live in spreadsheets. They have their block lists in Excel already. Let them upload the file, done. That was my first instinct, and it was wrong, and figuring out why it was wrong is one of the decisions I'm most sure about from the whole moderation project.
The obvious feature
Context first. This is the content moderation tool Wayground built so conservative districts would stop blocking us at the firewall. Admins block content by keyword; teachers can still see what's hidden and request access. It replaced the "kill the whole library" solution Sales wanted, and the entire value of it rests on being granular — blocking a little, preserving most of the library.
For the keyword-entry piece, CSV upload is the clean answer on a whiteboard. It's fast, it's familiar, it matches how admins already store their lists, it scales to any size. If you were grading the feature on input ergonomics alone, CSV wins every category. So we scoped it, and then we went and talked to admins before building it.
They told us the thing that killed it: they had 1,000+ keywords ready to paste in. Not fifty. Not a curated list of genuinely sensitive terms. Over a thousand, and they'd upload all of them without a second thought if we gave them a file picker.
The number was the problem, not the ergonomics
Here's the part that flipped my thinking. The problem was never "how do admins get their keywords in." The problem was "how many keywords should exist at all," and CSV upload quietly answered that question the worst possible way.
Every blocked keyword is a term the system has to account for in search and recommendations. Block enough of them and you've degraded search quality — for everyone, teachers included — because now the engine is routing around a giant exclusion list. A thousand-keyword block list doesn't just hide a thousand terms. It warps discovery across the whole product. And the admin who pasted that list has no idea they did it, because from their seat they just uploaded a file and moved on. The cost lands on teachers searching for resources, who get worse results for reasons no one can see.
CSV upload is frictionless at exactly the wrong scale. It makes dumping 1,000 keywords precisely as easy as entering 10. It removes every natural check on volume. The ergonomic win and the product risk are the same property — how effortlessly it scales — pointing in opposite directions.
So we made them do it by hand
We cut CSV upload. Admins copy-paste from their spreadsheet or type keywords in manually. It's more annoying. That's the feature.
Manual entry and copy-paste put a soft ceiling on volume. Not a hard cap — I didn't want to invent an arbitrary limit and defend "why 200 and not 250." I wanted the effort to scale with the volume, so that blocking 1,000 keywords felt like the thousand-keyword decision it actually is, while blocking the 20 you genuinely care about stayed easy. Friction as a governor: cheap when you're using the tool as intended, increasingly costly as you approach the behavior that quietly wrecks search.
The admins who need this feature almost never need a thousand keywords. They need the handful of terms driving their district's firewall block. The 1,000-keyword admin was pattern-matching — "I have a big spreadsheet, I'll dump the big spreadsheet" — not actually reasoning about what each keyword costs. Making them paste or type is enough friction to interrupt the dump and turn it back into a series of choices. The friction here was the manual entry itself; we didn't lean on an explicit counter or warning, just the plain fact that a thousand terms take a thousand terms' worth of effort to put in.
Capping the admin to protect the teacher
The through-line for the whole moderation tool was: give admins real control without destroying teacher value. It's easy to think of that as a content fight — which resources stay, which get hidden. But it also showed up as an infrastructure decision nobody would put in a case study headline. Search quality is teacher value. A teacher who can't find good resources has lost the library just as surely as if you'd blocked it.
So capping admin power here wasn't about distrusting admins. It was about protecting a shared resource — search and recommendations — from being casually degraded by one well-meaning person with a big spreadsheet and a frictionless upload button. The admin optimizes for their district's political cover. The search index is a commons that every teacher draws on. CSV upload let one party quietly tax the other. Copy-paste keeps the cost of over-blocking visible and personal to the person choosing to over-block.
What I took from it
The best input method on paper was the worst one for the product, and the reason is a principle I keep coming back to: when a feature's convenience scales faster than its consequences, the convenience is the bug. CSV made 1,000 keywords as easy as 10 while making 1,000 keywords far more damaging than 10. That mismatch is the tell.
Sometimes the pro-user move is to not build the smooth thing — to leave in enough friction that the expensive action feels expensive. Copy-paste beats CSV not because it's better UX in isolation. It's worse UX in isolation. It's better product, because it puts a governor on the one behavior that would have quietly degraded the experience for the people the whole tool was supposed to protect.
This decision comes from the Wayground content moderation work.