Warum dein Projekt ein Design-Dokument braucht, bevor du anfängst zu bauen

Ein Design-Dokument ist ein schriftlicher Plan, der beschreibt, was du baust, warum du es baust und wie es funktionieren wird. Es ist kein Benutzerhandbuch. Es ist keine Aufgabenliste. Es ist das Denken, das passiert, bevor das Bauen beginnt. Im Kern beantwortet ein Design-Dokument drei Fragen. Welches Problem lösen wir? Was ist die vorgeschlagene Lösung? Und welche Abwägungen und Alternativen haben wir in Betracht gezogen? Alles andere – die technischen Details, die Umfangsgrenzen, die Zeitschätzungen – hängt an diesen drei Fragen. Design-Dokumente werden je nach Branche unterschiedlich benannt. Software-Teams nennen sie Technical Design Documents oder RFCs. Spieleentwickler schreiben Game Design Documents. Produktteams schreiben Product Requirement Documents. Das Format variiert, aber der Zweck ist immer derselbe: den Plan aus deinem Kopf in ein Dokument bringen, das andere Menschen – oder du in der Zukunft – lesen und verstehen können.

Es fühlt sich kontraintuitiv an. Du bist begeistert, anzufangen. Die Idee ist klar in deinem Kopf. Ein Dokument zu schreiben fühlt sich wie Beschäftigungstherapie an, die dich verlangsamt. Also überspringst du es und steigst direkt in die Implementierung ein. Zwei Wochen später stellst du fest, dass die Architektur ein Feature nicht unterstützt, das du für einfach gehalten hast. Oder ein Teammitglied hat etwas gebaut, das deinem Ansatz widerspricht, weil du den Ansatz nie aufgeschrieben hast. Oder du stoßt auf eine Design-Entscheidung, die du nicht durchdacht hast, und musst jetzt refaktorisieren. Ein Design-Dokument fängt diese Probleme ab, bevor sie dir echte Zeit kosten. Wenn du aufschreibst, wie etwas funktionieren soll, bist du gezwungen, die Details durchzudenken. Du entdeckst Randfälle. Du erkennst Abhängigkeiten. Du erkennst, dass das „einfache“ Feature tatsächlich Änderungen an drei verschiedenen Systemen erfordert. Die Zeit, die du fürs Schreiben eines Design-Dokuments aufwendest, ist immer weniger als die Zeit, die du für das Beheben von Problemen aufgewendet hättest, die das Dokument verhindert hätte. Es ist nicht einmal knapp. Ein paar Stunden Schreiben können Wochen der Nacharbeit ersparen.

Du brauchst keine starre Vorlage, aber ein gutes Design-Dokument deckt in der Regel folgende Bereiche ab. Beginn mit der Übersicht. Ein oder zwei Absätze, die erklären, was dieses Dokument abdeckt und warum es wichtig ist. Jeder sollte diesen Abschnitt lesen können und den Umfang verstehen. Definiere als Nächstes das Problem. Was ist defekt, fehlt oder wird benötigt? Sei konkret. „Benutzer brauchen eine bessere Suche“ ist vage. „Benutzer können vergangene Projekte nicht finden, weil die aktuelle Listenansicht keine Filterung oder Sortierung unterstützt“ ist nützlich. Beschreibe dann die vorgeschlagene Lösung. Das ist der Hauptteil des Dokuments. Erkläre, was du zu bauen planst, wie es funktionieren wird und wie die Benutzererfahrung aussieht. Füge genügend Detail hinzu, damit jemand anderes im Team es allein aus dieser Beschreibung implementieren könnte. Füge einen Abschnitt über betrachtete Alternativen hinzu. Welche anderen Ansätze hast du geprüft? Warum hast du diesen gewählt? Das zeigt deine Überlegungen und hilft zukünftigen Lesern, die Entscheidung zu verstehen. Liste schließlich offene Fragen und Punkte außerhalb des Umfangs auf. Was hast du bewusst entschieden, nicht zu tun? Was bedarf noch der Diskussion? Das verhindert Scope Creep und hält das Dokument ehrlich darüber, was es abdeckt und was nicht.

