Prototyping Tips
 |  | |
Because grayscreen prototyping is the foundation of our development process, we have built many automated tools for creating and modifying prototypes efficiently. The principles of prototyping, however, are technology independent. Our first prototypes were built with straightforward HTML, some were even built using DreamWeaver. The following descriptions do not necessarily reflect how we implement grayscreen prototyping today, but rather how anyone can implement the process using whatever technology they are most comfortable with. The following tips will provide some practical help for building prototypes that will effectively communicate the structure, content, and functionality of a website.
The first round of prototyping usually focuses on the overall structure of a site, namely, the main site categories and subcategories. Separating main categories from site utilities (home, contact, search, etc.) is another aspect of defining structure. Identifying site features, functions, and sections is similar to developing a well worked-out site map. An HTML prototype is better than a site map, however, because it presents these elements in a more tangible and relevant way. For example, a prototype might represent the main sections of a site as "about us," "our products," "news," "partnerships," and "investors." These sections would be grouped together at the top of the page as its main navigation bar. In the upper right hand section of the page links for site utilities such as "home," "contact," "search," and "site map" can be added. These might be grouped separately from the main navigation elements to show that they would be displayed differently from the main navigation bar. Thus a prototype can describe the relationship between two different types of navigation without getting into specific issues of visual design.
Actual content for a site must be constructed once the overall structure has been worked out. Rather than using final copy for this step "dummy" copy can be used to mock up the content. The length of the "dummy" copy gives the client an idea of how long the final copy will need to be. It can also be helpful to add a rough first sentence to dummy copy that describes its final purpose. For example, the copy on the main section page for a product area might read, "This is an initial paragraph to give the user a general overview of your product offerings. A very simple mention of primary benefits would be appropriate here, but keep it short. Lorem ipsum dolar yadda yadda yadda..." The thoroughness of this rough "place holder" copy helps the client create appropriate content for the site.
Sites using database driven content or other technical functions present serious communication problems due to the gap between the technical nature of these functions and a client's lack of technical background. Differences between dynamically generated and static content are often lost on clients without technical experience. In order to communicate clearly about technical functions, prototypes must translate these aspects into a form that anyone can understand.
This can be accomplished through the use of programmer notes and mock-ups. Mocking-up site features can simulate intended functionality. For example a page might show a series of form fields, pull down menus, or checkboxes that would simulate a site feature. Of course these elements would not be functional. Adding programmer notes to these screens takes the place of the actual functionality and informs the client and development team as to how a site function should work.
When a website is database driven (as most sites are these days), it is critical to define database fields. Content that is generated from a database must be broken down into various fields. The client needs to understand what information will be drawn out of a database and what the related database fields will be. Adding "from database" links next to all database-generated content will help identify these instances. These "from database" links can then point to text files that list the actual database fields for a specific piece of content. This allows the client to confirm that the proposed database fields are appropriate to the content.
Programmer notes and links that lead to descriptions of database fields help the client and team to communicate clearly about how the site will work, especially when developing a database driven site.
For example, having reviewed a list of fields and having read the programmer notes, it might occur to someone that a particular piece of content needs a date field that is not listed. A date field can then be added to the prototype before the databases are built, thus avoiding a potential miscommunication. Miscommunication of database structure is the most common area where costly mistakes are made.
Sometimes the initial representation of site content and features requires a bit of "guess work" on the part of the developer. Ideally, sample content or data from the client forms the basis of the initial prototype. But sometimes we don't have much information to go on and have to guess.
For example, a contact form may have many fields or just basic contact information fields. The data might need to be stored, or emailed to several people. By taking a first guess at the form fields on a contact form and indicating what will happen to the information in a programmer note, the client will be able to respond to what they see and evaluate whether it meets their needs. When a client has something tangible to respond to they can more effectively refine the details of content and functionality. When details are addressed early, adjustments can be made, budgets can be altered if necessary, and conflict and wasted time can be avoided.
Using templates can help keep prototypes simple and malleable. Because the layout of a prototype is not as important as the structure, content, and functionality it represents, you can save time by reusing previous prototypes or working from generic prototype templates. Revising existing prototypes or building a library of prototype templates will make the prototyping process faster.
There are some technological ways of increasing the efficiency of the prototyping process, for example the use of "includes." There are different technical means for implementing includes. In general, an include is a special piece of code on a web page that refers to another source document, and then includes the contents of that document in the web page at the point where the include code is placed. This allows for elements of a site that are consistently displayed from page to page, such as a navigation bar, to be maintained in a single location. In this way, changes to the navigation structure, which are to be expected and encouraged, can be made quickly and easily. For example, at some point in the prototyping process, a new section might be added or renamed in the navigation bar. Instead of having to adjust the navigation code on every prototype page, the navigation bar's include file is changed once, and all of the pages in the prototype then reflect the change.
As was mentioned earlier, one of the more challenging areas for web development projects remains the creation and delivery of content by the client. Since grayscreen prototypes represent content, they help avoid the problem of receiving content that does not fit the site. A prototype can help the content collection process as well.
Once a thorough prototype exists, it can become a great content collection mechanism. One way to accomplish this is to assign a color to any text in a prototype that needs to be provided by a client. All of the instances where such content is specified in the prototype can then be listed on a content overview page. Each item can be linked to the specific prototype page where the content is needed, allowing the client to refer to its context. This list page can also contain due dates and assignments associated with each item. This will help the client manage the content creation, editing, and delivery process.
Another way that a prototype can facilitate content collection is by placing a "email to" link next to each area on the site where a client must provide content. These links can trigger an email window from which the client can copy and paste, or attach the specific piece of content for that page and email it to the developer. Coordination of content is facilitated by embedding the subject line of the email with the name and placement of the content (as it is labeled in a prototype). This helps identify where each piece of content belongs on the site.
As the client provides content, the color of the links on the content list page can be changed to distinguish content that has been provided from content that is still needed. This mechanism is extremely helpful to clients as they create and deliver content. The positive feelings such help produces are another example of how grayscreen prototyping not only plays an important role in getting the job done, but also creates positive relational dynamics.
Ultimately the client needs to "sign off" on a prototype so the designers and programmers can build the working site. Since the developer is making a strong commitment to communicating about the project in detail, the client needs to be committed to understanding what is being described and giving approval to the prototype.
A prototype, once it is completed, is the blueprint from which the final site is built. At some point, the prototyping phase needs to come to a clear end, at which time the client will sign-off on the prototype. It can be helpful to include a reminder in the sign-off document that makes it clear that the approved prototype is the final specification and definition of scope for the project.
Because many things will change during grayscreening the client needs to be aware that what they are approving is the final definition of the site. Any other documents, emails or even conversations that may have occurred are superseded by the prototype.
Grayscreen prototypes help improve the process of communicating the structure, content, and functionality of a proposed website. While the process itself is valuable, the role of the project manager is critical to the process running smoothly. While I am using the title project manager here, a developer may sometimes refer to this role as account manager, producer, or project leader.
The project manager is responsible for translating, communicating, and educating the client about the project using a grayscreen prototype as a communication tool. This is an important and challenging role. We have found that it is important for a project manager 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 project manager will be able to explain the technical issues in a way that is highly relevant and understandable to the client.
The project manager should always make sure that the language in the programmer notes (or anything in a prototype) is simple and understandable to the whole team. Sometimes a project manager will need to reword a programmer note (with the programmer's knowledge) to clarify it for the client.
It may seem like prototyping is a lot of work - and it is. But it is far less work that has to be done when critical details are overlooked or misunderstood. The work is well worth it when as a result of solid thoughtful prototyping is a happy client and an effective website.
Step one: establishing structure
The first round of prototyping usually focuses on the overall structure of a site, namely, the main site categories and subcategories. Separating main categories from site utilities (home, contact, search, etc.) is another aspect of defining structure. Identifying site features, functions, and sections is similar to developing a well worked-out site map. An HTML prototype is better than a site map, however, because it presents these elements in a more tangible and relevant way. For example, a prototype might represent the main sections of a site as "about us," "our products," "news," "partnerships," and "investors." These sections would be grouped together at the top of the page as its main navigation bar. In the upper right hand section of the page links for site utilities such as "home," "contact," "search," and "site map" can be added. These might be grouped separately from the main navigation elements to show that they would be displayed differently from the main navigation bar. Thus a prototype can describe the relationship between two different types of navigation without getting into specific issues of visual design.
Step two: representing content
Actual content for a site must be constructed once the overall structure has been worked out. Rather than using final copy for this step "dummy" copy can be used to mock up the content. The length of the "dummy" copy gives the client an idea of how long the final copy will need to be. It can also be helpful to add a rough first sentence to dummy copy that describes its final purpose. For example, the copy on the main section page for a product area might read, "This is an initial paragraph to give the user a general overview of your product offerings. A very simple mention of primary benefits would be appropriate here, but keep it short. Lorem ipsum dolar yadda yadda yadda..." The thoroughness of this rough "place holder" copy helps the client create appropriate content for the site.
Step three: defining functionality
Sites using database driven content or other technical functions present serious communication problems due to the gap between the technical nature of these functions and a client's lack of technical background. Differences between dynamically generated and static content are often lost on clients without technical experience. In order to communicate clearly about technical functions, prototypes must translate these aspects into a form that anyone can understand.
This can be accomplished through the use of programmer notes and mock-ups. Mocking-up site features can simulate intended functionality. For example a page might show a series of form fields, pull down menus, or checkboxes that would simulate a site feature. Of course these elements would not be functional. Adding programmer notes to these screens takes the place of the actual functionality and informs the client and development team as to how a site function should work.
Practical tip: database field definition
When a website is database driven (as most sites are these days), it is critical to define database fields. Content that is generated from a database must be broken down into various fields. The client needs to understand what information will be drawn out of a database and what the related database fields will be. Adding "from database" links next to all database-generated content will help identify these instances. These "from database" links can then point to text files that list the actual database fields for a specific piece of content. This allows the client to confirm that the proposed database fields are appropriate to the content.
Programmer notes and links that lead to descriptions of database fields help the client and team to communicate clearly about how the site will work, especially when developing a database driven site.
Practical tip: guessing
Sometimes the initial representation of site content and features requires a bit of "guess work" on the part of the developer. Ideally, sample content or data from the client forms the basis of the initial prototype. But sometimes we don't have much information to go on and have to guess.
For example, a contact form may have many fields or just basic contact information fields. The data might need to be stored, or emailed to several people. By taking a first guess at the form fields on a contact form and indicating what will happen to the information in a programmer note, the client will be able to respond to what they see and evaluate whether it meets their needs. When a client has something tangible to respond to they can more effectively refine the details of content and functionality. When details are addressed early, adjustments can be made, budgets can be altered if necessary, and conflict and wasted time can be avoided.
Practical tip: using templates
Using templates can help keep prototypes simple and malleable. Because the layout of a prototype is not as important as the structure, content, and functionality it represents, you can save time by reusing previous prototypes or working from generic prototype templates. Revising existing prototypes or building a library of prototype templates will make the prototyping process faster.
Practical tip: using "includes"
There are some technological ways of increasing the efficiency of the prototyping process, for example the use of "includes." There are different technical means for implementing includes. In general, an include is a special piece of code on a web page that refers to another source document, and then includes the contents of that document in the web page at the point where the include code is placed. This allows for elements of a site that are consistently displayed from page to page, such as a navigation bar, to be maintained in a single location. In this way, changes to the navigation structure, which are to be expected and encouraged, can be made quickly and easily. For example, at some point in the prototyping process, a new section might be added or renamed in the navigation bar. Instead of having to adjust the navigation code on every prototype page, the navigation bar's include file is changed once, and all of the pages in the prototype then reflect the change.
Practical tip: content collection and organization
As was mentioned earlier, one of the more challenging areas for web development projects remains the creation and delivery of content by the client. Since grayscreen prototypes represent content, they help avoid the problem of receiving content that does not fit the site. A prototype can help the content collection process as well.
Once a thorough prototype exists, it can become a great content collection mechanism. One way to accomplish this is to assign a color to any text in a prototype that needs to be provided by a client. All of the instances where such content is specified in the prototype can then be listed on a content overview page. Each item can be linked to the specific prototype page where the content is needed, allowing the client to refer to its context. This list page can also contain due dates and assignments associated with each item. This will help the client manage the content creation, editing, and delivery process.
Another way that a prototype can facilitate content collection is by placing a "email to" link next to each area on the site where a client must provide content. These links can trigger an email window from which the client can copy and paste, or attach the specific piece of content for that page and email it to the developer. Coordination of content is facilitated by embedding the subject line of the email with the name and placement of the content (as it is labeled in a prototype). This helps identify where each piece of content belongs on the site.
As the client provides content, the color of the links on the content list page can be changed to distinguish content that has been provided from content that is still needed. This mechanism is extremely helpful to clients as they create and deliver content. The positive feelings such help produces are another example of how grayscreen prototyping not only plays an important role in getting the job done, but also creates positive relational dynamics.
Practical tip: approval process and policy
Ultimately the client needs to "sign off" on a prototype so the designers and programmers can build the working site. Since the developer is making a strong commitment to communicating about the project in detail, the client needs to be committed to understanding what is being described and giving approval to the prototype.
A prototype, once it is completed, is the blueprint from which the final site is built. At some point, the prototyping phase needs to come to a clear end, at which time the client will sign-off on the prototype. It can be helpful to include a reminder in the sign-off document that makes it clear that the approved prototype is the final specification and definition of scope for the project.
Because many things will change during grayscreening the client needs to be aware that what they are approving is the final definition of the site. Any other documents, emails or even conversations that may have occurred are superseded by the prototype.
Practical tip: the role of the project manager
Grayscreen prototypes help improve the process of communicating the structure, content, and functionality of a proposed website. While the process itself is valuable, the role of the project manager is critical to the process running smoothly. While I am using the title project manager here, a developer may sometimes refer to this role as account manager, producer, or project leader.
The project manager is responsible for translating, communicating, and educating the client about the project using a grayscreen prototype as a communication tool. This is an important and challenging role. We have found that it is important for a project manager 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 project manager will be able to explain the technical issues in a way that is highly relevant and understandable to the client.
The project manager should always make sure that the language in the programmer notes (or anything in a prototype) is simple and understandable to the whole team. Sometimes a project manager will need to reword a programmer note (with the programmer's knowledge) to clarify it for the client.
Pulling it all together
It may seem like prototyping is a lot of work - and it is. But it is far less work that has to be done when critical details are overlooked or misunderstood. The work is well worth it when as a result of solid thoughtful prototyping is a happy client and an effective website.
| | |
