Ein Thema, das sich kontrovers diskutieren lässt. Wireframes sind in der Tat nicht immer das Architektur-Mittel der Wahl. Aber in sehr vielen Fällen sehr wohl.

Was mir immer aufstößt, sind Pauschalisierungen, ohne Kontext.

Hierzu mal zwei Äußerungen des Autors:

It doesn’t take a good designer long to whip up a Photoshop mockup, and a good coder can create a HTML prototype in a short time too. Both can be reused in the final product (which saves time), and both are much closer to the real experience than a wireframe (which helps make the right decisions).

Mag sein. Aber a) sind Wireframes immer noch schneller und b) können die richtigen Personen auch auf Basis von Wireframes die richtigen Entscheidungen treffen – zum richtigen Zeitpunkt im Prozess. Es gibt natürlich aber auch Fälle und kleinere Projekte, in denen der Wireframe schon zur Kanone gegen den Spatzen mutiert. Es kommt darauf an.

My problem with your point is that because wireframes are so easy to modify, people get obsessed with shuffling things around until they obtain a perfect wireframe, but this really doesn’t accomplish much: a perfect wireframe does not translate into a perfect site, there are just too many factors that are left aside at such an early stage.

Ein perfekter Wireframe ist natürlich keine Garantie für ein perfektes Endprodukt. Ein guter Wireframe trägt aber zu einem soliden Fundament bei. Die Angst vor Leuten, die einen Wireframe zum Anlass nehmen, Dinge immer wieder hin und her zu schubsen, liegt in einer fehlenden Prozess- und Methodenkenntniss begraben. Es kommt darauf an, wann und für wen die Wireframes in Frage kommen.

Hierzu kann ich ein Buch sehr empfehlen. Dan M. Browns “Konzeption und Dokumentation erfolgreicher Webprojekte”. Darin geht es v.a auch darum, wann, in welcher Form man Deliverables (so auch Wireframes) erstellt und wem und wann man sie präsentiert. Das Buch habe ich vor einiger Zeit hier mal vorgestellt.

Ein Re-Design. Hintergründe dazu im Happy Cog Studio.

Corporate Websites sind keine Silos mehr, in der wir alle unsere Daten und Features reinstopfen, um dann alle Interessenten einzeln ins Silo zu lassen, um sich die Sache mal anzusehen.

Über die Anforderungen an moderne Corporate Websites: 5 Wege die Corporate Website mit Social Technologies weiterzuentwickeln.

Das Problem mit den WirHabenDochKeineZeitUndKeinBudget-Gespenstern: The User Centered Design Conundrum.

Gedanken zum Thema Wireframes: The Future of Wireframes.

Tabellen haben auch ihre Daseinsberechtigung. Ein paar Tipps und Anschauungsbeispiele: Ultimate guide to table UI patterns.

Print stirbt, Digital rockt. Verwirrung. Über verschiedene Arten von Content und damit umzugehen: Books in the Age of the iPad.

Brutal mag da etwas übertrieben sein, aber die Statements lassen erahnen, wie umfangreich und komplex das Management einer Website sein kann. Vielleicht habt auch Ihr schon in überraschte Gesichter geblickt, wenn es um Wartungskosten, Aufwände für frischen Content etc. ging. Oder Ihr seid daran verzeifelt, dass in großen Gremien, stundenlang über verschiedene Grüntöne diskutiert wurde.

Der o.g. Artikel listet 28 Punkte und Zitate. Von initialer Bedeutung sind meiner Meinung nach die Punkte:

• Direction bzw. Ownership
• Bunfights (interessanter Begriff) bzw. zu viele Stakeholder
• Speed Kills bzw. Go-Live in Rekordzeit

Gerade Direction und Ownership gilt es zu Beginn und für den späteren Betrieb eindeutig zu klären. Um erstens konsistent sein zu können und zweitens vorwärts zu kommen. Gerade an diesem Punkt scheitern viele Angebote, gerade dann, wenn es um Corporate Websites geht. Das endet oft darin, dass die Besucher einer Website förmlich erschlagen werden. Weil jede Abteilung meint, prominent auf der Startseite vertreten sein zu müssen.

