As a professional software developer, my job is to plan, design and implement software solutions to problems. This involves learning about a business problem, the process that is followed, and designing software that makes this process easier or even automatic. Almost all software is written this way and for this purpose. And most developers do a good job of fulfilling goal #1: make it work. However, I've noticed a disturbing lack of attention to what should be goal #2: presentation.

Of course, I'm generalizing. I'm lumping some facets of software into making it work and lumping others into presentation. Let's, for the purpose of this post, go with the following definitions:

• Making It Work - The software is functional and performs expected calculations accurately. The average user can operate the software to successfully complete a task.
• Presentation - The layout of the software is intuitive and optimized for common flows. The performance of calculations is optimized. Common tasks are automated as much as possible.

In business, function is everything. This is unfortunate, because form matters, both in interface and structural design.

Interfacing

The most obvious, and public, example of form is in your user interface. The control layout, the data grouping, the flow all coalesce into an important feature of your software. A good user interface can greatly improve the productivity of your users, which is, by the way, the reason you exist as a software developer. Conversely, a poor user interface can harm your users productivity. Taking advantage of your preferred development platform's (which happens to be C# .NET for me) built in functionality can do wonders for your project; it makes the difference between good software and great software. Simple implementations, such as setting intuitive tab stopping on forms or writing clear and specific error messages, make the lives of your users easier.

Optimization

Most overlooked, and most difficult to solve, is the problem presented by performance that is acceptable. I see code all the time that is never optimized because at some point an algorithmic solution to a problem was found, and even though it isn't as fast as it could be, it just works. Sometimes this code exists for legitimate reasons. There are times when the simplest code is not as performant as a convoluted equivalent. This is rarely the case though. In my experience, this has usually been used as an excuse by people not interested in spending the time to correctly structure or comment their code. I distinctly remember in college being told to always go with the simplest coding option because memory and processing time is so cheap now. To this I say bah. This is the kind of thinking I see that has led to database calls, file processing a myriad of other processes taking minutes to complete when they could have been run in seconds.

Why Should Anyone Care?

You may ask why this matters. It matters because the interaction between the user and the software is a very critical determinant for the success of your software. Your users probably won't be able to tell you that a database call is just a little laggy if they have never made a database call themselves. Your users won't be able to let you know that you should change the tab stop settings on a form or that the work flow for that thing they do over and over all day could be tweaked or automated. Users aren't, for the most part, trained to analyze their workflow in this manner to watch for inefficiencies. Hell, you're lucky if you find out about legitimate bugs before entire business processes spring up to workaround it until you're left with a breaking change in the fix for the original bug.

What your users will know is when you get it right. The right interface and optimization of backend processes can increase productivity. More importantly, perhaps, is the increase in user morale that the right balance can bring. Happy users get more done. Happy users don't dread working with your software. Happy users make your life easier.

A Tale Of Two Designs

The perfect example of good and bad presentation, I feel, can be seen in the current mobile OS wars between Apple and Google. I think most people, despite any perceived shortcomings of iOS in its feature set, one must admit that the presentation and performance of existing features is top notch. The iPhone took off the way it did because everything about iOS was a piece of art. Apple has sacrificed numbers and features in exchange for perfect presentation.

Google, on the other hand, seems to side more with a rich feature set, but with less desirable presentation. Android feels like it's been designed with the average engineer in mind, whereas iOS feels like it has been designed for the average not engineer. This is one of the reasons I'm against owning a phone running Android. I have yet to see a phone running Android behave as intuitively and fluidly as an iPhone. For example, the scrolling animation is always jittery. When I slide a control on the iPhone, I feel like I'm interacting with a physical entity. When I slide a control on an Android phone, I feel like I'm sending a command to a computer and it is having a hard time keeping up with me. That's a purchase (or even a series of purchases) that Google and the respective cellular carriers are losing out on because of a lack of attention to presentation.

These things matter. A lot. There are costs in productivity, morale, and sales associated with presentation. Don't lose out. If nothing else, just consider it another engineering challenge: optimizing your users.