Interactive wireframes and wireframe “storytelling”

I spoke recently at Develop 2011 and GDC Europe 2011 (and also wrote in Develop) about some of our approaches to game design, and there’s been a lot of interest in an approach I call “interactive wireframes” – game designers from other companies are talking about applying the technique and game design students want to use it in their coursework.

This post looks in more detail at how we specified games in the past, and how we switched to interactive wireframes for International Racing Squirrels, currently in production for Channel 4. It also looks at how we used the wireframe in “storytelling” mode to do very early user testing.

Dr Jo Twist, commissioning editor for education at Channel 4, says: “The interactive wireframe really helped me visualise and understand the game, the mechanic and the user journeys that Playniac was building. It was as if, at that very early stage, the game had already been made.”

The past: use-cases

The use-case approach is widely used in the mainstream software industry. We applied it for various games including Lost Army of FuShi, an action puzzle game Playniac produced for BBC Bitesize; and Alien Farm, a multi-user, collaborative, alien herding game for CBBC. The use-case explains a user’s wishes, the action they will take and the results.

On the sample page below you can see the use-case for Alien Farm’s “attractor field” feature, used to attract panicking aliens towards the player’s ship. Players click to switch the attractor field on, at which point its energy starts to run out. It then stops working either when they switch it off or it runs out of energy.

Alongside the use-case we also used a screen flow diagram to show all of the screens in the game and how the user moves between them.

This is how the attractor field feature looked once implemented in the game:

Use-cases look like a handy tool for detailing game features, but we found that in practice they quickly become large documents that are difficult to maintain. They are painstaking to write and, worst of all, no one really wants to read through them, especially when the specification is evolving and there may be many versions. They are excellent at specifying functionality very precisely, but leave little room to manoeuvre in the implementation of the game.

The main issue with the use-case approach, however, is that it doesn’t give a sense of what the game is like to play or how the game’s graphical user interface (GUI) might be laid out, so we decided we needed to find a more visual technique.

The past: static wireframes

Many readers will be familiar with wireframes, and we have used them for many projects including Journey to Fossil Island, an ecological adventure quiz game we created for British Gas.

This was an episodic game, with missions for release over several weeks. The wireframe diagram above shows the mission select screen. You can see that there are six missions that are either completed (the player finished the mission on a given date and with a given score), ready to play or locked (to made available on a given date). The wireframe makes the functionality clear and also hints at the possible layout of the information on the screen, without pinning it down.

Other GUI elements are also indicated. You can see the game’s news ticker at the top, and buttons to view achievements and results. This is how the finished mission select screen appeared in the game:

The wireframe diagram below shows the map view screen for the game. The game features six locations on an island that the player visits in turn, and this wireframe could be created before any of the locations had been designed or even named.

When players complete a level, the location transitions from polluted to clean. The diagram shows two completed locations, and the player about to move to the third. Several interface elements that are common to the previous screen are also reproduced here.

Below you can see how the finished map screen appeared in the game. Here three missions have been completed (the forest, mountains and hills in the background) and the player’s ship (the green blimp front right) is about to arrive at the fourth, a polluted bay.

The benefit of static wireframes is that they give an immediate visual sense of the layout of game screens and their functionality. They are not intended to include or convey any design for the finished screens, even if occasionally they do include icons for conciseness. They are diagrammatic, so they do not convey look and feel or colour schemes.

They also allow some GUI design to be done early in the project and in an abstract manner, and are very easy to understand for both technical and non-technical readers. They are useful for communicating the game to everyone involved and the design and development teams will use them to take the game forward.

We found, however, that the approach does not give a good sense of screen flow and user interaction, so for our next game we decided to take wireframes one step further …

Interactive wireframes

International Racing Squirrels is a race team management simulation that has the player running a team of jet-setting squirrels. They train their squirrels to boost their stats and upgrade them with accessories from a shop, before sending them to race up mountains, across deserts or through futuristic cityscapes. Behind the game play, a realistic financial model simulates real-world consumer finances.

We decided to create an interactive wireframe where all the buttons on screen would be active, although none of the game functionality would be implemented. Interactive wireframe screen layouts look quite similar to their static counterparts, but users can mouse over to reveal tooltips showing relevant information and click to advance to different sections of the game. The entire wireframe is embedded below.

Get Adobe Flash player

The interactive wireframe was created using Adobe Flash CS4, and we used AS2 mode to enable us to work entirely on the tool’s linear timeline using basic instructions, rather than having to write any separate code. The wireframe was delivered to our team and client as an SWF file embedded in a password-protected web page.

