Anforderungen an Website-Prototypen (webinale, Berlin)

Vortrag vom 23. Mai 2007 (↻ 23. September 2022), exklusiv für die webinale, Berlin (nicht gehalten). Schwerpunkt: (RSS-Feed für alle Themen).

Dieser und viele andere Beiträge sind auch als hübsches, wohlerzogenes E-Book erhältlich: On Web Development.

Inhalt

  1. Definitionen
  2. Problem
  3. Anforderungen
    1. Universalität
    2. Aktualität
    3. Realismus
    4. Fokus
    5. Zugänglichkeit
    6. VerfĂĽgbarkeit
    7. Verbindlichkeit
    8. Kontinuität
    9. Kommunikation
    10. Dokumentation
  4. Nachteile
  5. Vorteile
  6. Checkliste

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 (und erst recht 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 Änderungen und Neuerungen auf der Live-Website bezogen.

Realismus

Aber: Blindtext ist okay.

Der Einsatz von realem Mikrocontent bedeutet eine wahrscheinlichere Berücksichtigung konzeptioneller Aspekte sowie ein geringeres Risiko von »Implementierungsverlusten«. Die verschiedenen 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 nicht zur Live-Website »verkommen«.

Zugänglichkeit

Breites Publikum vorsehen:

Während Web- 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

Fixe URL vorsehen, um:

… was mit lokalen und temporären Prototypinstallationen nicht möglich ist.

Verbindlichkeit

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. Drift ist zu vermeiden.

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:

Vorteile

Ein guter Prototyp bedeutet:

… und dadurch:

»Mehr Spaß« durch die wesentlich unwahrscheinlichere Frustration, die auftritt, wenn Web- und Softwareentwickler Fehler beheben müssen, die aufgrund abweichender Implementierung entstanden sind – unerheblich, ob unsorgfältig übernommen wurde oder dies jeweils legitim war, aber unkommuniziert. Wie viele »Schläfer«-Elemente gibt es mittlerweile allein auf Ihrer Website?

Checkliste

Ist der Prototyp (und das Designsystem):

War dies nützlich oder interessant? Teile diesen Beitrag, werde Nanosponsor oder unterstütze meine Arbeit, indem du mit meinen E-Books lernst.

Ăśber mich

Jens Oliver Meiert, am 9. November 2024.

Ich bin Jens (lang: Jens Oliver Meiert), und ich bin ein Frontend-Engineering-Leiter und technischer Autor/Verleger. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin Mitwirkender an verschiedenen Webstandards und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Ich experimentiere gerne, nicht nur in der Webentwicklung (und im Engineering Management), sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Erfahrungen und Ansichten. (Bitte sei kritisch, interpretiere wohlwollend und gib Feedback.)