Produkt Designer & Researcher1 Designer - 2 DevsKI-Wissensassistent1,5-Tage Sprint
Ein Mobile-first-KI-Konzept für Hirth Engines: Das Erfahrungswissen der Ingenieure fließt im normalen Arbeitsalltag in ein zentrales System — ohne hohen Dokumentationsaufwand, ohne den Arbeitsfluss zu unterbrechen — und lässt sich genauso dynamisch wieder abrufen.
Tritt am Prüfstand ein Fehler auf, verlieren Ingenieure Stunden damit, Lösungen neu herzuleiten, die Kollegen längst gefunden haben. Die Geschäftskosten sind real: verzögerte Projekte, wiederholte Fehlersuche und Risiko, wenn Expertenwissen das Haus verlässt.
Die Kern-Erkenntnis aus dem Interview: Ingenieure meiden Dokumentation nicht aus Faulheit, sondern weil jedes vorhandene Tool Reibung hinzufügt — in einem ohnehin zeitkritischen Job. Neue Login-Flows, Pflichtformulare, der Wechsel in eine Desktop-App — jedes davon ist ein Grund, es zu lassen.
Also kehrte sich das Designziel um: nicht „sie mehr dokumentieren lassen“, sondern den Dokumentationsschritt ganz entfernen — gesprochene Erklärungen passiv sammeln und in ein hypothesengetriebenes Retrieval-System einspeisen.
„Dokumentation wird von den Jungs meistens vermieden. Sie versuchen, sie zu umgehen, weil sie Zeit kostet.“— Field Engineer, Hirth (Stakeholder-Interview)
Wie könnten wir Ingenieuren ermöglichen, Expertenwissen zu erfassen und abzurufen, ohne ihrem bestehenden Arbeiten einen einzigen Schritt hinzuzufügen?
Ein 60-minütiges, halbstrukturiertes Stakeholder-Interview mit einem Field Engineer, auf Empathy-Map-Quadranten abgebildet; wörtliche Zitate für das Clustering extrahiert.
Empathy Map, Point-of-View-Statement und 12 Jobs-to-be-Done — jedes im Interview-Signal verankert, Annahmen gekennzeichnet, wo extrapoliert.
How-Might-We-Fragen, Feature-Mapping und explizite Scope-Cuts — behalten wurde nur, was ein Interview-Zitat oder ein JTBD rechtfertigen konnte.
Mobile-first, KI-generierte Screens für vier Kern-Screens — Problem-Input, Hypothesen-Liste, geführte Fehlersuche, Quick Capture — direkt nachjustiert und im Team zu einem funktionsfähigen Prototyp weiterentwickelt, in zwei Runden mit dem Lead Engineer usability-getestet. Für einen Lo-Fi-Schritt blieb im 1,5-Tage-Hackathon keine Zeit; UX und Development arbeiteten asynchron parallel.
UX-Artefakte in ein Narrativ übersetzt, das ein nicht-technisches Führungspublikum bewerten kann — UX-ROI als Strategie zur Expertenbindung gerahmt.
Artefakte: Interview-Transkript & Empathy Map · Point-of-View · 12 Jobs-to-be-Done · How-Might-We → Mechanismus-Mapping · Produktanforderungsdokument mit Erfolgsmetriken-Framework · 4-Screen-Konzept · zwei Usability-Test-Runden am funktionsfähigen Prototyp · Pitch-Narrativ.
Wörtliche Zitate den vier Quadranten zugeordnet — kein formales Kodierschema, bei einem Einzel-Interview (N=1) bewusst leichtgewichtig gehalten.
Quelle: Stakeholder-Interview Hirth Engines · Empathy Map & Pains/Gains synthetisiert aus dem vollständigen Recherche-Artefakt.
→ Vollständige Empathy Map ansehen (PDF)Wie könnten wir Ingenieuren ermöglichen, Expertenwissen zu erfassen und abzurufen, ohne ihrem bestehenden Arbeiten einen einzigen Schritt hinzuzufügen?
Jeder Job ist auf ein wörtliches Interview-Zitat verankert, ins JTBD-Format „Wenn … möchte ich … um …" übersetzt.
Situation„Wenn ein Fehler auftritt, den ich noch nicht kenne — zum Beispiel Kratzer auf dem Kolben —"
Motivation„möchte ich sofort eine priorisierte Liste möglicher Ursachen sehen, statt bei null anzufangen,"
Ergebnis„um direkt mit der wahrscheinlichsten Hypothese zu testen, statt Stunden mit Herleiten zu verlieren."
Situation„Wenn ich einem Kollegen gerade erkläre, wie ich ein Problem gelöst habe,"
Motivation„möchte ich das im selben Moment aufnehmen können, ohne extra etwas aufzuschreiben,"
Ergebnis„um zu dokumentieren, ohne meinen Arbeitsfluss zu unterbrechen oder Zeit zu verlieren."
Zum Aufklappen — jeder Job vollständig im Situation / Motivation / Ergebnis-Format. Gruppiert in 5 Themen: Problemlösung (3) · Informationszugriff (3) · Wissenserfassung (2) · Vertrauen & Validierung (2) · Zugang & Akzeptanz (2).
Situation„Wenn ein Fehler auftritt, den ich noch nicht kenne — zum Beispiel Kratzer auf dem Kolben —"
Motivation„möchte ich sofort eine priorisierte Liste möglicher Ursachen sehen, statt bei null anzufangen,"
Ergebnis„um direkt mit der wahrscheinlichsten Hypothese zu testen, statt Stunden mit Herleiten zu verlieren."
Situation„Wenn ich das System nach einer Lösung frage,"
Motivation„möchte ich direkt angeben können, was ich schon ausprobiert oder ausgeschlossen habe,"
Ergebnis„um keine Vorschläge zu bekommen, die ich längst getestet habe, und Zeit zu sparen."
Situation„Wenn ich mich für eine wahrscheinliche Ursache entschieden habe,"
Motivation„möchte ich eine geführte Schritt-für-Schritt-Anleitung statt eines ganzen Handbuchs,"
Ergebnis„um strukturiert vorzugehen, ohne mich durch irrelevante Seiten zu lesen."
Situation„Wenn ich eine erste Antwort vom System bekomme,"
Motivation„möchte ich eine kurze Vorschau sehen, bevor ich mich auf die volle Detailtiefe einlasse,"
Ergebnis„um schnell zu entscheiden, ob das überhaupt relevant ist, ohne lange Texte lesen zu müssen."
Situation„Wenn ich eine Ursache weiterverfolge,"
Motivation„möchte ich verlinkte Handbücher, Diagramme und Berichte an einem Ort haben,"
Ergebnis„um nicht mehr zwischen Büchern, Ordnern und einzelnen KI-Tools hin- und herzuwechseln."
Situation„Wenn ich einen sichtbaren Defekt vor mir habe,"
Motivation„möchte ich ein Foto hochladen und eine visuelle Einschätzung bekommen,"
Ergebnis„um das Problem schneller zu kommunizieren, als es in Worten zu beschreiben."
Situation„Wenn ich einem Kollegen gerade erkläre, wie ich ein Problem gelöst habe,"
Motivation„möchte ich das im selben Moment aufnehmen können, ohne extra etwas aufzuschreiben,"
Ergebnis„um zu dokumentieren, ohne meinen Arbeitsfluss zu unterbrechen oder Zeit zu verlieren."
Situation„Wenn ich nach der Fehlersuche eine Zusammenfassung als Folie habe,"
Motivation„möchte ich diese einfach hochladen und vom System auswerten lassen,"
Ergebnis„um Wissen beizutragen, ohne Inhalte manuell nochmal einzutippen."
Situation„Wenn das System mir eine Antwort gibt,"
Motivation„möchte ich sehen, von wem sie stammt und worauf sie beruht,"
Ergebnis„um sie einschätzen und im Zweifel mit der Quelle direkt klären zu können."
Situation„Wenn ich eine falsche oder veraltete Information im System finde,"
Motivation„möchte ich sie markieren und korrigieren können, zurückverfolgbar zur Quelle,"
Ergebnis„um die Wissensbasis für das ganze Team verlässlich zu halten."
Situation„Wenn ich am Prüfstand oder im Feld unterwegs bin,"
Motivation„möchte ich das System vom Handy aus nutzen können, ohne Umwege,"
Ergebnis„um Hilfe zu bekommen, ohne extra an einen Schreibtisch zurückzumüssen."
Situation„Wenn ich dem System mein Problem beschreibe,"
Motivation„möchte ich das in ganzen Sätzen tun können, nicht nur mit Stichworten,"
Ergebnis„um Nuancen zu vermitteln, die das System sonst nicht verstehen würde."
Jedes behaltene Feature ist auf ein HMW und ein JTBD rückführbar.
| Feature | HMW | JTBD |
|---|---|---|
| Voice-Capture + NLP | Lösung sprechen & strukturieren | 07 · Sprachnotiz vor Ort |
| Hypothesen-Karten | Suche wie ein Kollege | 01 · Priorisierte Ursachenliste |
| Passive Erfassung | Doku ohne Dokumentieren | 07 · Sprachnotiz vor Ort |
| Verlässlichkeitsstufen | Konfidenz signalisieren | 09 · Quelle & Autor pro Antwort |
UX Design baute zwei klickbare No-Code-Prototypen (Base44, Replit) für Feature-Exploration und inspirierende Umsetzung; das Dev-Team entwickelte parallel einen funktionsfähigen MVP mit Fokus auf technische Machbarkeit — asynchron statt sequenziell.
Fokus: technische Funktionalität und Machbarkeit.
Fokus: Feature-Exploration und inspirierende Umsetzung, unabhängig von technischen Constraints.
Der Pitch verkaufte UX nicht als Ästhetik, sondern als Risikoreduktion: Jedes Feature wurde direkt auf ein Interview-Zitat zurückgeführt, jede Kostenentscheidung direkt gegen die genannte Schmerzgrenze gerechnet. Für ein nicht-technisches Führungspublikum wurde der Produktvorteil in Geschäftsrisiko übersetzt — Wissensverlust bei Personalwechsel, verzögerte Projekte, wiederholte Fehlersuche — statt in Interface-Details.
Die Differenzierung ist nicht die KI. Es sind das Experten-Korrektur-Schwungrad und die reibungsfreie Erfassungsschleife, die Wettbewerber nicht leicht kopieren können.
Sprache, Foto oder Text — im Moment des Lösens, ohne Formular.
Auto-Tagging und NLP-Klassifizierung ordnen den Input ein.
Hypothesen-Ranking nach Verlässlichkeitsstufe für die nächste Anfrage.
Ingenieur markiert Schritt erledigt / fehlgeschlagen / teilweise — der Mensch bleibt in der Schleife.
Korrekturen fließen ins Modell zurück — das Schwungrad dreht schneller.
Ingenieure denken vorwärts von Ursachen, nicht rückwärts von Stichworten.
Entfernt den Dokumentationsschritt vollständig.
Vertrauen entsteht durch nachvollziehbare validierte Quellen.
Direkte Antwort auf die im Interview genannte Kostengrenze von €20.000/Jahr — sonst kippt das Projekt.
Kein Interview-Signal, kein stützendes JTBD.
Fügt dem Erfassungs-Flow Reibung hinzu.
Ursprünglich für das fokussierte 4-Screen-Konzept zurückgestellt: geringer Mobile-Nutzen, kein validierter Job für die primäre Persona. Im 1,5-Tage-Zeitrahmen blieb dann doch Raum dafür — gebaut und mit dem Lead Engineer getestet. Bleibt für den mobilen Kern weiterhin nachrangig, ist aber Teil des funktionsfähigen Prototyps.
Aus dem Hackathon entstanden und in zwei Runden am funktionsfähigen Prototyp usability-getestet — hier steht offen, was belegt ist und was noch Annahme bleibt.
Research-Output-Verhältnis: 1 Interview → 12 JTBD → 4 Screens → funktionsfähiger Prototyp. Zielwerte (< 2 Min. bis zur ersten Hypothese, < 30 Sek. Erfassung, 20–40 % kürzere Lösungszeit binnen 6 Monaten) sind Pitch-Projektionen, als [Annahme] gekennzeichnet bis zu einer Pilotstudie.
Aus dem 1,5-Tage-Konzept ist ein aktives Vorhaben geworden.
In hochtechnischen Kontexten besteht die Aufgabe im Design nicht darin, Features zu erfinden — sondern die zu entfernen, die Experten das Leben schwerer machen. Jede behaltene Entscheidung hier führt auf ein Interview-Zitat zurück; jeder Cut auf dessen Fehlen.
