Website Prototype Technical Specification
From Web Smart Newsletter: Web Development Fallacies, Part 1
Originally published December 2001 - Updated July 2006. By Eric Holter.
Originally published December 2001 - Updated July 2006. By Eric Holter.
Developer Fallacy #2: In the words of George Bernard Shaw, "The single biggest problem in communication is the illusion that it has taken place."
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. next >











Share
DIIGO