Speed Kills beschreibt den Umstand, dass (leider) oft die Qualität der Inhalte und Usability/Barrierefreiheit, einem schnellen Go-Live geopfert werden.

Obwohl. Vielleicht ist das Managen einer Website doch brutal ;-)

Aber lest selbst: 28 reasons why website management is brutal.

Dazu kam es aber trotzdem ;-) Die Diskussion ist – wenn teils auch etwas Pingpong artig geführt – nicht ganz uninteressant. Und offenbart zwischen den Zeilen weitere interessante Aspekte. So z.B. auch den des Einflusses von Redakteuren auf die Barrierefreiheit.

Wenn man aber 10 Redakteure hat, die HTML Code eingeben, wie sie gerade lustig sind, hilft weder das W3C noch ein Validator… ;-)

Stimmt bedingt, wie auch ein folgender Kommentar anmerkt.

Hier könnte einer der zahlreichen zertifizierten Entwickler in Ihrem Haus sicher weiterhelfen und den RTE ordentlich konfigurieren. Das kann schlechten Redakteurscode signifikant mindern.

Stimmt. Aber auch so lassen sich Fehler nie ganz ausschließen. Ein noch so gezielt konfigurierter Editor verhindert nicht alle Fehler. So war es auch bei uns im Fall einer großen Webseite, wo trotz zusätzlicher Schulungen und Guidelines für Redakteure, immer wieder mal Fehler auftraten. Aber auch das ist ganz normal.

Das Zauberwort heißt Qualitätssicherung. Auch eine fertige und zum Startzeitpunkt fehlerfreie Webseite, muss in regelmäßigen Abständen geprüft werden. Nur so lässt sich Qualität halten.

Eine Website ist eben nie fertig. Die Einhaltung von guten Standards und Prozessen ist auch und v.a. im Betrieb essentiell für die Qualität und den Fortbestand einer Webseite.

Also – unabhängig vom Thema Barrierefreiheit – ist es schlicht und ergreifend so: Es gibt keine automatische Hohmpäidsch (Artikel hier im Webzeugkoffer).

Ich habe es dabei v.a. auf die Aufwände für Kommunikation mit dem Kunden abgesehen. Aufwände für den Mailverkehr und Telefonate. Aufwände, die bei der Projektkalkulation – würde ich mal behaupten – oft unterschätzt werden.

Im konkreten Beispiel haben sich bisher 30 Stunden Gesamtaufwand ergeben. Knapp 4 Stunden sind für die Kommunikation mit dem Kunden draufgegangen. Also rund 13% für Kommunikation im Projekt. Wohlgemerkt ein 1:1 Projekt. Ein Kunde, ein Auftragnehmer.

Mir kommt das noch eine Spur zu viel vor und mein Ziel für kommende Projekte wäre, diesen Posten auf unter 10% zu drücken.

Es ist allerdings darauf zu achten, die Kommunikation nicht zu vernachlässigen. Ganz ohne das persönliche Gespräch oder die Mail zwischendurch geht es dann auch wieder nicht. Denn gute Kommunikation hat nämlich auch einen positiven Einfluss auf den Projekterfolg.

Kommunikation ist Arbeitszeit ist Projektaufwand

Bei der Kalkulation eines Projektes ist die Kommunikation fester Bestandteil. In Angeboten findet man diese nicht unbedingt direkt. Sie ist Bestandteil von Angebotspositionen wie z.B. “Projektmanagement-Aufwand”. Oder man hat eine Pauschale, die grundsätzlich draufgeschlagen wird und so in allen Positionen berücksichtigt ist.

D.h. wir müssen entsprechend Aufwände bei der Angebotskalkulation berücksichtigen. Aber auf der anderen Seite müssen wir als Anbieter auch an uns bzw. einer bestmöglichen Kommunikation arbeiten. Schätze ich also 30 Stunden Umsetzungsaufwand (inkl. Konzeption und Beratung), dann schlage ich etwa 4 Stunden drauf (13% aus obigem Beispiel).

