Flowmaps and Frag-Grenades, Part 2

I’d like to talk specifics a bit. I’m sure there will be some readers at B&A who aren’t gamers, and probably even more who haven’t played Halo—so my apologies to those folks— but… describe in some detail exactly what you contributed to the finished product.

When I look at Halo 3, what ‘pieces’ of the experience did you work on?

I worked on the IA, navigation and screens for the game shell; the social design for the game for systems such as the party system, matchmaking systems and sharing systems; on rewards systems such as the stats, medals and experience ratings; and also on how that user experience extended to the web through Bungie.net. I also worked on the theater features such as film clips and screenshots, and on the Forge “in-game” UI. My compatriot David Candland handled the in-game HUD in addition to collaborating with me on the design, look and feel for the overall UI and specifically handling the visual design for the game. Aaron Lemay was the art and graphic design lead for our team, including Bungie.net. Max Hoberman was the lead for the entire multiplayer and UI team during the planning stage of the project.

The information architecture and navigation includes all of the screens and flow to support the game experience outside of the game—we refer to this as the “Game Shell” UI. With Halo 3 we started by identifying what the “core game experiences” would be for the game and grouping them into “modes”.

These modes were:

• Campaign:The story mode where players play through an adventure either solo or cooperatively.
• Matchmaking:Players are matched with other players over the internet based on similar skills or experience and based on game preferences to play games that are controlled by Bungie matchmaking.
• Custom Games:Players set their own game rules and maps in a player-hosted game lobby.
• Forge:Players can customize maps to play in Custom Games or to share with the community.
• Theater:Players can view films from any game mode and take screenshots.

Do these modes then inform the IA of the shell?

Grouping the experiences as modes allowed us to start with a foundation for the overall player experience and a baseline for the information architecture. Each of the modes support many options within the mode, but these 5 modes have unique characteristics that support a”focused” player experiences within the mode over a period of time. With the priority that “everything is social,” each of these modes are designed to support from 4 to 16 players either locally, on System Link or over Xbox Live, so we gave each of these modes its own “lobby” where players could gather to share the experience.

In addition to focusing the core experiences in the game, this lobby system sets up the infrastructure for our party system. In Halo a “party” is a group of players that gather to play together, particularly over Xbox LIVE. The party leader is the player who makes decisions for what the party will do together, and the system allows players to stay together and do anything they want without breaking up. In Halo 2 this was termed the”virtual couch”…

Yeah, I recall that H2 was really revolutionary at the time—made it so easy to form a group and hang out for the night…

It’s like sitting on the couch together—if you decide you want to switch from one game mode to another on Xbox LIVE you can do it together just like if you were sitting on the couch with your friend. This is a very big deal on consoles because many online systems do not have this flexibility and it is not always easy to get together and stay together online.

The end result was a fairly simple information architecture for our game shell. Each mode has a lobby. Within the lobby, the specific options are contextual to the game mode. For example, in Campaign the main options are to select a level or difficulty for the story, whereas in Custom games the main options are to select a game type or map to play. The lobbies themselves are “locations” for players to gather into a party and play together and once players are together they can easily switch modes from within the lobby system to travel together to try a different mode. For example, a party of players may decide to customize a map together in Forge, then switch over to Custom Games to play on the map they just created.

The other major areas for player experience are community, personal identity, sharing, and settings. These are very much tied to a player’s personal profile and so in the information architecture these are all presented in a global menu that can be accessed anytime by pressing the “Start” button. The menu is always tied to the identity of the player who presses the button.

Regarding navigation and orientation, our goal was that the player always understands where they are in the game and that menus are in most cases only a couple of levels deep. In most cases the player is only a few clicks away from a core location. Another benefit of grouping the experiences into modes is that the main experiences for the game are easily discoverable from the main menu.

What kind of process did you follow?

The overall timeline for game development was “pre-production” where the studio teams plan what we wanted to do for the project and evaluates scope, then “production” where we execute on the design. At the end of pre-production each team submits an overall design document to the leadership group and the project features are approved. For the interface and experience this was a pretty detailed document for the overall information architecture and screens for the game. This is similar to a product requirements document, but in the games world these are design documents. Over the course of the project the design evolved in some places or was scaled back in other places. A great idea may be recognized well into production and is never discarded automatically, but anything new that is proposed during production is weighed against other features that are in development.

