Developers are typically not HTML or usability experts and produce poor quality prototypes. Having a long-term style sheet management philosophy for a project requires a CSS and HTML expert (a “Web Developer”).
But there still needs to be room for developer change of the prototype – some ideas will not work when it comes time to implement. For example:
| Prototype |
Real life |
| Search results rarely show more than a few rows. |
Many results require either scrolling or pagination |
| Specific text lengths for displaying data is assumed. |
Actual user data is much shorter/longer and causes wrapping. Sometimes if there are data quality issues, the data can legitimately be null or missing. |
| Prototypes cover just the Javascript and CSS they need to render the example. |
Lots of functionality usually still needs to be added, such as clearing of search results, print friendly pages, custom headers and footers, autocomplete, AJAX queries. |
| Navigation models are simple – there are no HTTP posts so back buttons work perfectly and all links are simple. |
HTTP post submits prevent the browser back button from working, and links sometimes must be submit buttons. |
| Look and feel of validation errors are rarely covered. |
Complexity for the developer is rarely considered. |
| Information and error pages not usually covered. |
It's difficult for a prototype writer to guess all the possible error and information conditions in an application. |
So for a prototype:
Get an experienced Web Developer. They will be fast.
Make sure they use XHTML. There are few reasons to develop in HTML these days.
CSS styles should be the simplest possible, with mostly <div> tags in the XHTML.
Assume the prototype will be used for development, not throwaway. So come up with maintainable style sheets and put in some real life expected data samples.
Use the prototype to confirm the business stakeholder view of where development will go, before a large amount of money is spent in the development process.
