In testing, evaluating and recommending fixes to web-based applications, I continually come across the same problems — what I would call classic user interface design mistakes. These mistakes inevitably have repercussions on an organization’s bottom line, either affecting its overall costs to support the product (tech support, training time), or as a threat to customer satisfaction with the product (and consequently with the company). It is therefore vital to find and fix such design flaws as early as possible in the development process.

Mistake #1: The “me too” feature set

Here’s one problem that never seems to run out of steam. The mistake is in appropriating features that are used on other sites and services simply to get on the functional bandwagon, without thought as to how the features integrate into the application. This is particularly problematic when there is more than one contributor to the feature set.

There is nothing inherently wrong with borrowing conventions — after all, the web has thrived on it - but a necessary first step is to consider the goals of the application. What do you want users to be able to do with it, and why? Only then does it make sense to consider how different features can help you accomplish your goals.

One way of preventing this design mistake is to insist on getting business (or user) requirements rather than specific feature requests.

Mistake #2: Talking in jargon

You may not know you have jargon in your application until you sit a prospective user down with it and discover that he or she has no idea what some of the words on the screen mean.

There are different flavors of jargon, including industry jargon (common in B-to-B applications, but also to be found in consumer applications), technical jargon (typically, terms used by developers to describe parts of the application itself or items in the “software world”), and proprietary jargon, which are words or names invented by you, your team, or your company as part of your branded product or user experience. All of these are potentially confusing to users, and can trip them up as they try to use your web application.

All types of jargon should be reduced or eliminated wherever possible. If you must use proprietary terms or names within your application, provide definitions for the terms or otherwise clarify what they mean.

Mistake #3: Too little guidance

Another common error in application design comes out of the assumption that the user knows where he’s going. He may not, and your application may not be guiding him sufficiently through the principal flows. Users may simply not know how to start a process, what to do next in a flow, or how to finish a task unless you guide them through it. If you don’t, they may also wander all over your application, and take circuitous routes to finding information.

Insufficient guidance on data entry (such as how to format dates or enter passwords) can also lead to a frustrating cycle of error messages. Providing clear, prominent instructions with simple examples can alleviate this issue.

It should always be obvious how to start, how to proceed, and how to finish a task. Simple techniques for helping a user through an application include prominent page prompts and default button styles.

Mistake #4: Putting “help” out of reach

Most users need some form of assistance at some point in an application, especially within complex flows or processes. However, some will prefer a prominent 1-800 number so they can call for support, some prefer context-sensitive help pop-ups, and some like to check the FAQs (and will expect to find their answers there).

But almost universally you will find that users agree on one thing: help should be close at hand. Burying the answer to a common user question too deeply in a general help section, or hiding that 1-800 number, is not going to win you any points with your users and customers.

The solution to an overly remote help service is to update your application to reflect answers to actual questions users are asking, to place your support phone numbers on the headers or footers of all pages, and to provide as much in-context help as you can. If your application is extremely large or complex, you also need to ensure that the help is constructed in a standard format, so that users can quickly and easily navigate or search it.

Mistake #5: Lack of Page Focus

A lack of page focus usually manifests itself as pages that have too many things going on, and too many places to look. You can almost hear the designers or developers in the background: “There seems to be a little extra screen real estate here…why don’t we stick in….” We’ve all been on the receiving end of this problem, but when it comes to designing pages, there seems to be a “more is more” mentality with many design and development teams. At the heart of this classic mistake is a lack of goal-setting for each screen or page. Where or how does it fit in the flow and the overall site structure? By setting these goals out on paper in the site architecture or in flowcharts, you can prevent much of the visual noise that happens as applications develop.

Mistake #6: Not getting user input

While mistakes #1-5 are all about the user interface, this last classic problem is about process, and it underlies many of the others. Most development efforts I’ve had to “fix” had this as the core problem — the design team never sat real users or customers down with the application and asked for feedback. The reasons for this may relate to the development schedule (“We don’t have time to talk to users”), the budget (“Usability testing is expensive”) or simply a lack of knowledge about how to go about it. It may also be that the team members simply didn’t want to hear what real users had to say about their application, either out of fear that it might take them backwards in the process (“We’ll have to start all over!”) or fear that it will make them look stupid, and put their jobs in jeopardy.

Granted, user feedback may seem painful (anyone who’s sat through usability testing will attest to that), but its value is so high that it’s worth putting it at the top of the list of activities to include in the development process. And by getting such feedback earlier in the process, many of the problems listed above can be avoided.

The good news is that all of these mistakes can be fixed — by focusing on user needs up-front, by listening to user feedback, and by adjusting the application’s user interface to reflect that feedback. By shifting the focus to the user, you can ensure that your web-based application gets on track and stays on track.

Meryl Enerson is president and founder of Enervision Media, a user-centered research and design consultancy. Enervision has assisted software companies as well as Fortune 1000 corporations in evaluating and improving the usability of their websites and applications. She can be reached at meryl@enervisionmedia.com.