Leaping Into Indie UX

by:   |  Posted on

Show Time: 33 minutes 40 seconds

Download mp3 (audio only)
Download m4a (with visuals, requires iTunes, Quicktime, or similar)


Podcast Summary

In this episode Chris Baum speaks with Donna Spencer, Lynne Polischuik, Justin Davis and Erin Jo Richey at the 2012 IA Summit about their interactive panel discussion Taking the Plunge: Diving Into Indie UX. They share practical and personal considerations of being an indie designer, including how to to get over the fear of making the jump, where and how to find clients, managing the business side of design and what it’s like to work alone.


“When you first start this you are really insulated…when I looked back it in the first six months to a year I didn’t make any money! When you’re in that initial phase you’re really excited… I think if you looked at it objectively you’d never do it.”

“I spent three years working my butt off to have all of the buffers in place… if there’s no work there’s no backup second income. It took a good couple of years to get enough money in the bank… where I could finally start to relax and say no to work knowing other things would come up and not kill me.”

“I got pushed out of the nest with a reasonable size contract.. and I was OK for a couple of years but I look back now on projects I took on that now I never would have taken on… taking on the wrong clients, taking on the wrong projects… I got to a point recently last Fall where I asked am I happy is this where I want to be?”

“I have been an independent for just over a year now… I had joined the agency that would come in as an analyst and then transition to an Information Architect. We decided that they didn’t want to take the agency in the direction of UX or IA and we talked about the role within the company… I didn’t want to focus on the same types of marketing … I did get laid off but I didn’t have a backup plan put in place.”


Thanks to “Vitamin Talent”:http://vitamintalent.com/ and Morgan Kaufmann’s “It’s Our Research”:http://www.amazon.com/Its-Our-Research-Stakeholder-Buy-/dp/0123851300/ref=sr_1_1?s=books&ie=UTF8&qid=1331302670&sr=1-1 for sponsoring this podcast.

And thanks to “ASIS&T”:http://www.asis.org/ for their support of the “IA Summit”:http://iasummit.org/ and this podcast.

How to Win Friends and Influence People Remotely

by:   |  Posted on

Living in Australia and working with team members based in the US and India, discovering ways of being more effective in my job, has become a bit of a hobby. However my situation is not unique. Knowledge workers are increasingly required to work in a distributed manner – in some cases this is working specific weekdays from home, in other cases it involves close interaction with team members spread across continents. Please note this is a rapidly changing area, even in the time between writing this article and its appearance on B&A many things have changed.

Outsourcing (mainly to India and China) and reductions in travel spending due to the recession has lead to more and more distributed teaming. Add to this the reduction in cost and increased availability of broadband, working from home, or moving to Hawaii is increasingly an option both requested by employees and agreed to by employers (in my case Surfers Paradise).

Once remotely located a designers ability to interact with other team members and effect change are funneled through the telecommunication mediums that the team uses to communicate. This article lists the available mediums and analyzes their respective strengths and weaknesses and provides suggestions for their effective use.

Real Time Voice

We have three main types of telephone service: landline telephone service, mobile, and VOIP. Working out which to use, when is not as straight forward as you would think.

Landline phone

A landline telephone in concert with a conference calling system forms the backbone of a distributed workers ability to communicate with team members in real time.

While many thought the introduction of mobile and VOIP would reduce the importance of landlines, in many ways the opposite has been true. Mobile disappoints as a medium for clear communication, and wide adoption of asymmetric broadband systems has in many cases hamstringed VOIP to be as a complete replacement for landlines.

A mobile phone connection has less audio fidelity than a landline, and it has a habit of dropping out or breaking up at the most inopportune moments. In one case in India, mobile providers limit conversations to 60 minutes – requiring tedious re-login to calls that spill over the hour. Added to this, the temptation for calls to be taken in inappropriate places – bars, restaurants, the shopping mall etc. – is too much to resist.


VOIP services on the other hand are a mixed bag. Sometimes the audio fidelity can be of almost CD quality. On the other hand intermittent breaking up of the audio stream and the occasional dropped line can make them more unreliable even than mobile connections.