Laut meinem oben formulierten Ziel möchte ich aber auf 10% oder darunter kommen. Also 3 Stunden für Kommunikation. Und ich denke, dass sich durch die Berücksichtigung einiger Grundregeln auch die 3-4% rausholen lassen. Ich berechne dann zwar eine Stunde weniger, biete aber auf der anderen Seite vielleicht ganz einfach einen besseren Service und kann einen besseren Preis machen. Gerade dann, wenn meine Kommunikation zielgerichtet und geordnet beim Kunden ankommt.

(Persönliche) Ansatzpunkte für bessere Kommunikation

Ich habe mir ein paar Ansatzpunkte identifiziert, die mir dabei behilflich sein können, zukünftig noch effizienter mit den Kunden zu kommunizieren:

Anfragen gesammelt beantworten: Gerade in der Endphase eines Projekts treten immer wieder Fragen auf oder den Kunden fallen noch kleine Fehler auf. Gerade kleinere Fehler treten oft an verschiedenen Stellen auf, werden aber im Prinzip durch das gleiche Problem verursacht. Daher lohnt es sich, die Anfragen erst mal etwas abzuwarten und dann später strukturiert zu beantworten. Am besten man einigt sich auf ein solches Vorgehen (Fehler beobachten, sammeln, dann Bugfixing)

Eher mal zum Telefon greifen: Ich habe mir angewöhnt, dass ich eine Frage, deren Antwort per Mail voraussichtlich länger als 3-4 Sätze werden wird, lieber gleich per Telefon beantworte.

So viel Erklärungen wie nötig: Ich neige manchmal dazu, Fragen etwas ausführlich zu beantworten. Zwei Probleme: Erstens schreibe ich dann mehr und damit länger. Zweitens kann es passieren, dass ich den Kunden mit allzu ausführlichen fachspezifischen Erläuterungen verwirre.

Kommunikation hat natürlich noch weitere Aspekte. Im größeren Rahmen, also nicht dem kleinen 1:1 Projekt, sind es dann v.a. auch Meetings von Projektteams, die als großer Zeitfresser zu berücksichtigen sind. In solchen Fällen kann der Kommunikationsaufwand durchaus auch mal höher ausfallen.

Nach ein wenig Recherche stelle ich fest, dass es doch einiges an Tipps zum Thema und Ansatzpunkte für Verbesserungen gibt. Daher gibt’s zum Abschluss noch ein paar Links zum Thema schlanke und effiziente Projektkommunikation.

Links zur schlanken Projektkommunikation

• Gesprächsführung in der Kundenkommunikation
• Effektiv per E-Mail kommunizieren
• Goldene Regeln für schlechte E-Mails
• A Little Less Conversation
• The Power of Good Communication

Und nicht vergessen. Auch die Projekt-Deliverables und Dokumentation können ein Ansatzpunkt für die bessere Kommunikation sein. Ich habe das mal am Beispiel Scribbles bzw. Skizzen beschrieben: Scribbles erzählen mehr als tausend Worte

Es besteht Nachholbedarf hin zur weiteren Professionalisierung des Webdesign.

Hier mal eine kleine Sammlung zum Thema, verbunden mit der Frage nach Euren Erfahrungen und Quellen.

Planung, Konzeptansätze und Deliverables

Die gelisteten Artikel liefern nicht den allumfassenden Plan und Konzeptansatz. Aber sie deuten das breite Spektrum und die vielen Betätigungsfelder ganz gut an.

• Basiskoffer für die Reise durchs Netz: Beschreibt was man auf der Projektreise immer bei sich haben sollte.
• Das perfekte Konzept gibt’s natürlich nicht. Aber man kann sich annähern.
• Checklisten für die Projektplanung
• Planning a Website: Bisher sind das zwei Teile (Wireframes und Konzept, sowie Content-Strategie)
• How Much (work) is a Website? A lot!
• User Experience Deliverables

