FAQ

• Do I need to put a moment in every frame when using Narrative Studio?
• How can I model branching in a user journey?
• How can I add team members to my narrative?
• What’s the difference between docs and specs?
• Can I describe technical details down to algorithms using Narrative Studio?
• How does Narrative Studio support GraphQL?
• How does Narrative Studio integrate with existing workflows?
• Isn’t narrative-driven development like event storming?
• How does domain-driven design (DDD) work with Narrative Studio?

Do I need to put a moment in every frame when using Narrative Studio?

Definitely not. You only want to put moments where it makes sense. If you’re starting from the beginning and putting it together frame by frame, it’s typical for every frame to have a moment because you’re telling the story step by step. But as you define the story more, add interfaces and actions, you’ll find gaps between moments where a lot happens behind the scenes, like system processes. An action could be “the user adds an item to their cart,” and the next moment might be “the user checks out.” Between those two moments, lots of processes happen in the back end, which will take up space in your narrative. So no, not every frame needs a moment.

How can I model branching in a user journey?

There are a few different approaches. A user journey can be a single narrative, depending on the complexity, or it could be a sequence of narratives. For example, a simple narrative could be “the user logs in.” But when things get more complex, you can create branches or forks. A branch is when, say, the payment is successful, but if it fails, you branch out into a new narrative for failed payments. A fork is different: the user may not be logged in when adding items to their cart, so they fork out, log in, and then come back into the main flow. A branch leads to its own terminal state, while a fork brings the user back into the main narrative.

How can I add team members to my narrative?

You’d invite them in to collaborate with you. When you bring them in depends on what phase you’re in. If you’re in the discovery phase and need feedback, you can bring them in early. You can also do pair modeling with them, just like you pair program, and having multiple brains on the task leads to better outcomes. Later on, if you’re at a handoff point between teams, like from business to tech, that’s also a good time to bring in more people. Just always leave room for feedback and keep things flexible as the narrative progresses.

What’s the difference between docs and specs?

A doc is like a Confluence page where you put down your ramblings — early requirements that are still loose and free form. A spec, on the other hand, is for when you’ve finalized your design and need to communicate the solution. Specs are structured and detail how things should be built, like class hierarchies or architectures. A doc is for capturing the free-form thoughts and early requirements, while a spec comes after you’ve designed the solution and are ready to communicate it clearly. Think of it like building a house: first, you ramble about wanting tall ceilings, then you define requirements like having space for a family, and finally, the specs are the detailed blueprints you hand over to builders.

Can I describe technical details down to algorithms using Narrative Studio?

You can, but we wouldn’t recommend it. Right now, it’s better to focus on the outcomes you want rather than the technical details like algorithms. Leave the implementation to the developers. You should describe what you want to happen in terms of behavioral specifications, like, “I want the closest color match to be returned when the user selects red.” The focus should be on the “what” — what behaviors and outcomes you want — not the “how” in terms of specific algorithms. The implementation, like the choice of algorithm, should be left to the developer, as long as the behavior is correct.

How does Narrative Studio support GraphQL?

If you think about the building blocks for any complex business line application, you have four major flows: navigation (moving between interfaces), command (sending instructions through the system), data retrieval (getting data from the system), and system reactions (one system triggering another). GraphQL capitalizes on these concepts through mutations (equivalent to commands) and queries (equivalent to data retrieval). Narrative Studio supports GraphQL by allowing you to define schemas and queries at the boundaries. You can design a demand-driven schema setup by defining how different systems will talk to each other, helping to map out the demand and the systems you’ll hit. For example, if you’re building a super graph for an entire company, Narrative Studio can help model how different systems need to communicate and the demand the application has on the data.

How does Narrative Studio integrate with existing workflows?

Narrative Studio and NDD are superpowers to Agile, not replacements. It doesn’t change Agile’s principles. In fact, narratives are a next-level evolution of user stories. Instead of using just small, myopic user stories, narratives give you a bigger view of the initiatives you’re working on. You can add them to your current process or replace user stories with them. They give more context and a greater understanding of what you’re actually trying to create. You don’t have to deliver a narrative in a single iteration like a user story. It can span across multiple iterations, much like an epic, but with a lot more detail and clarity about the overall picture.

Isn’t narrative-driven development like event storming?

NDD was definitely influenced by event storming, but it’s evolved into something a bit different. Event storming is great for understanding a sequence of events, but narratives let you dive deeper and add more detail. Business folks often want to add more than just a simple event like in event storming. NDD lets you model moments in time with more flexibility, making it easier to communicate across teams. It’s compatible with event storming, but narratives allow for more descriptive and comprehensive storytelling. The origin of NDD was actually born from trying to teach event storming to business people, but they struggled with sticking to simple events, so we introduced the concept of “moments” to give them more flexibility. NDD has since grown into its own distinct discipline, but the influence of event storming is definitely still there.

How does domain-driven design (DDD) work with Narrative Studio?

With Narrative Studio, as you describe moments, you start to converge on a shared language, which is a key part of DDD. As people talk about moments, commands, and events, they refine the language of the domain, which leads to better designs. Narrative-driven development helps you arrive at that shared understanding in a high-bandwidth, collaborative way. Narrative driven development precedes or works in tandem with DDD by helping you sharpen your domain language through time-sequenced storytelling. DDD traditionally gives you a static snapshot of a domain, but narratives allow you to model the evolution of that domain over time, which is critical for understanding how the business and system change.