It’s always great when you have the opportunity to built a site from the ground up. You have opportunities to design things right the first time, and set standards in place for future users, designers and developers alike. These are the good times.

More often than not, sites are already built and deployed for the world to view. Moreover, there are probably unintentional standards in place which get in the way of your best efforts to do right by the site, the content and the user.

It can be said that, much like user experience is either good or bad, there is no such thing as no standard, there is merely a good or bad standard. Once a project is underway, if there are no standards to work from, they will create themselves.

Pretty soon you find yourself in the corner holding a roller and a can of paint with a confused look on your face.

“How did I get HERE,” you ask.

Patterns become entrenched. People begin to rely on the uneven foundation. It is expected that things are going to be built around warps in the floorboards. Broken becomes the new fixed.

Suppose you approach a site that has a decade, or more, of this kind of entrenched patterning. You will quickly discover that doing any updating, making any change or acting upon the site in any way is a momentous task.

On one side of the fence stand the engineers who have cobbled together this house in the swamp and there you stand, Captain Ahab, looking at the white whale of usability and proclaiming you will have victory regardless of the cost.

This kind of standoff leads to what I refer to as usabilibloat. Usabilibloat is the unexpected and swift expansion of codebase and resource usage to support a cumbersome system and a user interface which may be little more than merely passable. Typically this kind of situation is not grown out of contention or malevolence but simply out of “organic growth.”

Organic growth, when controlled and directed, can allow a site, tool or other system to flourish and become a loved and trusted tool. When uncontrolled, organic growth of a site becomes malignant.

The first step to take when approaching a site which is in danger of developing usabilibloat is to assess what is easy to fix and what is hard. The hard things are typically systemic problems, likely related to cutting a corner years ago. Often, the person who cut said corner is long gone and others are left to pick up the pieces.

The easy problems should be evaluated as to level of efficacy regarding user experience and ease of maintenance in the long run. Don’t ignore any of them, but make a list and order the problems as they should be handled.

Sometimes easy problems reveal systemic ones, so be aware. If an easy problem starts to become a systemic problem, shift it from the easy list and move on.

Once you have sorted the easy problems in order of importance and immediacy, evaluate the ideal user experience. Note the key features and make a list of them. These are the do or die features. These are the “if our system doesn’t have these, it is a non-starter.”

Appraise the list of easy-to-fix issues and non-starter features and roll these out in the earliest version of your site. Forget about the other neato things you intend to put in place one day. Just get the site rolling with what you need and give people something to click on.

Something that is key for limiting usabilibloat: build an API. Create something to allow your UI to interact with the system below. It can be hacky. It can be ugly. It may not work quite right the first time you try it. Regardless, with a good programming interface, you can interact with the user in a consistent way while the developers pull the system back from the edge of the abyss.

By building an API, you separate the UI from the system and allow the pieces to move more independently. A major benefit you will gain from this approach is the ability to give your users something to click on early. The more user testing you can incorporate the better. If you can incorporate it early, you are doing well.

User testing will help to eliminate more usabilibloat. Your users will tell you if something works better, worse or about the same as what they were expecting. Sometimes you will discover you can cross items off your list as they are unrelated to what your user is truly interested in.

After you’ve accomplished these critical steps, continue to work through your site in much the same way, iterating in the UI elements as they are appropriate and refine the system to work more efficiently within the scope of the user needs.

Usbilibloat should be managed from the earliest possible moment. The only remedy available once usabilibloat sets in is time and sweat. If bloat is carried too far, your users will suffer for your sins.

The key to your salvation is planning. If you see your site heading for the edge, take a moment. Sit down with your developers and make a plan. managing the issue early will save lots of grief for both you and your users. Meet the problem head on. Break your UI away from the rest of the system. Save your users and make the web a better place.