No one can deny that the UX of an application or game is essential to its success. But not everyone has access to a talented and experienced UX designer. As an indie developer with no real talent for graphic design and no training as a UX designer, I have to muddle through and try to do the best I can with what I have. This article shares a few tricks I’ve learned through the years that help make up for my weakness as a UX designer.
Rules
I only have two rules for doing UX design. My first rule is: be lazy.
Through years of practice I have become quite adept at following this rule. But why is being lazy a good attribute for doing UX design? Because it prevents one from doing stupid, cute, things. Sure, some of those stupid/cute things might be brilliant, but most of them would diminish the UX of the product or perhaps take a lot of your development time for no real improvement to the final result. Just like in evolution, there are lots of mutations but only a very few of them will actually be useful.
I have also found that being lazy is a sort of filter for adding new features to the UX of a product. When I think of something new to add or enhance, I usually just make a note of it and then forget about it. If a few people who are testing the product suggest the same feature, then maybe it was actually a good idea. Once I have reinforcement for the idea, I’m motivated to push through my laziness to implement the new feature.
My second rule is: copy good UX whenever you see it.
This one is a no-brainer. Everyone does it, but I suspect that most people feel a little cheap in doing so. I say embrace your inner copycat. If you see a product that has great UX, then copy that stuff and tweak it a bit to make it yours. Every first-person shooter game is a knockoff of the original, Wolfenstein 3D. I’m so glad that no one at Bungie thought that they would be called copycats for creating Halo.
Tips
These are suggestions and techniques that I have found useful. Hopefully some of them will do the same for you.
Beta feedback
Everyone asks their friends and family to offer feedback when a product is in beta. I’ve found that when I ask them to test something and provide feedback, more often than not I get lackluster results. Every now and then someone will take the time to give me thorough feedback, but they are few and far between.
Eventually I decided to bake the feedback into the product itself. Now people would be able to test something out and then at the appropriate time I would take them to a screen that would ask them a few yes/no or true/false questions and give them a field to type in a response. In other words, I improved the UX of being a beta tester. Instead of asking people to email me their feedback, I put them in a space that asked direct questions. And in answering those questions, they would oftentimes be inspired to elucidate their answers in the input field.
This is something that you can include in production, as well. I have experimented with randomly letting the feedback screen appear after a game has been completed. But be careful to respect your users’ time. Don’t continually barrage them with the same questions over and over or expect them to answer questions that will take up too much of their time. I usually aim for something they can answer in less than 30 seconds.
Tracking data
I can’t stress enough the importance of using some analytics package for user tracking. You need to know things such as which countries your users are in so you can make informed decisions about providing translations and such. I use Google Analytics in every app and game I create but sometimes the data they give me isn’t quite enough. So I add in my own tracking code to discover specific details that I might be able to use to make improvements. For instance, I might want to see what sort of frame rate the user is getting during certain parts of the game so I’ll capture that bit of data and send it to the server. This is a bit of a pain to do the first few times but the code is largely reusable between projects. Be careful not to send data like this during the middle of gameplay or during an application process where it would interfere with the responsiveness of the product.
The game shell
If you are creating a game, don’t forget that you have a shell around the game. I like to think of every game as a game embedded inside an application. And that application needs to be as friendly and fun to use as the game itself. Well, maybe not quite as much fun as the game, but it at least shouldn’t suck. So when creating a game, don’t just concentrate on the game interactions. Make that shell something to be proud of. That’s the sort of polish that great games have.
Make the application more like a game
If you are making an application, think of how the users will interact with it and give them the controls to make it as quick and easy as possible. You may think that the internal sales reporting app you are making is boring as crap, but the people who will be using it think of it as a tool to get their job done. Give them the controls they need so that they can run through that app like they were playing a game like Civilization. At the very least, make sure the tab order of the controls is correct. If you can add keyboard shortcuts and controls, then even better. Remember, you will use it as little as possible but the users you are creating it for will use it to death.
Don’t be like Duke
Lastly, don’t be like Duke Nukem. Ship your application or game sooner rather than later and rely on user feedback to help you make the improvements that users want instead of making the improvements you think users want. Believe me, the earlier you can get user feedback the earlier you can make your product exactly what users are looking for.
Think like your users
I find it impossible to do UX design and development at the same time. My mode of thinking for development often blinds me to obvious UX issues. When you’re doing UX design work try and do it early in the morning before you’ve started working on your project. You need to come to your project with fresh eyes. Every now and then you’ll say to yourself, “What was I thinking when I built this?”
Do UX work early
If you’re like me and work mostly on your own projects then you might find that there is often a long period of time between thinking up a new idea for a project and actually starting development on it. Don’t let that time go to waste. You can use it to draw mockups and jot down notes that you might use later. When I start development first without something to guide me I usually find myself writing lots of code that gets thrown away. Not because the code didn’t work, but because I didn’t realize that the UX around the code just wasn’t sufficient. These are often things I could have discovered if I’d just draw some thoughts on a whiteboard for a few minutes instead of diving into code, which is my first instinct.
What do you think? Do you have any suggestions to help others improve their applications and games from a UX perspective?
