WärmeCheck – Detaillierte Projektübersicht
Zurück zur Case StudyWärmeCheck
Redesign eines Heizungswartungs-Buchungssystems – von generisch zu branchenspezifisch.
Ein Hamburger Heizungsfachbetrieb (GasControl) nutzt für die Online-Terminbuchung ein generisches SaaS-Tool. Die Analyse deckte 3 funktionale Bugs und 10 UX-Probleme auf – darunter kompletten Datenverlust beim Zurücknavigieren. WärmeCheck ist die neu konzipierte, getestete und umgesetzte Buchungsstrecke dazu.
Auf einen Blick
| Rolle | UX Research · Interaction Design · Frontend Development |
| Zeitraum | 01.03. – 01.06.2026 |
| Kontext | Konzeptstudie |
| Methodik | 9 Phasen: Kontext → Nutzungskontextanalyse → Systemanalyse → Anforderungen → Prototyping → Formativer Test → Integration → Summativer Test → Doku |
| Methoden | User Flow Recording, Heuristische Evaluation (Nielsen), Persona, Formativer Usability-Test (n=4, qualitativ), Summativer Vergleichstest (n=6, Within-Subjects, SUS) |
| Tools | Figma, HTML, Tailwind CSS, Obsidian, GitHub Pages |
| Ergebnis | Vollständige, responsive Buchungsstrecke – live, getestet, dokumentiert |
| Links | Live Demo · GitHub |
Meine drei wichtigsten Beiträge
- Eine systematische Systemanalyse aus zwei kombinierten Methoden – User Flow Recording und alle 10 Nielsen-Heuristiken – die 3 Bugs und 10 priorisierte Painpoint-Cluster produzierte.
- Ein Redesign, das Fachwissen nicht voraussetzt: kW-Analogien, Tooltips, “Weiß ich nicht”-Optionen, Review-Seite und Persistenz statt Datenverlust.
- Ein zweistufiges Testverfahren – formativ am Prototyp, summativ im direkten Vergleich gegen das Originalsystem – mit dokumentierter Iteration dazwischen.
01 Kontext Definition
Unternehmen analysiert, Nutzergruppe definiert
GasControl ist ein Hamburger Heizungsfachbetrieb, der Privatkunden bei jährlicher Wartung, Reparatur und Instandhaltung von Gasheizungen betreut. Das Kerngeschäft ist stark saisonal – der Großteil der Buchungen fällt in Spätsommer und Herbst, bevor die Heizperiode beginnt. Genau in dieser umsatzstärksten Phase ist eine funktionierende Buchungsstrecke geschäftskritisch.
Für die Online-Terminbuchung setzt GasControl ein generisches SaaS-Tool ein (eTermin.net). Ein Tool, das für beliebige Terminarten gebaut ist – und deshalb keine der fachlichen Entscheidungen unterstützt, die eine Heizungswartung verlangt.
Die betriebliche Konsequenz
Ein Nutzer, der abbricht, bucht woanders. Rechtschreibfehler und falsche Preisangaben im Live-System untergraben das Vertrauen in die Professionalität des Betriebs – bevor der Techniker überhaupt an der Tür steht.
Nutzergruppen (identifiziert)
- Privater Eigentümer Einfamilienhaus ← Hauptzielgruppe
- Vermieter Mehrfamilienhaus
- Mieter mit eigener Gastherme / Etagenheizung
- Hausverwaltungen, Wohnungsbaugesellschaften, Facility Management (B2B)
Belegt durch Beobachtung: Das Kontaktformular in Schritt 5 enthält eine Auswahl verschiedener Firmen-Typen. Das Tool versucht aktuell B2C und B2B gleichzeitig zu bedienen – ohne für eine der beiden Gruppen einen sauberen Pfad zu haben.
Im Scope
- Die Buchungsstrecke selbst, vom Einstieg bis zur Bestätigungsseite
- Hauptpersona: privater Eigentümer EFH, Neukunde
Bewusst ausgeschlossen
- Echtes Backend, Datenbank, E-Mail-Versand
- Login / Account-System
- Hausverwaltungs-Flow (sekundäre Persona, dokumentiert aber nicht ausgearbeitet)
- Admin-Bereich, Mehrsprachigkeit
02 Nutzungskontextanalyse
Interviews durchgeführt, Persona erstellt, User Storys & Aufgabenmodelle erstellt
Nutzungskontext-Annahmen
| Dimension | Erkenntnis |
|---|---|
| Gerät | Buchung überwiegend am Smartphone (Wohnzimmer, Küchentisch). Desktop möglich, nicht zwingend. |
| Vorwissen | Wartungsintervall unklar (jährlich vs. 2-jährlich). kW-Klasse den wenigsten bekannt – steht auf dem Typenschild im Heizungskeller. Wartung / Gebrauchsfähigkeitsprüfung / Schornsteinfeger werden häufig verwechselt. |
| Situation | Geplante Wartung als Hauptfall, Saison-Peak August–Oktober. Notfall-Reparatur als Fehlleitung: diese Nutzer landen auf der Wartungsseite, brauchen aber keinen Wartungstermin. |
| Ziel | Schnell einen passenden Termin. Sicher sein, das Richtige gebucht zu haben. Wissen, was einen erwartet. Bestätigung, dass die Buchung angekommen ist. |
Hauptpersona
Markus Hoffmann, 54, Office-Job (Verwaltung / Buchhaltung) Hamburg-Bergedorf · Einfamilienhaus seit wenigen Monaten · Neukunde Tech-Affinität: mittel – iPhone, WhatsApp, Online-Banking; meidet Registrierungen
“Ich will wissen, dass ich das Richtige gebucht habe – und das ohne stundenlange Recherche.”
Markus ist aus einer Mietwohnung ins eigene Haus gezogen. Bisher hat sich der Vermieter um die Heizung gekümmert, jetzt ist er selbst verantwortlich. Er weiß, dass eine Gastherme gewartet werden muss – aber weder welche kW-Klasse seine hat, noch was Brennwerttechnik ist.
Was Markus weiß: dass jährlich gewartet werden sollte, dass vernachlässigte Wartung gefährlich ist (Kohlenmonoxid), den Hersteller seiner Heizung.
Was Markus nicht weiß: kW-Klasse, Brennwert vs. Heizwert, Unterschied Wartung / Gebrauchsfähigkeitsprüfung, passendes Intervall, Servicegebiete.
Design-Prinzip daraus: Sicherheit dominiert vor Geschwindigkeit. Im Konfliktfall lieber 30 Sekunden länger für Klarheit als ein Schritt weniger für Tempo. (Für Bestandskunden würde sich diese Priorität umkehren – relevant für spätere Erweiterungen.)
Aufgabenmodell – Hauptaufgabe
| Benutzergruppe | Privater Eigentümer EFH, Neukunde |
| Aufgabe | Einen Heizungswartungstermin online buchen |
| Vorbedingung | Seite ist aufgerufen, Nutzer steht vor Smartphone oder PC |
| Teilaufgaben | 1) Terminbuchungsbereich finden 2) Region prüfen 3) Leistung auswählen 4) Datum und Uhrzeit wählen 5) Kontaktdaten eingeben 6) Eingaben prüfen (Review) 7) Verbindlich buchen |
| Nachbedingung | Der Nutzer hat einen Termin gebucht und eine eindeutige Bestätigung erhalten |
Sekundäre Persona (Skizze, nicht ausgearbeitet)
Mitarbeiter einer Hausverwaltung – bucht für Dritte, oft mehrere Geräte gleichzeitig, Rechnungsadresse ≠ Standort. Effizienz wichtiger als Erklärung. Im Redesign bewusst nicht abgedeckt.
03 Systemanalyse
Mit 10 Nielsen-Heuristiken Buchungstool analysiert, Bug findings
Methodik
Vor der Bewertung stand Domain-Research: Was ist eine Heizungswartung? Was eine Gebrauchsfähigkeitsprüfung? Wer bucht wann und warum? Ohne dieses Fachwissen hätte ich nur Oberflächen bewertet, nicht Inhalte.
Danach zwei kombinierte Methoden:
- User Flow Recording – die komplette Buchungsstrecke als fiktiver Privatkunde durchlaufen, jeder Schritt mit Screenshot und Beobachtung dokumentiert
- Heuristische Evaluation nach Nielsen (1994) – alle 10 Heuristiken systematisch angewendet, Severity-Skala 0–4
Funktionale Bugs
| Bug | Beobachtung | Severity |
|---|---|---|
| Bug 1 – Preis-Diskrepanz | Klick auf das 60-kW-Paket (360 €) führt ins Buchungstool mit 30-kW-Preis (215 €). Der Nutzer bucht unwissentlich zum falschen Preis. | 4 – Geschäftskritisch |
| Bug 2 – Wärmepumpen-Sackgasse | Die Wärmepumpen-Karte sieht identisch aus wie die anderen, ist aber keine Auswahl sondern ein Hinweis. Bei Klick verschwindet der Weiter-Button. | 3 – Groß |
| Bug 3 – Multi- statt Single-Choice | ”Bestandskunde” und “Neukunde” lassen sich gleichzeitig anklicken, obwohl sie sich ausschließen. Das System speichert widersprüchliche Daten. | 3 – Groß |
Heuristik-Befunde – Severity pro Heuristik
| Heuristik | Severity | Kernbefund |
|---|---|---|
| #1 Visibility of system status | 3 | Schritt-Indikator verschwindet in Schritt 4; inverser Kontrast im Indikator |
| #2 Match system / real world | 3 | Unerklärter Fachbegriff “Brennwerte”; “Stadtteil” statt PLZ; Region vor Leistung |
| #3 User control and freedom | 4 | Kein Notausgang, kein erhaltener Buchungsstand, Datenverlust beim Zurückspringen |
| #4 Consistency and standards | 3 | Inkonsistente Selection-Patterns (Cards vs. Checkboxen), zwei Schritt-Granularitäten, Rechtschreibfehler im Live-System |
| #5 Error prevention | 4 | Befund E: Datenverlust ohne Warnung. Validierung erst beim Absenden. Schwache Plausibilitätsprüfung |
| #6 Recognition rather than recall | 3 | kW-Klassen unerklärt, Eingaben werden zwischen Schritten nicht wiederverwendet |
| #7 Flexibility and efficiency | 2 | Bestandskunden-Markierung ohne Funktion, kein Wiederbuchen-Shortcut |
| #8 Aesthetic and minimalist design | 3 | Doppelte Navigation, drei Themen auf einer Seite |
| #9 Error recovery | 3 | Leere vs. ungültige Felder unterschiedlich kommuniziert, keine Beispiele in Fehlermeldungen |
| #10 Help and documentation | 3 | Ein einziges Info-Icon in der gesamten Strecke |
Der Hauptbefund
Befund E – Datenverlust beim Zurückspringen. Severity 4 – Katastrophal.
Sobald der Nutzer über Schritt-Indikator oder ÄNDERN-Button auf einen früheren Schritt springt, gehen alle Eingaben der nachfolgenden Schritte verloren. Ohne Warnung, ohne Recovery.
Das Paradox: Das Tool lädt aktiv zum Zurückspringen ein – durch klickbare Schritt-Indikatoren und ÄNDERN-Buttons in der Übersicht. Es lockt den Nutzer in eine selbst gebaute Falle. Die gute Idee wird durch die Implementierung entwertet.
Priorisierte Painpoints (Auszug)
| # | Painpoint | Severity |
|---|---|---|
| 1 | Datenverlust ohne Vorwarnung | 4 |
| 2 | Falscher Preis durch Bug + fehlender kW-Kontext | 4 |
| 3 | Verbindliche Buchung ohne Kontroll-Schleife | 3 |
| 4 | Tool erwartet Fachwissen, das die Zielgruppe nicht hat | 3 |
| 5 | Unklare Schritt-Struktur (zwei Granularitäten) | 3 |
| 6 | Inkonsistente Selection-Patterns | 3 |
| 7 | Validierung zu spät und inkonsistent | 3 |
| 8 | Sackgasse bei Wärmepumpen-Auswahl | 3 |
| 9 | Verschwindende Navigation in Schritt 4 | 3 |
| 10 | Verpasste Service-UX-Chancen | 2 |
Das übergeordnete Muster: Das Tool sammelt Daten vom Nutzer, ohne ihn bei den Entscheidungen zu unterstützen, die zur Datenangabe nötig sind. Das ist ein systematisches Versagen, nicht eine Reihe von Einzelproblemen.
Stärken, die das Redesign übernehmen sollte
- Buchungsübersicht mit Live-Update, ÄNDERN-Buttons und kumulativem Gesamtpreis
- Pflichtfeld-Validierung mit klarem, lokalisiertem Fehler-Feedback
- Funktionierende Tastatur-Navigation
- Personalisierte Termin-Anzeige mit Techniker-Name und -Foto – ungewöhnlich gute Service-UX, schafft Vertrauen bei einer intimen Dienstleistung
04 Anforderungsspezifikation
Erfordernisse aus Nutzer & Konzept sowie Systemanalyse in Nutzeranforderungen abgeleitet
Nutzeranforderungen
| ID | Anforderung | Löst |
|---|---|---|
| NA1 | Der Benutzer muss erkennen können, wo er einen Termin buchen kann. | Painpoint 4 |
| NA2 | Der Benutzer muss seine Region mit PLZ und Ort eingeben können und Feedback zur Verfügbarkeit bekommen. | H2.2, UX 5 |
| NA3 | Das System muss Wartungsoptionen mit Preis, Dauer und verständlicher Beschreibung anzeigen, sodass ohne Fachwissen ausgewählt werden kann. | Painpoint 4, UX 4 |
| NA4 | Der Benutzer muss Zusatzleistungen mit verständlicher Erklärung ihres Nutzens sehen können. | UX 3, UX 4 |
| NA5 | Der Benutzer muss erkennen können, wo er einen Tag auswählt. | UX 1, H1.1 |
| NA6 | Der Benutzer muss erkennen können, wo er eine Uhrzeit auswählt. | UX 1 |
| NA7 | Die Eingabe persönlicher Daten muss klar strukturiert und fehlerrobust sein. | Painpoint 7 |
| NA8 | Der Nutzer muss nach Abschluss eine eindeutige Bestätigung erhalten. | H6.4 |
| NA9 | Der Nutzer darf beim Zurücknavigieren seine Eingaben nicht neu eingeben müssen. | Befund E |
| NA10 | Der Nutzer muss alle Eingaben vor der verbindlichen Buchung in einer Übersicht sehen und korrigieren können. | UX 2, H3.4 |
| NA11 | Der Nutzer muss bei unbekannten technischen Details (kW-Klasse, Hersteller) die Möglichkeit haben, das Feld zu überspringen. | H6.1, H6.5 |
Interaktionsspezifikation (Auszug)
| Teilaufgabe | Handlung des Benutzers | Reaktion des Systems | NA |
|---|---|---|---|
| Terminbereich öffnen | Tippt auf “Wartung buchen” | System öffnet die Buchungsstrecke | NA1 |
| Region eingeben | Gibt PLZ oder Ort ein | System prüft Servicegebiet und gibt Feedback; bei Treffer außerhalb: klare Fehlermeldung mit Kontakt-Verweis | NA2 |
| Leistung auswählen | Wählt eine Wartungsoption | Auswahl wird visuell bestätigt und gespeichert | NA3, NA4, NA11 |
| Termin auswählen | Wählt Datum, dann Uhrzeit | System zeigt verfügbare Zeitfenster; Zeitslots erst nach Datumswahl | NA5, NA6 |
| Kontaktdaten eingeben | Füllt Formular aus | System validiert und markiert fehlerhafte Felder mit Inline-Meldung direkt unter dem Feld | NA7, NA9 |
| Buchung prüfen | Öffnet die Review-Seite | System zeigt alle Eingaben mit Bearbeiten-Links ohne Datenverlust | NA10 |
| Verbindlich buchen | Klickt “Verbindlich buchen” | Bestätigungs-Dialog mit Preisnennung, danach Bestätigungsseite | NA8, NA10 |
MVP-Scope
Drin: 7 Schritte (Welcome → Region → Service → Termin → Kontakt → Review → Bestätigung), Persistenz, Warnung beim Zurückspringen, durchgängiger Fortschritts-Indikator, Techniker-Anzeige, Bestätigungs-Dialog, Kalender-Export (ICS), Stornierungshinweis, Hilfe-Tooltips, “Weiß ich nicht”-Optionen, Mobile-First.
Raus: echtes Backend, echter Verfügbarkeitskalender, Login, E-Mail-Versand, Admin-Bereich, Bestandskunden-Shortcut, Hausverwaltungs-Flow, Mehrsprachigkeit.
Design-Prinzipien für alle Folgephasen
- Sicherheit vor Geschwindigkeit
- Kein Fachwissen voraussetzen – alles erklären, “Weiß ich nicht” ermöglichen
- Jeder Schritt braucht eine Aktion
- Mobile-First
- Persistenz ist Standard, nicht Feature
05 Prototyping
Wireframes, Low Fidelity dann Mid Fidelity dann High Fidelity erstellt. Mockups erstellt.
User Flow – Soll
| Schritt | Inhalt | Löst |
|---|---|---|
| 0 – Welcome | Begrüßung, Vertrauenssignale, Auswahl Wartung / Notfall-Hotline | Domain-Insight (Notfall-Trennung), Painpoint 4 |
| 1 – Region-Check | PLZ-Eingabe, Servicegebiet-Prüfung | H2.2, H2.3 |
| 2 – Service-Details | Heizungsart, Wartungspaket, Zusatzleistungen, Hersteller optional, “Weiß ich nicht” | Painpoint 4, H6.1, H6.5, H2.1 |
| 3 – Termin | Datum + Zeiten auf einer Seite, Techniker mit Name und Foto, aktiver Weiter-Klick | Painpoint 9, Painpoint 1 |
| 4 – Kontaktdaten | Pflichtfelder klar, PLZ auto-übernommen, Zwischenspeichern, Warnung beim Zurückspringen | Painpoints 1, 6, 7, 10 |
| 5 – Review | Alle Eingaben zusammengefasst, Bearbeiten-Links ohne Datenverlust, Bestätigungs-Dialog | Painpoint 3 |
| 6 – Bestätigung | Buchungsdetails, “Was passiert als Nächstes”, Stornierungshinweis, ICS-Export | H6.4, H3.4 |
Angewendete UX-Laws
| Gesetz | Anwendung |
|---|---|
| Hick’s Law | Schritt 2: so wenige Optionen wie möglich gleichzeitig, Zusatzleistungen erst nach Hauptauswahl |
| Fitts’ Law | Mobile-First: Weiter-Button immer im Daumenbereich |
| Miller’s Law | Max. 3 Hauptoptionen sichtbar; Review in klare Blöcke statt als Wand |
| Von Restorff | Empfohlenes Paket hervorgehoben, “Verbindlich buchen” klar dominant |
| Zeigarnik | Durchgängiger Fortschritts-Indikator |
| Primacy / Recency | Schritt 0 baut Vertrauen auf, Schritt 6 schließt sauber ab |
| Tesler’s Law | Die Komplexität der Heizungsbranche muss irgendwo hin – entweder trägt sie der Nutzer (schlechte UX) oder das System (Tooltips, “Weiß ich nicht”) |
| Occam’s Razor | Jedes Element muss seinen Platz verdienen |
Wichtige Design-Entscheidungen
Primärfarbe Orange statt Rot — Das Original nutzt ein aggressives Rot. Für WärmeCheck ein wärmeres Orange (#E8720C): thematisch passend (Heizung, Wärme) und einladender für einen Neukunden, der Vertrauen aufbauen will.
Region und Service als getrennte Schritte — Im Original lagen Stadtteilsuche, Angebotsauswahl und Zusatzleistung auf einer Seite, mit inkonsistenter Benennung in Progress Bar und Übersicht. Im Redesign klar getrennt und konsistent benannt.
kW-Klasse mit Analogie erklären — Statt “30 kW” allein: “30 kW – typisch für Wohnungen und kleinere Häuser bis ~150 m²”. Wer es nicht weiß, bekommt eine “Ich bin unsicher”-Option.
Inline-Fehlermeldungen — Direkt unter dem betreffenden Feld statt in einem zentralen Block oben. Behebt eines der stärksten Findings der Heuristischen Evaluation.
Review-Seite vor verbindlicher Buchung — Vollständige Übersicht plus Bestätigungs-Dialog mit Preisnennung. Der Nutzer entscheidet bewusst.
Desktop-Layout — Two-Column ab md-Breakpoint: Flow links (max. 600 px), Buchungsübersicht rechts (sticky, 300 px).
Lerninsight aus dieser Phase: Begründungen vor Entscheidungen. Mehrfach wurde gezeichnet, bevor die Entscheidung stand – das hat zurückgeworfen. Ab Phase 4 strukturierter: erst entscheiden, dann zeichnen.
Zweites Lerninsight: Mid-Fidelity bedeutet echte Inhalte. Echte Texte, echte Zahlen, echte Namen – das macht den Usability-Test aussagekräftiger.
06 Formativer Usability-Test
Qualitativer Test am Figma-Prototyp mit 4 Probanden – Ziel: Schwachstellen finden, nicht messen.
Setup
| Datum | 10.04.2026 |
| Ort | Vor Ort |
| Prototyp | Figma-Prototyp auf iPhone |
| Probanden | 2 Elternteile (56, 57 – hoher Persona-Fit), 2 Geschwister (19, 27 – jünger als Persona) |
| Ablauf | Zwei Durchläufe pro Proband: der erste zur Beobachtung mit Thinking-Aloud, der zweite mit Zeitmessung. 6 Aufgaben von der Startseite bis zur Buchungsbestätigung, ohne Hilfe, danach 3 offene Interviewfragen |
| Erhebung | Beobachtete Probleme, Zögern und Fehlinterpretationen als Hauptergebnis. Als einziges quantitatives Maß die Durchlaufzeit. Kein SUS, keine Erfolgsquoten – diese Messung folgt in Phase 08 am gebauten System. |
Warum der Schwerpunkt qualitativ liegt: Ein formativer Test soll Probleme aufdecken, solange Änderungen noch billig sind. Erfolgsquoten oder Zufriedenheitswerte an einem Klickprototyp zu erheben, hätte eine Präzision vorgetäuscht, die das Artefakt nicht hergibt – ein Prototyp ohne echte Fehlerzustände lässt sich kaum “nicht lösen”. Die Zeit wurde in einem zweiten Durchlauf mitgenommen, weil sie ohne Zusatzaufwand zu haben war. Die belastbare Messung folgt in Phase 08.
Aufgaben-Durchläufe
| Aufgabe | P1 (56) | P2 (57) | P3 (27) | P4 (19) |
|---|---|---|---|---|
| 1 – Einstieg | ✅ | ✅ | ✅ | ✅ |
| 2 – Service | ✅ | ✅ | ✅ | ✅ |
| 3 – Termin | ✅ | ✅ | ✅ | ✅ |
| 4 – Kontakt | ✅ | ✅ | ✅ | ✅ |
| 5 – Review | ✅ | ✅ | ✅ | ✅ |
| 6 – Bestätigung | ✅ | ✅ | ✅ | ⚠️ |
Durchlaufzeiten (zweiter Durchlauf): 2:01 / 2:15 / 1:39 / 1:10 Min – Ø 1:46 Min. Der jüngere Proband ist erwartungsgemäß schneller; die Eltern brauchen rund 30 Sekunden mehr, was unkritisch ist.
Findings nach Severity
🔴 Kritisch – PLZ-Feld-Inkonsistenz Die Überschrift sagt “Ort oder PLZ”, das Feld zeigt nur “PLZ” als Placeholder. Alle vier Probanden waren verwirrt, zwei gaben den Ort ein. Ein klassischer Konsistenz-Verstoß – im eigenen Durchlauf nicht aufgefallen, im systematischen Test sofort.
🟠 Groß – kW-Hinweis nicht gesehen oder nicht verstanden P1: “Welcher kW-Hinweis?” (komplett übersehen). P2: sieht ihn, weiß aber nicht was kW bedeutet. P3: schätzt 30 kW. Der Hinweis existiert, löst das Problem aber nicht – “Die kW-Zahl steht auf dem Typenschild” hilft nur, wenn der Nutzer gerade im Heizungskeller steht.
🟠 Groß – Hersteller-Auswahl: Unsicherheit bei allen Probanden Bestätigt UX 6 aus Phase 1 durch echte Probanden. Die “Weiß ich nicht”-Option funktioniert (P3 nutzt sie sofort), ist aber nicht prominent genug – P1 und P2 zögern.
🟡 Klein – Review-Seite, Zeitreihenfolge, Techniker-Anzeige P1 fand das Zurückspringen zum Bearbeiten “lästig”. P2 wollte zuerst die Uhrzeit wählen, dann das Datum – ein natürliches Verhalten (“ich will morgens um 9”).
🟢 Positiv Einstieg sofort gefunden (alle), Trust-Block wird von den Eltern gelesen, Kalender sofort verstanden, Kontaktformular selbsterklärend, Bestätigungsseite überzeugt, Kalender-Export gefunden, Datenschutz-Checkbox bemerkt.
Überraschung: Die Techniker-Anzeige mit Name und Foto löste beim ältesten Probanden eine sichtbar positive Reaktion aus – “Ah, witzig.” Vertrauenssignale wirken, besonders bei der Hauptpersona.
Iteration daraus
| Fix | Änderung |
|---|---|
| Fix 1 | Placeholder und Überschrift angeglichen; das Feld akzeptiert jetzt explizit PLZ oder Ortsname |
| Fix 2 | kW-Hinweis um eine Analogie ergänzt, “Weiß ich nicht” visuell hervorgehoben |
| Fix 3 | ”Ich bin unsicher” als erste Option platziert – ältere Probanden übersahen sie am Listenende |
| Fix 4 | Zeitslots erst sichtbar nach Datumswahl, mit Hinweis “Bitte wählen Sie zuerst ein Datum” |
07 Software Integration
Figma-Prototyp als Tailwind-CSS-Datei angelegt und live gegangen
Stack: HTML + Tailwind CSS, gehostet über GitHub Pages.
- Design-Tokens aus Figma als Tailwind-Konfiguration gespiegelt – Design-System und Code sprechen dieselbe Sprache
- Mobile-First umgesetzt, Desktop als Two-Column-Layout ab
md-Breakpoint (Flow max. 600 px links, sticky Buchungsübersicht 300 px rechts) - Browser-seitige Persistenz – Eingaben überleben das Zurücknavigieren
- Dynamische Preislogik: Auswahl der kW-Klasse aktualisiert alle Preisanzeigen im Flow (Event Listener auf die zwei Karten, zentrale Preis-Variable)
- Echte Fehlerzustände mit Inline-Validierung statt zentralem Fehlerbalken
- Kalender-Export als ICS-Datei
🔗 Live: https://pixelninja0.github.io/waermecheck-buchung/ 🔗 Code: https://github.com/PixelNinja0/waermecheck-buchung
08 Summativer Vergleichstest
Altes Live-System gegen neues Live-System, 6 Probanden, gemessen statt beobachtet.
Setup
| Datum | 15.05.2026 |
| Probanden | n = 6 |
| Systeme | Original (eTermin.net, live) vs. WärmeCheck (live) |
| Design | Within-Subjects – jeder Proband bediente beide Systeme |
| Reihenfolge | Counterbalanced: 3 Probanden starteten mit dem Original, 3 mit WärmeCheck (kontrolliert Lern- und Ermüdungseffekte) |
| Aufgabe 1 | Eine vollständige Buchungsstrecke mit vorgegebenem Kontext durchlaufen |
| Aufgabe 2 | Einen im Formular eingebauten Fehler finden |
| Metriken | Effektivität (Task Success Rate), Effizienz (Zeit + Klicks), Zufriedenheit (SUS) |
Warum dieses Design: Ein Redesign ohne Vergleichswert misst nichts. Erst der direkte Gegentest gegen das Originalsystem, mit denselben Personen und denselben Aufgaben, macht eine Aussage darüber möglich, ob die Änderungen tatsächlich etwas bewirken.
Ergebnisse
| Maß | Original | WärmeCheck | Differenz |
|---|---|---|---|
| Effektivität – Aufgabe 1 | 100 % | 100 % | – |
| Effektivität – Aufgabe 2 | 100 % | 100 % | – |
| Effizienz – Aufgabe 1, Zeit | 2:30 Min | 1:55 Min | −35 s (−23 %) |
| Effizienz – Aufgabe 1, Klicks | 22 | 19 | −3 (−14 %) |
| Effizienz – Aufgabe 2, Zeit | 0:56 Min | 0:40 Min | −16 s (−29 %) |
| Effizienz – Aufgabe 2, Klicks | 10 | 9 | −1 (−10 %) |
| Zufriedenheit – SUS | 73 | 82 | +9 |
Interpretation
Effektivität sagt hier nichts – und das ist die eigentliche Erkenntnis. Beide Systeme sind zu 100 % lösbar. Das Originalsystem ist nicht kaputt, es ist teuer in der Benutzung. Nutzer kommen ans Ziel, brauchen dafür aber rund ein Viertel mehr Zeit und mehr Klicks. Genau diese Art von Reibung führt im echten Betrieb zu Abbrüchen – nur eben nicht in einer Testsituation, in der niemand aufgibt, weil er weiß, dass er beobachtet wird.
Effizienz verbessert sich durchgängig, in beiden Aufgaben und in beiden Maßen. Die Klickreduktion fällt geringer aus als die Zeitersparnis – ein Hinweis darauf, dass der Gewinn weniger aus kürzeren Wegen kommt als aus schnelleren Entscheidungen. Genau das war der Anspruch: nicht weniger Schritte, sondern verständlichere.
SUS 73 → 82. Nach der Einordnung von Bangor et al. (2009) liegt 73 leicht über dem Durchschnitt von 68, 82 im oberen Bereich – der Übergang von “good” zu “excellent”. Dass beide Werte von denselben Personen im direkten Vergleich vergeben wurden, macht die Differenz belastbarer als zwei unabhängig erhobene Scores.
Grenzen der Studie
- n = 6 ist eine kleine Stichprobe. Die Ergebnisse zeigen eine klare Tendenz, sind aber nicht als statistisch abgesichert zu lesen.
- Effektivität differenziert nicht – für einen Unterschied hätte es schwierigere Aufgaben oder realistischeren Zeitdruck gebraucht.
- Testsituation ≠ Realsituation: Abbrüche, der wichtigste Painpoint des Originals, lassen sich im Labor kaum provozieren.
- Die vier Fixes aus dem formativen Test waren zum Testzeitpunkt bereits umgesetzt. Ihr Einzelbeitrag zum Ergebnis lässt sich deshalb nicht isolieren.
09 Dokumentation & Integration
Markdown-Dokument in Obsidian angelegt und Website live gebracht. Projekt-Reflexion. Ende.
- Vollständige Prozessdokumentation in Obsidian – alle 9 Phasen mit Zwischenständen, Befunden und Iterationen
- Case Study auf der Portfolio-Seite
- Diese Projektübersicht + README im Repo
- Live-Demo und Quellcode öffentlich
Ergebnis & Reflexion
Was entstanden ist
- Eine vollständige, responsive Buchungsstrecke – live, mit echten Fehlerzuständen, konsistenten Design-Tokens und einem Nutzerfluss, der auf realer Persona und systematischer Analyse basiert
- Eine dokumentierte Systemanalyse mit 3 Bugs, 10 Heuristik-Befunden und 10 priorisierten Painpoint-Clustern
- Zwei Usability-Tests: formativ am Prototyp (n=4, qualitativ), summativ im direkten Vergleich gegen das Originalsystem (n=6, Within-Subjects) – mit dokumentierter Iteration dazwischen
Was ich gelernt habe
Methodisch sauber vorgehen zahlt sich aus. Der größte Lerneffekt war die Disziplin, Phasen wirklich einzuhalten: erst verstehen, dann definieren, dann designen. Die Versuchung war mehrfach groß, früher mit dem Design anzufangen. Aber die Heuristische Evaluation hat Befunde produziert, die ich ohne strukturierte Methodik nie gefunden hätte – zum Beispiel den Datenverlust, der erst beim systematischen Durchgehen von Heuristik #5 in seiner vollen Schwere sichtbar wurde.
Testen, was man baut – auch wenn es unbequem ist. Der formative Test hat gezeigt, dass selbst Probleme, die ich für klein hielt (PLZ/Ort-Inkonsistenz), alle vier Probanden betroffen haben. Und Probleme, die ich für groß hielt (kW-Auswahl), wurden durch die richtige Hilfestellung entschärft. Ohne echte Probanden wäre das Redesign auf meinen eigenen Annahmen geblieben.
Domain-Research vor der Bewertung. Ohne Fachwissen bewertet man nur Oberflächen. Und: wenn zwei Personen dasselbe unterschiedlich interpretieren, ist die Optik kaputt – nicht die Interpretation.
Was ich anders machen würde
Mehrere Konzeptvarianten parallel entwickeln, statt früh auf eine Richtung festzulegen – erst der Vergleich zeigt, ob eine Lösung wirklich die beste ist oder nur die erste. Und eine größere Stichprobe für den Usability-Test: n=6 zeigt eine Tendenz, trägt aber keine belastbare statistische Aussage.
Was ich persönlich mitnehme
Eine gute Struktur sorgt für sorgfältiges Arbeiten. Nicht als Selbstzweck – sondern weil sie die Fragen erzwingt, die man sonst überspringt.
Nächste Schritte
Bestandskunden-Account mit “Wieder buchen wie letztes Jahr”, Hausverwaltungs-Flow als eigener B2B-Pfad, SMS-Erinnerung vor dem Termin, Techniker-Tracking am Einsatztag, Bewertung nach dem Termin.
Anhang
- Live Demo: https://pixelninja0.github.io/waermecheck-buchung/
- GitHub: https://github.com/PixelNinja0/waermecheck-buchung
- Figma-Prototyp: Figma
- Analysiertes Original: https://www.gascontrol.de/termin/ (eTermin.net)