Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Der Projektverlauf aus dem Bilderbuch

Best Practice Projektmanagement

Der Projektverlauf aus dem Bilderbuch

Durch moderne Browser auf unzähligen, immer wieder neuen Ausgabegeräten mit unterschiedlichen Bildschirmgrößen haben sich auch die Anforderungen an das Projektmanagement responsiver Webseiten drastisch verändert. Wir geben euch Tipps, wie ihr ein Web-Projekt plant, konzipiert, gestaltet, entwickelt und betreibt, so dass dabei weder Zeit oder Budget überschritten werden noch die Qualität leidet.

Zu oft werden seitens der Kunden oder Agenturen die alten Wege des sogenannten Wasserfallprinzips vorgegeben oder verlangt, also eine Abfolge der Projektschritte Planung/Konzeption > Grafiklayout > Frontend > Backend > Launch. Diese Praxis entsprach aber noch nie einem angemessenen Projektmanagement für Webseiten. Die klare Linearisierung von Leistungen und Zuständigkeiten im Lasten-/Pflichtenheft ist für Entscheider oder in größeren Teams leider noch immer attraktiv und das ganze funktionierte augenscheinlich bis vor wenigen Jahren irgendwie, jedenfalls so lange man sich auf die Nutzung von Webseiten am Desktop oder Laptops verlassen konnte.

Mit den Anforderungen an responsive Webseiten wissen wir, dass sich mit einem veränderten Nutzungsverhalten auch die Herangehensweise an Planung und Umsetzung grundlegend ändern muss. Jeder von euch, der schon einmal eine moderne Website nach dem Wasserfallprinzip umsetzen musste, kennt die potenzierten Gefahren von unvorhergesehenen Umsetzungsproblemen, unkalkulierten Mehrstunden und faulen Kompromissen in der Darstellung.

Planung

Die Planungsphase ist das Fundament unserer Arbeit. Wer hier pfuscht, muss wie im Hausbau mit einer ewigen Ruine rechnen. Planung umfasst heute nicht mehr die Festlegung einer linearen Leistungsabfolge, sondern die ständige Infragestellung, Kontrolle und Verifizierung von Zielen, Umfang, Inhalten, Zielgruppen und Nutzerverhalten. Nur auf dieser Grundlage können die unterstützten Browser, Breakpoints für verschiedene Bildschirmgrößen und Rahmenbedingungen für Benutzerführung, Barrierefreiheit und Style Guide festgelegt werden.

Ich empfehle euch, diese Planung nur bei sicheren Kunden mit in das Angebot einzupreisen, bei unsicherem Ausgang der Angebotsfindung solltet ihr diese Arbeit als separaten Projektworkshop anbieten und auch separat abrechnen. Wichtig ist nur, dass ihr vor Beendigung der Planungsphase eine Angebotsabgabe unbedingt vermeiden solltet – zu ungenau wäre die Aufwandsschätzung, die mit einem Puffer entweder das Angebot unnötig verteuert, oder ihr geht am Ende mit dem Stundenlohn eines Burgerverkäufers nach Hause.

In der Regel sind eure Kunden zwar auf das Projekt vorbereitet, aber auch hier steht wie bisher das Design an erster Stelle, heutzutage lediglich ergänzt um den Satz »Soll auch auf dem Smartphone gut aussehen«. Die von Kunden immer gern präsentierten Mockups oder bereits ausgearbeitete Grafiklayouts für Desktop-Monitore solltet ihr mit dem Hinweis »darauf kommen wir später zurück« zunächst beiseite legen.

Fragen über Fragen: Meeting/Checkliste

Die Komplexität der Themen innerhalb der Planungsphase erfordert in vielen Fällen ein Meeting aller beteiligten Akteure und Entscheider, bei größeren Projekten sind mehrtägige Workshops sinnvoll. Kleine Projekte können auch mit der Zusendung einer Checkliste geplant werden. Zunächst geht es um das Ziel und die Funktion der Website, um die Zielgruppen, die mit der Webseite erreicht werden sollen und um das zu erwartende Nutzerverhalten.

