Über den Autor - mitp.de · PDF fileder Mandoline, liest Comics, ... los, wenn Sie eine andere Methode einsetzen. Es ist eine Arbeitsanleitung, aber kein Software-Buch. Dieses Buch

13

Über den Autor

Dan Brown begann, über Deliverables und Dokumentation zu schreiben, nach-dem er auf dem IA Summit ein Poster über Wireframes präsentiert hatte. SeineArbeit im Web begann 1994, und das Thema Information Architecture entdeckteer 1997. Seitdem hat Brown sowohl Behörden als auch Fortune-500-Kunden, dar-unter die Federal Communications Commission, den U.S. Postal Service, dieTransportation Security Administration, US Airways, Fannie Mae, First USA, Bri-tish Telecom, Special Olympics, AOL und die Weltbank, bei Projekten beraten.

Brown schreibt einschlägige Artikel und hält zahlreiche Vorträge über User Expe-rience Design, Information Architecture, Usability und Content Management.Seine Beiträge wurden in Boxes and Arrows, UX Matters, CHI Bulletin und Inter-active Television Today veröffentlicht. Er hat an der American University, George-town, und an der Duke University unterrichtet. Er nimmt sehr aktiv an derörtlichen Information Architecture Community in Washington teil, und veranstal-tet regelmäßig Workshops und alle zwei Monate Gruppenlesungen. Brown wird inder User Experience Community wegen seiner Fähigkeit geschätzt, komplexeIdeen zu kommunizieren und überzeugende Deliverables zu erstellen. SeineVisio-Fähigkeiten werden weltweit gefürchtet und bewundert.

2002 gründete Brown mit Information Architects aus der ganzen Welt das Infor-mation Architecture Institute, den ersten Berufsverband dieser Branche. Seit 2005sitzt er im Aufsichtsrat des Instituts.

Wenn Dan Brown nicht über Information Architecture, Design oder ContentManagement nachdenkt, kocht er gerne für seine Familie, macht Lattes, spielt aufder Mandoline, liest Comics, spielt Videospiele und erweitert seine umfangreicheLego-Sammlung. Brown lebt mit seiner Familie und vielen, vielen Haustieren inBethesda, Maryland, in einem renovierten Bungalow aus dem Jahre 1922.

00___Communicating Design.book Seite 13 Donnerstag, 21. Mai 2009 1:28 13

http://www.it-fachportal.de/5507



15

Vorwort

Dieses Buch handelt, mit einem Wort gesagt, von Dokumentation. Hört sich lang-weilig an, nicht wahr? Dokumentation – die Sammlung von Dokumenten, die imLauf eines Projektes erstellt werden – ist in vieler Hinsicht das Fundament desWebdesigns. Schließlich werden Dokumente normalerweise auf Papier erstelltund landen auf einem Regal, wo sie von niemandem gelesen werden. Wie coolkann das schon sein?

Wer bereits am Design einer Website mitgearbeitet hat, weiß, dass die Dokumen-tation für den Erfolg des Projektes entscheidend sein kann. Sie treibt den Prozessvorwärts, indem sie das Designkonzept festhält und Mitgliedern des Projektteamskommunizieren hilft. Webdesign-Dokumente – oder »Deliverables« (wörtl. »zuLieferndes« siehe Kapitel 1), wie sie manchmal genannt werden – dienen auch alsMeilensteine, die den Fortschritt eines scheinbar endlosen Prozesses markieren.Sie dokumentieren Geschichte. Mitarbeiter, die später zu einem Projekt hinzusto-ßen, können sich anhand dieser Dokumente schnell einen Überblick über die Ent-scheidungen verschaffen, die von früheren Projektteams getroffen wurden.

Ein Dokument fixiert eine Idee. Vielleicht hört sich dies für das Webdesign-Geschäft zu philosophisch an, doch offen gesagt: Wenn wir eine Idee nicht wirk-sam kommunizieren können, wie dürfen wir dann annehmen, wir könnten umsie herum eine Website erstellen?

Der Wert guter Dokumentation ist unbestritten, aber im Kanon des Webdesignswird erstaunlich wenig darüber gesagt. Ich will damit nicht sagen, Deliverableswären nie thematisiert worden. Rufen Sie den Blog eines beliebigen Designersoder Information Architects auf und Sie werden bestimmt wenigstens einen Arti-kel über wirksames Wireframing oder einen Satz von Symbolen für Flowchartsfinden. Aber eine umfassende Betrachtung, was eine brauchbare Design-Doku-mentation ausmacht, werden Sie nicht finden.

Oberflächlich betrachtet hilft Ihnen dieses Buch, Ihre Dokumentation zu verbes-sern. Sie lernen, Ihre Deliverables zu planen und zielgerichtet in Meetings und fürProjekte einzusetzen. Dabei versucht es nebenbei, die Merkmale eines gutenDokuments zu erläutern und Ihnen den Unterschied zwischen einem schlechtenDokument und einer schlechten Idee erkennen zu helfen.



Vorwort

16

Was Sie über dieses Buch wissen sollten

� Es behandelt nicht jedes Deliverable. Dieses Buch beschreibt zehn der ge-bräuchlichsten Webdesign-Deliverables – diejenigen, auf die Sie nicht verzich-ten können, wenn Sie überhaupt in dieser Branche beschäftigt sind. Es handeltsich um User Experience Deliverables. Wenn Sie also lernen wollen, wie manEntity-Relationship-Diagramme oder Unified-Modeling-Language-Diagrammeerstellt, sollten Sie an anderer Stelle suchen. Es gibt zahllose Dokumente überUser-Experience-Arbeit, die in diesem Buch hätten behandelt werden können;doch sie sind ungebräuchlich oder proprietär oder wurden bereits an andererStelle beschrieben. Wollen Sie Näheres über Webdesign-Dokumente aller Artwissen, sollten Sie die Website des Buches besuchen:www.communicatingdesign.com.

