Requirements for Website Prototypes

Post from June 9, 2007 (↻ July 1, 2015), reflecting Jens the Developer.

This and many other posts are also available as a pretty, well-behaved e-book: On Web Development (announcement).

The following article is derivative of the speech I intended to hold on the webinale 07 in Ludwigsburg. It covers “best practice” for website prototypes based on HTML, CSS, and DOM scripting.

Definitions

Prototype:: A project-related collection of static and/or dynamic templates made of HTML, CSS, and DOM scripting.; A comprehensive microcosm of your online investment.

Consequently, factors like technical basis, information architecture, or quality assurance—by e.g. automated tests—are not covered here since the principles below have to be seen independently.

Problem

Bad (or even nonexistent) prototypes cost money.

Requirements

Universality

Include everything that is used live.

The “What”, related to page types and elements.

Actuality

Include everything that is used live.

The ”How“, related to possible nova on the live website.

Realism

Use “real” keywords and “real” microcontent.
Address different use cases.

But: Dummy text is okay.

The use of realistic microcontent more likely means consideration of conceptual aspects as well as less risk of “implementation losses”. “Different use cases” serve “visual integrity”—do certain teaser constellations work, does the leading of long list entries fit, and so on.

Focus

Keep it simple, avoid redundancies.

The goal: A prototype must never become the live website.

Accessibility

Take into account a broad audience:

Developers (for developing and testing),
Project managers (for inspection at the inside),
Clients (for inspection at the outside),
Users (for usability tests).

While frontend and software developers always belong to the audience of prototypes, of course, other groups are often ignored. This equals wasted potential—and wasted money. Please also note that the “users” group slightly induces a change in requirements since it generally requires more realism and less focus.

Availability

Offer a stable URL in order to:

enable ongoing use,
emphasize the importance of the prototype.

…as opposed to “local” prototypes.

Commitment

Requirements and changes in the prototype induce changes in the implementation, meaning the live website.
Requirements and changes in the implementation induce changes in the prototype.

You will usually observe a “shift” as soon as a prototype based website goes online—at first, the prototype is authoritative, but changes after the launch might rather induce changes of the prototype.

Continuity

Continuous maintenance, after project close-out, too.

Potential jackpot: The next relaunch is just a redesign.

Communication

Communicate changes, indifferent if related to prototype or implementation.

…understandably, implied by former requirements.

Documentation

Document design principles and characteristics (modules, constraints, snares).

This should be mandatory even though good, working prototypes have never died of missing documentation.

Disadvantages

A good prototype requires:

Discipline.

Advantages

A good prototype means:

Easier frontend development and testing.
Easier and more unapologetic implementation.
Easier maintenance.
“Real Life” showroom.

…and thus:

Better quality,
less costs,
more fun.

“More fun” by the quite more unlikely frustration that occurs when frontend or web developers fix errors and bugs that have been caused by differing implementations, be they bred by careless adoption or by missing communication. How many “sleeper” elements are there on your website alone?

Checklist

Is the prototype:

comprehensive?
up-to-date?
available, now?

About the Author

Jens Oliver Meiert, photo of November 30, 2015.

Jens Oliver Meiert is a German author, philosopher, adventurer, artist, and developer. Here on meiert.com he shares—and occasionally generalizes and exaggerates—some of his thoughts and experiences.

If you have any questions or concerns about what he writes, ask him to explain, or share your own position by sending a constructive comment or email. (Then, if you think something could be of interest to Jens, recommendations for excellent literature are always welcome.)

Comments (Closed)

On June 12, 2007, 13:51 CEST, Mike Padilla said:

To further enhance your hi-fidelity prototypes as a requirements collaboration tool, consider using Protonotes - http://www.protonotes.com/

Protonotes are notes that you add to your prototype that allow project team members to discuss system functionality , design, and requirements directly on the prototype. You can think of it like a discussion board/wiki in direct context of your prototype. Once you have signed up with Protonotes, all you have to do is share your unique Protonotes url with your project team members and they can begin adding notes to the prototype - they do not have to sign up.
On October 21, 2008, 20:32 CEST, Jens Oliver Meiert said:

This post is also available in German.

Have a look at the most popular posts, possibly including:

Looking for a way to comment? Comments have been disabled, unfortunately.