I saw this comic about usability (linked from this question at Stack Overflow) and couldn’t help but let out a distressed laugh. How often have you seen this happen at your workplace, or in an application you’ve had the “pleasure” of using? For every elegantly designed UI that exists, there seems to be a plethora of poorly designed ones that do their best to confuse users.

To me, a lot of this UI complexity stems directly from a lack of separation between the UI and business logic layers.

Proper separation

As developers, we’re accustomed to the best practices of modularity and separating the implementation from the interface. This has lead to such patterns as MVC and Interface Oriented Design. However, when it comes to designing the UI layer, these rules sometimes aren’t followed. This is why we end up with overly complex “Search” pages, offering every option under the Sun, and configuration dialogs/screens with a one-to-one relationship to settings files or some other underlying implementation detail under the guise of “letting the user decide what they want”.

Without clear UI planning, this one-to-one relationship tends to rear its ugly head more often. Take our first example of a “Search” page. In most applications, the search functionality is interacting with some sort of a database backend, most likely a SQL RDBMS. The lazy approach is to design the search form based on the format of the SQL query itself. This is how we get search forms with multiple fields, drop-down boxes and so forth – because this format translates almost directly into a SQL query; i.e. of the form WHERE col1 LIKE... AND col2 LIKE...

Just because this is easier for the developer, doesn’t mean it’s the best solution for the end user. In fact, it’s often the case that this is the exact opposite.

Thinking like a user

In general, users don’t care about the implementation of your application or how it stores data. They shouldn’t have to know about the columns of the table where the data is stored, so why make a search form that exposes this? Instead, you need to understand what your users want and how they’re most likely to use your application. This isn’t an easy task, as many have pointed out.

This is where I think most UI problems come from – a misunderstanding of what users want. This isn’t to say that these developers are dumb or careless; but just that when it comes to empathizing with their users, they often are unable to because they know their own software and have such an intimate view of it from a coder’s perspective.

Take the example of QTTabBar, a Windows Explorer extension written in .NET that adds many useful features such as tabs, etc. to the interface. It is an excellent extension and does things very well, but the options page is a complete nightmare.

There are just too many options on this one page; what do they all mean? Furthermore, there are nine more tabs, each with roughly the same number of additional options! This is far too complicated, and I’m guessing most people will never have a use for all of these options.

Of course, it’s completely unfair of me to pick on QTTabBar in this manner, considering it’s written by one guy who has chosen to give it away for free. And, as I mentioned before, it’s a very useful utility that I can wholeheartedly recommend.

A simple story

Take a simply example, where we want to search a set of items, each of which have four separate properties – name, description, URL and tags. The items are displayed on screen with all of the four properties shown. The naive way would be to provide a search form that had fields for each property and allow users to search that way.

But with this simple (albeit contrived) example, there is an obviously simpler solution. Since all of the four pieces of information about an item are shown onscreen, it would be much better just to provide a single search field whose input would be used to search all four properties, returning all items that had a match in any of the properties. From a user’s point of view, this makes sense, since they are searching through what they know they can see and interact with.

If an advanced search was needed, it could be added later, but I would only do this if I knew it was absolutely needed by users, since the simple case is likely good for >90% of your users.