TinyTales | A Design Sprint to Reorganize the Book Information Page

TinyTales is a startup that knows the magic of a bedtime story and how meaningful those nightly rituals become for family bonding. They built a platform to make it happen for families everywhere. But something was breaking the spell and families were stuck. They wanted to read together. Instead, they found themselves in an endless search. What story was right for a five-year-old? A nine-year-old? Both at the same time? Did this book have the values we care about? Would it be too scary? Too babyish? How long would it take to read? My challenge was to help families quickly decipher which story is the right story, so they can spend more time reading and bonding together.

On the first day of the sprint, I reviewed the user interviews and research highlights, spent time with the persona, and I immediately saw what was really going on. Parents weren't being indecisive, they were being intentional. They wanted to purposefully choose a story. To do so, they needed to find out: if a story was age appropriate, what topics were covered, if it had educational value, entertainment value, and what thematic life lessons were being explored. However, TinyTales gave parents zero way to find those things out besides skimming the entire story themselves first.

For families with multiple kids of different ages, the problem multiplied. Find a story for the youngest and realize it won't work for the oldest, start over. Again. Or finally finish reading the story the first kid chose, and time to start searching again for another story the second kid gets to choose. Time was everywhere and nowhere. Parents also had no idea if a story took fifteen minutes or an hour. Some would start reading and blow past bedtime. Others would have to stop mid-story. And if a kid was interested in a specific topic? Good luck unless it was in the title. Discovery felt random. With so much missing information, parents turned to external platforms for reviews to guide their decisions. The missing piece wasn't more stories. It was information and seeing the right information in the right place at the right time.

I created a journey map, mapping out every moment a parent and child encountered friction. But I didn't just list the problems, I traced them back to missing information. What specific details would solve each friction point?

This was a six-day modified Google Ventures design sprint, and I had to make a critical choice early on. I went back and forth on this. The search screen felt important. That's where families started. But I kept asking: even with a perfect search, what happens next? A better search could still spit back fifty books. They're still overwhelmed. The real problem wasn't finding a story. It was determining if a story is the right one. That happens on the book information screen. This is where all the questions get answered. This is where a parent decides: yes, we're reading this tonight. This is where the friction actually lived.

I referenced the journey map from Day 1 to make sure every screen reflected the key user moments. I focused on a minimal set of core screens because time constraints meant I couldn't design everything. So, I had to be strategic. The flow focused on searching, deciding, previewing, selecting, reading, and reviewing a story.

I knew this app would be used at night, by sleepy families, with kids who are still learning to read. So the visual design had to reflect that. I designed darker, calming screens that would reduce stimulation and promote relaxation. I chose colors and elements that I would associate with terms: bedtime, starry night, child-like, magical, dreamlike. As a former educator I knew I needed to use images and icons everywhere because kids are still learning to read and they heavily rely on visual aids. So visual aids had to be clear and engaging. I designed interactions to feel like flipping through a book, to mimic that tactile experience of browsing a library.

I conducted five moderated usability tests. Of the five people I interviewed, two were parents, one was an uncle, and two were parents that were also elementary educators. Three of my tests were conducted in person using a tablet. Two of my tests were conducted remotely on a laptop using tablet preview mode. I acted as the proxy-user following the lead of the participants. Tests that were done remotely were due to scheduling constraints.

The visual design stood out. Users said it was engaging and polished. More importantly, they said it would cut down their search time. They could see what they needed. They felt confident in their choices.

However, a new problem unexpectedly emerged. Nobody knew how to start reading. Users could save stories to read later to "My Reading List" or add them to "Tonight's Stories" to read multiple books in a queue, but there was no clear path to just... read. One story, right now. This led to bigger confusion: What's the difference between "Tonight's Stories" and "My Reading List"? When do I use each one? Why are there so many ways to read? It wasn't a small issue. It was a critical moment where they'd decided on a story and were ready. And I'd made that moment unclear.

1 / 4

I had solved the discovery problem. But I'd created a new friction point: clarity about how to actually read. If this project were to move forward, I would implement three high-priority changes:

• First: Redesign the search experience so the search engine and filter system expand together. No switching between screens. Fewer decisions.
• Second: Add brief tutorials that explain the purpose of "Tonight's Stories" and "My Reading List." Scaffold the mental model. Help families understand when and why to use each one.
• Third: Add a "Read Now" button. For families who just want to read one story. Right now. Tonight. Simple as that.

Then I would test again. New round of usability tests. New iterations. I'd measure task success rates, error rates, and ask families directly: Can you explain the difference between each reading method? That answer would tell me everything.

For future phases, I'd incorporate some user requests: the ability to read stories in other languages. A "Favorites" list. A "Want to Read" list. An "Already Read" list. Metrics on how many books they've read, how much time they've spent reading, how many times they've revisited a story.

The story queue feature came from real insight. In interviews parents said that they typically read three stories a night. However, they were not pleased by the cycle of reading one story, searching for the next, choosing it, reading it, searching again. Three times over. So I designed "Tonight's Stories" to solve that. Do all your searching upfront. Save books to a queue. Read them back-to-back. Uninterrupted.

However, sprint constraints got in the way. When I realized I wasn't going to have enough time to fully prototype the multi-story experience, I should have cut those screens from testing entirely. Instead, I kept them in the flow. I thought I could still gather insight on the queue feature. I also knew that multi-story reading was the realistic bedtime ritual for families. Cutting it felt wrong, but it ended up just causing confusion.

Here's what I didn't realize at the time: the core problem the design sprint was trying to solve was helping families find the right story. Not managing multiple stories. I was trying to do too much. I was overscoping. In retrospect, I made the wrong call by including those screens. It was a hard decision in real time, but now I understand it was the wrong one. The design sprint needed to stay focused. By trying to address both problems, finding one story and queuing multiple stories, I muddled the insights I actually needed.

If I could do it again, I'd commit to solving one problem in the sprint. Test the single-story experience. Get clear feedback on that. I would have gathered clearer insights. I would have known definitively whether families wanted a queue or if they just needed an easy way to start reading. Then, if the queue feature was still a priority, I'd prototype and test it separately.