Maxime Alexandre Beck
Alle Arbeiten

AkDe

Digitale Verwaltung, neu gedacht: eine iOS-App, die Behördengänge nach Lebenslagen ordnet.

Bachelorarbeit. Aus einer heuristischen Evaluation von zehn Bürgerplattformen in fünf Ländern habe ich Designprinzipien abgeleitet und daraus einen lauffähigen iOS-Prototyp in Swift und SwiftUI entwickelt. Er bündelt alle Vorgänge eines Lebensereignisses in einem geführten Prozess – ohne dass Nutzende wissen müssen, welche Behörde zuständig ist.

Kontext
Bachelorarbeit, HfG Schwäbisch Gmünd
Rolle
Einzelarbeit – Recherche, Konzept, UX/UI, iOS-Entwicklung
Werkzeuge
Swift, SwiftUI, Xcode, Figma
Jahr
2026
Betreuung
Prof. David Oswald, Prof. Gerhard Buurmann

Leitfrage

„Welche Designprinzipien machen digitale Bürgerplattformen in anderen europäischen Ländern erfolgreich – und wie lassen sie sich für eine nutzerorientierte Bürger-App in Deutschland adaptieren?“

Vorgehen

Die Case Studies sind nach dem Double Diamond gegliedert: erst das Problem verstehen und schärfen, dann Lösungen entwickeln und umsetzen.

DISCOVERDEFINEDEVELOPDELIVER
  1. Discover

    Verstehen

    • Desk Research (OZG, Normenkontrollrat)
    • Heuristische Evaluation von 10 Systemen
    • Bewertungsrahmen: 27 Kriterien, 4 Dimensionen

    Erfolg ist eine Frage der Informationsarchitektur, nicht der Technik.

  2. Define

    Definieren

    • Synthese der Befunde
    • 8 Designprinzipien
    • Value Proposition Canvas
    • 4 Personas

    Anforderungen an AkDe – jede aus einem Befund abgeleitet.

  3. Develop

    Entwickeln

    • Five Planes nach Garrett
    • Informationsarchitektur nach Lebenslagen
    • User Flows für 3 Personas

    Konzept einer App, die nach Lebenslagen statt nach Behörden navigiert.

  4. Deliver

    Umsetzen

    • iOS-Prototyp in Swift/SwiftUI
    • Designsystem als Code-Tokens
    • Barrierefreiheit nach BITV 2.0

    Lauffähiger Prototyp mit 77 modellierten Leistungen.

Discover

Verstehen

Problem

Ein Designproblem, kein Technologieproblem.

Das Onlinezugangsgesetz verpflichtet Bund, Länder und Kommunen seit 2017, 575 Verwaltungsleistungen digital anzubieten. Laut Nationalem Normenkontrollrat erfüllten 2023 nur rund fünf Prozent davon die gesetzlichen Anforderungen.

Das Ergebnis für Bürgerinnen und Bürger: Wer umzieht, BAföG beantragt und ein Führungszeugnis braucht, landet auf mehreren Portalen mit eigenen Logins, eigener Navigation und Medienbrüchen – ausdrucken, unterschreiben, einscannen. Die Portale funktionieren technisch, scheitern aber an der Frage, was Nutzende eigentlich erreichen wollen.

Methode

Zehn Systeme, ein einheitlicher Maßstab.

Grundlage ist eine heuristische Evaluation: Zwei deutsche Portale – ZuFi Baden-Württemberg und das Stuttgarter Serviceportal – wurden mit den Spitzenreitern des EU eGovernment Benchmarks verglichen: GOV.UK, Eesti.ee, Borger.dk und Suomi.fi sowie deren Bürger-Apps.

Der Bewertungsrahmen kombiniert vier etablierte Kataloge – Nielsens Heuristiken, WCAG 2.2, Mobile-Guidelines der Nielsen Norman Group und GDS-Patterns – zu 27 Kriterien. Jedes wird von 0 bis 4 bewertet, anhand derselben Testaufgaben wie „Melde dich um“ oder „Prüfe den Status deines Antrags“.

10
Systeme evaluiert – Portale und Apps aus Deutschland, Großbritannien, Estland, Dänemark und Finnland
27
Kriterien in vier Dimensionen: Usability, Barrierefreiheit, Mobile UX, E-Government
108
Punkte maximal je Webportal, jedes Kriterium bewertet von 0 bis 4

Ergebnis