In my experience, current standard residential DSL and Cable IP services (at least in Australia) do not provide enough upstream bandwidth to allow both a VOIP and web conference sessions to run concurrently without some congestion issues. Of course if you are on the receiving end of a presentation it is not so much of an issue. However when you are the presenter (when it is critical that you communicate clearly), the bandwidth associated with your presentation and your voice stream invariably results in your voice breaking up giving others on the call a bad experience.

Conference Calling Tips

  • Make it a rule not to use your mobile for conference calls unless it is unavoidable, and then make sure you pick an appropriate place to take the call. Defer your turn to present – if at all possible – to when you are close to a landline.
  • Stay off your VOIP line when your presenting unless you have wide (1 megabit or greater) upstream bandwidth
  • Before the call – be sure to provide a agenda for all conference calls
  • Web conferencing – if a web conference is going to be part of the call include the connection details along with the agenda
  • After the call – be sure to send out minutes by email to provide a written reference of call results.
  • It makes sense to invite all call attendees to a group chat session. This can add significant value to the conference call by:
    • providing transparency as to who is currently on the call
    • cueing upcoming presenters
    • managing questions

Asynchronous text

The value of offline text communication is unquestioned. To date this type of communication has occurred primarily using email services, but a relatively new kind of service called “groups” is becoming more popular among distributed teams – for good reason.



  • Ubiquitous – everybody has and knows how to use it
  • Mature – email clients both desktop and web based are feature rich


  • Overuse – important messages get lost amongst the less important
  • Spam – filtering sometimes removes important messages
  • Attached Files – not a good storage solution and file sizes are limited
  • Address book – requires send to, cc and bcc to be managed manually



  • Membership – access to content and automated notifications is limited to group members
  • Suite of service scoped by project– depending on the provider a group offers an array of useful services:
  • threaded messaging, polling, calendar, file archive and link manager
  • One place to go – by centralizing all offline communications a single repository is now available for members to access all recorded data associated with a project
  • Updates – Users can decide what areas of the group they wish to receive notification of updates on and how they are delivered (each update, once a day, once a week etc.)


  • Relatively unknown – groups of all the mediums discussed in this paper have the smallest user base
  • Member management overhead – this is not required if email is used as the primary offline communication tool
  • Usage enforcement overhead- for a group to be effective its usage needs to be enforced

Email while a very useful tool for general communication, is increasingly less effective for teams working closely. Important messages are being overlooked in increasingly large inbox or in some cases removed by aggressive filtering.

Groups can add value to project teams by centralizing all offline communications and automating the notification of updates. Well known implementations include: Yahoo Groups, Google Groups, Basecamp, and Microsoft SharePoint. It must be said that while groups are great for distributed teams they are only effective if strictly enforced as the primary offline communication medium. In situations where members are mixing communications up between email and the project group their value is significantly reduced.

Offline Text Tips

  • Assign a group master at the beginning of each project who’s tasks will be to:
    • create and name the group
    • create and manage team member enrollments
    • create and manage file archive and link folder structures
    • enforce group usage
    • moderate message threads
  • Use standard email subject schema (Project Name : Message Context : Action Description). This allows your team members to more efficiently pick which of your communications they should read.
  • Write conclusions and actions at the top of the message. Don’t bury important content deep inside or at the end of a long message.
  • Keep the airways clear. Email chains on frivolous topics clog inboxes – do not contribute to them if you can resist it.

Real Time Text

Real time text — or chat —is becoming more recognized as a useful business tool. However with the good comes the bad.


  • Less intrusive – more immediate than sending email but less intrusive than a telephone call. Chat is an excellent way to informally communicate with an individual team member.
  • Ubiquitous – almost everybody is familiar with one or more of the popular chat clients
  • Team status – if everybody in the team is on the same chat client it can provide a single place to view the “online” status of your team


  • Distracting – overuse by individuals can detract from work focus
  • Service dependence – while consolidation is occurring, there are still a number of firewalled chat services.

When not over used chat represents an excellent medium to promote informal communication between team members. Chat has been described as the virtual equivalent of the water cooler conversation. This kind of communication can promote innovation as well as go a long way to improve bonds between distributed team members.

