Designing Artist-Friendly Tools
Notes on tool UX for non-technical artists — the difference between a script and a tool.
A script and a tool can do the exact same operation and still be completely different things to the person using them. A script assumes the user knows what it does, when it's safe to run, and what to do if it fails halfway. A tool assumes none of that — and that assumption is the entire job of tool design.
The undo test
The single best predictor of whether artists will actually adopt a batch tool is whether it has a real undo path. Not a warning dialog before running it — an actual, reliable way to revert a batch operation, including one that partially failed. Every tool I've shipped that skipped this got used cautiously, on small selections, "just to be safe." The moment undo landed, usage jumped because artists stopped hedging against the tool being wrong.
Fail with a sentence, not a stack trace
Error messages are part of the UI, not a debugging afterthought. "IndexError: list index out of range" tells an artist nothing about what to do next. "3 of 40 assets couldn't be renamed — they're currently open in another editor tab" tells them exactly what happened and what to fix. Writing that second message usually costs a few extra lines of validation code. It's almost always worth it.
Match the tool to where the work already happens
Editor Utility Widgets exist specifically so tools can live inside the editor UI artists already have open, rather than as an external script they have to remember to run. Every extra step between "I have a problem" and "the tool that solves it" is a reason the tool doesn't get used. If a workflow requires opening a terminal, running a script with the right arguments, and copying output back into the editor, most of that friction can usually be removed by building the tool where the work already is.
Build for the artist who's had a long day
The best test for a new tool isn't whether a careful, well-rested person can use it correctly — it's whether a tired artist at 6pm, moving fast, can't accidentally break something with it. Confirmation dialogs for destructive actions, sane defaults, and dry-run previews before a batch operation commits all come from designing for that person, not the ideal user.