Beruf Webdesigner?

Kann man Webdesigner lernen? Die folgenden Artikel zeigen, woran es noch mangelt und was von Webdesignern heute gefordert wird bzw. auch gefordert werden sollte.

• Webdesigner haben es schwer!
• Das Leistungsspektrum von Webdesignern
• Traumjob Webdesigner – Medienberufe in der Übersicht
• The State of the Web Design Profession
• Web Design Education Sucks

Klar wird auch, dass es nicht den Webdesigner gibt. Man muss auch Schwerpunkte setzen: Webdevigner oder Webdeseloper?

Nicht zu denken an die ganzen Teildisziplinen wie z.B. Informationsarchitektur, Userexperience (UX), etc. Sind das alles Berufsbilder für sich? Kann eine Person das alles abdecken? Nein. Zumindest nicht jedes Gebiet als absoluter Experte. Gefragt sind also auch Kommunikationsfähigkeiten, die dabei behilflich sind, mit anderen zusammenzuarbeiten.

Den Webdesigner gibt es also nicht? Sieht ganz so aus. Es kommt auf die Spezialisierung an und z.B. darauf, ob man eher konzeptionell/analytisch, gestalterisch oder technisch veranlagt ist.

Ein ganzheitlicher Prozess

Webdesign(er) kann mehr ;-) Für neue Leser dieses Blogs verweise ich nochmal auf einen meiner Artikel. Webdesign: Ein komplexer und permanenter Prozess, wo ich im Ansatz aufgezeigt habe, wie umfangreich die Sache ist.

Das Portfolio der Webdesignerin Isa Costa.

In der ersten Woche nach dem Urlaub stand die Orientierung im Vordergrund. Was gibt’s neues und was sind die wichtigen Themen? Dabei sind natürlich auch wieder ein paar kommentierte Links ins Netz gegangen.

• A shorthand for designing UI flows: Was machen Nutzer jetzt und was werden sie tun (können)? UI Flows als dynamische Ergänzung zu Wireframes. Oder auch als Wireflows bekannt.
• Das Social Web im Vergleich zu herkömmlichen Publikationskanälen, sein Wachstum und die Verlagerung zum mobilen Web: Interesting Facts About the Internet and Social Web
• 7 Steps for Systematizing The Design & Build Process: Snippets, Templates, Frameworks und vieles mehr bilden die logistische Basis hochwertiger Webentwicklungsprozesse.
• Sechs Anforderungen an zeitgemäße Corporate Websites: Die meisten sind es derzeit wohl nicht – zeitgemäß
• Ein dicker Schinken: If You Printed The Internet …
• Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs

Ein neues Blog gibt’s auch. Future of Web Strategy ist Sebastian Küpers’ neue Blogquelle zum Thema Webstrategien der Zukunft und dem sozialen Netz.

Der Userexperience Designer Vitor Lourenco präsentiert auf seiner Website sein Portfolio. Die sehr minimalistische Aufmachung gefällt mir richtig gut. V.a. das Zusammenspiel von großer Typo und viel Whitespace. Abzüge gibt’s für den Code darunter.

• Grundlagen Druck-Stylesheets: Etwas älter, aber gerade im April aktualisiert und sehr ausführlich
• Gute Seiten, schlechte Seiten: 7 Qualitätskriterien zur Beurteilung von Webseiten – und Web-Designern
• Warum der Seitenzoom nicht das Ende für flexible Layouts bedeutet
• Techniken des WCAG 2 zu offen angelegt?: Offenheit ist gut, führt aber auch zu Uneindeutigkeit. Das wiederum macht das Testen nicht gerade einfacher.
• Architekturen, Wartbarkeitsfragen: Auch und vielleicht v.a. hier zeigt sich im späteren Betrieb die technische Qualität einer Website
• Maintainability Guide (Beta): Jens Meierts Einstieg zum Thema Wartbarkeit in der Webentwicklung
• The Battlefield of Design: Designers vs Clients: Es hilft ungemein, die Kunden in den Prozess mit einzubinden
• Effective Maintenance Pages: Examples and Best Practices: Gute Wartungsseiten sind ein wesentlicher Bestandteil der Kundenkommunikatioon. Was gerne vergessen wird.