Real Time Text Tips

  • Stay logged in – make it a point to log into to your chat client when working
  • Status indicator – always keep your status indicator current, giving your team immediate transparency to your current accessibility
  • Manage your contacts – be sure to create logical folder groupings for all of your chat contacts. This will give context when contacts you don’t often converse with reach out to you.
  • Don’t use file transfer – stay away from chat based file transfers they are slow and unreliable. Use the project group or email instead.

Web Conferencing

Web conferencing, has gone from a nice to have, to a must have for many organizations. In fact in the case of usability research it is the now the norm for user testing of product prototypes. It is not long ago when web conferences were special events organized for clients. Nowadays most calls that involve design issues have a web conferencing session. This is true even with only two parties on the call.


  • Visual stimulus – when integrated with a conference call, a web conference can show presentations, mockups, and other documents.
  • Other services – Commonly bundled services include: polling, white board, agenda, meeting minutes, chat, and meeting audio/screen recording.


  • Single sign-on – as is often the case separate authentication is required to enter the web conferencing system. Very few systems integrate phone, web and group functionality, current systems often require users to login multiple times.
  • Browser dependencies – many web conferencing systems require specific platforms and browsers
  • Bandwidth intensive – presentations rich in graphic/photographic material can over tax bandwidth resources causing audio and visual lag between presenter and viewers.
  • No standard interface – it seems every web conferencing system takes a unique approach to its user interface, making it difficult for users to transition between different systems
  • Screen size dependencies – some systems do not cater well to different screen resolutions between conference presenter and viewers.
  • Expensive – web conferencing systems are expensive to subscribe to, buy, and maintain for individuals.
  • However this is changing rapidly with Powerpoint to flash conversion tools and built-in screen share facilities such as those found in Skype and iChat.

Web conferencing is a major boon to distributed teams. As the market for these services matures we will see big improvements such as integrated video cam capture, audio recording, speech to text by current vendors as well as the emergence of new extensions to chat and VOIP clients which traditionally have been free.

Video Conferencing

In the past, video conferencing required expensive dedicated systems. Web based video streaming and integration with popular chat and VOIP services has started to change this. However to date the use of real time video as a business communication tool has been low.


  • Visual cues – in a one to many situation a head and shoulder video stream of the presenter can provide viewers visual cues missed in conference calls
  • Relationship building –in a one to one situation being able to see the person you are interacting with increases you’re ability to communicate and bond faster


  • Bandwidth dependencies – video streams are bandwidth intensive
  • Client dependencies – many of these services are tied to chat/VOIP providers that require specific platforms and browsers
  • Small user base/Low take-up – the value add of person to person video in a design context is still tenuous. This however may change when functionality arrives to enable three or more video streams to be viewed concurrently.
  • Immature culture – the fledgling nature of this type of communication means there is very little culture in acceptable behavior.

Video Conferencing Tips

  • How you look influences peoples perception. As such how you light your face, what you wear, and the background behind you are all factors that should be considered when using real time video for business purposes.

Real time video brings marginal value to distributed teams. At this time it could be described as a nice to have, especially in situations where bandwidth is scarce. In the future it may become more important especially if integrated into web conferencing systems where the presenter’s video stream is included in the web conference stream.

UX Book Clubs

by:   |  Posted on

In early Nov 2008, I started to talk to a few people about the idea of a book club in Sydney to discuss User Experience (UX) books. Russ Unger and Donna Spencer encouraged me to let other people hear about it, and when I did – through the Information Architecture Institute (IAI) Members discussion list, and then through the Interaciton Design Associaton (IxDA) – many people thought it was a good idea.

And then something surprising happened, people liked the idea so much that they started doing things to make it happen. Andrew Boyd registered the “uxbookclub.org”:http://uxbookclub.org/doku.php domain, set up the wiki, and starting the content rolling. Will Evans designed a logo, wrote a whole bunch of content, set up a decent structure, and let everyone use either, or both, if they wanted. Andrew’s been in on the wiki each day tidying and gardening, making sure it doesn’t get out of control.

