Use of user journeys in game development

I know we've never used them, at least to my knowledge.

From the description, it looks like the kind of thing instructors put in to try to prove that a concept is used in industry where you look for something that doesn't exist, find things that somewhat match what a person might have done, and thereby establish to a young impressionable student that it is actually industry standard.

There are times where people describe what a user might experience. It is good for products to develop a series of statements about a product. There is the single statement about what your product is. There is the "elevator speech", fast enough you can give it when stuck in an elevator and someone asks "what do you do?", typically from 20-60 seconds. There is a two-minute version. There is a two page version. And there is a 10 page description or overview or pitch.

All are quite different from "user stories", which are descriptions of tasks or features inside a program. Like "As a user, I can pick the 'game options button' and be shown the features for the game, including this and that and the other."

I've never heard of User Journeys being used in games. They seem to make more sense in the context of office or business software that attempts to act as a tool for the user to accomplish some specific task, and where one piece of software might offer many tasks and thus many journeys. Games usually just offer you one 'task' - i.e. the core gameplay loop - and even as the game progresses, the way you interact with the software stays static. So I don't think the approach is very applicable.

(I see User Stories used, but even they seem a bit contrived most of the time. Some places just use a backlog of tasks but don't attempt to write user stories for them.)

Hi Mike,

> In an agile game development user stories are used in the sprint backlog.

If you want to go by the definition, then user stories are one type of product backlog item used to populate the product backlog. A set of user stories (short descriptions of what a player will do in your game if the feature it describes is implemented) that are to be added to a game within a sprint is called the sprint goal. A sprint backlog is that goal plus the plan to achieve it within the sprint, usually in the form of tasks or however you plan your work.

This isn't how you *have* to work using agile, it's just the agreed upon definition.

Like the others, I haven't heard of user journeys, but in games there is often a need for larger constructs of user stories that bring together a narrative of features for the player. I'd encourage exploring user journeys.

Here are links to short articles about other narrative structures I've seen used:

http://blog.agilegamedevelopment.com/2016/04/user-story-mapping-for-games-example.html

http://blog.agilegamedevelopment.com/2016/04/mechanic-driven-development.html

Good luck!

Clint

Thank you all for your replies!

You confirmed what I've found during my reserach, that's good in a way :)

I've found one post about how to apply user journey in computer games. Combined with the player's journey by Amy Jo Kim, I think, I've found my basis for further research.

Thanks!

Yannick

You might want to bear in mind that the player is not always the (only) customer - for big budget games the publisher is arguably the main customer. This confuses some Agile approaches that presume you're iterating to please the eventual user, when in fact you're iterating to satisfy the customer who presumes to know what the players will buy. :)

So the user story is something like: "We had these people make a thing, and then we sold millions of copies of the thing for $60 a pop."