� Es ist unabhängig von Ihrer Entwicklungsmethode. Methoden kommen undgehen, aber Dokumente scheinen mehr oder weniger konsistent zu bleiben.Dieses Buch geht von der zentralen Annahme aus, dass es unabhängig voneiner bestimmten Methode von jedem verwendet werden kann. Doch davonabgesehen ist es schwierig, über Dokumentation zu schreiben, ohne gewisseAnnahmen über den Zeitablauf oder Abhängigkeiten zu treffen. Deshalb willich einige wenige methodologische Annahmen machen (siehe etwas später).Diese Annahmen geben dem Buch eine Struktur, machen es aber nicht nutz-los, wenn Sie eine andere Methode einsetzen.

� Es ist eine Arbeitsanleitung, aber kein Software-Buch. Dieses Buch wird Ihnenhelfen, bessere Deliverables zu erstellen. Es wird Ihnen helfen, diese Deli-verables besser Ihren Kunden und Teamkollegen zu präsentieren. Es wirdIhnen sogar helfen, die Risiken abzuschätzen, die mit der Erstellung und Prä-sentation von Deliverables verbunden sind. Aber es wird Ihnen nicht vermit-teln, wie Sie diese Deliverables mit Software-Anwendungen erstellen können.Verschiedene Entwickler verwenden unterschiedliche Werkzeuge, aber dieWahl eines Werkzeugs sollte wenig Einfluss auf die Botschaft und den ZweckIhrer Dokumentation haben.

� Es ist ein Kochbuch. Jedes Kapitel in diesem Buch ist ein Rezept für die Arbeitmit einem andersartigen Dokument. Jeder hat eigene Vorstellungen von einembrauchbaren Ergebnis. Fügen Sie eigene Randnotizen hinzu. Vielleicht könnenSie sogar eine Technik für eine Art von Dokument auf eine ganz andere Art vonDokument anwenden. Auch wenn ich mich bemüht habe, jedes Kapitel alseigenständige Einheit zu schreiben, können Sie auch in den anderen KapitelnInspiration für das jeweilige Deliverable finden.



Vorwort

17

Drei Arten von Zielpersonen

Dieses Buch ist für Leute geschrieben, die Deliverables erstellen, Deliverablesanwenden und Deliverables absegnen.

� Deliverables erstellen: Egal, ob Sie als Anfänger oder erfahrener Praktiker desWebdesigns Deliverables erstellen – dieses Buch wird Ihnen helfen, Ihr Zielnicht aus den Augen zu verlieren. Es bietet Ihnen entweder neue Techniken fürdie Planung oder Präsentation von Deliverables oder eine Auffrischung IhrerFähigkeiten, wenn es bereits eine Weile her sein sollte, dass Sie etwa einen SatzWireframes entwerfen mussten.

� Deliverables anwenden: Vielleicht sind Sie nicht für die Erstellung der Sitemapzuständig; aber Sie müssen in den nächsten Tagen, Wochen oder Monaten stän-dig auf sie zurückgreifen, um Content der vorhandenen Site in diese neue Struk-tur zu migrieren. Vielleicht sind Sie auch ein Entwickler, der Code schreibenmuss, damit sich die Website der Dokumentation in den Wireframes entspre-chend verhält. Vielleicht sind Sie auch ein Kunde und müssen Ihre Vorschlägeund Ideen für ein Redesign in Ihrem Unternehmen »verkaufen«. Die Personaskönnen Sie dabei unterstützen; aber Sie wollen sicher sein, dass sie korrekt sind.Dieses Buch hilft Ihnen dabei, sich auf die Gespräche mit dem User-Experience-Designer Ihres Teams vorzubereiten.

� Deliverables absegnen: Als Geldgeber wollen Sie die Gewissheit haben, dassSie für Ihr Geld einen entsprechenden Gegenwert bekommen. Für Sie als Kun-de oder Haupt-Stakeholder, der letztlich seinen Geldbeutel öffnet, hängt vielvon diesen Dokumenten ab. Sie brauchen sie, um das Projekt voranzutreiben,um den Gegenwert zu beurteilen und die Kontrolle über das Designteam zubehalten. Aus diesem Buch können Sie lernen, was Sie von den DeliverablesIhres Teams erwarten dürfen.

Das Gespräch fortsetzen

Deliverables haben sich erheblich geändert, seit ich 2002 in Boxes and Arrows zumersten Mal darüber schrieb. Seit dem Durchbruch des Internets in den frühen1990er Jahren gab es wesentliche Transformationen. Dieses Buch ist ein Ort, umein Gespräch über Dokumentation aufzunehmen. Das Gespräch wird auf derWebsite www.communicatingdesign.com fortgesetzt. Dort finden Sie in englischerSprache

� herunterladbare Beispiele, sowohl aus dem Buch als auch von den Lesern

� Tutorials für die Erstellung von Dokumenten aller Art

� Vorlagen und andere Werkzeuge, um Deliverables zu erstellen



Danksagungen

18

� Ratschläge von User-Experience-Experten zur Präsentation Ihrer Dokumenteund zur Zusammenarbeit mit Teamkollegen

� weitere Informationen über Deliverables, die in diesem Buch nicht behandeltwerden

Danksagungen

Ohne Marjorie Baer, Michael Nolan und meinem ganzen Projektteam bei NewRiders wäre dieses Buch immer noch nur eine Reihe von Ideen in meinem Hinter-kopf.

Stephen Anderson, Ashley Cook, Jesse James Garrett, Bryce Glass, Paul Gould vonMAYA Design, James Melzer, Sarah Rice und Todd Warfel sind brillante User-Experience-Experten, die wissen, dass man Ideen nicht nur haben, sondern auchkommunizieren muss. Sie brachten ihre Erfahrungen in dieses Buch ein; und ichdanke ihnen für die ausgezeichneten Beispiele, die sie mir zur Verfügung gestellthaben.

Thomas Vander Wal, der meinen Kontakt zu New Riders knüpfte, und Geoff Shott,der sagte: »Ich würde das Buch unbedingt kaufen«, als ich ihm die Idee vorstellte.

Steve Swasey und Gary McMath von Netflix erlaubten es mir großzügig, dasScreen-Design ihrer Filmeseite für die Illustrationen in Kapitel 10 zu kopieren.

