Another way to reduce and refine is not in the application itself, but rather in the process of creating Web applications.
Many companies step through a lengthy and complicated process each time a new application is designed and built. This process often begins with the creation of a Vision Document, which outlines the business goals and desires for a new application. This can be followed by a Software Requirements Specification (SRS), which details the features the application must offer. And this, in turn, can be followed by a Functional Specification, which describes how features should behave, look, and work, complete with both high- and low-level use cases. The creation of all these documents can lead to the design of wireframes (iterated repeatedly until approved), the conversion of the wireframes into final artwork, and finally, the construction, testing, release, and marketing of the application.
Even when an application is extraordinarily simple, this process can take months. It's a highly wasteful process that often results in an application no better (and usually worse) than if the first three documents had been skipped and the developers went straight from use cases to code, with graphics created Just In Time.
In many cases, in fact, the people doing the research for a new productproduct comparisons, user research, and so onare not the same people who must create the wireframes and artwork for the application. This creates a large disconnect. The people with all the knowledge are on one side of a cubicle divider, while the designers are on the other. This disconnect means those who did the research must dump a ton of information on the designer, who must then translate the information into a design. This often results in hours of impromptu meetings between the designer and the researcher to clarify requirements and better understand what needs to be designed. Quite wasteful.
Cleaning up your process
Cleaning this whole mess up can be highly beneficialto the company and its users. In addition to cleaning up the interface for an application, we need to clean up the process used to build them.
First, stop relying on specifications.
It's perfectly understandable that in many companies, specifications (aka specs) must be written. Typically, they're required to get buy-in from management and development teams and such to build the application in the first place. Beyond this, however, they have very little effect on reality. Applications almost never adhere to them, and they're almost never updated to reflect changes made to an application's design once development has started.
Furthermore, specs are usually about a million pages long, and no one really has the time to read them. Designers want to know about the activity so they can create a design that supports it. Developers want to know how the application will function. And marketers want to know how they can market the thing. Because specs are so long (and usually extremely boring), they fail to meet any of these needs effectively.
Once the development project has been approved and is in motion, put the spec away and stop worrying about it. At this point, your goal should be to Know What To Build.
Design now, not later
I also strongly recommend turning the application designer and the researcher into a two-person team. When a knowledgeable designer is involved from the beginning, he can help decide which features are absolutely essential, study the activity the application is meant to support to gain a thorough understanding of it, and begin creating wireframes right away instead of struggling through a researcher-to-designer brain-dump later on and guessing his way through the design.
The designer is the one who needs to understand the activity the most, so that he can effectively design an application that supports it. If research is to be done, the designer should be there, doing it. Sketches can be created the moment an epiphany strikes, and wireframes and use cases can be created and revised all along the way.
When the designer has all the information and knowledge he needs to design an effective application, the application will, indeed, become more effective.