Here are four process-oriented problems that occur time and time again on the design of large Web sites and apps. See if any of them sound familiar.

Problem # 1: Design by Committee
Situation: A well-meaning—and well-liked—project manager or team leader marshals the opinions of everyone in the organization for what to add to the Web site. The manager wants to make sure everybody’s opinions are included, so he or she generates a long list of features to be included, few of which are questioned, none of which are prioritized, and most of which end up being implemented.

What Happens & Why: The product fails with users when it rolls out. The users simply don’t have the same goals as the people around the conference table with their whimsical wish list of features. Design by committee almost never works.

Solution: The only solution for a failed design-by-committee Web site is to hire a lead designer with a solid history of success. He or she will need to prioritize the content and feature set based on business goals and user requirements. Only then can a unified user experience be developed. A strong lead designer helps eliminate unnecessary elements and improves the overall Web experience.

Problem #2: Over-Ambitious Project Schedule
Situation: The board asks the CEO, who asks the CTO, who asks the VP, who asks the director, who asks the project manager to get the next release—with significant functionality—out by the beginning of the first quarter, not the fourth quarter. Nobody can say no.

What Happens & Why: The over-ambitious project schedule trips up the designers and developers. Features that should have been included are left out. Shortcuts are taken in the implementation. Important steps are neglected. User requirements are overlooked. Some things don’t work properly. The resulting product, when it does get released, falls short of everyone’s expectations. Everybody knows it, but nobody knows how to fix it.

Solution: If negotiating with the board isn’t an option, the new release may need to be fine-tuned bit by bit until it does work. An excellent way of addressing these issues is to quickly do a usability lab study. Put the release in front of a sample of eight to 10 respondents who match the profile of your users, and have them do a series of tasks—buy something online, try to find information, conduct a transaction—they might ordinarily do on the site or application. Have a user experience professional conduct the research, produce a formal report, and make sure it goes up the hierarchy and is seen by management, along with a set of recommendations for what to fix.

By identifying any usability and user issues quickly, you’ve just bought yourself the time—and right—to address the issues—one by one, if need be—in subsequent releases.

Problem #3: Lack of Quality Assurance
Situation: This scenario is increasingly common with Web-based products: Nobody is assigned the task of testing and checking a Web site or Web application before it rolls out for quality assurance (QA). Developers may do their own quick checks on their work, taking merely minutes to do so, and then tell the project manager to roll it out. Other team members take their word for it or are too busy to check an entire new release.

What Happens & Why: The site ends up riddled with errors and typos. Features may not work. It may be buggy, quirky, and just plain peculiar in some sections. Lack of QA and testing can have disastrous consequences on an organization’s credibility. An added level of complication: Team members may not agree on what’s working properly, because of the lack of written specifications.

Solution: It’s not that hard to create a specification document if your team agrees on what the site is supposed to do. A well-written spec document is the first step toward getting a QA process in place. Once you have even a basic spec created, it’s essential to have someone who is not a developer test any code created. It’s as difficult to test your own code as it is for writers to proof their own material—it’s just human nature to miss the mistakes in your own work. So the QA team needs to come from somewhere else within the organization. Alternatively, an outside contractor or vendor can be used to check the site against the spec.

Can specs be created after the fact? Yes. It’s never too late to create a spec and then add the QA process.

Problem #4: Silo Wars
Situation: Different departments or divisions within an organization each have responsibility for certain areas of a Web site. Their contribution to the content or functionality comes with little coordination except at a technical level. For example, they may be using the same content management tools. This is different from design by committee because each of the member groups has little interaction with each other and is not so much collaborating as they are coexisting.

What Happens & Why: Major inconsistencies in approach, including language, visual style, and user interaction, begin to appear as the site grows over time. At first, it doesn’t feel like a problem, but one day it reaches the point where it’s obvious to the users and management. Inevitably, the blame game starts and leads to tension between the groups, making coordination even more difficult.

Solution: The organization needs a style manual. Style manuals can be helpful for limiting choices. The manual should cover language as well as visual and interactive elements. If there is no design department, it could originate from the department responsible for brand management. Once a manual is developed, a team should be given the task of cleaning up the site sections to bring them into alignment with the manual before any more work proceeds.