Often, projects fail — not because of one glaring error that everyone is aware of, but because of an aggregation of smaller, less-obvious design mistakes that, in combination, prove fatal.

• Despite the maturity of Web tools and platforms, many Web development projects fail to achieve their goals.
• The root cause of many failures is lack of a value-driven, user-centered design process based on objective data about user behavior.
• Symptoms of root causes can have multiple manifestations, from premature technology selection to lack of validation with actual users.

• Before investing in technology, invest in a design process grounded in empirical data.
• Strive for a process of continuous improvement focused on core scenarios tied to business value.

An apparent paradox lies in the maturity of Web versus the still-numerous failures in Web and user experience design projects. Although the Web is almost 20 years old, many enterprises make mistakes in designing and building websites and applications. It is not an issue of lack of technical skill. Organizations have staff that can code HTML, design attractive graphics, and do server-side programming. Development tools and platforms are mature, reliable, and secure. But, too often, what gets built with these tools falls short of meeting user needs and organizational goals due to a lack of user-centric design discipline.

These are often silent failures. Gartner has written about the "Teflon portal," the dynamic website that looks good at first glance, but is not "sticky." The project deliverable is on time, on budget, visually attractive, fulfills all the functional requirements in the voluminous documentation, and has adequate performance, reliability and security. Viewed from a distance, the project appears a success. Users, on first visit, express benignly positive statements, such as, "I am glad our company has a modern, attractive website." However, user behaviors tell a different story: They do not stick around, and few return. Often, senior management is unaware of the failure, because no metrics have been defined, no baseline measurements have been taken of the old system, and no comparison is available to measure user engagement with the new system. However, if the organization invested a significant sum and users don't return, then the project fails to gain necessary return on investment (ROI).

How does this happen? The root cause is lack of a value-driven, user-centered design process that builds on proven interaction patterns validated by objective data about user behaviors. (see "A Value-Driven, User-Centered Design Process for Web Sites and Applications").

In addition to the root cause, Gartner has identified 10 common, specific mistakes.

A common mistake is to begin with technology selection, rather than defer this until progress has been made in defining a business strategy, a business value framework, user scenarios, design patterns, user market segmentation, personas, information architecture, validation scenarios, etc.

Many projects begin with a choice of technology, such as Flash and Silverlight, without the understanding of user needs, functional requirements and business strategy that would necessitate the use of this technology. Frequently, these decisions are developer-driven (internal teams want to work with the latest and greatest technology). Sometimes they are vendor-driven, either on the product side (platform/tool vendor) or on the service side (consulting firm or system integrator). Some companies have not only decided to build an application with a particular Ajax or rich Internet architecture (RIA) technology, but have made that decision without having any staff in place with those skills. This qualifies as a compound error, and occurs both in "greenfield" projects and in the redesign of existing systems. When the root problem is lack of a user-centered design process, adding a "coat of Ajax paint" or, alternatively, a heavy RIA front end will result only in incremental usability improvements, at best.

Many organizations conclude that their current website or application is outdated, unfriendly, not competitive, and/or hard to maintain. These conclusions may well be justified, but are often arrived at through intuition, anecdotal evidence, or word-of-mouth complaints. These are valid data points, but insufficient in helping formulate a strategy that would lead to an effective replacement system. What is needed before throwing out an old system and replacing it with a new one is a detailed understanding of business goals, a defined set of user scenarios or workflows that are tied to business activities, and a systematic way of gathering objective data about user behaviors. Without a baseline measurement, the organization will find it difficult to know whether the replacement system is a genuine improvement over the original. The organization is flying blind, and has forgotten the maxim, "You cannot fix what you cannot measure."

If users are complaining, then it's likely true that the system is not user-friendly — for every user who complains, there may be 10 who feel the same way and do not voice their opinions. However, this does little to lead the way to a system that is user-friendly. There are still too many designers and developers who think that adding gratuitous animation, cute icons, rounded corners on panels, or splash screens improve the usability of a system. What actually helps in designing a user-friendly system is systematic research into user needs (including segmentation into personas), definition of high-value use cases and user workflows, alignment of usage scenarios with proven interaction design patterns, validation of proposed design alternatives with usability testing, and postlaunch analytics of user behavior.

In the world of Web applications and commercial software, there is often an unconscious acceptance of the view that "more is better," that more features mean a better, more complete design. Product managers strive not to lose a feature war with a competitor. By contrast, a well-known statement from Michelangelo about his art is that an artist (sculptor) does not create a statue, as much as remove the excess stone from the block of marble in which the creation is imprisoned. Although competent designs and usable systems can be produced by simple aggregation of features, landmark designs such as the Apple iPod find success by reducing features to the set that delivers a cohesive, compelling user experience. Great designs rethink every common assumption — for example, "Is an on/off button really necessary?"