Ein Design-Dokument ist nicht etwas, das du einmal schreibst und dann vergisst. Die besten Design-Dokumente entwickeln sich mit dem Projekt mit. Während du baust, wirst du Dinge lernen. Manche Annahmen werden sich als falsch herausstellen. Manche Teile des Plans werden sich ändern. Das ist völlig normal. Das Dokument sollte diese Änderungen widerspiegeln. Notizen hinzufügen, was sich geändert hat und warum. Abschnitte aktualisieren, die nicht mehr der Realität entsprechen. Entscheidungen markieren, die revidiert wurden. Das verwandelt dein Design-Dokument in eine Projektgeschichte. In sechs Monaten, wenn jemand fragt „Warum haben wir es so gebaut?“, steht die Antwort im Dokument. Du musst dich nicht darauf verlassen, dass sich jemand an ein Gespräch von vor Monaten erinnert. Der Schlüssel ist, das Dokument leicht aktualisierbar zu machen. Wenn es in einem Tool lebt, das von deinem eigentlichen Projekt getrennt ist, wird es niemand aktualisieren. Wenn es direkt neben deinen Aufgaben und Zeitplänen ist, wird das Aktualisieren zu einem natürlichen Teil des Workflows. IndieDevBoard enthält eine Funktion für Design-Dokumente mit strukturierten Abschnitten, die in deinem Projekt leben, sodass die Spezifikation nah an der Arbeit bleibt, die sie beschreibt.

Wenn du in der Spieleentwicklung tätig bist, fragst du dich vielleicht, wie sich das zu einem Game Design Document (GDD) verhält. Sie sind verwandt, aber unterschiedlich. Ein GDD ist spezifisch für Spiele. Es deckt typischerweise das Spielkonzept, die Mechaniken, die Geschichte, das Level-Design, die Art Direction, Audio, UI und mehr ab. Es ist die Bibel des Spiels. Alles über das Spiel sollte aus dem GDD beschreibbar sein. Ein Design-Dokument im weiteren Sinne betrifft jedes Projekt oder Feature. Es könnte ein einzelnes Feature innerhalb eines Spiels, ein API-Design, ein Website-Redesign oder einen neuen Prozess beschreiben. Es ist fokussierter und in der Regel kürzer als ein GDD. In der Praxis verwenden viele Spielteams beides. Das GDD ist das High-Level-Visionsdokument. Einzelne Design-Dokumente decken spezifische Systeme oder Features innerhalb des Spiels ab, wie das Kampfsystem, das Inventar oder die Multiplayer-Netzwerkschicht. Das GDD sagt „Das Spiel hat ein Inventarsystem.“ Das Design-Dokument erklärt genau, wie das Inventarsystem funktioniert, wie das Datenmodell aussieht und wie es mit anderen Systemen interagiert.

Du musst kein perfektes Design-Dokument beim ersten Versuch schreiben. Fang mit den Grundlagen an. Schreib auf, was du baust und warum. Beschreibe die Lösung in genügend Detail, dass sie nützlich ist. Füge offene Fragen für alles hinzu, worüber du unsicher bist. Je vertrauter du wirst, desto natürlicher wirst du mehr Struktur hinzufügen. Du entwickelst ein Gefühl dafür, wie viel Detail ausreicht. Du lernst, welche Abschnitte für deine Art von Projekt am wichtigsten sind. Das Wichtige ist, anzufangen. Ein grobes Design-Dokument, das eine Stunde zum Schreiben braucht, ist unendlich nützlicher als ein perfektes, das du nie schreibst. Dein zukünftiges Ich und deine Teammitglieder werden dir dafür danken.