Ich danke Kateryna Andryushchenko und allen Mitarbeitern bei Computer Sys-tems Odessa, die mir eine kostenlose Kopie von ConceptDraw 5 zur Verfügungstellten, nachdem meine Demoversion abgelaufen war.

Mein Dank gilt auch Erin Malone und Christina Wodtke, die der Ansicht waren,eine regelmäßige Kolumne über Deliverables wäre eine gute Idee. Danke auch andie verschiedenen Lektoren bei Boxes and Arrows, die aus meinen bizarren Artikel-ideen nützliche Tutorials gemacht haben.

Lou Rosenfeld, Peter Morville und Jesse James Garrett wissen alle, was erforder-lich ist, um ein Buch zu schreiben. Dennoch hielten sie mich für fähig, dies zutun. Ich danke ihnen für ihre Ermutigung.

Es gibt zwei Online Communities, an denen sich jeder Experience-Design-Expertebeteiligen sollte. Die Mitglieder-Mailing-Liste des Information Architecture Instituteund die Experience-Design-Mailing-Liste der AIGA erwiesen sich immer wiederals zuverlässige und inhaltsreiche Quellen für Dokumentenbeispiele und den Testvon Ideen.

Jeder, der Washington D.C. besucht und mit unserer Information ArchitectureCommunity interagiert, sagt dasselbe: »Sie haben hier eine Gruppe mit wirklich



Danksagungen

19

großartigen Leuten.« DCIA ist unsere örtliche Information-Architecture-Organi-sation. Sie besteht aus über 300 Mitgliedern im Großraum von Washington.Unsere Events sind immer gut besucht, und die Beiträge der Community sindimmer inhaltsreich und begeisternd. Diese Gruppe, insbesondere die Mitbegrün-derinnen Marcy Jacobs und Stacy Surla, sind für alle ein ständiger Quell der Inspi-ration und des Ansporns. Ich kann mir keinen besseren Ort für die User-Experience-Branche vorstellen.

Jeder Esel braucht eine Karotte, die ihm mit einem Stock vor die Nase gehaltenwird, um immer weiterzugehen. Dies gilt auch für mich. Deshalb habe ich mirselbst für die Beendigung dieses Buches eine neue Mandoline versprochen. DieseMandoline ist die Collings MT. Ich danke der Collings Guitar and Mandolin Com-pany dafür, dass sie ein so wundervolles Instrument herstellt, und dem MusicEmporium in Boston und insbesondere seinem ausgezeichneten Saiteninstru-ment-Verkäufer, Adam Dardeck.

Abb. E.1: Die Collings MT Mandoline, ein feines Instrument

Wann immer ich feststeckte, sei es bei einer bestimmten Frage, einem ganzen Kapi-tel oder sogar dem Inhaltsverzeichnis, bat ich James Melzer um Rat. Wir lerntenuns auf dem IA Summit 2002 in Baltimore kennen und stellten fest, dass unseregemeinsamen Interessen weit über IA (Information Architecture) hinausgingen.



Danksagungen

20

Seitdem sind wir eng befreundet. Wann immer ich James um Rat fragte, konnte ermir fundiert und auf den Punkt helfen. Ohne ihn hätte dieses Buch kein Kapitelüber Wettbewerbsanalyse gehabt. (Und wenn ich James danke, darf ich seine Frau,Becky, nicht vergessen, die viel aus eigener Erfahrung beisteuern konnte.)

Meine Eltern, Geschwister und Freunde, die mich fragten, wie es dem Buch gehe,gaben mir unabhängig von meiner Antwort immer ihre Unterstützung.

Amy Standen, meine Lektorin, hielt trotz nicht eingehaltener Termine und Band-wurmsätze zu mir, obwohl uns sieben Zeitzonen trennten. Eine bessere Lektorinhätte ich nicht finden können; und ich danke ihr für ihre pragmatische Weisheitund Geduld im Umgang mit meinem fragilen Ego.

Sarah Holden, meine Frau, passte sich klaglos meinen ungewöhnlichen Arbeits-stunden und Schreibgewohnheiten an. Während ich in den vergangenen neunMonaten über Wireframes und Personas nachdachte, war Sarah mit unserem ers-ten Kind schwanger. Sie hat mich unbeirrt und vertrauensvoll unterstützt und gabmir damit genau das, was ein neuer Autor (und neuer Vater) brauchte.



21

Kapitel 1

Einführung

Ein Deliverable ist ein Dokument, das bei einem Webdesign-Projekt erstelltwird, um die Kommunikation zu erleichtern, Entscheidungen zu dokumentie-ren und Innovation anzuregen.

Deliverables (wörtl. »etwas zu Lieferndes«, ein Endergebnis eines Prozesses) erfül-len viele Funktionen. Sie werden aus drei Hauptgründen erstellt:

� Zielklarheit (Consistency of vision): Webdesigner, die in kleinen Teams arbei-ten und ihre Teamkollegen genau kennen, genießen den Luxus einer Umge-bung, die einer Ehe vergleichbar ist. Dagegen kann man in einem großenTeam, dessen Mitglieder von Projekt zu Projekt wechseln, das Verhalten unddie Reaktionen der anderen Mitglieder nicht voraussehen. Während eines Pro-jektes entwickelt sich das Konzept einer Website; in seinen verschiedenenPhasen werden unterschiedliche Leute eingesetzt. Bei großen Teams und Pro-jekten besteht die Gefahr, dass jeder das Konzept etwas anders versteht. Mit ge-eigneter Dokumentation können Sie dafür sorgen, dass alle dasselbe Ziel ver-folgen und nicht aus den Augen verlieren und deshalb ihre Anstrengungen aufein gemeinsames Ergebnis ausrichten.

� Verantwortlichkeit (Accountability): Als beratender oder angestellter Webde-signer eines Unternehmens müssen Sie dafür sorgen, dass jeder die getroffe-nen Entscheidungen und ihre Auswirkungen kennt, versteht und entsprechendhandelt.

