SDLC / Design

SDLC

Design

Die Designphase, manchmal auch Architekturphase genannt, klärt, wie eine tragfähige Lösung aussieht, und entwickelt dafür eine Blaupause, sowohl technisch als auch aus Nutzersicht. Es wird festgelegt, wie Komponenten zusammenspielen, wie Daten fließen, welche Schnittstellen benötigt werden und wie Sicherheits- und Compliance-Anforderungen erfüllt werden können.

Parallel entstehen Konzepte für Benutzerführung und Oberflächen, die sich am realen Arbeitsalltag der künftigen Nutzer orientieren, nicht nur an technischer Machbarkeit. Design ist damit ein Bindeglied zwischen dem, was fachlich gebraucht wird, und dem, was später robust gebaut werden kann.

Was in der Designphase geklärt wird

Fünf Bereiche prägen einen tragfähigen Entwurf:

  • Architektur: Wie sind die Komponenten geschnitten und wie spielen sie zusammen?
  • Schnittstellen: Welche Verbindungen zu bestehenden Systemen sind nötig und wie sehen sie im Detail aus?
  • Nutzerführung: Wie bewegen sich künftige Nutzer durch die Lösung, welche Wege und Entscheidungen erwarten sie an welcher Stelle?
  • Oberflächengestaltung: Wie sieht die Lösung aus, welche visuelle Sprache, welches Design System und welche Barrierefreiheitsanforderungen gelten?
  • Qualitätsmerkmale: Welche Anforderungen an Sicherheit, Skalierung und Compliance muss die Architektur von Anfang an mittragen?

Diese fünf Bereiche entstehen selten nacheinander. Eine Schnittstellenentscheidung wirkt sich auf die Architektur aus, eine Sicherheitsanforderung auf die Nutzerführung, eine Entscheidung im Design System auf die Barrierefreiheit. Design ist deshalb eher ein Abwägen als ein lineares Abarbeiten.

Wer typischerweise beteiligt ist

Die Softwarearchitektur oder technische Leitung verantwortet die Gesamtstruktur und trifft die grundlegenden Technologieentscheidungen. UX-Verantwortliche gestalten die Nutzerführung, im besten Fall auf Basis echter Beobachtungen aus dem Arbeitsalltag der Nutzer. UI-Designer entwickeln daraus die visuelle Gestaltung, oft mit einem Design System, das über dieses eine Projekt hinaus Bestand hat. Das Entwicklungsteam wird schon hier einbezogen, damit der Entwurf auch tatsächlich umsetzbar bleibt. Bei regulierten Themen kommen Sicherheits- oder Compliance-Verantwortliche hinzu und der Fachbereich prüft, ob der Entwurf noch zu den realen Abläufen passt.

Typische Risiken

Wird diese Phase vernachlässigt, wandern Architekturentscheidungen unstrukturiert in den Code. Integrationsprobleme treten dann erst spät auf und Nutzeroberflächen bleiben hinter den tatsächlichen Bedürfnissen zurück. Nachträgliche Umbauten an dieser Stelle sind meist deutlich teurer als eine gründliche Designphase im Vorfeld.

Was am Ende vorliegen sollte: Übergabe an die Entwicklung

ÜbergabeartefaktWarum es zählt
Architekturentwurf oder -diagrammGibt der Entwicklung eine gemeinsame Struktur vor
Schnittstellen-SpezifikationVerhindert Integrationsüberraschungen später
UX-Flows und UI-PrototypenSichert, dass Nutzerführung und visuelle Gestaltung nicht nebenbei entstehen
Technologie- und PlattformentscheidungenVermeidet Grundsatzdiskussionen mitten in der Entwicklung
Nicht-funktionale VorgabenWerden sonst erst im Test sichtbar, wenn Korrekturen teuer sind

Je konkreter diese Übergabe ausfällt, desto weniger muss die Entwicklung eigene Architekturentscheidungen treffen, die eigentlich schon im Design hätten fallen sollen.

Fragen, die sich alle Beteiligten stellen sollten

  • Wurden Auswirkungen auf Sicherheit, Wartbarkeit und zukünftige Änderungen besprochen, nicht nur die Erstimplementierung?
  • Gibt es verständliche Darstellungen von Architektur, Nutzerführung und Oberflächengestaltung, die auch außerhalb der IT anschlussfähig sind?

Design-Entscheidungen, die nur in Diagrammen für Techniker existieren, lassen sich von Fachbereich und Management kaum mittragen. Eine verständliche Darstellung ist deshalb Teil der Aufgabe, nicht nur Kür.

Im Beispiel: Ablösung des Ticketsystems

In der Designphase unseres Beispiels zur Ticketsystemablüsung werden Systemarchitektur, Schnittstellen zu bestehenden Systemen, Nutzerführung und die grundlegende Oberflächengestaltung konkretisiert. Hier zeigt sich auch, ob sich die in der Analyse gesammelten Bedürfnisse überhaupt technisch sinnvoll miteinander vereinbaren lassen.