First one volunteer, then another, and another put their hand up and offered to organize a UX Book Club in their local area. New York City joined Sydney, Canberra, and Washington D.C. By the end of that first week over 28 cities had a local UX Book Club under way, and nearly 400 people had signed up to take part.

The first meeting was held in Silicon Valley in mid-December, followed by meetings in New York and Los Angeles, Philadelphia, Chicago, Canberra, Sydney & Austin. Through the second half of February meetings were held in Atlanta, Minnesota, Melbourne, Tel Aviv, Brisbane, Toronto, London and Chicago.

The What and the Why

UX Book Club is a fairly simple idea: get a group of people together, choose a book, and agree on meeting details. Go away and read the book. On the date set, come together and discuss the book. Talk about how you might use what you’ve read in your work; how your experiences run counter to the book; an example of how the book is spot on. Have a bloody good argument about it, then go have a drink and talk about it some more.

At a UX Book Club you have an incentive to read some of those user experience books you’ve heard about but still lays on your bookshelf. You discuss the book with other UX practitioners, which will help you get more out of the book. And you meet fellow UXers working in the same town as you.

You also hear about a lot of books that other people have read, found interesting, but aren’t suitable for discussion by the group. That may be because they’re too long, or highly specialized, or too expensive for a large group of people. Hopefully, though, you’ll be exposed to a much broader range of books than you do on mailing lists or blog posts currently.

How It Works

The Sydney meeting – held on February 3rd – seems to have been fairly typical of the experiences across the board – with local variations in terms of weather, location, and numbers. But the stories seem to have a consistent theme: great discussion, lots of energy, and a good time had by all.

“It was fairly incredible how natural — how routine — it felt. I mean, here was a group of people, many of whom had never participated in any community event, and none of whom (to my knowledge) had ever engaged in an extrinsically focused book club. The book became the medium for discussion, though the topic remained entrenched in UX and design.” 
- Jonathan S Knoll, UX Book Club NYC

UX Book Club Sydney held the February meeting at the offices of the “News Digital Media”:http://usit.com.au team in their “New York Lounge”. Their hospitality was greatly appreciated, and the space was perfect for the event.

The event was structured along the same lines as those used by New York City (thanks to Cindy Chastain) and applied successfully in Los Angeles. The meeting opened with a brief welcome and introduction, then a volunteer from the group gave a 5-minute overview of the book (in our case Bill Buxton’s Sketching User Experiences). We broke into two groups (10 and 13 people, respectively) and headed to opposite ends of the Lounge to discuss the book in detail. Cindy’s rationale for the smaller groups was that they give everyone a much better opportunity to contribute to the discussion – and this was borne out by the comments I received afterward.

After a good solid hour or so of group discussion we came back together, had a bit of a recap, thanked everyone for attending, and relocated to a nearby pub to carry on. The ‘official’ proceedings kicked off at 6pm and ended just after 8pm. The ‘after-hours’ discussions wound up around 10pm. Not bad for the first event.

The entire event was terribly uncomplicated, and I highly recommend the format. Better yet, the discussion highlighted areas of the book I hadn’t really considered important on first reading. This new information encourages me to go back and re-read those parts, armed with some real-world anecdotes to help make it more concrete.

“UX Book Club got me to finally pick up a book I had been meaning to read, and to have the chance to exercise my brain a bit. I found myself waxing philosophical with my fellow book clubbers about education and urban planning, as well as positive (and negative) user experiences we’ve had.”
– “Roz Duffy”:http://stellargirl.typepad.com/stellargirl/2009/02/my-current-muse-ux-book-club.html, UX Book Club Philadelphia

The events serve as both means and end. Reading the books being discussed is a good thing, in and of itself. You will get more out of the event having read the book, and the overall level discussion and engagement will be higher for everyone.

But reading the book isn’t required. The book acts as a starting point for a wider-ranging discussion around the topic. Each person brings not only their understanding of the book, but alsp the full breadth of their professional and educational experience to the discussion. So whilst reading the book provides everyone with a common frame of reference, the really interesting discussion arises from our differences.

“Most UX people I know are web interaction designers like me, but the book club drew developers, software UI designers, business strategists, visual designers, and various flavors of agency and in-house IAs and IxDs.”
– Sarah Mitchell, UX Book Club Los Angeles