� Rückverfolgbarkeit (Traceability): Dokumentation schafft verbindliche Doku-mente, auch wenn Sie nicht ein einziges Deliverable ausdrucken. Indem Sie dieEntscheidungen im Laufe des Projektes festhalten, dokumentieren Sie das ge-samte Projekt und können später leicht prüfen, wo das Team wesentliche Ent-scheidungen getroffen hat. Am Ende eines Projektes erinnern Sie sich vielleichtnicht mehr genau, warum Sie bestimmte Dinge getan haben – was etwa derGrund dafür war, einen Button an eine ungewöhnliche Stelle zu setzen oder vomStandard-Layout einer Seite abzuweichen. Wenn Sie das Projekt dokumentierthaben, können Sie die Gründe für diese Entscheidungen leicht nachschlagen.

Doch diese Gründe sind nicht nur für große Teams relevant. Auch wenn Siealleine oder in einem kleinen Unternehmen für Webentwicklung arbeiten, brau-chen Sie rechtlich verbindliche Dokumente, wenn Sie einen Vertrag aushandeln.Teams stellen oft fest, dass ihr Kunde leicht durch interne Querelen abgelenkt



Kapitel 1Einführung

22

wird. Sie benötigen deshalb ein Dokument, um die Richtung des Projektes nichtaus den Augen zu verlieren.

Von Zeit zu Zeit flammen in der User Experience Community heftige Argumentegegen die Dokumentation auf. Es kommt eine neue Methode auf den Markt, dieumfangreiche (oder überhaupt welche!) Dokumentation ablehnt. Oder die Leutehaben einfach mal wieder genug davon, dass es so schwierig ist, Kunden zufrie-denzustellen. Diese Diskussionen sind nützlich, weil sie dazu beitragen, unserVerständnis von und unsere Konzentration auf den Zweck von Dokumenten zupräzisieren und immer klarer herauszuarbeiten. Dokumente können, wie andereWerkzeuge auch, missbraucht werden. Der größte Missbrauch besteht darin, dassein Dokument um seiner selbst willen erstellt wird und keinen Mehrwert zuIhrem Projekt, Ihrem Team oder dem Endprodukt beiträgt.

1.1 Die zehn Deliverables

Dieses Buch ist ziemlich strikt aufgebaut. Jedes Kapitel behandelt eines der insge-samt zehn Deliverables. Jedes Kapitel besteht aus drei Abschnitten: Erstellung derDokumentation, Präsentation der Dokumentation und kontextuelle Einordnungder Dokumentation. Diese Struktur soll die Ratschläge für die Dokumente verein-heitlichen. Dieses Buch beschreibt drei Kategorien von Dokumenten:

� Anforderungsdokumentation (User Needs Documentation): Wenn Sie eineWebsite designen wollen, müssen Sie zunächst Ihre Zielgruppe verstehen unddieses Verständnis festhalten: Was wissen Sie über die Benutzer? Die Antwortauf diese Frage wird normalerweise bei einer Marktforschung oder Marktanaly-se erarbeitet und in Form so genannter Personas (eine Bezeichnung, die sichfür die früher gebräuchliche Bezeichnung Kundentyp eingebürgert hat) fest-gehalten. Zu diesem Prozess gehören auch Tests, die durch den Usability-Test-Plan und die Usability-Test-Ergebnisse dokumentiert werden.

� Strategiedokumentation (Strategy Documentation): Vor dem Design müssenSie wissen, was Sie entwickeln wollen. Konzept-Modelle dokumentieren die zu-grunde liegenden konzeptionellen Strukturen, Content Inventories (etwa: In-haltsverzeichnisse einer Website) dokumentieren den Umfang des Contentsder Website, und Wettbewerbsanalysen (Competitive Analyses) bewerten kon-kurrierende Websites.

� Designdokumentation (Design Documentation): Schließlich müssen Sie dieUser Experience (Benutzererfahrung) selbst beschreiben. Diese Designdoku-mente ähneln unterschiedlichen Linsen, die bestimmte Aspekte der Erfahrungbetonen. Wireframes zeigen die Struktur jeder Seite, Flowcharts beschreibendie Interaktion zwischen dem Benutzer und dem System, Sitemaps beschrei-ben die Gesamtstruktur der Website, und die Screen Designs dokumentierenihren Look-and-Feel.



1.2Informationskategorien in Deliverables

23

1.2 Informationskategorien in Deliverables

Jedes in den Kapiteln beschriebene Deliverable verfügt über drei Kategorien vonInformationen:

� Kategorie 1: Diese Kategorie beschreibt die wesentlichen Elemente der Doku-mentation, also den Charakter des Deliverables. So besteht etwa eines der Kate-gorie-1-Elemente einer Sitemap – die Struktur einer Website – aus ihren Con-tent-Bereichen. Ohne Content-Bereiche könnte eine Dokumentation kaum alsSitemap gelten.

� Kategorie 2: Einige Elemente verstärken die Botschaft und liefern zusätzlicheHintergrundinformationen oder ergänzen einige Beziehungen, die Sie zeigenwollen. Diese Kategorie-2-Elemente sind, im Gegensatz zu denen in der erstenKategorie, nicht erforderlich, aber sie können den Lesern der Dokumentationhelfen, sie zu verstehen. Sie müssen nicht jedes Element verwenden, das in derzweiten Kategorie beschrieben wird.

� Kategorie 3: Die dritte Kategorie der Informationen in einer Dokumentationhat sehr unterschiedliche Inhalte. Sie enthält normalerweise nicht unbedingterforderliche Informationen über den größeren Kontext. So zählen etwa Quel-lenangaben zu dieser Kategorie, sofern sie nicht für das Verständnis des Deli-verables notwendig sind.

Abb. 1.1: Diese Beispielrepräsentation der Kategorien in einer Dokumentation ist etwas metaphorisch. Tatsächlich sind die Informationskategorien nicht immer so scharf getrennt. Wenn Sie mehr Informationen in eine Dokumentation einfügen, wird es leichter, ihre Hauptbotschaft zu verdecken.