So schneiden die zehn Systeme ab.

  1. GOV.UKWeb100 %
  2. Eesti.eeWeb97 %
  3. Borger.dkWeb96 %
  4. Suomi.fiWeb89 %
  5. Suomi.fi AppApp85 %
  6. ZuFi Baden-WürttembergWeb79 %
  7. Eesti.ee AppApp75 %
  8. BorgerApp / MitIDApp72 %
  9. Stuttgart Service-PortalWeb69 %
  10. GOV.UK AppApp68 %
Eigene Bewertung, heuristische Einschätzung – keine empirisch validierten Messwerte. Apps auf einer angepassten 100-Punkte-Skala. Deutsche Systeme hervorgehoben.

Define

Definieren

Synthese

Was die Besten gemeinsam haben.

Die Auswertung zeigt ein klares Muster: GOV.UK, Eesti.ee, Borger.dk und Suomi.fi erreichten 89 bis 100 % der Punkte – nicht wegen besserer Infrastruktur, sondern wegen einer konsequent nutzerorientierten Informationsarchitektur. Die deutschen Portale kamen auf 79 und 69 %.

Daraus habe ich acht Designprinzipien abgeleitet. Die wichtigsten: Navigation nach Lebenslagen statt nach Behörden (Borger.dk), durchgängig digitale Prozesse ohne Medienbruch (Suomi.fi), Plain Language als Vorschrift (GOV.UK), sowie Antragsstatus-Tracking und das Once-Only-Prinzip (Eesti.ee).

Personas

Vier Menschen, vier Anforderungsprofile.

  1. Leon, 27

    Junior-Entwickler, zieht um. Hohe digitale Kompetenz – zeigt, was Once-Only bei mehreren Anträgen spart.

  2. Sarah, 38

    Projektmanagerin in Teilzeit, zwei Kinder. Wenig Zeit – braucht Statusverfolgung statt Nachtelefonieren.

  3. Hans, 67

    Rentner, geringe digitale Kompetenz. Für ihn entscheiden Plain Language und Barrierefreiheit über Vertrauen.

  4. Aisha, 34

    Erzieherin, Türkisch als Muttersprache, nutzt Android. Macht Mehrsprachigkeit und die Grenzen einer iOS-App sichtbar.

Develop

Entwickeln

Konzept

Von unten nach oben: Garretts Five Planes als Rahmen.

  1. Strategy

    Menschen wollen Lebenslagen erledigen, nicht Behörden finden. Ein Satz, aus dem sich alles Weitere ableitet.

  2. Scope

    Leistungen vollständig in der App modellieren statt verlinken, BundID als einziges Login, Once-Only-Datenprofil.

  3. Structure

    Keine Behörde als Navigationspunkt. Stattdessen acht Lebenslagen – von „Wohnen & Umzug“ bis „Rente & Alter“.

  4. Skeleton

    Adaptives Dashboard: laufende Anträge zuerst, sonst die Lebenslagen. Jeder Screen beantwortet genau eine Frage.

  5. Surface

    iOS Human Interface Guidelines, WCAG 2.2 AA und Plain Language: „Führungszeugnis beantragen“ statt Paragrafendeutsch.

Startseite, adaptives Dashboard, Leistungssuche und „Meine Anträge“ – eine Behörde taucht erst im Detail auf.

Deliver

Umsetzen

Flow 1 – digital

Ein Führungszeugnis in vier Schritten.

Vor dem ersten Tap sieht man, was einen erwartet: volldigital, 3–5 Werktage, 13 €, fünf Prozessschritte, drei Dokumente. Im Formular greift Once-Only – als sichtbarer Schritt mit Einwilligung, nicht als versteckter Haken. Danach erscheint der Antrag sofort in „Meine Anträge“, mit Vorgangsnummer und Status.

Info, Prozess und Dokumente – alles Wichtige vor dem Antrag. Rechts: die Once-Only-Abfrage im Formular, hier am Beispiel der Ummeldung.

Flow 2 – vor Ort

Ehrlichkeit als Designprinzip.

Nicht alles ist digital möglich. Die Ummeldung verlangt in Deutschland noch persönliches Erscheinen – AkDe verschweigt das nicht. Der Button heißt dann „Zur Vorsprache vorbereiten“: Die App sagt, welche Dokumente man mitbringen muss (z. B. die Wohnungsgeberbestätigung nach § 19 BMG), was schon aus dem Profil bekannt ist, und verfolgt auch diesen analogen Vorgang in „Meine Anträge“.

Der Prototyp läuft als native App auf einem echten iPhone, nicht nur im Simulator.

Barrierefreiheit

