Skip navigation
factory /><div class=

Defining a Website Specification

From Web Smart Newsletter: Web Development Fallacies, Part 1
Originally published December 2001 - Updated July 2006. By Eric Holter.
print PDF email a friend
<<  1 | 2 | 3 | 4 | 5 >>  

Web Development Fallacies, Part 1
1.Web Development Problems
2.Presenting Designs
3.Communicating
»Website Specification
5.Website Frustration

Sign up to Web Smart:


| RSS
Developer Fallacy #3: "The client never said they wanted that!"

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.   next >

print PDF email a friend
<<  1 | 2 | 3 | 4 | 5 >>  
FACEBOOK


Comments


 Zeal Murapa February 25, 2009 4:43 AM
Good Articles! Well written too