So funktioniert Designdokumentation, Teil 1

Regel 2: Layout vereinheitlichen. Ein Designdokument benötigt einheitliche Strukturen. Gerade wenn mehrere Designer gemeinsam an einem großen Dokument arbeiten, läuft man Gefahr, Leser durch wechselnde Formatierungen und individuelle Schreibstile zu verwirren. Gemeinsam erarbeitete Formatvorlagen, die hin und wieder auf ihre Sinnhaftigkeit geprüft werden, wirken Wunder. Sie erfordern zwar die Selbstdisziplin aller Beteiligten, erleichtern aber die Lektüre ungemein.

Regel 3: Redundanz vermeiden. Wiederholungen sind der Feind des Designdokuments. Sie minimieren die Lesbarkeit und lenken vom Wesentlichen ab. Hinzu kommt: Was an zwei Stellen genannt wird, muss auch an zwei Stellen aktualisiert werden. Eine klare Priorisierung von Designinhalten und eine eindeutige Zuordnung zu einzelnen Features helfen, Redundanzen vorzubeugen.

Regel 4: Begründungen von Regeln trennen. Es kann wichtig sein zu begründen, weshalb eine bestimmte Designentscheidung getroffen oder verworfen wurde. Diese Begründungen sollten jedoch nicht mit den Regeln eines Features vermischt werden, um Verwirrung zu vermeiden. Für unsere Anno DDDs verwenden wir dazu beispielsweise FAQs, die am Ende jedes Designeintrags die wichtigsten Begründungen, Alternativen oder Problemstellungen mit einer Frage und einer dazugehörigen Antwort erfassen. (siehe Kasten: Anno Standarddesigneintrag)

Regel 5: Bilder sagen mehr als Worte. Fließtext ist immer die schlechteste Lösung. Ist er nicht zu vermeiden, unbedingt auf übersichtliche Formatierungen achten! Ansonsten empfiehlt es sich, bei jeder Gelegenheit auf bessere Instrumente zurückzugreifen, seien es Listen, Tabellen, Diagramme oder Illustrationen. Sie können schneller erfasst werden und helfen dabei komplexe Inhalte anschaulich darzustellen.

Regel 6: Imperativ statt Konjunktiv. Der Konjunktiv hat in einem Regelwerk nichts verloren. Er unterminiert die Aussagekraft des Designs. Die Verbindlichkeit von Regeln, die mit »sollte, könnte, würde« oder »hätte, wäre, wenn« garniert sind, geht gegen Null. Auch Wörter wie »eventuell« und »vielleicht« haben in einem DDD nichts verloren. Das Design wirkt auf Leser sonst unsicher und austauschbar. Stattdessen: Imperativ verwenden! (Und nicht: »Stattdessen könnte man auch den Imperativ verwenden.«)

Regel 7: Das Glossar nicht vergessen. Jedes Designdokument benötigt ein aktuelles und dem Team vertrautes Glossar. Zwei Namen für ein und dieselbe Sache sind zwar allzu menschlich, aber auch die natürlichen Feinde reibungsloser Kommunikation (Beispiel: »Ist die Grafik vom fliegenden Schloss schon geliefert worden?« »Keine Ahnung, aber gestern ist das schwebende Schloss rein gekommen.« »Hm… ist das dasselbe?«).

Regel 8: Ständige Aktualisierung. Ein Designdokument, das nicht fortlaufend aktualisiert wird, wird unweigerlich nutzlos. Auch wenn es im fortschreitenden Produktionsprozess einen hohen Kraftaufwand bedeutet, ist es unerlässlich, dass das DDD stets die aktuellste Informationsquelle bleibt und nicht vom Flurfunk abgelöst wird. Im Fall des Scheiterns wird das DDD ein Schattendasein als ungeliebtes Mauerblümchen fristen und hilflos dem Chaos beiwohnen, das unweigerlich beginnt sich auszubreiten. Dieser letzte Satz war übrigens schlecht strukturiert und stilistisch schauderhaft -- mit Absicht. Er ist ein typisches Beispiel ausufernder Designerprosa. Für Programmierer wäre ein knappes (aktuelles DDD = Ordnung) > (veraltetes DDD = Chaos) besser gewesen.