2023 habe ich UFMn der Öffentlichkeit vorgestellt. Was damals als jahrelange Eigenentwicklung begann – viel Ausprobieren, viel Verwerfen, viele Projekte – hat sich seither weiterentwickelt.
Durch Feedback von anderen UX Designern. Und später in enger Zusammenarbeit mit Sandra Hohl, die vor allem die Notation in Figma grundlegend weiterentwickelt hat. Das Ergebnis ist eine eigene Website, eine Figma Library in Version 3.0 und eine Methode, die unterdessen in vielen Teams produktiv eingesetzt wird.
Höchste Zeit für einen ehrlichen Zwischenbericht.
UFMn ist nicht mehr das, was es bei der Erstveröffentlichung war – und das ist gut so.
Die Grundausrichtung ist dieselbe geblieben: eine gemeinsame Notation für Userflows, die nicht nur UX Designer verstehen sollen, sondern alle Beteiligten. Entwickler, Product Owner, Business Analysten. Was sich verändert hat, ist die Reife. Die Notation ist konsistenter, die Library besser strukturiert, die Anwendungsfälle breiter dokumentiert.
Und vor allem: Mehr Menschen arbeiten damit. Unterdessen nutzen zahlreiche UX Designer – und damit auch die entsprechenden Entwicklungsteams – diese Notation. Eine Methode setzt sich nicht durch weil sie perfekt ist, sondern weil sie verlässlich genug ist, damit mehrere Menschen darauf aufbauen können.
Die grössere Frage stellt sich erst jetzt – mit KI-Tools wie Figma Make auf dem Vormarsch. Aber dazu später mehr.
Die Notation ist bei jedem Projekt eine Herausforderung. Das war so, das bleibt so – mit oder ohne UFMn.
Was UFMn ändert: Ich muss die Struktur nicht jedes Mal neu erfinden. Es gibt ein Muster, dem ich vertrauen kann. Ein Ausgangspunkt, der funktioniert. Das klingt nach wenig, spart aber in der Praxis erstaunlich viel Energie – gerade in der frühen Projektphase, wo sowieso alles gleichzeitig passiert.
Dazu kommt das Kommunikations-Argument, das nach wie vor stimmt: Wer einen gut gemachten UFMn-Flow vor sich hat, versteht schneller was gemeint ist. Meetings werden kürzer. Missverständnisse werden früher sichtbar. Die Methode zwingt einen anders zu denken – weg vom Screen, hin zum Prozess.
Bei kleinen, überschaubaren Projekten funktioniert UFMn fast von alleine. Bei grossen, chaotischen Projekten – genau dort wo man es eigentlich am meisten bräuchte – ist es trotzdem nicht immer einfach, die Files aktuell zu halten.
Das ist keine Kritik an der Methode. Das ist eine ehrliche Beobachtung über Projektrealität. Wenn sich Anforderungen schnell ändern, leidet die Dokumentation als erstes. Man muss dann immer wieder zurückschauen, nachführen, aufräumen. Das braucht Disziplin – und die kommt nicht aus einer Library, sondern aus einer Projektkultur.
Unterm Strich rechnet es sich trotzdem. Wer mit UFMn arbeitet, ist am Ende schneller als wer es nicht tut.
UFMn ist eine strukturierte, regelbasierte Notation. Genau das, was KI-Systeme eigentlich gut verarbeiten könnten – wenn man sie liesse. Und genau da fängt das Problem an.
Gerade wenn ich an Figma Make denke, vermisse ich etwas.
Figma Make hat eine textuelle KI-Schnittstelle. Keine flow-basierte. Das bedeutet: ich kann der KI nicht zeigen, wo was wie funktioniert. Ich kann keinen UFMn-Flow als strukturierten Input in Make einbringen. Und umgekehrt: wenn Make Screens generiert, gibt es keinen automatischen Weg, daraus eine saubere UFMn-Struktur abzuleiten.
Dabei wären genau das zwei sinnvolle Richtungen. Erstens: UFMn als Eingabe – ich beschreibe Flows in einer strukturierten Notation, die KI versteht die Logik dahinter. Zweitens: UFMn als Ausgabe – Make generiert nicht nur Screens, sondern auch die entsprechende Prozessdokumentation.
Prototypen lösen das Problem nicht. Sie sind nützlich, aber das Grundproblem in der Zusammenarbeit – wer versteht wie der Prozess wirklich funktioniert – bleibt bestehen, solange die Übergabe nicht strukturiert abläuft.
Vielleicht ist das nur eine Frage der Zeit. Vielleicht wird sich das irgendwann von selbst lösen. Vielleicht braucht es dann weder das eine noch das andere. Ich weiss es nicht – aber ich finde die Frage wichtig genug, um sie jetzt schon zu stellen.