Für alle nutzbar – nicht nur für die Mehrheit.

Öffentliche Stellen müssen nach BITV 2.0 barrierefrei sein. AkDe setzt das im Prototyp mit eigenen Einstellungen um: hoher Kontrast, reduzierte Bewegung, größere Touch-Flächen und eine Farbfilter-Simulation, mit der sich die App aus Sicht farbenblinder Menschen prüfen lässt.

Dazu kommt Sprache als Zugangshürde: Die Texte sind in Plain Language geschrieben, die Oberfläche ist in fünf Sprachen verfügbar – Deutsch, Englisch, Französisch, Spanisch und Türkisch.

Designsystem

Farbe trägt Bedeutung.

Das Farbsystem ist im Code als Tokens angelegt und unterstützt Hell- und Dunkelmodus sowie einen Hochkontrast-Modus. Grün steht für volldigitale Leistungen, Orange für Vorgänge vor Ort – Farbe ist dabei nie die einzige Information.

  • akGreen

    #00A94F

    Primär · volldigital

  • akOrange

    #FF6A00

    Vor Ort · Hinweise

  • akYellow

    #FFC400

    Akzent

  • akDark

    #2B2B2B

    Kontrast

  • akBackground

    #F6F7F8

    Hintergrund (hell)

Code

Jede Leistung ist ein Datensatz, kein Link.

Models/Leistung.swiftSwift
enum DigitalStatus: String {
    case volldigital  = "Volldigital"
    case teildigital  = "Teildigital"
    case persoenlich  = "Persönlich"

    var farbe: Color {
        switch self {
        case .volldigital: return .akGreen
        case .teildigital: return .akOrange
        case .persoenlich: return Color.akOrange
        }
    }

    var icon: String {
        switch self {
        case .volldigital: return "checkmark.circle.fill"
        case .teildigital: return "minus.circle.fill"
        case .persoenlich: return "person.fill"
        }
    }
}

struct Leistung: Identifiable {
    let id: String
    let name: String
    let behörde: String
    let ebene: Verwaltungsebene    // Bund, Land, Kommune
    let kategorieId: String        // die Lebenslage
    let digitalStatus: DigitalStatus
    let dauer: String
    let kosten: String
    let beschreibung: String
    let icon: String
    let schritte: [Schritt]
    let dokumente: [Dokument]
    let istFavorit: Bool
}
  1. Jede Verwaltungsleistung ist als vollständiger Datensatz modelliert – mit Behörde, Verwaltungsebene, Kosten, Dauer, Prozessschritten und Dokumenten. Darauf bauen Suche, Detailansicht und Antragsformular auf.
  2. Die Lebenslage (kategorieId) ist das Ordnungsprinzip; die Behörde ist nur ein Attribut. So wird die Informationsarchitektur der Arbeit direkt im Code abgebildet.
  3. Der DigitalStatus steuert Farbe und Symbol zentral: Grün mit Haken für volldigital, Orange für Vorgänge mit Behördengang.
77
Verwaltungsleistungen vollständig modelliert – mit Behörde, Dokumenten, Kosten und Dauer
286
Prozessschritte, Ende-zu-Ende abgebildet – digital wie vor Ort
5
Sprachen der Oberfläche: Deutsch, Englisch, Französisch, Spanisch, Türkisch

Ergebnis

Ein lauffähiger Prototyp statt eines Konzeptpapiers.

AkDe läuft als native iOS-App mit vollständig modellierten Verwaltungsvorgängen und Mockdaten. Der Prototyp zeigt, dass die zentralen Konzepte umsetzbar sind: lebenslagenbasierte Informationsarchitektur, BundID als einheitliche Anmeldung gemäß OZG 2.0, Once-Only und durchgängige Prozesstransparenz – für digitale wie für analoge Leistungen.

Reflect

Reflexion

Grenzen & nächste Schritte

Was der Prototyp zeigt – und was nicht.

Die Bewertung beruht auf Expertenurteil: Eine heuristische Evaluation findet potenzielle Probleme, keine empirisch belegten. Der Prototyp arbeitet mit Mockdaten und ist nicht an echte Behördenschnittstellen angebunden; seine Wirkung hängt in der Praxis von BundID und einer behördenübergreifenden Integrationsschicht ab.

Der nächste Schritt wäre eine Nutzerstudie mit realen Testpersonen – besonders mit Menschen wie Hans, deren Hürden sich durch Heuristiken nur begrenzt erfassen lassen – sowie eine Umsetzung für Android und Web.