Web Development Fallacies, Part 1

It can be tempting to blame and criticize clients when projects go bad. But more often than not, problems can be traced back to mistaken assumptions on the part of the developer. Recognizing these fallacies can help clarify our responsibilty as the developer in a web project.

Many of the concerns identified in these developer fallacies apply to Newfangled as a web developer. However, when working together with an agency in a development project, clients do not make much distinction between what the agency is responsible for, and what the developer's responsibilities are. Because of this it is appropriate for you to be aware of these common developer fallacies.

These fallacies were originally written as stand alone articles. Each one is accompanied by a corresponding solution examining how grayscreen prototyping can help overcome these common web development problems.

Form follows function
I believe strongly in the maxim "form follows function." Design should always revolve around a predefined function or purpose. Too often sites are visually designed prior to full project definition.

In these cases the design will never be as good as it could be because it will not have been considered with the site's final structure and function in mind. Visual design that is based on a clear and deep specification will always be more appropriate and compelling than designs created before a project is fully specified.

Graphic designers are trained to not only to decorate, but to make communication clearer. When most people think about design they think about making something look good, making it aesthetically pleasing. These aspects of design are far from being the entire concern of the designer. Emil Roder wrote "To design is to plan, to order, to relate, and to control. In short, it opposes all means of disorder and accident." This statement describes the heart of design, it is the opposite of disorder. It suggests intention and deliberation. Designers are concerned about communication, how they can make a message clearer and more direct. Designing without specification is like laying out a pamphlet without knowing what it is supposed to say. Without specification, all that is left for a designer is decoration.

When a designer works from a clear specification, not only can they do their job faster and better, but it is also easier and less frustrating. Their designs are usually better because they are based on good, clear, and thorough specification. More importantly, the feedback and approval process is less frustrating because the client reviews the layouts at the appropriate time.

I have found that one of the reasons clients react negatively to proposed layouts is fear. The fear stems from a sense that the developer has not yet fully grasped what the client has in mind for the full content and functionality of the site. It is very hard for anyone to divorce their view of a layout from their actual expectations of what a site should be and do. When we go after "look and feel" approval first (as opposed to content or functionality approval) we are trying to get the client to divorce themselves from their own expectations. We are asking them to trust us and to try and imagine how the site might work even though what they are looking at does not fully describe the final product. This is asking too much from them.

Not only are we asking the client to make a leap of imagination that they are uncomfortable making, but we are also asking them to do so without first having gained their trust. When design is one of the first deliverables in a project, we have not yet had enough time and opportunity to earn a new client's trust. Any negative reaction from a client at this point sets the stage for further mistrust and fear as the project progresses.

One way to deal with this problem is to spend more time analyzing the client's needs and planning the overall strategy for a site before entering into a design process. While this is the right thing to do, it creates another negative dynamic, that of waiting too long to "show them something." Strategy and planning can often take a long time, too long for most clients to wait before they "see something." This dynamic drives the premature creation of "look and feel" layouts.

Thus a dilemma arises, either spend an appropriate amount of time planning, and risk taking too long to show the client something, or show them premature layouts that are not based on a clear understanding of the project. It can be a real catch 22.

Grayscreen prototyping is a simple HTML-based approach to modeling, documenting, and specifying web sites during the initial stages of the development process. Working through a grayscreen prototype prior to design and development allows for effective communication with clients thereby overcoming the many barriers inherent to web development. Through grayscreen prototyping we found a way to turn these negative dynamics into positive ones. By entering into an HTML prototype phase right away we are able to "show clients something" very quickly. Because a prototype is a working document devoid of visual design, the clients feel free to change and restructure, add or take away content from the prototype. The back and forth not only gives us a very good understanding of what the client wants, but by the end, the client knows that we understand what they want. We are able to show them something (the prototype) and at the same time get the information we need to do our job of designing. Now when we present the first layouts we have a different dynamic. They are not worried that we do not understand their needs; they are certain we do. We do not ask them to approve layouts that have been divorced from content and functionality; the layouts are designed with the content and functionality already defined. When they see the look and feel, they can comment on just that, the look and feel, without the unconscious baggage of concerns about content and functionality. This whole process helps us avoid major pitfalls of web development and replaces them with very positive interactions.

It has been my experience that the absolute key skill a web development company must have is not database programming, killer design, flash animation, or internet marketing savvy. It's the ability to communicate technical information non-technically! If we can't do this, we will never be able meet our clients' expectations.

