Inhaltsbereich Navigation Navigation Fußzeile

Vorgehensmodell

Das Design System ist immer führend, d. h. “single source of truth“ und verpflichtend für neu erstellte oder wesentlich überarbeitete öffentliche Angebote des Zolls. Die fertigen DESY-Komponenten können direkt eingesetzt werden, ohne jedes Projekt erneut bei Null starten zu müssen.

Von Dritten neu erstellte Komponenten müssen zunächst durch das Design System-Team auf die Einhaltung des Regelwerks überprüft werden. Dies geschieht auch, um zu bewerten, ob es sich um ein verallgemeinerbares Muster mit Potenzial zur Nachnutzung handelt, das in Zukunft auch anderen Verfahren zur Verfügung gestellt werden sollte.

Die inhaltliche Basis des Design Systems sind:

  • Die seit Frühjahr 2021 durchgeführte Inventarisierung des Ist- und Soll-Bedarfs im Zoll-Portal.
  • Die Vorgaben des Styleguides für Zoll.de in der Version vom 19. Oktober 2017.
  • Die fachlichen Anforderungen, sofern sie die Oberflächen betreffen.
  • BITV 2.0 (Barrierefreie Informationstechnik-Verordnung des Bundes)
  • DIN SPEC 66336 „Qualitätsanforderungen für Onlineservices und -portale der öffentlichen Verwaltung“ und der Servicestandard der öffentlichen Verwaltung, in dem definiert wird, wie digitale Services nutzendenfreundlich entwickelt werden.
  • Weiterhin sind die anwendbaren Normen zur Software-Ergonomie (DIN 9241) in das Design System eingeflossen.

Darüber hinaus gilt:


Unser Agiler Ansatz Permalink

Das Design System wird in einem agilen Modell iterativ erstellt. Wir übersetzen die fachlich-inhaltlichen und technischen Anforderungen an Komponenten in User Stories und liefern diese in Sprints. Hierfür gelten folgende Regeln:

Definition of Ready (DoR):

Das Team akzeptiert eine User Story zur Umsetzung nur, wenn:

  • Funktionales Design,
  • Funktionale Abhängigkeiten,
  • Nicht-funktionale Anforderungen,
  • Barrierefreiheits-Kriterien,
  • Gestaltungsmuster,
  • Akzeptanzkriterien,
  • Priorisierung,
  • Aufwandsschätzung,
  • Dokumentation,
  • Freigaben

vollständig und final vorhanden sind.

Definition of Done (DoD):

Der Product Owner akzeptiert eine User Story zur Abnahme nur, wenn:

  • Akzeptanzkriterien,
  • Peer Reviews,
  • Automatisierte Tests, Komponententests, Integrationstests, Benutzerakzeptanz-Tests, Regressionstests, BITV-Tests,
  • Integration in die Codebasis,
  • Systemvoraussetzungen erfüllt,
  • Unteraufgaben geschlossen,
  • Demos durchgeführt,
  • Dokumentation in Wort und Bild vorhanden,

erfüllt sind.


Wie erstellen wir die Komponenten? Permalink

DESY vereinfacht die schnelle Prototypenentwicklung und Implementierung, gewährleistet Konsistenz und Skalierbarkeit und stellt sicher, dass Barrierefreiheit, Performance und Usability frühzeitig berücksichtigt werden. Dazu hat sich in den vergangenen Jahren die folgende Vorgehensweise als sehr erfolgreich bewährt:

1   Verwendung beschreiben
Neu zu erstellende oder wesentlich zu überarbeitende Komponenten werden zunächst gemeinsam mit der anfordernden Fachseite und der Konzeption analysiert (vgl. hierzu Feature Requests). Dabei wird die Funktionalität beschrieben, eventuell auch eine Abgrenzung zu anderen Komponenten formuliert. Es werden erste Low-Fidelity-Wireframes erstellt, um die Komponente verproben und demonstrieren zu können, und es werden mögliche Interaktionen mit gewünschten und auch unerwünschten Ergebnissen niedergeschrieben.
2   Nicht-funktionale Anforderungen festlegen
Auf Basis des ersten Arbeitspaketes ist es nun ein Leichtes, die für die neue Komponente zutreffenden nicht-funktionalen Anforderungen, z. B. aus der Barrierefreiheit und der Gebrauchstauglichkeit, aufzulisten und das Interaction Design zu beschreiben. Um die Anforderungen möglichst schlank und übersichtlich zu halten, verzichten wir hier auf allgemeingültige Regeln wie ausreichende Kontraste, die immer und überall gelten. Stattdessen werden hier nur die besonderen Anforderungen, z. B. an die Bedienung dieser speziellen Komponente per Tastatur oder auf Touch-UIs, gelistet und nachvollziehbar als Akzeptanzkriterien und gleichzeitig Test-Hinweise beschrieben.
3   Oberflächen gestalten
Mit den Informationen aus den vorherigen Schritten werden nun die High-Fidelity-Designs inklusive aller möglichen Zustände einer Komponente auf Basis der grundlegenden DESY-Gestaltungsregeln erstellt. Die Umsetzbarkeit wird von der Frontend-Entwicklung überprüft, das Ergebnis wird hier im Design System in Wort und Bild dokumentiert und erneut mit der Konzeption (1) validiert. Die ausgereiften Designs können nun in Prototypen für Nutzertests überführt werden.
4   Frontend entwickeln
Auf Basis der Arbeitspakete 1–3 folgt nun der letzte Schritt vor der finalen Qualitätssicherung: Die benötigten Frontend-Codes (HTML, CSS, JS) werden Technologie-agnostisch erstellt, sodass sie mit beliebigen geeigneten Frameworks implementiert werden können. Abschließend findet eine Überprüfung der neuen Komponente auf die Einhaltung der BITV-Anforderungen statt, um Fachverfahren die Sicherheit eines barrierefreien Ergebnisses zu geben, wenn die DESY-Komponenten bestimmungsgemäß verwendet werden.
Erst Verwendung, dann Barrierefreiheit, dann Design, dann Code.
Reihenfolge der Arbeitspakete