So, how do you come up with user models? The best method is to study the actual users and create a sort of composite of their individual traits. But, where in the wide range of attributes of your real life users should your user model fall?

You should consider that your users will get better with the software as time goes on, but the vast majority will never achieve "expert" status. Your tool needs to address the needs of intermediate users best, so your user model should represent someone at that skill level.

Come up with a name for your user model. A name gives you the ability to discuss the user model with your group effectively.

As an example, let's say we're creating a new level design tool. Most game developers, including designers are male, so our user model should be a guy. Let's call him "Brad" since it sounds like a good name for a level designer to me.

How old is Brad? Well, in game development, design is a pretty young field, compared to art and programming, so Brad should be pretty young. Let's say the average level designer on our team is 27, so let's go with that.

Where did Brad go to school? What did he study? He probably went to a liberal arts school. He could have a degree in Computer Science, but that would make Brad one of the more technical designers, and we want our tool to target those with less technical experience, so let's say he has a degree in English, instead.

Is Brad married? Probably not, but he might have a girlfriend. How does all of this affect how the tool should be developed? It doesn't directly affect the tool, but it certainly has an effect on Brad's personal goals and that, in turn, affects his goals at work. It doesn't take much effort to fully flesh out the user model, and the effort is rewarded by a deeper understanding of the real-life users.

What are Brad's goals? Why did he get into game development? What does he want to achieve in his current position? Once we know the user model's background, we can start to understand his motivation.

Understanding that can help us understand how to create tools that satisfy his goals. Those goals may include making a really challenging game, not putting in too much overtime, getting a raise, or getting promoted, to name a few.

These are high-level goals that ultimately affect tool-specific ones. Wanting to create a complex puzzle sequence in a level may stem from the user's desire to make a challenging game.

A user that doesn't want to work a lot of overtime may want the tool to be fast and easy to use as a result. Someone who wants a raise or promotion will want a tool that showcases their work and gives them a chance to stand out. Ultimately, understanding what your users want will give you the opportunity to satisfy their needs, making them happy, hardworking employees.

During development of the tool, feedback from individual users can be invaluable, but instead of directly injecting the response to that feedback into the software, check the user's ideas against the user model.

Each individual user will have his or her own unique way of working, but what you're looking for is a method that everyone can use well. Catering features to individual requests may leave you with a hodge-podge of interface components that don't fit into the overall picture.

Target specific users based on user models and focus on their goals. These users should be given exactly what they need. Less means they can't do the job; more means the job becomes overly complex. Every design decision should go through the goal filter: "Does this meet the goals of our user?" Only features that meet this requirement should be included in the design.

When goals supersede features, it is possible to find better ways to achieve success through fewer tasks for the end user. Understanding the goals of the user model also makes it possible to find a way to represent the data in a way that suits that person best.

How you respond to these goals to deliver a better user experience in your tools will be different for each tool. Once you do, your users will achieve much better results in a shorter time frame.

Conclusion

You can find the bottlenecks in your development pipeline and address them using the techniques I've discussed here. There are many others available, and you should try to find something that works well for your team.

If you determine that your tools are not as usable as they should be, you should consider redesigning them using goal-oriented methods.

Understanding your users will allow you to deliver software that meets their needs. Once they have the best tools in hand, they're on their way to higher efficiency and output, which ultimately leads to better games.

For Further Information

A. Cooper. (2007). About Face 3: The Essentials of Interaction Design. Wiley.

J. Brooke. (1996) SUS: A quick and dirty usability scale, pages 189--194. Usability Evaluation in Industry. Taylor and Francis.

J. Sauro & E. Kindlund (2005) A Method to Standardize Usability Metrics Into a Single Score. Retrieved December 17, 2008, from Measuring Usability Web site : http://www.measuringusability.com/papers/p482-sauro.pdf

---

Title photo by Nick Johnson, used under Creative Commons license.