Es geht nicht nur um die Inhalte des Lasten- und Pflichtenheftes, es geht vor allem um die Frage: Was wird wie von wem wo genutzt? Zur besseren Definition der Zielgruppen könnt ihr eure Fragen um die Persona-Methode erweitern. Mit der Persona-Methode wird versucht, hypothetische Nutzer mit bestimmten Eigenschaften, typischen Vorlieben sowie einem konkreten Nutzungsverhalten zu klassifizieren. Ziel ist nicht die Herausstellung einer realen und singulären Person, sondern imaginäre Nutzer als Prototyp(en) eurer Zielgruppe. Die Definition ermöglicht eine bessere Priorisierung der Anforderungen an Benutzerführung, Seitenaufbau, Design und Funktionen.

Das durch Statistiken oder heuristische Verfahren belegte, beziehungsweise wahrscheinliche Nutzerverhalten ist in erster Linie abhängig vom Content, der wiederum abhängig von der Funktion aufbereitet werden sollte. Zum Abschluss dieser Phase sollte euch nicht nur klar sein, auf welche Breakpoints und welche unterstützten Browser die Umsetzung hinausläuft, auch die Frage, ob die Nutzer hauptsächlich Desktop-Monitore, Tabletgrößen oder vorwiegend Smartphones verwenden werden, sollte beantwortet sein. Falls nicht, müsst ihr mit dem Kunden weiter an der Definition der Nutzer- und Zielgruppen arbeiten.

Nach Abschluss dieser Phase könnt ihr mit den gesammelten Informationen ein aussagekräftiges Angebot erstellen. Ich gebe seit ein paar Jahren keine Fixpreise mehr ab, sondern nur noch eine Aufwandsschätzung. Mit der Vorarbeit und dem Vertrauen eures Kunden ist das auch kein Problem. Erstellt ein möglichst detailliertes Angebot mit allen Pflichten- und Lastenaufstellung. Euer Kunde wird das nicht alles lesen, aber im Falle von unvorhergesehenen und ungeplanten Sonderwünschen ist das Dokument wichtig.

Content definieren, strukturieren, hierarchisch ordnen

Die Inhalte solltet ihr mit dem Kunden gemeinsam durcharbeiten, um den Content insgesamt zu definieren. Der Fokus liegt auch hier auf dem zuvor festgelegten Ziel und den Antworten auf die erwähnte Kernfrage, was wie von wem wo genutzt wird. Das Rückgrat einer Webseite ist die Navigation, deshalb strukturiert den Gesamtinhalt zunächst in logische Blöcke. Diese Grobstruktur definiert automatisch die Hauptnavigation. Davon ausgehend geht ihr in die Feinabstimmung: wo können Inhalte zusammengefasst werden, welche Inhalte müssen noch weiter diversifiziert werden? Auf diese Weise kommt ihr automatisch zu Untermenüs, je nach Umfang auch in mehreren Ebenen. Als »Tool« empfehle ich hier kleine Zettel, die schnell auf dem Tisch, einer Flip-Chart oder auf dem Fußboden hin- und hergeschoben werden können.

Webteam der britischen Regierung ordnet Inhalte mit Zettel auf einer Flipchart
Content-Strategie des Webteams der britischen Regierung: Zettelschieben auf einer Flipchart

Projekte verlaufen nicht linear

Der Begriff »Workflow« impliziert eine lineare Abfolge von Handlungen, die ihr in der Praxis vermeiden solltet: falls ihr euer Projekt im Team umsetzt, bindet frühzeitig alle Beteiligten mit ein. Das hat weniger mit Transparenz der Projektentwicklung zu tun, sondern mit dem praktischen Nutzen, wertvollen und oft unterschätzten Input schon in der Planungsphase zu erhalten. Der Designer wird vielleicht auf mögliche Gestaltungsbrüche bei den Anforderungen an die Inhaltsbereiche hinweisen, der Frontend-Entwickler auf mögliche Probleme bei der Umsetzung von geplanten Multimedia-Inhalten, der SEO-Experte auf doppelten Content. Alle werden durch die Einbindung aber früh Lösungen zeigen, die beim Weiterreichen fertiggestellter Projektpakete nur mit Umwegen oder gar nicht machbar wären.

