User and stories and goals for writing & narrative design – actually pretty useful

I used to really dislike writing user stories and goals in my narrative design work. Compared to colleagues working in other areas of design it felt a little odd when I was writing. But the more I use them, the more I find them useful even when writing. 

Goals

Goals should be the high level thing you want to achieve. Let’s say we want players to spend more time in our cool sci-fi RPG’s hat shop. We’re exploring an NPC hosting this shop and we think it’ll encourage players to use it more. So from here (or from any other brief a Creative Director might set you) let’s set some goals. Explain why something is a goal.

• Reward and encourage players to use the hat shop more so that players fully engage with the hat meta.
• Increase length of hat shop usage duration so that players take more notice of available hats.

User stories

Typically I’d have a few more, but this will do for an example. Now onto User Stories.

User stories are often deployed in software development. They describe something you want to achieve. Most importantly they are written from the point of view of a particular person. I like to make sure there are user stories that cover my colleagues in other disciplines, as well as different types of players we might encounter. If you get stuck on player types, you should think about your audience. Quantic Foundry’s Game Types can be a useful starting point. Otherwise make sure you’re aligned with your team and project leadership. Knowing who your game is for, is important.

 It’s also OK to note here you can absolutely write user stories from your own point of view. It’s especially helpful if you’re working in a larger narrative team. If someone needs to hop in and work on content you’ve authored it’s useful for keeping alignment. Ideally these should be specific. However, when I’m working with a team who may not be used to working with narrative I do include higher level user stories.  Not only is making documentation important, but encouraging engagement with your team. Most teams keep their GDD as a wiki so that the team can see and comment on work as it comes in. As a dev, keeping an eye on what the rest of your team is doing is important. As a narrative designer it’s important to keep communicating across the team.

Let’s take a look at some sample goals:

• As a narrative designer I want to create an engaging Hat shop character so that players are encouraged to interact with the hat shop.
• As a player with a visual disability I want an NPC that will describe the hats as I use the shop.
• As an artist I’d like a clear idea of what the shop NPC should look like so that I can design the character.
• As a designer I want an NPC that supports the hat buying meta, so that players will keep using the system.
• As a writer I want a NPC that can communicate in short snappy sentences so I can deliver dialogue without interfering in player experience.

Now these are super rough, and I’m sure a few wouldn’t make it through review. But that’s OK. You should be testing these with your colleagues and asking them to suggest more. Is there something they need from this character? Is there specific info they need in the documentation to implement their work?

Once these are agreed then you have a clear set of criteria to test the work against as you design and implement it. Documentation is also living. If things don’t quite work out. Or you realise you’ve missed something you can add it.

While I’m writing the spec for the hat selling NPC. I know they need to be someone players really want to react with. We want them to have VO, but we think it should be short and snappy. These are all feature requirements, but they are also the start of some decent character traits. An appealing character, who gets to the point

 Put ‘em right at the top of the page. You can use them for working toward narrative pillars as a whole. Then down into features, types of content, down to an individual character if you need to.

Did we achieve our goal?

 By working with our colleagues and working through a design process. We already have the start of a character. This character represents a major system in our hypothetical game. By thinking things through we’ve just applied a narrative filter to what is a fairly common game system. If we meet our goals however we’ve just increased player engagement and made the game more fun. Pretty neat eh?