We stand with Ukraine and our team members from Ukraine. Here are ways you can help

Home ›› Analytics and Tracking ›› UX Tips for Non UX Designers

UX Tips for Non UX Designers

by Dan Florio
6 min read
Share this post on


Some tricks for non-pros to help make up for UX design weaknesses.

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.


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.


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?

post authorDan Florio

Dan Florio, Dan Florio was an average designer who learned enough about writing code to become average at it as well. But he liked coding more than designing. Besides, it makes a great deal more money. Plus, all clients think they can design and create good UX. But none of them think they can write code. Back in 2008 he quit working for Microsoft XBox and became a freelance developer. It seemed that Flex was in high demand so he set out to teach himself to become a Flex/Actionscript developer. He needed a good project to work on that would push his skills to improve so he turned to an old idea he had about making a website that would help people know the best times to run and pee during a movie. He built it. Named it RunPee and then watched it spend a year being lonely and getting no visitors. Then someone in the media - Leo Laporte - learned about it. And others learned about it from him and so on and so on. Eventually Dan was doing radio interviews for stations as far away as South Africa. RunPee was surprisingly a success. Dan now lives in the South Bay area of Los Angeles where he is working hard - hardly working - to create another successful project. Most aren't but it's fun trying. You can read Dan's developer blog at polyGeek.com.


Related Articles

Did you know UX Magazine hosts the most popular podcast about conversational AI?

Listen to Invisible Machines

This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and