Unerfahrene Dokumentationsautoren wollen oft so viele Informationen wie mög-lich in ihre Deliverables einfügen. Meist ist dies nicht die beste Lösung und einerder Gründe, warum in diesem Buch Kategorien unterschieden werden. Wenn Sienicht genau wissen, was in eine Dokumentation gehört, halten Sie sich an die




24

Elemente der ersten Kategorie. Dann erfassen Sie alle wesentlichen Informatio-nen. Wenn Sie sicherer geworden sind, können Sie eines oder zwei Elemente derzweiten Kategorie hinzufügen. Ihr Urteilsvermögen, was in eine gute Dokumenta-tion gehört, entwickelt sich mit Ihrer Erfahrung. Fragen Sie auch Ihre Kundenund Teamkollegen.

1.3 Einige Annahmen

Obwohl das Buch im Wesentlichen prozessneutral sein soll, sind bestimmteAnnahmen über Ihre Arbeitsweise und Entwicklungsumgebung erforderlich.Trifft die Situation nicht auf Sie zu, sollte dies jedoch keinen Einfluss auf denInhalt Ihrer Dokumentation haben. Wenn Sie die Empfehlungen aus diesem Buchan Ihre Situation anpassen wollen, sollten Sie die Website des Buches besuchen(www.communicatingdesign.com; in Englisch!).

1.3.1 Das Projektteam

In diesem Buch ist häufig von dem »Projektteam« die Rede. Zum Projektteamzählen in diesem Kontext alle, die direkt mit dem Projekt zu tun haben: Entschei-dungsträger, Designer, Projektmanager, Entwickler usw. So könnte Ihr Unterneh-men etwa einen Finanzchef haben; aber diese Rolle macht ihn nicht automatischzu einem Mitglied des »Projektteams«.

Das Projektteam wird hier nur in groben Zügen beschrieben. Kunden, Designerund Entwickler gelten unabhängig von ihrer besonderen Expertise als eigenstän-dige Gruppen. So könnte ein Entwickler etwa mit dem Datenbankdesign oder derSystemarchitektur oder der Programmierung betraut sein. Aber im Kontext diesesBuches zählt er zu den technischen Experten, die für die Erstellung der System-komponenten zuständig sind.

Auch der Kunde wird einer eigenen Gruppe zugerechnet; aber die Unterschiedezwischen den Mitgliedern dieser Gruppe stellen eine der großen Herausforderun-gen unserer Arbeit dar. Kunden werden durch verschiedene Motive angetrieben:Geld, Ego oder den Wunsch, das Richtige zu tun. In diesem Buch beziehen sichdie Bezeichnungen »Kunde« und »Stakeholder« auf alle diese Arten von Men-schen. Zwar möchte ich Ihnen mit diesem Buch helfen, diese unterschiedlichenAnforderungen zu erfüllen, doch es ist Ihre Aufgabe, die Motive Ihrer Kundenherauszufinden.

Mit dem »Designteam« bezeichne ich in diesem Buch alle am Design-ProzessBeteiligten. Ein derartiges »Team« kann durchaus aus einer einzigen Person(Ihnen) bestehen; Sie könnten auch ein Grafikdesigner in einem Team mit vieroder fünf anderen speziellen Rollen sein.



1.3Einige Annahmen

25

Das Buch geht auch davon aus, dass das Projektteam über einen Projektmanagerverfügt, der für die Arbeit des Teams verantwortlich ist. Abgesehen von seinenanderen Aufgaben ist der Projektmanager für den täglichen Kontakt mit dem Kun-den und die Koordination der Aufgaben der Teamkollegen zuständig.

1.3.2 Die Methode

Mit dem Web haben sich zahlreiche Aufgaben und Funktionen nicht nur in derGeschäftswelt, sondern auch bei der Software-Entwicklung geändert. Der schnelleAblauf der »Internet-Zeit«, die Nachfrage der Kunden und sich schnell entwi-ckelnde Technologien haben die »traditionellen« Methoden des Software-Enginee-rings mit ihren längeren Zyklen, stabileren Releases und geringerer Einbeziehungdes Benutzers nutzlos gemacht. Doch die alten Methoden sterben nicht abrupt,sondern allmählich aus, wobei mehrere jüngere Methoden während der Über-gangsphase mit den älteren konkurrieren.

Zwischen Methoden und Dokumentation herrscht eine verzwickte Beziehung.Eine Methode wird oft nicht nur durch ihre Aktivitäten und Prozesse, sondern auchdurch ihre Outputs definiert. Dennoch verwenden viele Methoden immer noch die-selben Arten von Dokumenten; und viele Projektteams schätzen bestimmte Artenvon Dokumenten unabhängig von ihrer speziellen Methode.

Abgesehen davon werden in diesem Buch drei unterschiedliche Arten von Aktivi-täten unterschieden. Die meisten Methoden arbeiten mit ähnlichen Konzepten,wenn auch nicht immer mit denselben spezifischen Aktivitäten.

� Requirements (Anforderungen): Die meisten Methoden basieren auf der Prä-misse, dass man eine Website nur dann konzipieren könne, wenn man weiß,was sie tun soll. Diese Anforderung wird von Webdesignern und Entwicklernin »Requirements« dokumentiert. Requirements bestehen normalerweise auseiner Sammlung von Aussagen, die verschiedene Funktionen beschreiben, diedas System erfüllen sollte. Verschiedene Methoden gehen dabei unterschied-lich vor: Einige Methoden behandeln die Sammlung der Anforderungen ehernebensächlich, während sie bei anderen die zentrale Aktivität ist. Die Doku-mentation der Requirements unterscheidet sich auch gravierend: von umfang-reichen Spreadsheets über Zeichnungen mit Strichmännchen bis zu so ge-nannten Geschichten (Stories; Usage Stories) aus drei Sätzen. Letztlich geht esdarum, das Problem zu definieren, das Sie lösen wollen. Manche Methodenfordern eine komplette Definition des Problems, bevor die Lösung angegangenwird; andere erkennen an, dass man bestimmte Probleme erst dann wirklichverstanden hat, wenn man sie zu lösen versucht hat. Doch egal, wie Sie vorge-hen, gehe ich in diesem Buch davon aus, dass Sie Ihrem Kunden wenigstenseine gewisse Zeit zuhören und Ihre Zielgruppe untersuchen, um die Anforde-rungen kennen zu lernen.




