Two different users
Most production software is designed, quite reasonably, for someone who uses it constantly. A professional operator, in the same room, several times a week. That person builds fluency. They learn the shortcuts, absorb the quirks, and develop the intuition that comes from repetition.
For that user, a dense interface is a feature. More controls visible means fewer clicks. Terse labels are fine because they already know what everything means. Settings that persist between sessions are convenient, because they are their own settings from yesterday.
Volunteer teams are a different user entirely, and the difference is not skill. It is frequency and continuity.
A volunteer might run the desk twice a month. Between their turns, other people have used the same system and left it in some state. They may have missed the session where something changed. They are often doing this alongside other responsibilities, arriving shortly before it starts.
They are not less capable. They have less context, and context is what the professional's fluency is made of.
What changes
Design for the infrequent user and several conventions invert.
Persistence becomes a hazard rather than a convenience. For a daily operator, remembering last session's settings is helpful... they were their settings. For a rotating team, it means arriving to a system configured by someone else, for a different event, in ways not visible without checking. The most common live-day failure I see is not a mistake made today; it is a setting left from last time.
Density becomes a cost. Every visible control is something to evaluate. The professional filters instantly because they know which controls matter for their current task. The infrequent user cannot filter, so they see fifty things and have to reason about all of them, under time pressure, in a room that is filling up.
Memory requirements become failure points. Anything of the form "remember to also set X" will be forgotten by someone eventually. Not through carelessness... because it is invisible, and invisible requirements are forgotten by definition. If forgetting it breaks the event, that is a design flaw wearing a human's face.
Recovery matters more than prevention. The professional rarely makes the mistake. The volunteer will, and the important question is what happens next. A mistake that is obvious and reversible is a small moment. The same mistake, silent and irreversible, is the story of the day.
The principles I ended up with
These emerged from watching things go wrong, not from a design philosophy I started with.
Make the current state visible without asking. The single highest-value property. If someone can see what is going out, what is being recorded, and what is selected, without opening anything, most state errors are caught before they matter. If checking requires navigating, nobody checks when they are busy, which is exactly when they need to.
Reduce decisions, not clicks. These are different, and optimising for the second frequently makes the first worse. A control that does three things in one action is fewer clicks and a harder decision. For someone who has done it a hundred times, that trade is good. For someone doing it for the third time, it is bad.
Make the safe path the easy path. If the safe way to do something takes more effort than the risky way, people will take the risky way under time pressure. Everyone does. That is not a training problem; it is a gradient, and gradients win.
Default to the common case, loudly. Start from what most events need, and make deviations from it visible. A system in an unusual configuration should say so, because the person who set it that way is frequently not the person now sitting in the chair.
Let the state be reset. A reliable way to return to a known-good starting point is worth more than almost any feature. It converts "I do not know what is wrong", which is unbounded, into "start again from clean," which takes a minute.
What I got wrong
I have made every one of these mistakes, which is how I learned them.
I built interfaces that were efficient for someone who already understood the system, and was confused when they did not survive contact with a real rotating team. I persisted settings because it seemed helpful and created a category of failure where last week silently sabotaged this week. I added controls because each one was individually justified and collectively produced a wall.
The correction that helped most was cheap: watch someone use it who was not there when it was built. Not a usability study... just watch, and specifically resist the urge to help. Every moment you want to lean over and explain something is a design defect with a location and a witness.
That is uncomfortable in a specific way. You built it, you know exactly what to do, and watching someone struggle with something obvious feels like watching them fail. It is not. It is the interface failing, in public, with the evidence right in front of you. Sitting on your hands for ten minutes is the highest-value ten minutes available to you.
The best version of that test I have had was not in my own building. It was a first-time user on the media team at a national worship event, who had never touched the software before and had a job to do that evening. Nothing focuses a design like watching someone learn it under a deadline that is not yours.
Why this is the actual problem
Something I have come to believe: for volunteer-run venues, the binding constraint is almost never capability. The software can do far more than most teams use. The constraint is how much a system can ask of the people who will actually be sitting there on an ordinary week, with an ordinary amount of preparation, and someone missing.
Which means the valuable work is frequently subtraction. Fewer steps. Fewer things to remember. Fewer ways for last week to affect this week. None of that demonstrates well, because you cannot show an absence in a feature list, and it is the difference between a system that works on your good weeks and one that works on all of them.
The person I design for is the one who did not come last week, does not know what changed, and has fifteen minutes. If it works for them, it works for everyone.