Last year I watched a volunteer children’s ministry director attempt to run Sunday school prep on her phone while her toddler climbed on the kitchen counter. She had exactly seven minutes between finishing breakfast and loading the car. The curriculum platform she was using required three separate logins, two PDF downloads, and a supply list that assumed access to a craft store and a laminator.
She gave up and winged it with goldfish crackers and a Bible story from memory.
That moment taught me more about product simplicity than any design framework I’ve read. When your user is a part-time volunteer with no training budget, no tech support, and seven minutes to prepare — you learn fast what “simple enough” actually means.
I’ve carried those lessons into every product role since. Here are four that I apply constantly.
Design for the Five-Minute User, Not the Power User
Every product has a “five-minute user” somewhere in the workflow — the person who needs to accomplish a core task under conditions of time pressure, cognitive load, and limited context. They’re not the user who fills out your feedback surveys or attends your user interviews. They’re the ones who quietly abandon your product and find a workaround when it gets in their way.
For Sermons4Kids, that user was the Sunday morning volunteer in the parking lot at 8:55am. For enterprise products, it’s the admin configuring your tool during their lunch break because IT is overloaded. For B2C products, it’s the user trying to accomplish something during the three-minute window between meetings.
Most product teams design for the engaged, patient, curious user who will explore the product to find what they need. The five-minute user has none of those qualities in the moment that matters. They need the most important task to be one tap away with no ambiguity about where that tap is.
The diagnostic question: If someone with no training and no time needed to complete the single most important task in your product, could they find it in under 30 seconds? If not, that’s your simplicity problem.
Remove the Decision Tree, Not the Content
We rebuilt the Sermons4Kids homepage after session data showed that a significant percentage of users were abandoning at the content selection step. We had years of excellent curriculum. We had a well-organized library. We had filters and categories and search. Users still gave up.
The fix wasn’t removing content — it was removing the decision the user had to make. Now the homepage shows exactly four options: This Sunday’s Lesson, Last Week (for catch-up), Next Week (for advance planners), and Search. That’s it. Every other organizational structure lives behind Search for motivated users, but it doesn’t block the path for the Sunday morning volunteer who just needs this week’s materials.
Session completion rates improved immediately. The content didn’t change. The decisions the user had to make did.
Every product has a version of this problem: an information architecture that’s logical and comprehensive but requires users to make a series of decisions before they can do the thing they came to do. The solution is almost never more content or better organization — it’s opinionated defaults that route the majority of users directly to what they need, with the full flexibility available one level deeper for the users who want it. This connects directly to what Barry Schwartz documented: more choices create paralysis, not empowerment.
Question the Digital-First Default
This one surprised me. In a world of responsive design and mobile-first product development, the most valuable feature we built for Sermons4Kids was making everything print-perfectly every time.
Children’s ministry happens in physical spaces with physical kids. Volunteers need something they can hold, write on, and hand out. They need a backup when the WiFi fails. We spent months optimizing mobile responsiveness before realizing that “mobile optimization” for this use case meant “fits on one page when printed from a phone.” Not responsive design — print design.
The broader lesson: digital-first is a design assumption, not a universal user truth. The right question is “what format serves this user in their actual context?” — not “how do we deliver this digitally?” I’ve seen the same pattern in analytics tools where print-ready dashboards increased executive adoption more than better mobile interfaces, and in consumer apps where PDF export drove more engagement than in-app features for users whose workflows involved physical handoffs.
The Onboarding Moment Is Earlier Than You Think
For volunteer users, we discovered that the meaningful onboarding moment wasn’t first login — it was the first successful Sunday. The first time a volunteer used our curriculum and it worked in the classroom, with real kids, under real conditions, was when they became retained users. Everything before that was trial, not adoption.
This shifted how we thought about activation. The question wasn’t “did they complete setup?” — it was “did they succeed at the thing they came to do?” And the second question had very different design implications than the first. It meant making the path from signup to first successful use as short and obstacle-free as possible, even at the cost of features and configuration options that would be valuable later.
Most products define activation as completion of a setup flow. The better definition is completion of the first meaningful value exchange: the user did the thing they came to do, and it worked. Building backward from that moment tends to reveal a lot of unnecessary friction in the path to get there.
These principles show up everywhere once you’ve internalized them — in enterprise software, consumer apps, and AI products. The choice overload problem in AI features is fundamentally the same problem as the children’s curriculum homepage: unlimited options create abandonment. The design principle that solved it for Sunday school volunteers is the same one that solves it at scale.
Your Turn: Apply This Today
Take these directly into your next product review, sprint planning, or roadmap conversation:
- Map the constraint first. Identify your most time-pressured user segment. What is their real-world window to complete the core task? Design to that number — not to your average session length.
- Count steps to first value. Walk through your onboarding or core workflow and count every tap, click, decision, and login required before the user gets something useful. If it’s more than five, cut.
- Remove one option this sprint. Find a feature or navigation choice that fewer than 10% of users engage with. Archive it. Measure whether anyone notices.
- Rewrite one tooltip as a verb. Anywhere you explain what something is, rewrite it as what the user should do next. “Lesson plans” becomes “Start this week’s lesson.”
- Test with your least technical user. Give the product to the person in your target audience least comfortable with technology. Watch without coaching. The first pause is your biggest design problem.
- Apply the seven-minute rule. Before shipping any new feature, ask: can a distracted, under-resourced user get real value from this in under seven minutes? If not, simplify before you ship.
These principles also show up when you’re new to an organization: the first 100 days of a product leadership role require the same “design for the five-minute user” discipline applied to your own stakeholders — getting to value quickly, removing unnecessary process friction, making the path to trust short.
Building products for time-constrained, mission-driven users and fighting complexity at every stage? I consult with product teams on simplicity-first design, activation optimization, and building for users whose real-world context is nothing like your test environment. Let’s talk.