Enter The Mind Of The End-User

I wanted to make a quick post about how the end user interacts with our applications, and how we as developers sometimes get it completely wrong. Sometimes we are so engrossed with the code, the how, that we entirely forget how an end user would look at it.

Interface

The actual interface in any application is extremely important. Getting the interface wrong can totally kill a product before a customer even gets the opportunity to try everything out.

An interface has to include everything it needs to, but at the same time stay clean and simple. You want as little of a learning curve as possible. By placing things in logical positions, and using well-known widgets, you can easily fit everything together in an intuitive way.

I would recommend the use of Javascript to simplify your interfaces, and only officially supporting the latest browsers (that is, Firefox, Safari 2, Opera, IE6+). By setting such a requirement, you can use lots of Javascript widgets and finally throw out all of the old “web 1.0″ style pages, which just do not work with a lot of todays advanced applications. Obviously if you have a front-end where normal end-users use, you need to support as many browsers and platforms as possible. But I think you can afford higher requirements when you design an administrator interface.

I’m going to compare two web applications to make a couple of points. The first product is vBulletin, a commercial message board application that is regarded to be one of the best available on the market. The second is DeskPRO, a commercial helpdesk and ticket system. Here are screenshots from the User Search form from each application. I think each app is excellent, these just happen to be screens that illustrate the points I want to make.

If you ask me, the DeskPRO interface is much easier to use compared to the vBulletin interface. When you come to the vBulletin interface for the first time, you get a long page of options. It is a daunting task to go through all of those options and find the ones that are relevant to you. While the two search forms contain different criteria, DeskPRO still displays everything in a manner that is just easier to use.

Logical Separation

You can see the vBulletin page separates search critera from display options and ordering by simply putting those options into different tables. While this works in a way, it still does not let the user quickly scan the page and find the thing he or she is looking for. Even a reference at the top of the page that has anchors to each section would increase the usability of the vBulletin user search page.

The first step on the road to better interfaces is the ability to logically separate chunks of related objects and make getting to each section easy and intuitive. In the case of DeskPRO, you see the use of tabs. I love tabs for interfaces, they’re the perfect tool. Everyone knows what tabs are, what they do, and how to work them. That means you get the value of organization with zero learning curve. Instead of scanning a big long page for the section you want, you can simply click the tab and be presented with the options you want.

Input Overload

The second part is to simplify the options you present to the user as much as possible. Too many options is a bad thing. You may want to offer as much flexibility as possible, but it is easy to go over the line of “just right” and into the zone of “too much” (more on this in a bit).

Two perfect examples of what I mean can be found when comparing the DeskPRO and vBulletin interfaces. The first is the date field. If you want a date, then you should provide an easier way of inputting it then a simple text box. Select boxes seem to be quite popular as it ensures the format of the date isn’t a problem and the input is valid. But in todays world of rich interfaces, there’s no excuse not to use a Javascritpt widget to popup a mini-calendar for the user to select from.

The second example can be found in the number ranges. In DeskPRO you see the user ID range, and in vBulletin you see ranges for many properties from join date all the way down to infraction points. Why does each range in vBulletin span two inputs on two separate rows? This is redundant. If vBulletin were to combine each input box into a single row it would eliminate nine table rows. Nine! How much simpler would the form look at a glance if nine rows were removed?

Help

One thing both applications have in common is the ease at which help can be obtained (see the little help icons?). This is a very important thing to have. While it is always best to strive for a self-explanatory system, there will always be a user who wants some clarification on some aspect. By providing help at the click of a button, you make it that much easier to use your application.

Features

Every developer wants their app to be as flexible as possible. The more flexible the thing is, the happier the customer is because he won’t need to come back as often to request changes. But there comes a point where an application starts to have too many features. At that point the application has become bloated. We’ve all heard that word before, but what does it really mean and how does one avoid it?

To me, bloated software is software that contains too many features I never use and probably never will. Knowing that the features are there can be a comfort, but in the long run, it’s a development nightmare when there’s just so many. A prime example is the newest vBulletin release introduced Podcasting support. Which percentage of the customer base will use these features, do you think?

Features always come at a cost. Every feature you add makes the application more difficult to maintain, it adds to the “size”, it adds more stuff the user needs to look at, and it usually has at least a small hit on performance. To prevent your application from becoming bloated you should carefully consider every single feature before actually adding it in. If there is a large demand for a big feature, consider making it an addon instead of an actual built-in feature. The fact that you aren’t “hard coding” something new into your application will mean the new feature costs virtually nothing unless a customer chooses to activate it.

Besides just bloated software, you run the risk of giving the user too much to think about. Have you ever been shopping for a product where there are thousands to choose from? How hard was it to narrow down your choice to ten? To five? And how hard was it to actually choose the one you finally purchased? Instead of offering ten different things, it’s actually better to offer three. The last thing you want to do is overload the user with options.

Implementation

How to implement a feature may seem a silly thing to talk about, but it’s something that still trips even me up every once and a while. We are developers, remember, so we can’t exactly say how a real end user might interact or interpret our applications.

For instance, we as developers know all about ID’s. To the end user an ID is just a number. A user ID, a forum ID, a ticket ID — all numbers. A username, a forum title or ticket subject — these are the things the average end user thinks about. While providing an ID as additional information may be useful, I still see many applications that list form fields requesting ID’s as a way to identify something. For example, “Enter which forum ID’s you want to apply X to” is not a very usable form. For the average user, a select box that lists the forums is much more usable then an input box.

You always need to be on lookout. As developers, we are constantly thinking about how things work, how the gears are working behind the scenes. You always need to keep in mind that the user likely has no idea about the how things work, they just want the thing to do what they expect.

Developing a good application that does all sorts of nifty things is great, but by the time it comes to adding an interface around it, it’s like trying to proof-read your own work. While you can probably do a pretty good job if you put your mind to it, you need a fresh pair of eyes that hold no assumptions or knowledge of your work. So if you can, grab a friend to look over things and find out if you’ve done things in a clear and concise manner.

The Road To Great Applications: Become The User

I’ve gone over three major aspects of a good application: the interface, the features, and the implementation of those features. The interface needs to be easy to use and navigate, and needs to display everything important in such a way the user can find what he or she needs very quickly. For any application to be useful, it needs to have the features the users want and be flexible enough to fit their needs. As the developer you need to decide which features the majority of your customers actually want as to not introduce bloat. Finally, you need to implement the features in a way that the user can understand easily and use without much thought. To achieve this goal, you have to think like a user coming to your application for the first time. Do these things and I’m sure your products will fly off the shelves.

---

Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically each day to your feed reader.

Devlog | Powered by WordPress | ElegantBlue is a custom theme by Nathan Rice