Designing software older volunteers will actually use
Most parish administration runs on unpaid, often reluctant hands. Keeping the software calm and simple is not a finishing touch. It is where the real work goes.
Picture the person who will actually use parish software. Not the priest at a conference, not the tech-savvy young reader. The volunteer who keeps the office running. Often retired. Often doing it out of love and a sense of duty. Often quietly convinced that they are “not good with computers,” and braced to be made to feel it.
That person is our real user. Design for anyone else and you’ve built a tool the parish can’t actually run.
Most software is built for the wrong person
The industry optimizes for the power user: dense dashboards, endless configuration, keyboard shortcuts, notification badges competing for attention. That’s fine when your user is a full-time operator who lives in the tool eight hours a day. It is exactly wrong when your user opens the software for twenty minutes on a Tuesday to get the bulletin out.
For that person, every blinking badge is a small accusation. Every unexplained icon is a dead end. Every screen that assumes fluency they never claimed confirms the story they already believe about themselves. They don’t need more power. They need to not feel stupid.
Calm isn’t a visual style. For this user, it is the difference between running the software and giving up on it.
What calm actually requires
Calm is easy to say and expensive to build. In practice it means a set of stubborn choices:
- Legibility over density. Warm paper tones, a real reading serif, generous space, one restrained accent colour. The screen should feel like a well-set page, not a cockpit.
- Plain language. A person manages notifications, not “webhook configuration.” A button says exactly what it will do, and then a message confirms it did it.
- Smart defaults and auto-generated IDs. The software should arrive already knowing the reasonable answer, so the volunteer confirms rather than composes.
- Progressive disclosure. The common path is right there; the advanced machinery is available but never in the way. Complexity is earned, not front-loaded.
- Nothing blinks for attention. Urgency is reserved for things that are genuinely urgent, which turns out to be almost nothing in parish administration.
And it has to work from a phone
The work doesn’t happen at a desk. A priest checks the day’s feast from the car; a warden looks up a family from the narthex. So every part of the product is a real mobile surface, purpose-built for the phone rather than a desktop layout crushed to fit. Shrinking a dense interface onto a small screen doesn’t serve this user; it just makes the accusation smaller and harder to read.
Accessibility, for us, isn’t a checklist you pass at the end. It’s the posture you start from: the assumption that the most important person in the room is the one least sure they belong in front of the software. Build for them, and everyone else is served for free. Build for the power user, and you’ve quietly locked out the very person the parish depends on.