26

� Design: Sobald das Projektteam das Problem verstanden hat, kann es eineLösung entwerfen. In diesem Fall ist die Lösung eine Website, die die Anforde-rungen des Unternehmens und der Zielgruppe erfüllt. Ähnlich wie bei derErmittlung der Requirements ist auch diese Aktivität methodenspezifisch.Einige arbeiten mit einer kurzen Design-Phase, gefolgt von einer intensivenTestphase. Andere durchlaufen ausführliche Designzyklen, die von gelegentli-chen Tests unterbrochen werden. Und wieder andere erstellen zunächst einenPrototyp, der im Laufe der Zeit verfeinert wird. In diesem Buch gehe ich davonaus, dass Sie vor Ihren Design-Aktivitäten Requirements zusammengestellthaben und dass Sie das ungefähre Aussehen und Verhalten des Endproduktsmit Designdokumenten (wie Wireframes und Flowcharts) abgesteckt haben.

� Test: Die letzte Hauptaktivität der meisten Methoden ist das Testen. Normaler-weise handelt es sich dabei um eine Art der Qualitätskontrolle, mit der geprüftwird, ob sich die Website der Dokumentation entsprechend verhält. Für User-Experience-Experten umfasst das Testen fast immer auch Usability-Tests. Dabeiwird die Website (oder ein ihr entsprechender Prototyp) mit Benutzern getestet,um herauszufinden, ob sie alles verstehen. Das Testen kann den Requirementsvorausgehen, um herauszufinden, was mit der gegenwärtigen Website oder ver-wandten Websites funktioniert (oder nicht). Das Testen kann auch den Design-Prozess begleiten, um die Arbeit laufend zu begutachten und zu verfeinern.

Es gibt keine direkte Beziehung zwischen diesen Aktivitäten und den Arten vonDokumenten, die in diesem Buch beschrieben werden. So entsprechen etwa dieDesigndokumentationen nicht unbedingt der Design-Aktivität. In den Kapitelnwerden Sie selbst sehen, dass diese Deliverables, obwohl sie hauptsächlich für dasDesign verwendet werden, auch als Werkzeuge zur Sammlung der Requirementsoder das Testen eingesetzt werden können.

1.3.3 Die Kultur

Abgesehen von seiner Methode hat jedes Projektteam eine eigene Projektkultur,einen ungeschriebenen Satz von Regeln für die Zusammenarbeit. Sie umfasst: eingegenseitiges Verständnis der Werte, die jedes Teammitglied einbringt; die Kom-munikation der Teamkollegen untereinander; und die Rolle der Dokumentation indem Unternehmen.

Dieses Buch geht, vielleicht naiv, davon aus, dass ein gutes Projektteam aufZusammenarbeit und Konsens basiert. Die meisten Projekte laufen besser, wennsie unter den Annahmen operieren, dass jeder einen wertvollen Beitrag leistenwill und dass sich die Menschen dieses Wertes bewusst sind. Allerdings ist damitdas Risiko verbunden, dass es bei dem Projekt weniger darum geht, das Richtigezu tun, als eher darum, Egos zu streicheln. Die Entscheidungsfindung dauertlänger, und Innovationen erfolgen nicht in Gruppen. Aber eine Gruppe, die ent-



1.4Allgemeiner Prozess zur Erstellung eines Diagramms

27

schlossen ist, ein Projekt erfolgreich zu beenden, wird sich bemühen, diese Risi-ken zu verringern (obwohl vielleicht auch diese Annahme etwas naiv ist).

1.4 Allgemeiner Prozess zur Erstellung eines Diagramms

Viele Dokumente, die in diesem Buch beschrieben werden, enthalten Diagramme,visuelle Repräsentationen von Ideen oder Konzepten. Seit den Anfängen des Web-designs haben sich diese Bilder als beste Methode bewährt, um einige der Abstrak-tionen zu dokumentieren, mit denen Designteams arbeiten müssen. Obwohl alleDokumente in diesem Buch unterschiedlich erstellt werden, gibt es eine allge-meine Methode, nach der Sie ein Diagramm erstellen können. (Dies ist imWesentlichen der Prozess, den ich verwende. Wählen Sie aus, was für Sie passt.)

� Führen Sie eine Situationsanalyse durch. Die Darstellung einer Idee in einemDiagramm hängt von drei Faktoren ab: dem Zweck der Zeichnung; ihre Stel-lung in dem Prozess; und die Zielgruppe. Diese Faktoren werden für jedes De-liverable ausführlich beschrieben.

� Erstellen Sie eine Liste aller Informationen, die Sie dokumentieren wollen.Auch diese Technik wird ausführlich in jedem Kapitel beschrieben. Die einzel-nen Informationen werden als »Elemente« oder »Dimensionen« oder »Daten-punkte« bezeichnet. Sie repräsentieren einen kleinen Ausschnitt der Ge-schichte. Das Diagramm soll diese einzelnen Informationen zusammenfas-send darstellen.

� Planen Sie die Zeichnung auf dem Papier und dokumentieren Sie dabei so vie-le Elemente wie möglich. Die Skizze sollte Ihnen eine brauchbare Übersichtliefern, wie Sie all Ihre Informationen erfassen wollen.

� Übertragen Sie die Papierskizze in eine Zeichen-Software wie etwa AdobeIllustrator, Microsoft Visio oder OmniGraffle von OmniGroup. Normalerweiseist es am besten, mit einer Schwarz-Weiß-Zeichnung zu beginnen und sichnur auf das Layout zu konzentrieren.

� Überlegen Sie, wie Sie Farbe einsetzen wollen, und beginnen Sie damit zuexperimentieren. Bei Flowcharts eignet sich Farbe beispielsweise dazu, ver-wandte Schritte oder Pfade zu gruppieren oder die Aufmerksamkeit auf be-stimmte Elemente zu lenken. So könnten Sie etwa aus der Liste Ihrer Elementeeines oder zwei aussuchen, die sich am besten farblich darstellen lassen.