One of the main screens in International Racing Squirrels is the home screen, where the player gets an overview of their game and can manage their team, buy and upgrade homes and training activities, view their stats, pay bills, go to races and more. There was a lot to fit on this screen and the interactive wireframe also shows screen items in various states.

Though not usually a feature at the wireframe stage, this diagram gives a sense of the intended setting for the screen. The image in the background, added purely to indicate some intended context, is actually based on an illustration of the Ewok’s village from Revenge of the Jedi!

The completed screen brings those features very much into the world of the game, featuring an up-tree urban training facility.

The diagram below shows the game’s shop screen, where players can buy items such as running shoes and goggles to upgrade their squirrel’s race performance.

The finished screen, below, again brings the screen’s features into the world of the game, with shop items that have been created in collaboration with our writers on the project, Failbetter Games. Just as in the wireframe, you can see that all of the shop items have names, illustrations and stats boosts; we moved the descriptions onto a separate pop-up to make more space, and a couple of items are locked.

The main race screen is also important. It was decided early on that we would not create a first person racing game but, as in management sims such as Championship Manager or Football Manager, we would allow players to build up their team member’s abilities and then watch them perform. We provide some interaction during races in the form of a performance boosting mini-game and various power ups.

The wireframe shows the race position indicator, a loose tribute to Mario Kart, the overhead track overview, the “squirrel cam” showing the team member front-on and the mini-game. We illustrated several versions of the mini-game in the interactive wireframe before deciding on the final form.

The finished game screen shows all of those features in place. Here in the Jungle Tree Run race:

The mini-game only appears when it’s in use – during overtaking manoeuvres, when the game view zooms right in on the player’s squirrel. Here you can see the player wrestling to hold onto second place in the Country Scramble:

Interactive wireframes have all the benefits of their static predecessors and give a clear sense of screen flow. They also give some sense of the game dynamics. They are extremely easy to understand and incredibly useful for the design and development teams as well as the client. So many queries about the game can be resolved by referring to the interactive wireframe that in some senses it can seem as if the game is producing itself.

With some basic Flash knowledge, interactive wireframes are surprisingly easy to maintain once set up, and certainly easier than editing large text documents. They can also be easily delivered over the web. Although Adobe Flash Professional is our preference, interactive wireframes don’t only need to be build this way – a variety of tools, including Microsoft PowerPoint, Apple Keynote and Adobe Flash Builder can be used, each offering different feature sets. There are also dedicated wireframe tools that have some interactive features, for example MockingBird lets you link between static screens. We found, however, that they don’t offer quite the flexibility of the Flash approach. Adobe offers a free 60-day demo of Flash – plenty of time for a beginner to go through the tutorials and create their first wireframe.

Wireframe “storytelling”

An additional benefit of interactive wireframes is that they can be used for live testing. We found this invaluable to get some sense of the game in action early on. For the first time, we took the interactive wireframe into a very early user test for International Racing Squirrels in a London school. The sped-up video below shows a 15-year-old running through the entire game and using all of its features. Don’t forget that this is a game that doesn’t exist yet!

Twist endorses the approach: “The interactive wireframes were extremely helpful for school play-testing because, as we all know, showing people static wireframes just doesn’t cut it.”

The game is being played in what I’d call “storytelling” mode. Off camera a “games master” is playing the part of the software, describing everything that is happening but not immediately viewable on the screen – he might be saying “you have 750 acorns in the bank”, “a popup appears saying your rent was paid” or “the ‘race now’ button has started flashing”.

I was asked by a GDC delegate how this approach was useful if it can’t convey the excitement or visual experience of playing the actual game and so runs the risk of alienating the tester. We are not, however, trying to create an entertainment experience at this stage. By asking the participant to suspend their disbelief, allow us to tell them a story and join us in imagining the result, we are simply trying to understand more about our game.

Another delegate asked me the benefit of using this approach over going straight into a software demo – the method allows you to explore and refine some of the game play very early on and in a very fluid way, without committing to coding anything. To make a change to the game functionality, you simply change the script.


We’ve looked at how we evolved our game design process from using use-cases, through static to interactive wireframes. We’ve demonstrated how the latter not only lets us specify games in detail but also enables us to simulate how the game might play.

But this isn’t the only method we use to simulate an entire game before we start building it. I’m also going to post about paper testing – another approach that we find very useful.