Wireframes

Wireframes sind für moderne Webseiten das wichtigste Konzeptionstool, das zwischen der Festlegung eurer Contentstruktur und dem Aufbau der Seiten oder den Templates steht. Neben den Platzhirschen Photoshop und Fireworks könnt ihr ebenso gut Präsentationssoftware wie Powerpoint oder Keynote verwenden, oder auf eines der speziellen Wireframing-Tools zurückgreifen. Eine besondere Empfehlung von mir bekommt das Programm Gravit, eine Art Open-Source-Derivat von Fireworks, das als Online-Tool und als Applikation für Mac und PC zur Verfügung steht.

Ausgabe Google Bildsuche, Stichwort "Wireframes"
Google-Bildsuche zu Wireframes

Wireframes dienen nur der Aufteilung und Positionierung der Inhaltsblöcke und Seitenelemente. Wichtig ist deshalb, dass ihr mit Graustufen, Systemschriften und einfachen Formen arbeitet. Vermeidet Farben und jegliches Design. Wireframing ist immer »work in progress«, Fehler sind erlaubt, nichts wird in Beton gegossen, die Entwürfe sollten also schnell anpassbar sein. Wichtig: arbeitet eng mit eurem Kunden zusammen.

Nutzt die bereits erledigte Hierarchien innerhalb der Contentblöcke, um in den Wireframes neben der Festlegung typischer Seitenelemente unter Umständen auch obsolete Inhalte, beziehungsweise separate Elemente für mobile Varianten auszuloten. Erstellt mindestens zwei Wireframes, besser drei. Der Aufwand hält sich durch die Abwesenheit von Designdetails in engen Grenzen, aber ihr könnt grob die Aufteilung für Desktop/Widescreen, Tabletgrößen und Smartphones erstellen, wobei die Grenzen zwischen Mini-Tablets und aktuellen XL-Smartphones immer mehr verwischen.

Verwendet für die Wireframes möglichst früh die finalen Texte, drängt die Verantwortlichen rechtzeitig zur Generierung des Contents. Blindtexte erscheinen bequem, vor allem bei Mengentext kann der grob geplante Zeichenumfang in der Umsetzung von der tatsächlichen Textmenge jedoch derart abweichen, dass danach erneut alle Wireframes überarbeitet werden müssen. Grundsätzlich gilt: je später der finale Content bereitgestellt wird, umso größer die Unsicherheit, dass eine vorab gewählte Seitenaufteilung oder gar ein Layout passen – die Inhalte bestimmen schon in dieser Phase das Wesen und Aussehen der Verpackung. Ähnliches gilt auch für Platzhalterbilder, die aus Gründen der Bildwahrnehmung zumindest dort echte Halbton- oder Vektorgrafiken zeigen sollten, wo entsprechende Bildinhalte geplant sind.

… und kleine Projekte?

Nicht jedes Budget reicht für eine Webseite mit großem Funktionsumfang, einem individuellen Design und vorbildlicher Responsivität. Verzichtet trotzdem nicht auf Wireframes, konzentriert euch dabei aber nur auf die relevanten Seitenbereiche. Es genügt, wenn ihr am Ende mit diesen groben Skizzen ein passendes Fertigtemplate für euer CMS aussucht oder das Grundlayout bereits umgesetzter Webseiten wählen könnt. Die für das Design gesparte Zeit könnt ihr besser in die Sicherstellung der Barrierefreiheit investieren, ein Aspekt, bei dem gerade Fertigtemplates selten gut abschneiden.

Bunte Wireframes oder HTML?