Speed is often the most important factor in the visible user experience. This is especially true as consumers spend more time on mobile browsers suffering from unreliable network connections.

History shows that a fast and visually plain design will almost always beat an overly decorated, heavy and slow competitor — as Yahoo proved when it competed against AltaVista in the early days of business-to-consumer (B2C) portals, and as Google later proved when it competed against Yahoo at the dawn of Web 2.0 era.

The conventional wisdom is that usable designs stem from user interaction sequences that are based on principles of human factors research (i.e., how humans process information), as well as proven design patterns validated both in the lab and in production. There are many design principles and heuristics that expert designers apply to solving a design problem — principles such as the Rule of Sevens (no more than seven items in a list of menu choices), providing immediate feedback, showing context to keep the user oriented (through "breadcrumb trails"), providing an undo function (to cultivate exploratory use and to reduce user anxiety about possible actions), etc. These are all proven best practices. However, if there is one factor that contributes to usability more than any other it, is likely the raw speed of response. A fast system can compensate for many other shortcomings in usability. Users can attempt a sequence and back out if it leads in the wrong direction. A fast system can preserve the user's train of thought without requiring the full range of contextual cues and orientation.

Obviously, it is better to be both fast and well-designed. But if one is forced to sacrifice one aspect of the design, many candidates are more dispensable than fast response. It is important to note that perceived speed can be more important than real speed — in the sense that slow response can be mitigated by techniques such as progress bars or activity status indicators.

The design process is one in which design alternatives pass through phases, which can be considered as a funnel or pipeline of completeness, from numerous low-fidelity sketches on paper to multiple comps built in Photoshop to a few HTML wireframes to one or two high-fidelity prototypes built with real server-side code. The cost of making design changes increases at each stage in the fidelity pipeline. All of this represents a best practice. Where some organizations err is in evaluating possible designs. Often, organizations do not validate with actual users, but instead with proxy users — product managers or business analysts who stand in for users, sometimes with accurate results, but other times not. In some cases, truly representative users are enlisted, but there is a failure to account for the real context of use. Instead, tests are conducted in pristine laboratory conditions: the offices of the development team, with large screen displays, fast network conditions, quiet ambient sounds. But the target system may be deployed under very different conditions: a busy office with loud background noises, older hardware and slow network connections. If all else fails (in the sense of capturing feedback early in the pipeline), the fallback solution is to instrument the production system to gather analytical data from real users.

Although the limitations and shortcomings of the classic "waterfall" design process are now pretty well-known, many organizations still fall into the trap of this approach. This is often driven by an outsourcing relationship, because the waterfall phases align well with the life cycle of engagement with an outside Web design and development firm: gather requirements, design the system, test and launch. Agile processes that require close communication and collaboration among all team members are difficult to carry out in a situation where people are split into internal staff and external consultants — each set fragmented by different individual backgrounds, corporate culture, skill sets, etc. Nevertheless, organizations should strive for a process of continuous improvement. Half the project budget should be saved for after the system launch, to sustain iterative refinement.

Organizations often try to design a complete, closed and final solution, rather than designing a powerful, extensible vocabulary in which multiple solutions can be expressed. Key design decisions are not always about the final result, but about arriving at a set of design elements that can be easily and flexibly assembled and recombined to create a set of related solutions that can be assessed, tweaked and improved upon over time. Ideally, the lexicon should be open and extensible, resulting in an "architecture of participation." To be sure, undertaking a process of "metadesign" is a difficult challenge, and can often only be approximated.

Many organizations view the task of building a website or application as solving a visual design problem, or, alternatively, at arriving at a "silver bullet" technology selection decision.

Yet, the most critical success factors in a user experience design project often have little to do with visual design, per se. The importance of raw speed has already been mentioned. Also important in certain scenarios is advanced server-side processing that supports a radically simple front end (such as the Google home page, which consists of a dozen words and a single text-entry box). An emerging factor in user experience design is the design of social experiences. These nonvisual aspects of user experience design will grow in importance over time.

Perhaps the most common design mistake on an organization's home page is yielding to demands from various corners of the organization for "real estate" on the page — modules, navigation menu items, etc. The company website then becomes a reflection of "squeaky wheel" priorities, and becomes detached from user needs.

The larger the scale and scope of a project, the more diverse the collection of stakeholders, champions and perhaps those whose needs are overlooked. Sites usually cannot be successful unless they change how people interact or work. In these circumstances, political negotiation and compromise are essential to moving a project forward. Bending a design to meet a stakeholder's agenda cannot be avoided. Even so, it is a mistake to view this as design decision. Recognize it for what it is, a political necessity.

"A Value-Driven, User-Centered Design Process for Web Sites and Applications"

"Usability Drives User Experience; User Experience Delivers Business Value"

"What CIOs Need To Know About Application Simplicity"

This research is part of a set of related research pieces. See Customer-Centric Web Strategies: Responding to All Things Social for an overview.