Diesesmal sind fünf deutschsprachige Artikel dabei, was mich besonders freut. So darf das weitergehen.

Und siehe da, wenig später erhielt er Antwort von AA, genauer vom UX-Architekten des Unternehmens. Dieser bat, was man verstehen kann, um Anonymität. Steckt in seinen erklärenden Worten auch ein gutes Stück Frust. Interessante Hintergünde, muss man sagen. Für den ein oder anderen in ähnlicher Form vielleicht sogar bekannt.

Die Frage, die sich der Webdesigner danach stellte ist, warum viele Websites so deutlich schlechter sind, als die Leute, die sie machen?

But wait. If the UX architect at AA.com is actually pretty good, then why does the site suck so much?

Wo liegt das Problem?

Der UX-Architekt begründet die Zustände mit der Größe der Organisation, den umständlichen Prozessen und dem fehlenden Gehör, dass Experten oft finden. Sie gehen im größeren Grundrauschen oft unter. Er macht es sich damit vielleicht auch etwas zu einfach, aber im Kern steckt viel wahres. Das soll nicht als alles erklärende Ausrede gelten. Aber natürlich wirken sich die vom UX-Architekten geschilderten Umstände, mal mehr mal weniger auf das Ergebnis aus. Wenn auch nicht abzustreiten ist, dass die derzeitige Website deutlich zu weit von gutem Webdesign, geschweige denn einer guten Userexperience entfernt ist.

Zwei Thesen

Design durch Komittees hat seine Nachteile. Die Kunst liegt darin, die bestmögliche Zusammensetzung der Projektgruppen zu finden und Prozesse mit Spielregeln zu etablieren. Das ist zwar nicht ganz einfach, aber man sollte es versuchen. D.h. man braucht v.a. viel Durchhaltevermögen und Nerven. Das geht aber oft allen, an großen Projekten beteiligten Personen so. Uns Webdesignern genau so, wie vielen anderen auch. Jeder muss hier und da zurückstecken und v.a. lernen Kompromisse einzugehen.

Eine weitere These sollte nicht unerwähnt bleiben. Die reine Lehre gibt es nicht! Und je größer die Organisation, desto schwerer ist es (meist), sie in der Praxis zu leben und alles möglichst perfekt zu machen. Man muss Abstriche machen und versuchen gemeinsam zum bestmöglichen Ergebnis zu kommen. Da bleibt auch mal die ein oder andere goldene Regel im Buch stecken. Speziell Unternehmenswebsites müssen es sehr vielen Interessengruppen recht machen. Es gibt hier keine eindeutig definierte Zielgruppe.

Übrigens: Dustin Curtis’ Blog ist auch sonst sehr ungewöhnlich. Jeder Artikel hat sein eigenes Layout und Design. Ganz im Stil eines Magazins.

Das Blog von 45royale Inc., für mich immer noch eins der weltbesten Blogdesigns. Klar strukturiert, schönes Raster, kontrastreich und und schöne Typo. Abzüge gibt’s für die vielen Fehler im Markup.

• Web Design from the Gut: Interessanter und praxisnaher Einblick in den oft komplexer als gedachten Webdesignprozess am Beispiel MIX
• Visual Hierarchy in Web Design: Visuelle Hierarchien unterstützen bei der Aufnahme von Informationen
• 25 Incredibly Useful Usability Cheat Sheets & Checklists: Zeit mitbringen. Aber viele gute Tipps.
• Top 10 Information Architecture Mistakes: Informationsarchitektur hat mehr zu bieten als Sitemaps
• The future of wireframes?: Die Anforderungen an Wireframes haben sich geändert. In manchen Fällen sind sie sogar überflüssig.