Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
December 20, 2014
arrowPress Releases
December 20, 2014
PR Newswire
View All
View All     Submit Event






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Design Axioms for Game UI – Part II: Feedback
by Dirk Knemeyer on 11/12/12 01:40:00 pm   Expert Blogs   Featured Blogs

3 comments Share on Twitter Share on Facebook    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

Continuing my series on axioms for good UI design in games. You can check out part one here.

Feedback

Today we're going to look at issues relating to feedback: how people can best impact the evolution of a design. Unlike some other aspects, feedback is most likely to be overlooked by the most talented and natural designers. That is because they are more likely to trust their own talent and instincts, and have a clear and interesting vision for what they are trying to create. Often top designers need to be trained in the very need to get feedback in the proper ways, as well as the shape that feedback should take. On the other hand, your average designer is more likely to naturally turn to feedback as a component of their design process. For them, these lessons on feedback are less important from an awareness aspect and more from a method perspective.


Prototype Like Crazy


The best way to improve a design is to get prototypes made as early and as regularly in the creation process as possible. That is one of the reasons why digital game designers are more likely to have coding as a personal skill than art or graphic design: ultimately, to figure out if something is any good, you need to get it out of the laboratory of your mind and into the hands of users.


Pixel Perfect

Remember our Lorem Ipsum lesson from Part I? This is its twin. To evaluate a UI properly you absolutely need every pixel to be in its right place relative to the finished product you envision. Otherwise, there is no way to properly evaluate it.

This is a good moment to emphasize the different between a prototype of your game, and a prototype of your UI. The former should precede the latter. That is, game prototypes should be getting made within days of having the original idea. These cannot be pixel perfect right out of the gate, because the gap between "Here's my half-baked idea" and  "A lot of work has been done, we know we have a good concept on our hands, now let's get down to making it real" does not allow it. UI, ultimately, is the user's manifestation of "making it real". The pixel perfect axiom speaks to that, in particular.

Once you are creating a working UI, one in which you have a set direction for the game and have clearly defined what data and functionality needs to be apparent on the UI, you need to get that to pixel perfection as quickly as you can. Yes, you will likely need to do re-work later. Yes, pixel perfection takes longer than jamming out something that gets it done but looks shoddy. The time spent is more than worth it, because you get correct and useful feedback on the UI earlier in the process. This extra time, iteration and insight leads to having better, more effective UIs in the final product.  


Bitch! Loud and Often


There's a place for praise and compliments. It's called youth league soccer where everyone gets a trophy! Seriously though, the best thing you can do for any design, certainly to include a UI, is rip it apart. Pointing out what you like has a place as well, but ultimately knowing what is wrong and why is the most important thing that can happen in the feedback process. So if you are someone who is getting the feedback, tell people before, during and after that they should tear your design apart and not worry about your feelings. After all, you want to design something awesome, not get some faint praise that leads to shipping something bad. Then, if you are someone who is giving the feedback, mention every little thing you don't like, and have a clear, thoughtful explanation as to WHY. Use respectful language and try to manage the feelings of the creator if they are not taking it the right way. However, in the long run, you simply aren't helping them get to an outcome they can be proud of by holding back. Get it out there!


Eat Your Own Dog Food


This is done much more and better in game design than in the broader software design industry that I come from. The best way to test software design is to be using the software yourself, as early in the development process as possible. For the most part, teams of creators should be people who would be legitimately interested in using the thing they are creating. So not only shouldn't this be too difficult, but the feedback you are getting is from users who are in the target audience for what is being created. That is ideal. However, you also need to have people who don't like the game they’re working on to “dogfood it,” as well. The feedback you get from them will give you interesting insights into other possible players and purchasers, people who are not represented by the fanboys that comprise the typical development teams. The bottom line is, the testers who have the most feedback about the design overall should be yourselves.


Stop Seeking Approval from Others


