So when is it the right time to focus on the details? Whether or not you follow an interface first way of thinking when you work on your applications, you shouldn't be obsessing about the little things until the end of your project. Whether that text box is 2 pixels too far to the left is irrelevant until you've got everything working. This doesn't mean you shouldn't be thinking about how you can improve your interface while you're constructing your app...just don't let it slow down your development effort. When you think the functionality is ready...that's the time you can really start making your incremental interface improvements.
One great example of an improvement that is oftentimes almost imperceptible is reducing the number of clicks a user has to make in order to carry out a function. The less a user has to click their mouse button, the more productive they will be. With all we have to think about when developing an application, you might argue that worrying about the number of clicks is pretty trivial, but to users it can be very important. As an example of this, I can think back to a recent event in which one of our companies was converted from Outlook to Notes. Believe it or not, there was quite an outcry from many of the users over the fact that replying to a message in the standard Notes mail template required TWO clicks...first to click the 'Reply' action button and then a second to select the desired action ('Reply', 'Reply with History', 'Reply without Attachment(s)', etc.). Yes...this really steamed some people up. In fact, I'm sure this was the reason that the OpenNTF mail template designers added a single click 'Reply' button. (They even added an option to set the default behavior when using this button, which was a nice touch. Users can setup their desired behavior one time and then forget about it.)
One of the "small things" I'm in the process of adding to an existing "dashboard" application is the ability for users to access the four most frequently used options in one of the linked databases directly from the main page of the dashboard. These were determined through feature requests and some user testing and appear to make a big difference in the end user experience. Rather than opening the dashboard, clicking on the database link and then navigating to the place in the database they want to access, users take advantage of the equivalent function directly from a "drop-down" (implemented with layers!) that appears when clicking on a special icon. In most cases, it reduces the number of clicks by at least one. Even when it doesn't, the really cool thing is that the PERCEIVED amount of work is less, even when it's not. This idea of perceived usability is a big deal and one I'll look at in a future post. Below is a screenshot that shows the prototype dashboard feature in action. While not earth-shattering by any means, it's one more small step towards better usability with a minimal development effort and in that way, everybody wins.