Regarding design process, we targeted the foundation first. The information architecture and systems that would support the different features in the game, as well as the overall guiding principles for the game. This allowed us to understand where everything fit.

Then we tackled the major features based on scope and dependencies. Each of these “major features” would cover many areas of the game. For example, the lobby system would provide the foundation for many other features and was also a dependency in supporting the overall IA for the project. It included the “shell” for the interface, the player roster that shows who is in your game lobby and the core navigation for the information architecture. For each major “feature” set, I would put together a proposal for the feature using screen flow “posters” that outlined flow and also detailed screen requirements. We would then review these proposals with the team members that had an interest in the UI. From there we would refine and build out detailed design documents to support the development. Once the feature was built and in the game we would verify that the features were working according to specification through in-game testing.

We also had great support from the Microsoft usability lab. User researchers were part of our review process and provided heuristic analysis of the proposed designs, and also supported usability testing for both the early “prototype” ideas and later with the actual game.

Would your design artifacts look totally familiar to most practicing Interaction Designers? Wireframes, flows, that kinda thing?

Absolutely. The format I found most useful were poster flows.These are large format posters with detailed wireframe screens, navigation and flow decisions for a feature area. These would include detailed specs and use cases for specific features near the screen or decision point on the poster where they were relevant. I would print these out and post them on the wall near the UI pit, and also post them internally as pdf documents.

The posters allowed everyone in the studio to get an overview of the feature by reviewing the printed poster on the wall, and the engineers and QA team would use the pdf version as the spec while developing and testing the feature. I preferred this format because it was a format that outlined “the big picture” graphically, so it was easy to collaborate and refine as a team. It was also easier to update than a detailed 50 page word document. In many cases, the poster on the wall would be the “most up to date” spec because—as we were developing the feature—our team collaborated to work through issues together using the printed posters, and we would update the poster specification with markers as we refined the direction. The QA team calledthe poster wall the “wall of truth”.

I also put together design documents for the main feature areas such as matchmaking, the party system, sign-in and profile, etc. These were word documents with detailed specs, or in some cases excel spreadsheets. The word documents started with an IA diagram and overview of how the feature worked in context with the core shell UI and that then outlined specific specifications for each feature. Early in the project I also had wireframe”prototypes” in power point to walk through certain use cases to explain an idea and get feedback.

Did you do any prototyping of concepts? And how about tools in general? Does Bungie have proprietary tools for screen design and prototyping?

We conducted rough prototyping during planning to test our concepts in a usability lab or to get feedback on concepts, and we also put together a polished director demo to present the final interface proposal to the team at the end of the pre-production phase.

On the rough prototyping we worked with Randy Pagulayan and John Hopson from the Microsoft Game Studios User Research group to test the concepts in the usability lab. We put together a script for the prototype, then I created wireframe screens in illustrator and John coded the screens into a prototype so that test subjects could use an Xbox 360 controller to navigate the prototype. Randy and John and our team spent about three weeks running the prototype through tests and then rapidly iterating on ideas with matchmaking, the core game shell interface and the party system.

The content was all fakery, I think we called the game in the prototype “Mecha”, but it was designed to confirm the fundamental direction for our user experience. The lab setup and process was top notch and I really have to give props to the Microsoft usability team. The process helped us to refine our thinking and have confidence in the information architecture and core navigation. In fact, the final prototype for those sessions is very close to what we shipped in the final game.

David Candland, Max Hoberman and I then put together a polished demo in Director that was scripted to run through the main use cases for our proposed interface direction. We used this to present our proposed direction to the team and Max and the leads used this to evaluate the direction, gather feedback and reach consensus on feature sets and final direction as we moved into production.

Thanks, Colm!

Note: shortly after Halo 3 shipped, Colm left Bungie to work with Max
Hoberman at Certain Affinity, a game design and development company
based in Austin, TX.