Modernizing a process without losing the care behind it.
A volunteer-led exploration of where technology can reduce Sunday administration while preserving the deliberate checkpoints that protect children and support families.
Not adopted: KidsChurchLog is being prepared for stakeholder presentation and validation. It is not the church’s current operational system.
EVERY CHILD KNOWN.
EVERY RELEASE CAREFUL.
The conversation
Kids Church Ministry + Admin Service Ministry
I encountered the workflow from inside it.
As an ASM volunteer, I was already part of the environment where Sunday operations, responsibilities, and conversations happen. The opportunity emerged through discussions among volunteers—not from an outside requirements document.
Kids Church involves much more than recording whether a child attended. There is registration, check-in, knowing which children are currently under the ministry’s care, coordination between volunteers, and making sure each child is released through the proper process afterward.
A lot of the manual work exists precisely because volunteers are trying to be careful. My suggestion was not to discard that work, but to explore whether a more modern workflow could preserve the care behind it while reducing some of its administrative friction.
Firsthand experience gave me context and a useful place to begin. It did not eliminate the need to validate the proposal with people who experience other parts of the workflow.
The existing process
Simple tools can contain serious ideas
Paper wasn’t the problem.
Paper, pens, lists, claim numbers, remembered procedures, and volunteer coordination can be deliberately simple because they need to work with the people and resources available.
Replacing something simply because it is not digital is usually a bad reason to build software. The existing process already contains ideas worth preserving.
Given to parent or guardian
continuity of responsibility
→Presented when returning
A physical claim number is simple, but the thinking behind it is important: there should be continuity between the person checking a child in and the person returning for that child.
That continuity—not the paper itself—is the part the proposed digital workflow needs to understand and protect.
NOT: How do we replace paper with an app?Where could technology genuinely make the existing process easier and more reliable?
This isn’t just attendance
A child arriving creates a chain of responsibilities
Attendance is one event inside a larger journey.
The product needs to maintain a trustworthy relationship between the family, the child, the ministry, and the person who returns.
Who is this child? Who brought them? Which family do they belong to? Have they checked in? Where are they assigned? Who may pick them up? Have they already been released?
Because children are involved, convenience cannot be the only design goal.
- 01Family
Who brought the child?
- 02Child
Who are they connected to?
- 03Check-in
Have they arrived?
- 04Ministry
Where are they assigned?
- 05Release
Who is allowed to pick them up?
Modernization should serve the workflow
Technology fits into Sunday—not the other way around.
The useful questions are operational: what information volunteers actually need, when they need it, who is responsible for each action, which steps can be faster, which should remain deliberate, what happens when technology is unavailable, and how much training volunteers can realistically be expected to need.
The ministries already have responsibilities and a working process. The product should fit that environment instead of forcing the environment to reorganize around the product.
The goal is not digitization for its own sake. The goal is better operations.
From claim card to Family Pass
Preserve the concept, reconsider the medium
The Family Pass began with an existing claim number.
Instead of treating every Sunday as an isolated attendance event, the product can recognize the relationship between children and the people responsible for them.
A family can be registered, children can belong to that family, and the family can identify itself consistently during check-in and release.
The product idea is not “use a QR code.” It is to support that relationship.
Physical claim number
Something handed over at check-in and presented at release.
NFC card or sticker
A satisfying familiar tap—but with physical infrastructure attached.
Digital QR + Family Key
Test the workflow using familiar devices before asking the ministry to invest in hardware.
The infrastructure behind a tap
A nice interaction is not automatically the right first dependency
NFC quietly turns software into operations and inventory.
My first instinct was to preserve the physical mental model: a guardian receives something at check-in and presents it again at release. A card or sticker that could be tapped felt intuitive.
But NFC is not merely an interface decision. Somebody has to purchase, encode, distribute, replace, and inventory the passes. Something also has to read them.
Depending on whichever volunteer has a compatible phone is not a predictable operational plan. Dedicated readers improve consistency, but they also mean the church needs hardware before the workflow can properly operate.
NFC may eventually offer real value. It is simply too much commitment around an assumption that has not yet been validated.
Don’t make the organization commit to infrastructure before the product has earned the need for it.
Why QR for the early version?
Validate the workflow first. Invest in infrastructure second.
QR is not inherently “better” than NFC. It is more appropriate for what KidsChurchLog needs to prove right now. It requires no cards to manufacture, stickers to purchase, or dedicated readers to deploy. The interaction—show this code, scan this code—is already familiar to many church members.
That familiarity lets the proposal test the important assumption: does the Family Pass workflow actually help? If stakeholder feedback later demonstrates that NFC would meaningfully improve real Sunday operations, there will be a reason to revisit it.
A camera may fail. Permissions may be denied. A guardian’s screen may be difficult to read. QR must not become a single point of failure.
The objective is not to successfully scan a QR code.The objective is to identify the family and support a careful release.
Designing for volunteers
The software cannot become another ministry responsibility
Volunteers come to serve—not to operate software.
KidsChurchLog is not being designed for people whose primary responsibility is using KidsChurchLog. A technically sophisticated system underneath should ideally produce a very unsurprising experience on top.
Volunteers should not need extensive software training before they can help with Kids Church operations. If someone needs to understand how the software works internally to use it correctly, the interface has failed.
- Obvious actions
- Clear status
- Minimal navigation
- Readable information
- Predictable workflows
- Sensible defaults
- Useful error states
Designing for Sunday
Not quiet office software
Good UX changes when families arrive at the same time.
Sunday operations involve families arriving together, children moving between spaces, volunteers coordinating, guardians waiting, noise, distractions, queues, and different levels of technical confidence.
A workflow that feels reasonable while I am developing at a computer may feel unnecessarily complicated when several families are waiting and volunteers need to keep the operation moving.
The proposal eventually needs to be evaluated in the environment where it would actually be used. Interface polish at a desk cannot substitute for realistic Sunday validation.
obvious actions · clear status · minimal navigation · useful errors
Safety without theater
Care should come from the workflow—not from making the interface look complicated.
Because the product involves children, it would be easy to add security-looking features simply to make the interface appear serious. That is not the goal.
Every verification step has an operational cost. Every removed verification step can introduce risk. The work is determining which actions genuinely contribute to careful release.
The interface should help volunteers understand what has happened, what has not happened, and what still needs verification—without mistaking visual complexity for safety.
The proposed product direction
One operational system around a child’s journey through Kids Church.
Family registration, child profiles, attendance, and release are connected capabilities rather than separate administrative tools.
The first half of the product principle is about organization. The second is about responsibility: know who is currently under the ministry’s care and support a deliberate process for returning each child to their family.
Family Registration
Represent the family relationship once.
Child Profiles
Keep information needed to identify and manage children.
Sunday Check-In
Record that a child has arrived and is participating.
Attendance
Create useful records without administrative busywork.
Family Pass
Identify the family relationship during check-in and release.
Verified Release
Support the expected family-release workflow.
EVERY CHILD KNOWN.EVERY RELEASE CAREFUL.
The public proposal
The interface exists to start a better conversation.
The current experience includes proposed family-oriented workflows, check-in and attendance concepts, Family Pass, and child-release considerations.
The next question is not “Do you like the app?”Did I understand the problem correctly?View the proposal
The next important input
Stakeholder review is the next major milestone.
KidsChurchLog is being prepared for presentation to volunteers and other relevant stakeholders. It has not been adopted as the church’s operational system.
The next step is not simply to finish coding. It is to put the proposal in front of people who understand the workflow from perspectives other than mine.
Their feedback may confirm assumptions, invalidate others, reveal missing steps, or require significant changes. That is part of the design process—not a failure of it.
Administrative context and Sunday coordination
Direct child-care workflow experience
Responsibilities beyond a single volunteer’s view
The other side of check-in and release
Which assumptions were correct—and which were wrong?
What did volunteers immediately understand?
What confused them?
Which workflows are missing?
What did stakeholders not think was necessary?
Which features need to change or disappear?
What operational or technical constraints emerge?
Does the product direction itself need reconsideration?
If a design does not survive stakeholder feedback, that history should remain part of the case study. Change is evidence of the process.
The evolving case study
Presentation → iteration → implementation → realistic validation → retrospective
What KidsChurchLog is teaching me
Firsthand context gives me a place to start—not permission to stop listening.
KidsChurchLog is different from a product built entirely from my own frustration. Being part of ASM helped me recognize an opportunity and gave me enough understanding to propose a direction.
But Kids Church volunteers understand the child-care workflow from another perspective. Ministry leaders carry responsibilities I may not see. Families interact with the process differently again.
I can bring my experience as a volunteer and an engineer. I can propose, design, and build. But the product still has to survive contact with the people who will actually use and depend on it.
Here’s how I think we could improve this process.Did I understand it correctly?
If something does not fit how we actually serve, the software needs to change. Modernization is not successful merely because a process becomes digital. It succeeds when it helps us serve better.