� Verfeinern Sie Ihre visuelle Sprache. Die visuelle Sprache ist der Satz von Sym-bolen und Konventionen, die Sie auf die Liste der Elemente angewendet haben.An diesem Punkt haben Sie ein Gespür dafür entwickelt, wozu sich Ihre visuel-le Sprache eignet und wozu nicht. Insbesondere können Diagramme durch zuviele Elemente unleserlich werden; vielleicht vermitteln sie auch kein zusam-




28

menhängendes Bild. Wenn Sie die visuelle Sprache verfeinern, suchen Sienach Gelegenheiten, die Hauptbotschaften klar zu vermitteln. Sie suchen auchnach Möglichkeiten, überflüssige Informationen wegzulassen – visuelles Rau-schen, das wenig Bedeutung enthält oder kaum zu der Story beiträgt.

� Beschriften Sie die Zeichnung. Beschriften Sie die Elemente Ihrer Zeichnung,bevor Sie vergessen, was sie bedeuten, und fügen Sie zusätzlichen Text hinzu.

� Identifizieren Sie Schwachstellen. Senden Sie die Zeichnung zu Ihrem Druckerund benutzen Sie Ihren Marker. Sie sollten an diesem Punkt prüfen, ob sie mitIhrer Situationsanalyse übereinstimmt. Bis jetzt haben Sie sich so in die Zeich-nung vertieft, dass Sie etwas Abstand gewinnen müssen. Prüfen Sie, ob dieZeichnung die grundlegenden Fragen über Flowcharts beantwortet: Wo beginntder Benutzer? Wo hört er auf? Was sind die Hauptschritte in dem Prozess?

� Überarbeiten Sie die Zeichnung in der Zeichen-Anwendung. Übertragen SieIhre Kommentare in digitale Form.

� Prüfen Sie Ihre Arbeit. Haben Sie alle Details berücksichtigt, die Ihre Zielgrup-pen erwarten? Dies ist ein geeigneter Zeitpunkt für eine Begutachtung derZeichnung durch Kollegen. Sie könnten sie etwa einem Projektmanager zeigen.Er sollte die Zielgruppen ebenso gut wie Sie kennen und kann Ihnen Feedbackgeben. Sie können Ihre Arbeit auch testen, wenn Sie in einem Brainstormingeinige Fragen suchen, die Menschen stellen könnten, die sich Ihr Diagrammanschauen.

� Passen Sie die Zeichnung an. Ändern Sie die Zeichnung aufgrund der Kom-mentare und des Feedbacks aus dritter Hand. Besonders bei Flowcharts kanneine Ausrichtung der Elemente in einem Raster der Zeichnung ein professio-nelles Aussehen geben, selbst wenn sie nicht sehr viele Details enthält. Ruinie-ren Sie ein brauchbares Dokument nicht dadurch, dass Sie vergessen, Ihre Ele-mente korrekt auszurichten.

� Fügen Sie unterstützende Informationen hinzu. Ein professionell aussehendesDokument hat einen Titel, ein Datum, Quellenangaben und vielleicht eine Ver-sionsnummer. Diagramme in der Mitte einer Seite sagen nicht viel aus, wennsie nicht einige grundlegende Informationen über ihren Kontext liefern.

1.5 Allgemeine Tipps für die Präsentation von Deliverables

Die zweite Hälfte jedes Kapitels befasst sich mit der Anwendung der Deliverables.Denn selbst gelungene Flowcharts oder ausführliche Usability-Berichte sind nutz-los, wenn sie nicht weiterverwendet werden. Jedes Kapitel enthält ausführlicheEmpfehlungen für die Planung und Durchführung von Meetings über die Doku-mentation sowie für Ihre Optionen, wenn Meetings schiefgehen sollten. Hier sindeinige allgemeine Gedanken:



1.5Allgemeine Tipps für die Präsentation von Deliverables

29

� Legen Sie den Zweck des Meetings ausdrücklich fest. Ich kann gar nicht genugbetonen, wie wichtig es ist, den Zweck eines Meetings oder einer Präsentationausdrücklich festzulegen und mitzuteilen. Viele Leute glauben, ein Dokument,das in einem Meeting präsentiert wird, würde automatisch eine Agenda undeinen Zweck etablieren; doch ein Meeting zur Begutachtung eines Dokumentsunterscheidet sich nicht von anderen Meetings. Man kann den Zweck einesMeetings mit mehreren Techniken festhalten; die vielleicht einfachste ist eineListe mit Fragen. Schließlich wollen Sie mit den Teilnehmern ein Problem dis-kutieren; und wie könnte man eine Diskussion besser in Gang bringen als miteiner Liste mit Fragen? Zur Erinnerung: Die Deliverables in diesem Buch sindkein Selbstzweck, sondern Werkzeuge, um Ideen zu kommunizieren und zudiskutieren. Ihr Zweck sollte sich deshalb nicht auf das Dokument (das Deli-verable), sondern auf seinen Inhalt beziehen. Ein Beispiel für eine Deliverable-zentrierte Zweckformulierung wäre etwa »das Deliverable begutachten undKommentare erhalten«. (Wenn Sie meinen, das sei offensichtlich, sollten Siesich fragen, an wie vielen Meetings Sie teilgenommen haben, bei denen genauso etwas auf der Agenda stand.) Eine bessere Zweckformulierung müsste eineListe mit Fragen über den Inhalt enthalten – etwa: »Dieses Navigationsschemawurde erfolgreich getestet, aber es wäre für das Unternehmen ein neuer Weg.Sehen Sie irgendwelche Schwierigkeiten, passenden Content zu finden?«

