tldr: iterate, iterate, iterate.<p>Learning how to generate and test design hypotheses both with and without users is really important. I too am programmer and design did not come naturally at first; I had to develop it through practice (and much failure and dead code). I realized after a while developing good UX is not a linear process its cyclic. I'll share some HCI practices that I found worked well for me. These are the steps I usually when making apps for clients or for myself.<p>Before beginning a project I always like to have solid answers to two these questions. They pretty much motivate all my design choices.
- Who is going to use your app? What drives and motivates them to use your app specifically (i.e. why would they use your app and not something else)?
- What do they do right now to solve this problem? What is their next best option? What are the problems with the existing solution?<p>Next I'll make prototypes. Usually I start with paper and pencil or Powerpoint in a very low fidelity. Though it is tempting, I never write a single line of code until maybe a week or two into this process. Right now, your focus should be in exploring as much of the design space rather than committing to one single possibility - nothing is too crazy or outlandish at this stage. Don't use a ruler or be neat - just get it out so you can understand and evaluate it later. Don't worry about the technicalities of how things will be implemented you can worry about that later.<p>Once I have enough ideas I pick my 3 winners. The way I do this depends on the specific problem and its constraints - you should base this on the two important questions I mentioned first. For example, if your user is unfamiliar with technolgy, readability and simplicity might take priority over adding a useful but complicated feature. But if he's a developer, you might keep the jargon and add the features to enhance his experience. Don't stress over this process too much because in the end, this is all just based on just your own educated guesses.<p>Then I make a powerpoint mockup of my favorite idea - basically just slides linking to other slides, with different pictures and animations to make it look like an app. This next step is all about verifying your beliefs and ideas about what you picked. I try to make this as real as possible, adding slides to simulate page loading, using actual iOS or android icons and fonts in my designs but that is a personal choice. Use this mockup to evaluate and test with some users and/or the clients - the things that sometimes you assume or overlook about your users or the problems will surprise you. Consider the feedback and update your assumptions. Now reevaluate your original designs (even the ones you maybe threw out) and fix your mockup. Test it with some users 2-3 times again till no more important issues remain.<p>Now you write your code. This will be your first prototype. Try to be quick and use familiar technology as far as possible. You should have no problems converting your PowerPoint reference to code since you've done it a hundred times before. Add some sort of analytics / tracking so that you can measure important metrics in your app when it comes time to test.<p>Now find a set of users that you would like to test your app with - you could ask friends on HN or Facebook, post on Amazon MTurk or go door to door. Try to get your testers to be as close to the target demographic of your users - ideally your testers ARE your users but sometimes you can't be picky. Show your testers the app and get them to use it. If you can, get them to talk aloud as they use it, describing their thoughts process and action in a think aloud. If you can record this process in a video/audio or screen recording so that you can review it later.<p>Now organize that feedback and analyze it. What is the most common complaint/request your users have right now? Are the problems due to design or implementation? What are the differences between your initial mockup and your prototype and how do they affect the result? Based on this analysis improve your designs, update your code. Do it again a few times if necessary. Once your testers are reasonably happy release it to your actual users and see what they say - chances are by now you should have caught and fixed a lot of the design problems that were too domain specific or hard to discover for you alone and your users will be a lot happier!