Anforderungen an Website-Prototypen (webinale, Berlin)
Vortrag vom 23. Mai 2007 (↻ 8. Juni 2007), exklusiv für die webinale, Berlin (nicht gehalten).
Dieser und viele andere Beiträge sind auch als hübsches, wohlerzogenes E-Book erhältlich: On Web Development.
Inhalt
Definitionen
- Prototyp:
-
Eine projektbezogene Sammlung von statischen oder dynamischen Vorlagen basierend auf HTML, CSS und DOM-Scripting.
Ein Mikrokosmos Ihrer Online-Investition.
Entsprechend vor allem der ersten Definition sind im Folgenden Faktoren wie technische Basis, Informationsarchitektur oder Qualitätssicherung – durch zum Beispiel automatisierte Tests – von Prototypen nicht relevant.
Problem
Schlechte (oder gar non-existente) Prototypen kosten Geld.
Anforderungen
Universalität
Alles abbilden, das auch live ist.
Das »Was«, auf Seitentypen und -elemente bezogen.
Aktualität
Alles abbilden, das auch live ist.
Das »Wie«, auf etwaige Nova auf der Live-Website bezogen.
Realismus
- »Echte« Schlüsselwörter, »echten« Mikrocontent einsetzen.
- Verschiedene Anwendungsfälle abbilden.
Aber: Blindtext ist okay.
Der Einsatz von realem Mikrocontent bedeutet eine wahrscheinlichere Berücksichtigung konzeptioneller Aspekte sowie ein geringeres Risiko von »Implementierungsverlusten«. »Verschiedene Anwendungsfälle« dienen der Sicherstellung der »visuellen Integrität« – funktionieren bestimmte Teaser-Konstellationen, passt die Zeilenhöhe bei langen Listeneinträgen und so weiter.
Fokus
Einfach halten, Redundanzen möglichst meiden.
Erklärtes Ziel: Ein Prototyp soll nie zur Live-Website »verkommen«.
Zugänglichkeit
Breites Publikum vorsehen:
- Entwickler (zum Entwickeln/Testen),
- Projektmanager (zur internen Inspektion),
- Kunden (zur externen Inspektion),
- Benutzer (fĂĽr Usability-Tests).
Während Frontend- und Softwareentwickler logischerweise immer zur Zielgruppe von Prototypen gehören, werden andere Gruppen in der Praxis gerne vernachlässigt. Dies entspricht ungenutztem Potential und letztlich auch herausgeschmissenem Geld. Wichtig bei der »Benutzer«-Gruppe – hier verändern sich die Anforderungen ein wenig, da diese in der Regel mehr Realismus und weniger Fokus erfordert.
VerfĂĽgbarkeit
Fixen URI vorsehen, um:
- fortlaufende Verwendung zu ermöglichen,
- Wichtigkeit des Prototypen zu unterstreichen.
… im Gegensatz zu »lokalen« Prototypen.
Verbindlichkeit
- Erfordernisse und Änderungen im Prototyp bedeuten Änderungen in der Implementierung, also der Live-Website.
- Erfordernisse und Änderungen in der Implementierung bedeuten Änderungen im Prototyp.
In der Regel beobachtet man eine Verschiebung, sobald eine auf einem Prototypen aufbauende Website ins Netz geht – während vor Launch der Prototyp maßgebend war, können nach Launch erfolgte Änderungen der Live-Website Anpassungen am Prototypen induzieren.
Kontinuität
Fortlaufende Wartung, auch nach Projektabschluss.
Möglicher Hauptgewinn: Der nächste Relaunch ist nur ein Redesign.
Kommunikation
Änderungen kommunizieren, egal ob prototyp- oder implementierungsbezogen.
… logischerweise, durch die vorhergehenden Erfordernisse impliziert.
Dokumentation
Dokumentieren von Designprinzipien und Charakteristika (Module, Constraints, Fallstricke).
Auch wenn ein guter, funktionierender Prototyp noch nie an fehlender Dokumentation gestorben ist, ist dies dennoch ein obligatorischer Punkt.
Nachteile
Ein guter Prototyp erfordert:
- Disziplin.
Vorteile
Ein guter Prototyp bedeutet:
- Leichtere(s) Frontend-Entwicklung und Testen.
- Leichtere und unmissverständlichere Implementierung.
- Leichtere Wartung.
- »Real Life«-Showroom.
… und dadurch:
- Bessere Qualität,
- geringere Kosten,
- mehr SpaĂź.
»Mehr Spaß« durch die wesentlich unwahrscheinlichere Frustration, die auftritt, wenn Frontend- oder Webentwickler Fehler beheben müssen, die aufgrund abweichender Implementierung entstanden sind – unerheblich, ob unsorgfältig übernommen wurde oder dies jeweils legitim war, aber unkommuniziert. Wieviele »Schläfer«-Elemente gibt es mittlerweile allein auf Ihrer Website?
Checkliste
Ist der Prototyp:
- umfassend?
- aktuell?
- verfĂĽgbar, jetzt?
Ăśber mich

Ich bin Jens Oliver Meiert, und ich bin ein Engineering Manager und Autor. Ich habe als technischer Leiter für Google gearbeitet, bin dem W3C und der WHATWG verbunden und schreibe und begutachte Bücher für O’Reilly. Ansonsten experimentiere ich gerne, mitunter auch in den Bereichen Philosophie, Kunst und Abenteuer. Hier auf meiert.com teile ich einige meiner Ansichten und Erfahrungen.
Wenn du Fragen oder Anregungen zu dem hast, was ich schreibe, sende mir gerne eine Nachricht.
Ähnliche Themen
Das könnte dich ebenfalls interessieren:
- Prinzipien der Webentwicklung: Entwickeln Sie für was ist, nicht was sein könnte
- CSS der Zukunft
- Elemente, Tags und Attribute
Schwerpunkt: Webentwicklung.

Mein vielleicht umfangreichstes Buch: The Web Development Glossary (2020). Mit Erklärungen und Definitionen zu buchstäblich tausenden Begriffen der Webentwicklung und verwandten Feldern, aufbauend auf Wikipedia sowie den MDN Web Docs. Erhältlich bei Apple Books, Kobo, Google Play Books und Leanpub.