Requirements for Website Prototypes (and Design Systems)

Post from June 9, 2007 (↻ October 19, 2022), filed under and (feed).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

The following article provides the outline of the talk I intended to hold at the webinale 07 in Ludwigsburg. It covers best practices for website prototypes based on HTML, CSS, and DOM scripting.

Contents

  1. Definitions
  2. Problem
  3. Requirements
    1. Universality
    2. Actuality
    3. Realism
    4. Focus
    5. Accessibility
    6. Availability
    7. Commitment
    8. Continuity
    9. Communication
    10. Documentation
  4. Disadvantages
  5. Advantages
  6. Checklist

Definitions

Prototype:

A project-related collection of static or dynamic templates made of HTML, CSS, and DOM scripting.

A microcosm of your online investment.

Accordingly, factors like technical foundation, information architecture, or quality assurance—for example, through automated tests—are not covered here since the principles below have to be viewed independently.

Problem

Bad (and, even more so, non-existent) prototypes cost money.

Requirements

Universality

Include everything that is used live.

The “What,” meaning page types and elements.

Actuality

Include everything that is used live.

The “How,” meaning any other changes to the live website.

Realism

But: Dummy text is okay.

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

Focus

Keep it simple, avoid redundancies.

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

Accessibility

Take into account a broad audience:

While web and software developers always belong to the audience of prototypes, other groups are often ignored. This is wasted potential—and wasted money. Furthermore, the “users” group means a change in requirements since it requires more realism and less focus.

Availability

Offer a stable URL in order to:

…which isn’t possible with local and temporary prototype installations.

Commitment

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 will induce changes of the prototype. Make sure to avoid drift.

Continuity

Continuous maintenance, even after project finish.

Potential jackpot: The next relaunch is just a redesign.

Communication

Communicate changes, no matter if related to prototype or implementation.

…as implied by earlier requirements.

Documentation

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

This should be mandatory even though good, working prototypes rarely die of missing documentation.

Disadvantages

A good prototype requires:

Advantages

A good prototype means:

…and thus:

“More fun” through less frustration by fixing errors and bugs that have been caused by differing browser implementations. How many untested “sleeper” elements are there on your website?

Checklist

Is your prototype (and your design system):

Toot or tweet about this?

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!