Parents making a simple choice while already juggling a lot of logistics.
UX case study Working MVP
Redesigning family movie night to make it less work for parents.
Movies for Littles narrows the options to G- and PG-rated movies that fit a family’s location, schedule and bedtime, then carries that choice through a simulated purchase.
- Role
- Product designer and prototype builder
- Ownership
- Product idea, UX, visual design, prototyping and testing
- Timeline
- About three weeks, mostly after my son went to bed
- Status
- Working MVP using simulated showtime and transaction data while production ticketing access is pending
01 / Overview
The movie was never the whole decision.
For parents of young children, family movie night is never just about the movie. They also have to figure out what is appropriate, where it is playing, how far away it is and whether everyone can still get home on time.
Traditional ticketing sites are built to sell every available movie and showtime. Movies for Littles is built to remove most of them.
What can we see that is appropriate for our kid and still gets us home at a reasonable time?
A focused decision tool, not another broad movie marketplace.
Live inventory and ticketing depend on production partner access.
02 / The problem
Ticketing sites organize the inventory. Parents organize the evening.
I started with a problem from my own life. My family likes going to the movies, but most of what a conventional ticket site shows us is irrelevant. The movie may be too old for our son, too far away or technically early enough to start while still ending too late.
The first question was simple: could I reduce the decision to the few things a tired parent actually needs to choose?
01Where are you?
02How far will you drive?
03Which day works?
04When must it end?
The MVP handles ratings automatically and only shows G and PG movies. Parents do not need another filter for a choice the product can make for them.
03 / Design principle
Do the work behind the scenes so parents have less to do.
The interface is simple because the logic behind it is not.
Movies for Littles estimates when each showing will end, removes anything that misses the cutoff, sorts what remains, turns weekend searches into actual dates, remembers earlier choices and prepares sensible ticket and seat defaults.
Core principle
Do not ask a tired parent to solve something the product can solve for them.
The goal was not to make a normal ticket form shorter. It was to remove irrelevant movies, repeated confirmations and unnecessary decisions before the parent ever reached checkout.
04 / Key decisions
The strongest changes came from questioning how ticket sites usually work.
01
Plan the ending
Replace “Starts by” with “Ends by.”
I initially used a start-time cutoff because that is how ticketing sites are organized. Testing showed that parents were solving a different problem: when will the evening actually be over?
Starts by 7:15 p.m.
Easy to understand, but it still leaves the parent to calculate runtime and previews.
Ends by 9:30 p.m.
The product uses the listed runtime plus a conservative 30-minute theater buffer.
02
Match how parents decide
Organize results as movie, theater, then showtime.
The order follows the real decision: choose a movie everyone can watch, pick a convenient theater, then choose from the times that still fit the schedule.
03
Keep earlier choices
Let a showtime button skip everything the parent already chose.
Parents can use “Choose movie” to compare theaters, or tap a showtime directly when the movie, theater and time are already clear. The flow never asks them to confirm the same choice twice.
04
Offer two useful views
Use the grid for browsing and the list for comparing.
The poster grid makes it easy to browse on larger screens. The list makes it easier to compare theaters and times. Mobile always uses the list because that is where the real planning happens.
05 / Mobile iteration
Responsive was not enough. The first mobile version still behaved like a desktop page.
The first mobile layout technically worked, but it was too text-heavy, the posters were too large and the sticky search controls took up too much of the screen. I rebuilt the cards for quick comparison, then turned the open search form into a compact summary once the parent began scrolling.
I treated the collapsed card as a separate mobile state instead of squeezing the full form into less space. On an iPhone 14, it is about 240 pixels wide and 144 pixels tall. It stays sticky and readable without covering most of the results.
06 / Checkout
The purchase flow should feel like the product kept paying attention.
The MVP turns the finder into a seven-step flow, from the family’s first search through confirmation. Each choice moves the parent forward, and every later screen keeps the selected movie, theater, date and time.
01
Useful defaults
Start with two adults, one child and three adjacent seats.
This default came from my own family, not formal research. Parents still liked it because it felt like the product was removing work rather than merely shortening a form. Ticket quantities and seats remain easy to change.
02
Calm failure
Keep a declined payment on the payment screen.
The simulated decline says nothing was charged, keeps the entered information and lets the parent retry. It does not kick them back to the beginning.
07 / Parent testing
Six parents tested the final mobile experience.
This was a small qualitative panel, not a statistically representative study. It was enough to see whether parents understood the promise, the search and the full simulated flow without explanation.
“Family movies that fit bedtime” clearly separated it from a normal ticketing site.
Parents naturally thought about when the evening would be over.
One parent would use it to choose the movie and time, then compare final prices elsewhere.
All six understood the four controls, liked the collapsed card and did not want the settings to disappear completely.
Five tapped a showtime directly. One used Choose movie because they wanted to compare theater options first.
All six understood the highlighted showtime. Nobody interpreted it as already selected.
The strongest reaction was to the two-adult, one-child default and the adjacent seats. It felt like the product had already done the busywork.
The panel found one last ambiguity: “This weekend” had to become an actual date before anyone chose a showing. That issue was resolved in the final MVP.
“This tells me the thing I actually care about: when we’ll be done.”
“I can keep scrolling without forgetting what I searched for.”
“Two adults, one child and seats together is exactly what I was going to choose.”
“It feels like it was made by someone who has actually tried to take a small child to a movie.”
08 / Outcome
The simulated MVP now takes the parent all the way through checkout.
The current build starts with four simple questions and ends with a specific movie, theater, calendar date, showtime, ticket quantity, adjacent seats, payment and confirmation.
Final usability verdict
No known critical or unresolved usability issues in the simulated MVP.
The product promise is clear, the mobile search behavior works as intended, the weekend date is resolved before selection and the complete purchase flow is understandable without explanation.
What this does not prove yet
The MVP still uses simulated showtimes, seats, checkout and payment. Real inventory and a completed ticket purchase depend on production access to Atom’s partner APIs.
The first live test would be deliberately boring.
I would replace the simulated listings with real inventory, then complete one solo transaction before involving another parent or my own family. After that, I would test it with my family, but only at a theater with other things nearby or a showing with enough empty seats to buy replacements in person.
For ticket delivery, I would start with the simplest reliable option, likely email. Mobile wallet can come later. Fewer moving parts means fewer things to break while the live purchase loop is still being tested.
09 / Reflection
Personal experience found the problem. Testing kept it from becoming a product only I understood.
I had to separate “dad me” from “designer me.”
Dad me knew the frustration and assumed start time was the important constraint because that was the language I was used to seeing. Designer me had to test that assumption, listen when other parents reframed the problem and rebuild the product around when the evening ends.
The bigger lesson was that simplicity for tired parents does not come from making the interface look sparse. It comes from doing more work underneath it: filtering, calculating, resolving ambiguity, preserving choices and preparing the next likely decision.
The interface became simpler because the product took on more of the work parents were already doing.