Parallel zu den Wireframes kann auch ein Moodboard/Styleguide für die Website festgelegt werden. Oft werdet ihr mit Vorgaben arbeiten, die sich aus einem bestehenden CI oder dem Logo ergeben. Wichtig ist nicht die Quantität, achtet auf qualitative Aspekte wie Farbkontraste und Farbvariationen (Barrierefreiheit, Pseudoklassen), passende Schriften und grundsätzliche Formensprache. Denkt daran, dass es bei diesem Zwischenschritt nur um das »Look & Feel« gehen soll, damit sich euer Kunde ein Bild von seiner zukünftigen Webseite machen kann. Verzettelt euch nicht in den Untiefen von Photoshop & Co., Designdetails würde den Sinn dieser Arbeit konterkarieren. Wenn euer Styleguide bereits zentrale Elemente beinhalten soll, die dann unverändert in das finale Design übernommen werden – beispielsweise die Darstellung von Teaserboxen oder wichtigen Buttons – solltet ihr diese Arbeiten bereits als HTML-Dummies umsetzen. Es gibt keinen triftigen Grund außer die Bequemlichkeit bekannter Wege, HTML-Elemente vorher noch in Fireworks oder Photoshop zu gestalten. Ihr könnt in eure Dummies einen kompletten Textbereich mit Überschriften und Absätzen zur Visualisierung von Abständen, Zeilenhöhen und Schriftgrößen darstellen, hier sind auch Logo und Headerbild schnell eingepasst.

Umsetzung

Bis jetzt kamen wir ohne Grafiklayouts aus. Und ab jetzt sprechen wir schon vom HTML-Prototyping. Photoshop sollte ab jetzt geschlossen bleiben - zumindest im Idealfall. In der Regel sind bei einigen Kunden immer mal wieder Änderungen am Design notwendig, bei Farbvarianten können Grafikprogrammen dann durchaus effektiver sein als die ständige Bearbeitung eurer CSS-Datei. Wie bei den Wireframes gebe ich beim Prototyping auch hier den Rat: nehmt den Editor, die Tools oder das CSS-Framework eurer Wahl, mit dem ihr euch wohl fühlt und das ihr beherrscht. Da ich seit vielen Jahren mit YAML arbeite, verwende ich beispielsweise Thinkin' Tags. Ihr könnt ebenso Adobe Edge Inspect, Antetype, beziehungsweise Dreamweaver verwenden.

Screenshot des Layout- und Prototyping-Tools "Thinkin'Tags"
Screenshot Thinkin
Atomic Design vs. Trial & Error

Brad Frost hat eine interessante Methode der Designumsetzung vorgestellt, die vom kleinsten Element bis zur Gestaltung der Einzelseite reicht. Dieses Vorgehen, das er »Atomic Design« nennt, ist vor allem für größere Teams und heterogene Entscheidergruppen zu empfehlen, um in der Abstimmung eine Vielzahl von kleinen Nebenkriegsschauplätzen an der Gardinenfront zu vermeiden. Für kleinere Projekte empfehle ich eher eine Umsetzung nach dem Trial & Error-Prinzip. Elemente, die bereits im Styleguide oder als HTML-Dummy umgesetzt wurden, dienen als gute und vom Kunden bereits abgenommene Referenz für die Gesamtgestaltung. Die Ausarbeitung umfasst zwar einzelne Iterationsphasen und Korrekturschleifen, aber unter dem Strich sind die finalen Templates schneller fertig.

Screenshot der Website von Brad Frost zu "Atomic Design"
Brad Frosts Website zu Atomic Design

Work in progress = communication in progress

Selbst bei bestem Willen, mit Disziplin jede Planungs- und Umsetzungsphase einzuhalten, wird es im Verlauf eures Projektes immer wieder zu Problemen, ungeplanten Korrekturschleifen und lästigen Iterationen kommen. Die gute Nachricht: das ist nicht nur völlig normal, das ist oft genug auch notwendig, um die auf dem »grünen Tisch« erdachten Konzepte mit dem aktuellen Stand und veränderten Gegebenheiten des Projektes abzugleichen. Achtet lediglich auf eine stetige, offene und vor allem sachliche Kommunikation auf Augenhöhe. Emotionale Aussagen sind wenig hilfreich, da sie fast immer von einem gestärkten oder gekränkten Ego gespeist werden. Die überlegene Rechthaberei des Siegers und die gekränkte Rechtfertigung des Unterlegenen sind für jedes Projekt schädlich. Vermeidet einen derartigen Ego-Krieg, bei dem nicht selten das Projektziel der eigenen Standpunktverteidigung geopfert wird.

