It is very easy to forget about this. This is something especially programmers are susceptible to. We see programs from entirely different perspective. We understand how they work internally. Whole outlook of the program may be almost coincidental and just a result of a need to expose some functionality we happen to need.
This is the very problem that leads to poor user experience (UX). Even though the program may be used to achieve some specific goals, it isn't quite optimized for that. Instead you'll have a jumble of functionality you are supposed to be able to use somehow to get your thing done. Welcome to a world of pain.
Passionate Users
By definition, when you make something no one hates, no one loves it. -- Tibor Kalman
In my mind UX is all about passion. You want your users to be passionate in love it or hate it kind of way. Apple is a good example of this. They have hordes of very passionate users while there are also those who hate their products vehemently.
Now the question is how to achieve this. What can we do to make our users passionate?
The very first thing we can do is it rethink the notion of a user. Commonly we tend to see the users as some kind of a black box. They are just the people using our product. This is very counter-productive.
Personas
In order to make our users passionate we need to understand who they are. One way to do this is to model them using personas.
Personas present a set of archetypes that exhibit some characteristics of our actual users. They give us a way to sympathize with our users. Instead of treating the user as something generic, we have something very specific.
This is extremely valuable as it allows us to map the actual goals of the users and help them to achieve them as smoothly as possible. Goals may be analysed further and split up to concrete tasks. Each task may represent a specific piece of functionality in our program.
Personas and their goals provide a starting point for design. They provide a set of constraints that you may use to solve specific problems. While at it you might want to apply design patterns , proximity laws and all kind of theory you have available at your disposal.
What's in it for programmers?
By figuring out early on what we really ought to build, we get our development on a better track earlier on. Instead of hacking up something and hoping it works we can produce something better straight from the start.
The main problem with hacking is that you end up with something that has inertia of its own. Nothing is easier than to justify decisions based on the fact that something has been done already. Bad decisions tend to follow us around.
Traditionally UX design has been the last part of the software development cycle. This is just plain wrong. You simply cannot polish a turd. It is better to move UX design to the front of the process and let it guide rest of the development work.
This same problem applied to testing earlier. It was treated as something of a necessary bad. Nowadays the value of testing is understood better and it's taken in count earlier on. Techniques such as TDD embrace this idea.
I believe UX design may help in testing as well. By understanding what your actual users need, you get to understand requirements better. These requirements may be in turn be transformed into a set of tests. A classic example of this is acceptance testing.
Conclusion
In this brief post I wanted to highlight some points I learned especially from Alan Cooper's book "The Inmates Are Running the Asylum". Although the book is a bit dated it has some intriguing points.
Just to summarize remember to think about your actual users every once in a while. Understanding this seems to be some kind of a key to success or at least a less spectacular failure. :)