In saying all that it’s also important to recognise that no two UX Book Clubs will be the same. The books will be different. Some groups will meet monthly; others every alternate month. Some will be small affairs with half a dozen folks and others will be big (30+); and some will be more book reviews than book discussion. And that’s OK. What’s important is that we learn something, meet some people, and enjoy ourselves in the process.

“…And that sort of set the tone for the rest of the event: high-energy, engaged conversation, a fertile middle ground between events where there is a single speaker with everyone else semi-passively engaged, and free-for-all cocktail hours, which are fun and great for networking, but lighter on substance.”
– “Anders Ramsay”:http://www.andersramsay.com/2009/01/17/taking-the-ux-book-club-to-the-edge/, UX Book Club NYC

Getting Involved In UX Book Club

There are two ways to get involved in UX Book Club. The first is to sign up to the group in your local area. A list of existing UX Book Clubs is available on the wiki at “uxbookclub.org”:http://uxbookclub.org. There are around 50 groups already listed – including some groups that are just forming. If you’re working in UX or would like to learn more about the field to help with whatever work you are doing, add your name so that you can be kept informed.

The second way to get involved is to start your own UX Book Club in your area. We’ve found that the best thing to do add your city or town to the wiki list, then post a message to the IxDA.org or IAI mailing lists (or both) letting other people know. We’ll send an announcement out via “@uxbookclub”:http://twitter.com/uxbookclub on Twitter to help spread the word. If you have a local IAI, UPA, or IxDA chapter, tell them about it at your next meeting.

I’ll leave with you a quote from Whitney Hess (UX Book Club, NYC) that echoes the sentiments of so many UX Book Club attendees:

“These books really aren’t meant to be read alone — they’re references as well as jumping off points for exploration of the practice. It was great to hear what others thought of both the content and its context in the greater body of work, book-form and otherwise, that our community has produced.

I’m really looking forward to the next event.”

Flowmaps and Frag-Grenades, Part 2

by:   |  Posted on

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.

Flowmaps and Frag-Grenades, Part 1

by:   |  Posted on

By any measure, Halo 3 is one of the most wildly-successful consumer software interfaces in recent memory: more than 1 million players played the game in its first 24 hours on Xbox Live; over 8 million copies sold to date; and “over 100,000 pieces of user generated content being uploaded daily […] 30 percent higher than YouTube on a daily basis.” It’s probably safe to say that more cumulative man-hours have already been spent in Halo gaming lobbies than in Microsoft Word! But H3 is distinguished for another reason, too. It’s one of the earliest—and definitely one of the highest-profile—mass-market video games to benefit from the contributions of a dedicated interaction designer.

Colm Nelson was the interaction designer for Halo 3 and has been a working UX designer since 2000. Before joining Bungie (the Studio that produces the Halo series), Colm’s background was largely in Internet consumer applications, with a heavy bent toward entertainment software. Colm’s experience is unique, but it’s part of a growing trend in the gaming industry toward employing UX professionals. Colm would like to see this trend continue, and was gracious enough to speak about it with us, and share some insight into the intersection between his ‘traditional’ UX background and his job duties at Bungie.

Hi Colm—I’d like to thank you for taking the time out to speak to the B&A community. Given the audience here, I thought this emerging trend—this matriculation of interaction designers into the gaming world—is something that folks would want to know more about…

Online systems that facilitate player experiences around social interaction, custom content sharing and online communities have received a lot of attention by both the gaming press and fans and is definitely a hot trend in gaming. The gaming press has even begun to draw comparisons with these features to You Tube, My Space and Facebook. My observation is that developers that are offering more features in [the] user experience around the game are seeing more of a need to specialize and fill roles specifically around user experience and interface design.

Games with success in these areas have generally done a good job developing a solid feature set and matching the social goals of gameplay with the accessibility and usability of the features. Ultimately these features add to the longevity of a game’s popularity, which translates directly to sales. I think as a result there are more opportunities for traditional interaction designers in the games business.

