This reflection examines how storytelling helps designers anticipate user experience, question assumptions, and refine ideas while they are still taking shape.
Storytelling gives designers a way to imagine how a design will feel before it is fully built. A project may begin with goals, features, screens, or organized content, but those pieces do not always show how a person will actually move through the experience. Parrish (2006) presents storytelling as a design method that helps connect analysis with synthesis by imagining how situations unfold over time. Gibbons (2003) also reminds us that design involves more than individual parts; it requires attention to how those parts work together within a larger system. Kelley and Kelley (2013) add to this by emphasizing empathy, experimentation, and the importance of staying close to real human needs. At the same time, storytelling must be used carefully because a single story cannot represent every user, situation, or challenge. Across these ideas, storytelling becomes more than a way to explain a finished product. It becomes a tool for questioning assumptions, anticipating limitations, and refining an idea before it is fully developed.
Parrish (2006) helps frame storytelling as a way to think through experience, rather than simply to describe a finished design. A story pushes the designer to consider sequence, setting, tension, choices, and consequences. Instead of looking only at what a product or learning environment contains, storytelling asks how a person enters the experience, what they notice first, where confusion might appear, and what would make the experience feel meaningful. Gibbons (2003) supports this idea by explaining that design involves multiple constructs working together rather than one visible product or feature. Goals, tools, messages, activities, and interactions all shape the final experience. This perspective is important because something can look organized on the surface but still fail to support the person using it. Storytelling can help reveal those gaps by showing how the parts of a design work together over time.
The important point for me is that storytelling can make design thinking more concrete, but it should not replace critical analysis. A story can help reveal what a person may need, feel, or struggle with, but it can also narrow the design if the story is treated as the only possible experience. This is where competing perspectives matter. Different users may enter the same system with different goals, levels of comfort, responsibilities, and concerns. A design story should therefore be treated as a lens, not a final answer. It can help identify needs and possible gaps, but those ideas still need to be tested through feedback, revision, and attention to the larger context. In that way, storytelling is most useful when it helps designers ask better questions rather than assuming they already understand the full experience.
As I continue developing FamilyFlow, this helps me think beyond the prototype’s basic structure. It would be easy to describe the project only by its main sections, such as timeline, schedule, vault, and trusted records. However, a design story can help me imagine the real moment when those sections would matter. A parent may need to find a schedule change, return to a decision, locate a document, or understand what happened across several different tools. Storytelling helps me see where confusion, privacy concerns, access needs, or trust issues may appear before the prototype becomes more polished. For FamilyFlow, the story is not just a way to explain the product later. It is a way to shape the design now by keeping the focus on real situations, real users, and the details that need to remain clear as life moves.
“Stories are always drawn from life.” ~ Parrish

References:
Gibbons, A. S. (2003). What and how do designers design? TechTrends, 47(5), 22–25.
Kelley, T., & Kelley, D. (2013). Creative confidence: Unleashing the creative potential within us all. Currency.
Parrish, P. (2006). Design as storytelling. TechTrends, 50(4), 72–82.

