Mike-O-Matic

Being a web programmer is hard work. To be successful at it, one needs an intimate knowledge of many different languages and technologies: SQL for talking to databases, JSP/PHP/Coldfusion/ASP/Perl/Python/Ruby/etc to handle the dynamic functionality, and HTML/Javascript/CSS for the front end. In addition, they need to know the optimal way to fit each of these things together into a useful whole. This means learning frameworks, APIs, and design patterns.

Oh, that’s easy, you might say. Specialize. Get a database guy, graphics guy, and programmer and let them do their things. Get a tester to make sure it all works. Unfortunately for most IT shops this is a dream, and a distant one at that; individual developers are usually pressed into service building complete end-to-end solutions by organizations that either don’t understand the complexity of the work or can’t afford to bring in the additional staff.

It’s a miracle we even get up in the morning.

A byproduct of this “one man army” approach, developers are forced to do things that might not always be natural for them. Usually people who are competent in the more analytical parts of the job, such as the database and dynamic tier, aren’t quite as comfortable with the subjective and mushy parts, like GUI design and usability.

I’ve seen it many times.

Once I worked at a company that had a survey design tool, meant to be used by other employees of the company to build web surveys for external clients. One of the challenges that the designers of this application had (this was before I arrived) was that the clients were very finnicky about having the surveys appearing just so; they wanted pixel level control and the ability to handle any type of question anticipated or unanticipated. To accomplish this herculean task, the designers decided to make the surveys consist of multiple embedded HTML tables; theoretically, the survey builders could just break down the surveys into a grid and manipulate the cells as needed to get the appearance they wanted.

When it came down to implementing the interface for this tool all hell broke loose. Tables showed up everywhere with arcane icons in them for adding text, subtables, and form inputs. Each cell had an interface for editting it with field names like “Colspan,” “Padding,” and “Validation Javascript.” All of this made sense to programmers, but our end users were not programmers. Additionally, editting existing surveys was near impossible since digging down through layers of tables was difficult and having validation logic embedded in Javascript within individual table cells made changing anything very risky.

Granted, this is an extreme case, but I believe it demonstrates what can happen when programmers design user interfaces in isolation. Technically everything that was there was correct, and it worked as advertised. Practically speaking, it was useless for the end users and the developers themselves had to do much of the survey building for them.

Fortunately, designing user interfaces doesn’t have to be so complicated. Here are some tips to make it work for you.

1. Start with the End in Mind: After you get the determine the specifications but before you start coding and building the database, throw together some activity diagrams that will describe how the user will navigate through the application. Check them for sanity. Then start throwing together some rough sketches of the screens that would result.
2. Think Sequentially: When designing an interface, picture the optimal case in which you would like a user to do the data entry. You should be able to describe succinctly to your users the order of events.
3. Don’t Get Cute: There has recently been a proliferation of neat AJAX-y and Web Service-oriented widgets you can add to your website. Before introducing them to your environment, ask if it really helps the end user’s comprehension of what they need to do. For example, I have seen Google Maps mashups that have you click on a location in order to get to the next screen in a form. Most users won’t understand what to do here without needing to read some documentation, and nobody reads documentation. Speaking of that…
4. Don’t Count on Documentation: Generally nobody reads introductory text or anything else on a form (aside from the field names) before they start to fill it out. If your application counts on written descriptions to guide users from one step to the next, you should probably re-evaluate your flow and make the forms more obvious.
5. Group Things: There are some underutilized HTML elements that can be used to make your forms cleaner: FIELDSET and LEGEND. FIELDSET draws a nice box around your form or subform and LEGEND gives it a title. Using these elements lets your group logical form fields and give users a clue as to how to approach your form.
6. Web Apps Aren’t Database Interfaces: If your web app looks a lot like phpMyAdmin, you may want to change it. Your application should provide more value than that. Come up with abstractions that hide some of the “rawness” of the database. I once worked at (another) place that had a field labelled “TPL Provider” because that was what they called the column in Oracle with its no-digits-in-column-names policy, rather than the term “3PL Provider,” which is, you know, a real thing. (3PL stands for third party logistics) Don’t let this happen to you.

Follow these tips and you should be well on your way to a good user experience.

Til next time.

Subscribe to this Blog!