The answers to these questions can sometimes be very enlightening and can help you frame the context of your work in a more user-friendly way. Here's a recent example from my own experience:
I'm putting the finishing touches on a simple workflow application. It actually has a few neat and unique features, but most of it is the standard stuff. It happens to be a sister process to another application that is already in production, so it made sense to design the look and feel of the app to match the existing one. All of this makes for fairly tedious design work. Once most of the application was complete, I took a step back to review some of the functionality. One of the first things that struck me was that I had a really great feature on the main screen but I fell into the trap of making the user do the heavy lifting.
Sticking with my common theme of getting the user to their data as quickly as possible, I have a data entry field on the main screen that allows the user to input the unique identifier for the document, which takes them right to the form in question (assuming it's found).
For this particular application, documents are numbered according to the last two digits of the current year, followed by a "-" and then a three-digit sequential number (e.g 07-006). In my initial incarnation of this functionality, I just took the value the user entered into this field and did a lookup by key. If I found a match, I opened the doc, otherwise I told them there was no such document in the database. After spending a little time reflecting on this, I did some research into how users actually use these numbers. When communicating about a particular EWR, did they say "O seven dash O O six" or just "six"?
Turns out (not surprisingly) that there's a lot of variation about how people remember these numbers and communicate about them. This fact made me go back and rethink how to write the code so that it would simplify the act of finding a document for most of the users. With just a little extra effort, I was able to modify the code so that users can type in a variety of different formats and the document will be found. Using the example above, they can now type in:
If the user leaves off the year designation, then I assume it's the current year. They can choose to enter just the significant digits of the EWR number and in the code I simply manipulate the string they enter to use as my key in the lookup. I even check for ambiguous entries, so if they enter something like "06-", I then bring up a dialog box showing all of the 06-xxx documents. Overall, I tried to address the main ways a user might enter a number so I don't have to bring up a nasty error message telling them their document couldn't be found. I know it's really frustrating for me when I use an application and I am sure something is out there, but I just don't have the correct syntax to find it. It's empathizing with this frustration that inspired me to go back and work on the lookup functionality. Fairly trivial? Yes, it is, but add up the small gains like this and you end up with a much better user experience. With the new functionality, the user doesn't have to spend time thinking "what is the format I need to use to find a document?". Instead, they can just enter the number in the format that they are used to and they'll be whisked away to the document.
I encourage you to try this the next time you are building something new or tweaking an existing design. Try to find those places where you are asking the users to do more work than is necessary and then use your skills to make it easier for them. After all, as the developer, you've got all the muscle.