I’ve met developers that are actively recruiting from traditional software interaction design to take ownership of these features and if you look around you’re starting to see postings for UI designers—both Bungie and Blizzard are actively recruiting interaction designers and experience designers. There are also studios that are championing player experience research and design such as XEOdesign, Inc.

But I also think that if you look around you’ll see that it’s not as clearly defined role in all game companies as it is in traditional software so I think as a trend it’s fairly early. My impression is that in many game companies the interface and experience design in games is handled by either designers or artists that are also responsible for the overall game design. The good news is that if you are an interface designer with a passion for games, there are definitely opportunities out there.

Let’s start at the beginning. I actually remember seeing the job req. at Bungie that you filled … it even used the term ‘Interaction Designer.’ My jaw almost dropped—design jobs in the gaming industry typically focus on character design, level design, gameplay and mechanics. How did Bungie ‘catch religion’ about strong interaction design? About paying attention not just to the core gaming experience, but also all of that scaffolding that gets you into the game? The experience around the game?

Yeah, I had the same reaction when I saw the posting. I’d been looking for opportunities in the games industry for some time and had not seen any positions related to interaction design, so when I saw the posting I was amazed.

The guy that hired me, Max Hoberman, was the online, UI and multiplayer design lead for Halo 2. Max and the team at Bungie are really passionate about the user experience around the game and also about usability. It’s just part of the culture of the studio. You can see the results from the design of the party system and the matchmaking system from Halo 2. Heading into Halo 3 there was plenty of ambition for the social experience and with features for the game so the team decided to hire a dedicated Interaction Designer.

And how did you get the job? 😉

As soon as I saw the position I put together a portfolio and cover letter that said I wanted to help Bungie in their quest for world domination. I managed to get a phone interview with Max, which went OK. His feedback was that he enjoyed our conversation but if we had a second conversation he expected me to be more critical with my observations about what could be improved from Halo 2 and Bungie.net. This was on a Friday. The “if” felt pretty dicey to me so I decided to be proactive.

I worked all weekend on a concept document on ideas to improve Halo 2 and fired it off on Sunday night at 3am. I wasn’t sure how it would be received but it paid off because I got a invitation to visit Bungie for an interview. I flew to Seattle to meet the team for a full day interview and was really impressed with the energy and passion that they had for design and the experience around the game. It was a lot of fun—I was also passionate and the interview felt like a series of brainstorming sessions as we discussed problems and ideas and how we might solve them. I guess it went pretty well because they offered me the job!

Describe the development team to me. I (like you, before your time at Bungie) come from a web & consumer applications background with roles like Product Manager, Project Manager, Developers, Designers, Researchers. Is game development roughly the same? How were you situated on the team?

There are similarities. It is still software design so all of the practical considerations still apply—you need to manage the project well in order to succeed and you need the resources to make it all come together. Producers, engineers, designers, researchers and QA all play a role on the team. Producers at Bungie are roughly equivalent to project managers from my previous experience, although I think the producer role varies quite a bit across studios. But at the same time you have cinematics, art, modeling and animation that are also core to the project.

There’s really not a “product manager” role, at least at Bungie. The team makes pitches for the game, the leads of the studio then decide what will be greenlit for production, and the team leads propose and drives feature sets for the project. It’s a very collaborative process and it is driven by the leads of the various disciplines. An example is that in designing the online experience and interface plans we solicited feedback, then proposed features and prototyped “proofs of concept” in order to land on the feature sets that would be developed for Halo 3.

Was there a bit of culture shock moving into the gaming world? Did folks on the team generally ‘get’ what you were brought onboard to achieve?

Yeah, there was a bit of culture shock for me. Mainly because some of the tech, process and roles on the team were new to me. As far as people getting my role, I’d say it was about the same as what an interface designer typically encounters when joining a new team. Definitely the core team responsible for interface and social design had clear goals for how the interface design process would work and understood what I was tackling—we tackled it together as a team. I was really surprised at how important interface design and usability was to the entire team—it was awesome! And at a higher level, even if all the folks didn’t get the details about process, they were supportive and as a rule folks at Bungie are really good at giving feedback on concept proposals and contributing ideas.

[Stay tuned for another installment of Colm Nelson, designer and gamer.]