When facing communication problems, the issue is not that clients "don't get it." It's what we're asking them to "get" in the first place. A web site is a technical system. It can also be a complex information design puzzle. Information design is an important skill used in designing a website. The subtleties of information design are not something a developer should ever assume a client will "get" without careful explanation. We developers are the experts here. We are the ones who understand interactivity, dynamic content, and hypertext. We are the ones who recognize the complexities of information architecture, navigation systems, search engine dynamics, and browser compatibility. It is our responsibility to communicate these things effectively to our clients. But how do we communicate these important subtleties effectively?

The issues and topics that revolve around the subject of information design are not easy to communicate. They are hard enough to discuss among people who actually do information design. The language of information design is new and the term itself is not used consistently throughout the web development and interactive industry. Communicating about information design is a big challenge, but one that must be met if we are to solve this problem. As we consider how to communicate technical information we recognize that clear documentation is a critical element.

The problem with documenting
A website is software. It is written in code, and runs on a computer. The more dynamic a site, the greater the divide between the clients' knowledge and the product they are buying. Like software development, web development requires careful documentation. However, even when the developer takes the time to plan and document the specifications for a project, the client is often unable to understand what the technical specification is saying, because anyone without a technical background will be baffled by most technical documents.

What doesn't work
Recognizing the need for well-documented communication written in a non-technical terms, we often begin with site maps, flow charts, written descriptions of functionality, or story boards. These kinds of documents can help, but they often fail to communicate deeper levels of information, leaving clients with unmet expectations. These expectations aren't discovered until well into the design and development of the project. Although we may have represented the site accurately in our documents, they had not understood (or have forgotten) what we had defined. The client then is left feeling trapped and their expectations are unfulfilled.

HTML "grayscreen" prototyping
Part of the problem comes from trying to communicate a non-linear, hypertext object (a website), in a linear, non-hypertext way (on paper). However, if we take the exact same information we put into print documentation, but represent it in a simple HTML prototype, the experience of how the client reviews and understands the plans for the website changes completely.

True understanding of how a website is intended to function is grasped best when viewed in a working HTML prototype. This is not surprising since the web itself represents a true paradigm shift in how we relate to information. The web, unlike all other forms of communication, is non-linear. All other mediums of communicating information (books, magazines, television, etc.) are linear. Because hypertext is non-linear, the pages of a website may be visited in any order. This structural change from linear to non-linear (to say nothing of the technical issues involved) causes significant problems when attempting to document the structure in a linear way (on paper).

Creating HTML prototypes (a process we call grayscreen prototyping) allows us to communicate about a project in hypertext (HTML), a medium consistent with the final product. While it is close to impossible to describe the functions of a web site on paper, an HTML model of the site communicates very well. By building a simple HTML prototype of the site prior to design and programming, we can create a technical specification that everyone can understand. This prototype can then be used to educate and communicate with the client about the many detailed and complex issues of web development in a clear way that makes sense to everyone.

In many web development projects it's not until the site is already designed, and programming is mostly done, that the client is able to experience the site by clicking through it. It is then that they notice things they wanted (or expected). To make changes at this point is not only costly, but also time consuming. The end result is that the launch date is delayed and the budget grows (or the developer loses money). In any case, the experience is less than satisfying for either party.

Grayscreen prototyping is a simple HTML-based approach to modeling, documenting, and specifying websites during the initial stages of the development process. Working through a grayscreen prototype prior to design and development allows for effective communication with clients thereby overcoming the many barriers inherent to web development. The grayscreen process helps to avoid this dilemma. By working through the prototyping process, clients can iterate and change things while the document is still flexible. This allows for deeper specification (that the client comprehends) and a greater understanding of the project. Because they are reacting to a clickable, fully defined prototype, they see things that they otherwise would not see or notice until the end of a development project. These things are then easily changed to meet the client's needs.

Deeper understanding
Not only do clients understand prototypes, but they pay closer attention to the details than they do when reviewing other forms of paper documentation (site maps, flow charts, storyboards, etc.). Having "clicked-through" the prototype, the input they provide is much deeper, more insightful, and thorough than it would have been otherwise. So much so that we are able to address many of the "what if's" that inevitably come at the end of a project, before we even begin design or programming. Often, aspects of functionality and usability do not (and cannot) occur to the client until they experience the site. To ask the client to identify all of the features, functionality, and interactions before experiencing the site is unfair. Giving them something to experience and react to will not only improve their understanding, but will help them imagine what the site could be, at a point where it is still painless to make changes or additions.

Work flow for programming elements
Prototyping establishes the entire workflow of the site. The prototype can hold programmer notes, and contain links to database field structures, to simulate the working site in ways that other forms of documenting cannot. Whenever the site does something special with provided data, such as saving form data to a database, searching a database for requested information, saving a profile of a visitor, etc., we can map the entire process out in the prototype. This simulates the flow of screens and the type of data on them. Programmers need to know what happens to data when a user submits it. These subtleties are often overlooked and can come back later and cause real problems for the site.