� Legen Sie fest, was Ihnen das Meeting bringen soll, bevor Sie hineingehen. DerZweck eines Meetings kann von dem abweichen, was Sie sich davon verspre-chen. Selbst wenn Sie den Zweck verfolgen, Antworten auf einige Fragen zumWebsite-Design zu bekommen, könnte Ihre Agenda darin bestehen, den Stake-holdern Widersprüche zwischen verschiedenen Abteilungen des Unterneh-mens deutlich zu machen. Sie müssen diese grundlegende Botschaft nicht vorden anderen Teilnehmern des Meetings geheim halten; aber es ist wichtig zuerkennen, dass zwar alle Teilnehmer des Meetings einen gemeinsamen Zweckverfolgen, aber nicht unbedingt auch eine gemeinsame Agenda haben.

� Denken Sie über die Erwartungen, Agenden und Fragen der Teilnehmer nach.Nachdem Sie sich über Ihre eigene Agenda klar geworden sind, sollten Sieüberlegen, welche Agenden die anderen Teilnehmer verfolgen könnten. Siekönnen Ihre Botschaft und Ihre Agenda verfeinern, indem Sie über alle mögli-chen Fragen nachdenken. Bei einem politisch aufgeladenen Projekt könnteetwa jeder Stakeholder mit bestimmten Aspekten des Contents oder Funktio-nen liebäugeln, denen er gerne eine hohe Priorität einräumen würde. DasMeeting wäre der geeignete Ort, diese Wünsche geltend zu machen. AnstattIhnen zuzuhören oder am Gespräch teilzunehmen, denken diese Teilnehmerdas ganze Meeting lang nur über ihre eigene Agenda nach. Wie gehen Siedamit um? Sie könnten den Teilnehmern beispielsweise am Anfang des Mee-tings Gelegenheit geben, diese Probleme anzusprechen. Häufig sind sie nichtso umstritten, wie es sich die Teilnehmer vorgestellt haben. Und wenn Sie die




30

Probleme in einen umfassenderen Rahmen einordnen können, haben Sie eineEntschuldigung, eine unnötige Diskussion zu vermeiden. Haben Sie so dieangestauten Emotionen entschärft, können Sie mit dem Hauptzweck desMeetings fortfahren.

� Laden Sie so wenig Teilnehmer wie möglich ein. Nichts kann ein Meetingmehr ruinieren als Teilnehmer, die gar nicht dabei sein sollten. Sitzen zu vieleTeilnehmer am Tisch, kann ein Meeting schnell seinen Fokus verlieren oder ineinem Strudel konkurrierender Agenden zerrieben werden. Es wird schwierig,das Meeting erfolgreich zu beenden. Seien wir ehrlich: Manchmal sind wirauch einer dieser überflüssigen Teilnehmer.

� Verteilen Sie Ihr Material vor dem Meeting. Vielleicht scheint Ihnen dieseEmpfehlung kontraproduktiv zu sein; doch wenn Sie Ihr Material bereits vordem Meeting verteilen, können Sie direkt auf den Kern der Dokumente kom-men, ohne zu viel Zeit mit Hintergrundinformationen zu verbringen. Teilneh-mer kommen mit intelligenten Fragen in das Meeting; und Sie können sich aufdas Wichtige konzentrieren. Einige Leute glauben, sie würden mit ihrem vor-her herausgegebenen Material bereits die Pointe einer kunstvollen Geschichteverraten. Doch hier geht es nicht darum, einen Witz zu erzählen, sondern eineWebsite zu entwerfen. Wenn Sie sich wirklich sorgen, dass die Teilnehmer denwichtigen Punkt Ihrer Deliverables ohne Ihre Nachhilfe verpassen könnten,verweisen Sie auf eine Fragerunde am Ende des Meetings. Nehmen Sie sichvorher Zeit, mit ihnen das gesamte Dokument durchzugehen; vielleicht beant-wortet dann Ihre Präsentation bereits ihre Fragen.

� Schreiben Sie ein Protokoll über das Meeting. Es schadet niemals, die Entschei-dungen zu dokumentieren, die während des Meetings getroffen wurden. Selbstwenn Sie kein formelles Meeting-Protokoll erstellen, versenden Sie hinterhereine E-Mail mit den Ergebnissen. Sie machen dadurch die Zuständigkeiten kla-rer und geben den Teilnehmern Gelegenheit, Missverständnisse aufzuklären.

� Seien Sie stolz, ein gutes Meeting zu leiten. Es ist fast besser, als ein gutesDokument zu erstellen: das Gefühl, das Sie bekommen, wenn die Leute voneinem Meeting aufstehen und sagen: »Das war ein gutes Meeting.« Sie warenpünktlich fertig; und Sie haben Fortschritte gemacht. Dies sind die beidenDinge, die die Teilnehmer von einem Meeting erwarten. Versuchen Sie nicht,mehr zu erreichen.

� Rechnen Sie bei neuen Kunden damit, dass das erste Meeting nicht gut läuft.Sie müssen keinem Kunden erzählen, dass Sie erst einmal vorfühlen müssen.Doch wenn Sie damit rechnen, dass das erste oder die ersten beiden Meetingsnur dazu dienen, »Sie kennen zu lernen«, können Sie Ihre eigenen Ängste ver-ringern. Bei einem neuen Team oder einem neuen Kunden Dokumente zu prä-sentieren oder ein Brainstorming durchzuführen, kann beängstigend sein.



1.5Allgemeine Tipps für die Präsentation von Deliverables

31

Bevor Sie zu den guten Dingen kommen, sollten Sie Ihren Kunden kennen ler-nen, indem Sie ein, sagen wir mal, weniger bedeutungsträchtiges Meetingdurchführen, bei dem Sie ein relativ simples Dokument präsentieren könnten.Dadurch können Sie ein Gespür für den Arbeitsstil des Kunden und seine Artder Zusammenarbeit bekommen. Möglicherweise wird Ihr Deliverable in derLuft zerrissen, aber wenigstens wissen Sie danach, auf welche Dinge Ihr Kundeachtet und Wert legt.



Documents

Über den Autor - mitp.de · PDF fileder Mandoline, liest Comics, ... los, wenn Sie eine andere Methode einsetzen. Es ist eine Arbeitsanleitung, aber kein Software-Buch. Dieses Buch