Testen!

Der simple und per Mausklick generierte Styleguide Stylify Me bietet euch nicht nur eine Design-Zusammenfassung eures Projektes, er ist auch prima geeignet, eventuelle Inkonsistenzen bei Schriften und Farben offenzulegen. Nicht erst nach der Fertigstellung umfasst die ständige Testphase diverse IEs, als Idealfall könntet ihr außerdem umfangreiche Tests in einem Open Device Lab für mobile Geräte vornehmen. Sofern ihr euch diese Arbeit ersparen wollt (oder aus Budgetgründen ersparen müsst), bietet Browserstack mit einer Riesenauswahl von Desktop- und Device-Browsern eine bequeme, wenn auch nicht günstige Lösung auf der Basis von Emulationen.

Weiterführende Links

Allgemeines zum Workflow im Responsive Webdesign

Zielgruppenkonzeption und Personas

Wireframing

Moodboards und Style Guides

Prototyping

Testumgebungen

Kommentare

Olaf Gleba

Olaf Gleba (Webkraut)
am 01.12.2014 - 10:30

Danke Nils für den hervorragenden Artikel! Wahrscheinlich reicht gar nicht ein Bleistift, um alles zu unterstreichen, was dort drin steht.

Permanenter Link

Susanna Künzl
am 01.12.2014 - 16:57

Diesen Artikel würde ich gerne jedem so gewünschten Festpreis-Angebot beifügen. Auch bei kleineren Projekten sollten zuerst die Aktionen und Inhalte umrissen werden, bevor jemand Photoshop anwirft. Und beide Partner sollten wissen, anerkennen und kalkulieren, dass heute viel mehr Kommunikation benötigt wird, um eine Website zu erstellen.

Permanenter Link

Susanne Studt
am 02.12.2014 - 11:28

Der Mensch tut sich schwer, alte Gewohnheiten abzulegen. Schön, diesen ausführlichen und doch auf den Punkt gebrachten Text zum Thema Workflow für moderne Webprojekte hier zu lesen. Danke auch für die hilfreichen Tool-Links!

Permanenter Link

Norbert Felgendreher
am 10.12.2014 - 09:13

Hallo,
vielen Dank fü den Artikel. Zur "Umsetzung"...
für ThinkinTags gibt es offenbar seit einem Jahr keinen Support mehr.
Es macht einen verlassenen Eindruck, voller Spam, Anfragen bleiben unbeantwortet...
Ist was Projekt stillschwigend eingestellt worden

Gruß

Norbert

Permanenter Link
Nils Pooker

Nils Pooker (Autor)
am 10.12.2014 - 10:08

Hallo Norbert, die App selbst funktioniert einwandfrei. Eingestellt ist das meines Wissens nach nicht, ich kann Dirk mal kontaktieren. Gruß Nils
Permanenter Link

Norbert Felgendreher
am 10.12.2014 - 11:35

Hallo, Nils,
ich habe einen Account für ThinkinTags, den ich aber nicht mehr nutzen kann, weil die von mir erstellten Projekte nicht mehr heruntergeladen werden können (Meldung: 404 Not Found)
Eine Supportanfrage vor einigen Wochen blieb unbeantwortet. Das Forum ist zugespammt.

Gruß

Norbert

Permanenter Link

Dirk
am 10.12.2014 - 16:41

Hallo Norbert,

solch ein Projekt ist nicht immer zeitnah zu betreuen, wenn man es parallel zur normalen Arbeit und der Familie vorantreibt. Zendesk hat leider einen miserablen Spam-Schutz, daher wird das Forum immer wieder mal überflutet. Und es ist wirklich eine Sauarbeit, das wieder zu bereinigen.

Das Exportproblem hattest nicht nur Du. Es ist aber seit ca. einer Woche gefixt und ich habe seither beobachtet, ob wieder alles rund läuft. Vorhin sind auch die Tickets aktualisiert worden.

Permanenter Link

Die Kommentare sind geschlossen.