“Wir haben Prototypen gebaut, um den Raum zu überzeugen. Der Workflow, der dabei entstand, gab den Entwicklern einen spürbaren Vorsprung.”
Wer was sieht, und wann
Seismo Pulse fasst eine laufende Krise zu einem Live-Lagebild zusammen, für Betreiber kritischer Infrastruktur, für die ein Ausfall keine Option ist. Dasselbe Lagebild muss der Person nützen, die das Ereignis bewältigt, und der, die kurz draufschaut.
Die Aufgabe war nie, mehr Informationen zu zeigen. Sie war zu entscheiden, was wer sehen muss, und wann.
In dieser Case Study geht es um die frühe Phase.
Konkret um drei Dinge. Wie das Produkt in Module geschnitten wurde, damit sehr unterschiedliche Kundschaften sehr unterschiedliche Fassungen davon bekommen. Warum jedes neue Modul als lauffähiger Prototyp gebaut wird, bevor sich eine Spezifikation dafür schreiben lässt. Und der Design-to-Code-Workflow, der daraus entstanden ist.
Verstreut, dann ein Bild, dann drei Lesarten
Was über eine Reaktion entscheidet, liegt in getrennten Systemen, in Dokumenten und auf Papier. Ein Bild muss all das zusammenführen, und dann gleichzeitig drei Lesarten bedienen.
Unterschiedliche Kundschaften, ein Produkt
Seismo Pulse richtet sich an Organisationen, die etwas am Laufen halten müssen: Spitäler, Fluggesellschaften, Kantone, Bundesämter, die Post. Die Liste ist nicht abgeschlossen. Krisen haben sie alle, und keine meint damit dasselbe. Ein Ereignis ist bei einer Fluggesellschaft womöglich ein Flugzeugabsturz. Bei einem Netzbetreiber ist es ein Mastdefekt, den jemand vor Schichtende notieren muss.
Ein Bildschirm mit fest verbauten Panels konnte es also nicht werden. Jede Fähigkeit ist ein Modul, und ein Modul muss zwei Tests bestehen: Es lässt sich für eine Kundschaft abschalten, ohne dass der Rest bricht, und es besitzt eine eigene Art von Objekt, ob Ereignisse, Aufgaben, Journaleinträge oder Kontakte. Modularität steht in jedem Produkt-Deck. Hier war sie die erste Randbedingung und kein Feature.
Das Lagebild ist das Modul, das alle teilen, und der Ausgangspunkt jeder Kundschaft. Was sich unterscheidet, ist das, was drumherum steht, und was ein Eintrag darin am Ende bedeutet.
Eine Modulliste, zwei Ebenen
Die Struktur. Jeder Eintrag in der Leiste ist ein Modul mit einer eigenen Art von Objekt: Ereignisse, Aufgaben, Journaleinträge, Kontakte. Das Lagebild ist das Modul, das alle teilen, und der Ausgangspunkt jeder Kundschaft.
Prototypen als Argument
Der Satz an Modulen ist auf Wachstum ausgelegt. Jedes Kundengespräch bringt entweder ein neues Modul oder schärft ein bestehendes, und ein Modul, das noch niemand gesehen hat, lässt sich nicht spezifizieren. Also wird es zuerst als Prototyp gebaut und danach aufgeschrieben. Damit ist Prototyping hier die Methode und keine Phase: So wird entschieden, was das nächste Modul können muss.
In diesem Feld kauft niemand ein Konzept von einer Folie. Statt Bilder einer Idee zu zeigen, haben wir also lauffähige Software vorgeführt.
Wir haben viele Prototypen gebaut, KI-gestützt auf MUI, und sie in Demos und Präsentationen mitgenommen. Durchklicken statt beschreiben ist das, was die Stakeholder überzeugt hat. Diese Menge an Prototypen warf die nächste Frage auf: Wie baut man sie weiter, ohne dass auf dem Weg in den Code Qualität verloren geht?
Von Design zu Code, ohne Qualitätsverlust
Der naheliegende Schritt war, Figmas MCP-Server auf die Designdatei zu richten. Es funktionierte halb, und das ist schlimmer, als wenn es gar nicht funktioniert hätte. Eine Figma-Datei ist so aufgebaut, wie es für die Person sinnvoll ist, die sie gestaltet, und nicht wie Markup. Das Modell bezahlt also für den Aufbau eines Designs, lange bevor es dazu kommt, wie es gebaut werden soll.
Was an die Stelle trat, ist unspektakulärer und funktioniert. Tokens verlassen Figma als Rohexport, Skripte schreiben sie in die Struktur um, die Candos Entwickler ohnehin verwenden, und die Brücke wird synchron gehalten. Genau das macht daraus Infrastruktur statt einer einmaligen Konvertierung. Das hat einen Preis, und das Design zahlt ihn: Eine einzige von Hand gewählte Farbe, und das, was die Brücke garantieren soll, ist weg.
Ein Feature startet heute aus dem Ticket, einem Screenshot des Figma-Frames und dem Design System als Markdown. Die eigene Einschätzung der Entwickler zum Unterschied: 3×. Und die Praxis hat das Designteam ganz verlassen: Sales und Product Owner prompten auf der echten Codebasis, ein Pitch steht also auf dem tatsächlichen Stand des Produkts statt auf einem losen Artefakt.
Am Ende war der Workflow das Ergebnis.
Gebaut wurde er, um Prototypen für Demos zu machen. Herausgekommen ist ein gemeinsamer Ort, an dem Design, Entwicklung und die Entscheidenden dasselbe Produkt erkunden, und Figma-Screens landen heute deutlich besser in fertigen Features. Offen ist der Schritt selbst: Design, Prototyping und Umsetzung sind drei Züge nacheinander und sollten einer sein, eine Exploration, die in den Code fliesst, statt jedes Mal über eine Grenze gereicht zu werden. Das ist das Nächste, und ich habe es noch nicht.
Von der Idee zu etwas Lauffähigem
Prototypen. Produkt, Design und Entwicklung geben je das ab, was ihnen gehört: die Idee, die Tokens und Guidelines, das Markdown, das das Modell braucht. Zurück kommt lauffähige Software, ohne Schleifen.
3× schnellerer Start in ein neues Feature
Mein Beitrag
- Konzept und UX verantwortet: wie aus Ereignissen, Bedrohungen und Assets ein Lagebild wird, das auf jeder Ebene lesbar bleibt.
- Die modulare Struktur entworfen: was als Modul zählt, was eine Kundschaft abschalten kann, und wie dasselbe Modul organisationsweit und innerhalb einer Lage funktioniert.
- Die Prototyping-Praxis vorangetrieben, KI-gestützt auf MUI: lauffähige Software für die Stakeholder statt Folien.
- Den Design-to-Code-Workflow dahinter gebaut und die Praxis bis in Sales und Product Ownership gebracht.
Geschütztes Material
Interface-Screens der Live-Plattform und die Prototypen, die aus dem Workflow entstanden sind.
Das Produkt wird für Betreiber kritischer Infrastruktur entwickelt, das Interface ist deshalb nicht öffentlich.
Geschützte Fassung öffnen →Die Zugangsdaten liegen meiner Bewerbung bei, oder fragen Sie mich.
Ergebnis
3×
schnellere Feature-Starts, gemessen von den Entwicklern
Workflow
eine gemeinsame Brücke von Figma-Tokens in den Code, synchron gehalten
1
Produkt, pro Kundschaft konfiguriert statt neu gebaut
Seismo Pulse ist bei ecmt in Winterthur in aktiver Entwicklung. Die modulare Struktur ist dafür da, dass eine neue Kundschaft eine Konfiguration ist und kein Neubau. Und die Prototyping-Praxis hat mehr bewirkt, als nur die Demos zu gewinnen, für die sie gedacht war: Sie hat das Designteam verlassen, und der Workflow dahinter bestimmt heute, wie Features starten und wie das Produkt gepitcht wird. Geplant war das nicht.