I've worked directly with more than 100 designers at this point in my career. Lots of amazing people. But there are some not-always-positive designedly traits that I refer to as "They've got the designer gene." One of those is an eagerness to please creatively. You know what I'm talking about: the designer who works late into the night because their manager or client asked for an extra revision. The designer who would rather work extra to satisfy the dissatisfied then ask them for an extra week, or another few thousand dollars. Certainly, this impulse to serve and to please is a noble human characteristic. But in the big, scary world of business it can get in the way.

Another way these traits manifest is by seeking approval. Being afraid to do something new out of fear that it will upset someone. Or, waiting for a sign-off before continuing to keep things progressing. Or, being uncomfortable in more lean development cycles and gravitating to the more black-and-white waterfall processes of old. All of these things, in different ways, represent the designer seeking approval from others.

One of the magical things about design - and Apple has shown us this so many times - is that it is this wonderful opportunity to create something new and wonderful. Game UI is the platform within which the wonderful lives within games. Designers must become comfortable with the fact that, even if they are drawn to please others and would rather give more of themselves creatively than sully the process with aspects of business, they inhabit the role of creator and magician. That is a role that requires different traits, those of boldness, audacity, irrational faith in yourself, and belief in a vision to the degree that you will see it thru regardless of the compromises it requires.

So if you have that "designer gene" or just try to be respectful and responsive and eager-to-please, remember that great design of any kind including the UI ultimately is an act of bold and audacious creation. Take chances. Break rules. Ask for forgiveness, not permission.


Date Your Users


Everything you need to be successful in life can be learned from dating. If you understand how to get people into bed, you have the core knowledge and skills to move people in the way you want and need them in the rest of your life.

Getting great feedback from users requires “dating” them. You know: that time when you first meet someone, are still on your best behavior, and are eagerly and actively doing your utmost to get them in the sack, or keep spending time with you, or get married. Think of your users like a person you are dating. That means pay attention. A poetry professor of mine had the wonderful quote, "Love means paying attention." That single line has transformed my life. The reality is, when you pay attention to something, you are showing it love. And when things are shown love they are naturally compelled to return that love to you.

So:

  • Stay in frequent contact. If they contact you after a period of time, just checking in to see how things are going or if they can help some more, it is a sure sign that you are not paying proper attention. Be proactive and regular in your communication with users. It reinforces that you care, and that they are important.
  • Show interest. We can tell if people are paying attention to us. When working with users that means, when working face-to-face, maintain eye contact, use head nodding and gestures to show you hear and acknowledge them, and take notes to make it clear what they're saying matters. When dealing with them remotely, voice only, be sure to sure you are interested and enthusiastic in your voice. By email, be sure to respond to every single question that they have and be appreciative in your words and phrases. Make them feel like they are making a potentially important contribution.
  • Be responsive. Keep track of who-said-what. When you push the next version, make a point to show Tommy that his comment about the buttons not really looking like buttons was heard loud and clear; after all, see these great, puffy new buttons?! Close the loop so the users can see that they were listened to, and their comments made a real difference. This will encourage them to give you more feedback, creating a lovely little loop of continual improvement.


"Dating your users" will unlock great feedback and insight that will make your UI far better than it would be otherwise.

So those are our axioms on feedback. Next time we will cover the axioms relevant to that most mystical-but-central part of the UI: the interaction layer.


Related Jobs

GREE International
GREE International — Vancouver, British Columbia, Canada
[12.19.14]

Sr. Game Systems Designer
Demiurge Studios, Inc.
Demiurge Studios, Inc. — Cambridge, Massachusetts, United States
[12.19.14]

Game Director
Filament Games LLC
Filament Games LLC — Madison, Wisconsin, United States
[12.19.14]

Game Designer
Bigpoint GmbH
Bigpoint GmbH — Hamburg, Germany
[12.19.14]

Lead Game Designer (m/f) - Hamburg - 3344





Loading Comments

loader image