Team dynamics
Before we developed grayscreen prototyping the development process was consistently long and frustrating. We would begin by trying to get a site map finalized and a design approved. By the time the project got to production for coding, it would have already been through most of this long and frustrating process. Once the project was in the HTML phase the production staff often come back with some excellent suggestions. These suggestions would have made the site better and easier. But if the suggestion required modifications to the design or navigation, the ideas rarely made it into the site. The budget would already be stretched and the idea of going back to the client with changes they did not initiate was akin to masochism. Yet this feedback often contained valuable and helpful insight.

Programmers likewise would often be brought in after most of the functionality was defined. Many of their ideas were also overridden by budget and schedule constraints.

The grayscreen prototyping process utilizes the entire development team: information designers, project managers, HTML and database programmers, designers, and the client right from the beginning of the project. As they review the prototype at various stages they have many opportunities to give their insight and perspective, weighing in on the project before it is finalized. It allows them to ask important questions about the prototype before approval is sought. HTML and database programmers often recognize ways to simplify given features. They could not do this if the features were not modeled and fleshed out in a prototype.

Because the grayscreen process is a team-centered approach, each team member does a better job when it comes time for them to do their part. They are more informed about the whole project and they have a greater sense of ownership, having been on the team from the beginning and contributed to the overall process.

Developers and clients both come to a project with different values. The gap between what the developer values and what a client values can be quite wide. Not recognizing these differences can result in more miscommunication and exacerbate the negative relational dynamics. For example, normal people (in contrast to us developers) don't really value a well coded DHTML cascading menu. They don't appreciate the eight hours spent making a navigation feature work in Internet Explorer 6.0, Firefox and Safari. They do value good interaction, good listening, and clear communication. They'll remember the flavor of their interaction with you, not the subtle coordination of complementary color palettes used in the navigation system. They'll remember the agonizing meetings and missed schedules, not the cool flash presentation. The things that we developers value, such as quality in design and programming, are not the things that clients can see, understand, or measure. If they were to view the source HTML they could not discern whether the syntax was cross browser compatible or not. Meetings, documents, and conference calls are the interactions that our clients are going to remember. How we communicated with them, listened to them, and carefully explained things to them are the things they will value.

Because of the realities of interpersonal dynamics, web projects can easily get off on the wrong foot. Each missed expectation and miscommunication adds to an increasingly sour experience. In the end, the developer can likely end up hundreds of hours over budget and the client can still be displeased. Nobody wins.

The relational dynamics that occur between the developer and the client during the development of a web site can be just as important to the client's ultimate satisfaction as the resulting website itself. When we understand the need of managing the client relationship in addition to managing the project we can begin to improve the overall experience.

Fixing the problems
Many talented, skilled, and technically competent web development companies fail to become successful. Developing sites that meet the goals set out for them while managing the subtleties of a client's expectations is very difficult. Clients need to appreciate the difficulties the developer faces in meeting their needs. But is up the developer to communicate the subtleties and intricacies of information design, database interactions, and navigation systems in a way the client will value.

The key to solving these issues is not in better technology. The key is in the development process. The missing piece is a process that will effectively communicate the complexities of information design between developers and their clients. A solid and effective communication process can help manage client expectations and improve interactions, transforming each point where projects tend to spiral downward, into an opportunity to spiral upward. Without a cohesive process that addresses the problems of communication, expectations and interaction in a way the client can understand, the problems inherent in web development will spiral downward.

The solution to these managing relational dynamics is actually quite simple, but its impact is dramatic. Grayscreen prototyping is a simple HTML-based approach to modeling, documenting, and specifying websites during the initial stages of the development process. Working through a grayscreen prototype prior to design and development allows for effective communication with clients thereby overcoming the many barriers inherent to web development. This process changes the development experience completely. It communicates the technical and structural complexities of web development, and improves the relational dynamics between developers and their clients.

The role of the producer
The strength of a process like grayscreen prototyping is its ability to communicate about information design, and content and functionality of a proposed web site. While the process itself helps overcome many barriers, the role of the producer on the development team is critical to the process running smoothly.

The producer is responsible for translating, communicating, and educating the client about the project using the grayscreen prototype as the communications tool. This is an important role and a challenging task. We have found that it is important for a producer to have a good grasp of the underlying technology (enough to translate and educate), but not so much that they assume knowledge that the client may not have. Such a producer will be able to explain the technical issues in a way that is highly relevant and understandable to the client.

Being aware of some of the potential problems when developing a website is the first step in avoiding them. By using a process like grayscreening, that overcomes these barriers, we can turn potential negative experiences into positive ones. The results will be successful websites that meet the needs of our clients.