Vom Visual Computing zur nutzerzentrierten Frontend-Entwicklung: Die Learnings aus „Oliver Troger, Front End Developer bei smaXtec“ (smaXtec animal care GmbH)

Einleitung: Was wir von dieser DevStory mitnehmen

In der Session „Oliver Troger, Front End Developer bei smaXtec“ mit Speaker Oliver Troger von smaXtec animal care GmbH erleben wir eine klare, ungeschönte DevStory: eine Reise vom Studium über fachliche Schwerpunkte hin zu dem, was im Alltag im Frontend wirklich zählt – stetiges Refactoring, fokussiertes Prototyping, das Zusammenspiel mit anderen Teams und eine tiefe, stetige Beschäftigung mit Usability. Trogers Erzählung ist knapp, aber prägnant. Genau diese Prägnanz ist es, die in Zeiten voller Tech-Buzzwords Orientierung bietet.

Wir bei DevJobs.at haben zugehört, was ihn motiviert, welche Aufgaben im Frontend-Team den Ton angeben und welches Handwerkszeug er sich als besonders wirksam erarbeitet hat. Drei Botschaften ragen heraus:

• Ein ehrlicher Abgleich zwischen Interesse und Fachdisziplin führt zu besseren Ergebnissen als stures Festhalten am einmal Gewählten.
• Frontend-Qualität lebt von Refactoring, Prototyping und enger Zusammenarbeit – nur so wird das, was Nutzerinnen und Nutzer sehen, tatsächlich verständlich und wertstiftend.
• Ein Arbeitstagebuch ist kein „Nice-to-have“, sondern ein Kompass über Tage, Wochen und Monate.

Der Weg: Von Medieninformatik und Visual Computing zur Informationsvisualisierung – und weiter ins Mobile Engineering

Oliver beschreibt, wie er nach ersten Schritten rasch merkte, wie schwer es ist, „eigene Projekte umzusetzen, wenn man jetzt wirklich in der Sparte arbeiten möchte“. Diese Einsicht lenkte seinen Blick auf Informatik – weniger als Abkehr, mehr als Weg, Ideen mit greifbarer Wirkung zu realisieren. Er studierte Medieninformatik und Visual Computing, stieß aber an eine persönliche Grenze: Rendering Pipelines begeistern nicht jeden.

Was für manche ein Karrierebremsklotz wäre, wird bei ihm zum Weichensteller. Informationsvisualisierung sprach ihn an – und genau darüber kam er ins Mobile Engineering. Dieser Schritt führt ihn weiter dorthin, wo er heute arbeitet: im Frontend bei smaXtec, konkret am Messenger und an der App.

Aus unserer Sicht liegen hier drei sorgfältig gewählte Entscheidungen in Folge:

1. Den Mut haben, ein Themenfeld („Rendering Pipelines“) nicht zu idealisieren, sondern realistisch einzuordnen.
2. Das Naheliegende erkennen: Informationsvisualisierung verbindet Gestaltung, Struktur und Nutzersicht – ein natürlicher Pfad Richtung Frontend und mobile Anwendungen.
3. Das Gelernte konsequent übersetzen: vom „Wie sieht Information aus?“ hin zum „Wie bedienen Menschen diese Information?“ – also von der Visualisierung in die Interaktion.

Diese Kette zeigt, wie aus Spezialisierung eine Position mit großer Praxisnähe entsteht.

Das heutige Spielfeld: Frontend-Aufgaben zwischen Refactoring, neuen Features und Prototyping

Im Frontend-Team von smaXtec animal care GmbH ist die Aufgabenlandschaft breit. Oliver benennt drei Pole, die den Arbeitsalltag strukturieren:

• Refactoring, „weil wir ja immer am neuesten Stand bleiben möchten, um den Kunden bestmöglich die Informationen zu liefern.“
• Implementierung von neuen Features über Feature-Grenzen hinweg.
• Prototyping, „damit wir gewährleisten können, dass der Kunde die beste Usability hat.“

Diese drei Pole sind keine getrennten Tracks, sondern ein Spannungsfeld, in dem sich reale Produktentwicklung bewegt.

Refactoring als Qualitätssicherung

Refactoring bekommt in Trogers Schilderung eine strategische Rolle. Es geht nicht nur um Code-Schönheit, sondern darum, die Basis stabil, verlässlich und zukunftssicher zu halten – damit Informationen sauber, schnell und verständlich beim Kunden ankommen. Das impliziert:

• Regelmäßiges Aufräumen verhindert Tech-Debt-Spiralen.
• „Am neuesten Stand“ bleiben ist kein Selbstzweck, sondern Voraussetzung für verlässliche Informationsdarstellung.
• Refactoring gehört in die Roadmap, nicht in die Randzeiten.

Feature-Implementierung: von klein bis groß

Oliver macht deutlich, dass das Spektrum von Änderungen groß ist. Von kleinen Anpassungen, die die Usability merklich verbessern, bis hin zu „größeren Tasks, die ganze Features übergreifend implementiert werden sollen“. Das zeigt einen reifen Umgang mit Scope:

• Kleine, punktuelle Maßnahmen wirken schnell und verbessern den Alltag der Nutzer unmittelbar.
• Große, funktionsübergreifende Vorhaben schaffen Strukturen, die Produktteams über Versionen hinaus tragen.

Prototyping als Brücke zur Usability

Gerade im Frontend ist Prototyping die Brücke zwischen Annahme und Erfahrung. Troger stellt es klar in den Kontext von Nutzbarkeit: Prototypen dienen dazu, „zu gewährleisten, dass der Kunde die beste Usability hat“. Damit legt er den Fokus nicht auf Hi-Fi-Perfektion, sondern auf Erkenntnisgewinn.

Aus redaktioneller Sicht übersetzt sich das in einen Lernkreislauf:

1. Hypothese zur Nutzbarkeit formulieren.
2. Prototyp erstellen, der die Hypothese testbar macht.
3. Rückmeldungen aufnehmen, visuelle und interaktive Reibungen identifizieren.
4. Design- und Implementierungsentscheidungen anpassen.

Zusammenarbeit: Warum Frontend ein Teamsport ist

Oliver betont, dass bei größeren Tasks „mehrere Leute … involviert sind“. Ihm gefällt besonders, „dass wir mit anderen Teams in Kontakt stehen, da wir wissen müssen, was wir dem Kunden anzeigen möchten.“ Dieses Statement ist eine Erinnerung an das Wesen des Frontends: Es ist die Schnittstelle, an der Business-Entscheidungen, Datenflüsse und Nutzererwartungen zusammenlaufen.

Damit klare, verlässliche Benutzeroberflächen entstehen, braucht es:

• Kontext: Welche Information ist für den Kunden wirklich relevant?
• Priorisierung: Was gehört nach vorne, was in die zweite Reihe?
• Konsistenz: Welche Muster und Begriffe sollen überall gleich funktionieren?

Cross-funktionale Abstimmung ist dafür kein optionales Extra, sondern Arbeitsgrundlage. Trogers Freude an dieser Schnittstellenarbeit zeigt ein Mindset, das über die Codezeile hinausschaut.

Haltung und Fähigkeiten: Auge für Design, Neugier auf Usability – auch jenseits von Software

„Man braucht ein gewisses Auge für Design und auch die Lust, sich damit zu beschäftigen.“ Oliver verknüpft diesen Satz mit einer Beobachtung, die wir aus UX-Diskursen kennen, aber im Engineering-Kontext zu selten hören: Achte auf Usability nicht nur in digitalen Produkten, sondern auch bei haptischen Gegenständen.

Die Botschaft: Wer über gute physische Interfaces nachdenkt, trainiert dieselben kognitiven Muskeln, die im Frontend gebraucht werden. Ein Toaster mit klarer Rückmeldung – akustisch, haptisch, visuell – lehrt uns, was schnelle, eindeutige Signale ausmacht. Dieses Lernen übersetzt sich „implizit … in seine Arbeit“.

Für Entwicklerinnen und Entwickler bedeutet das:

• Beobachte die Welt wie ein Interface-Designer: Wo geben Produkte klares, verlässliches Feedback?
• Übertrage die Logik in digitale Oberflächen: Ein „Klick“ braucht ein Echo – visuell, textlich oder akustisch.
• Priorisiere Eindeutigkeit vor Raffinesse: Verständlichkeit ist das nachhaltigste Feature.

Ein Werkzeug mit Wirkung: das Arbeitstagebuch

Als „wirklich wichtiges Tool“ nennt Oliver ein Arbeitstagebuch. Der Nutzen klingt schlicht, ist aber enorm: „damit man immer sieht, was man macht … dass man sieht, was man gemacht hat die letzten Tage, nur Wochen oder Monate“. In Zeiten, in denen Arbeit granular, verteilt und asynchron geworden ist, schafft ein Arbeitsjournal eine persönliche Source of Truth.

Worauf es beim Arbeitstagebuch ankommt – abgeleitet aus Trogers Hinweis:

• Regelmäßigkeit: Kurze, tägliche oder wöchentliche Einträge, nicht perfekte Essays.
• Sichtbarkeit: Nutze es, um deinen eigenen Fortschritt zu erkennen – das schützt gegen den Eindruck, nichts „Greifbares“ erledigt zu haben.
• Anschlussfähigkeit: Ein Journal erleichtert Status-Updates, Rückblicke und die Priorisierung für die nächsten Schritte.

Ein Arbeitstagebuch stabilisiert damit drei zentrale Frontend-Dimensionen: Fokus (Was ist heute wichtig?), Verlauf (Was wurde gelernt, gebaut, verworfen?), und Kommunikation (Was kann ich transparent machen?).

Konkrete Leitlinien, die wir aus der Session ableiten

Basierend auf den Aussagen von Oliver Troger lassen sich handfeste Prinzipien für den Frontend-Alltag ableiten – ohne über die Session hinauszugehen:

1. Interessen ernst nehmen: Wenn ein Fachgebiet nicht resoniert (z. B. Rendering Pipelines), darf und sollte man den Kurs justieren.
2. Informationsvisualisierung als Brückendisziplin: Sie verbindet Denken in Strukturen, Daten und Darstellung – ein wertvoller Wegweiser Richtung Frontend.
3. Refactoring fest verankern: „Am neuesten Stand“ zu bleiben ist ein Dienst an den Kundinnen und Kunden, keine interne Nabelschau.
4. Prototyping zielgerichtet nutzen: Teste Usability-Annahmen früh; Prototypen sind Erkenntniswerkzeuge, keine Endprodukte.
5. Aufgaben skalieren: Von kleinen Usability-Fixes bis zu funktionsübergreifenden Features – beide Ebenen verdienen Aufmerksamkeit.
6. Zusammenarbeit suchen: Frontend entscheidet mit, wie Informationen sichtbar werden; das gelingt nur, wenn Teams eng kooperieren.
7. Design-Auge schulen: Neugier auf Gestaltung ist ein Doppelklick auf Nutzbarkeit.
8. Aus der physischen Welt lernen: Ein Toaster mit klarem Feedback ist eine Schule der Signalgebung.
9. Arbeitsjournal führen: Fortschritt sichtbar machen, Kontext halten, Entscheidungen nachvollziehbar dokumentieren.

Wie Refactoring, Prototyping und Journalführung zusammenwirken

Die drei Schwerpunkte, die Oliver setzt, sind kein Zufallstrio. Sie verstärken einander:

• Refactoring schafft die stabile Basis, auf der Prototypen schnell entstehen und validiert werden können.
• Prototyping liefert die Evidenz, die bestimmt, welche Refactorings wirklich nötig sind, um Usability-Ziele zu erreichen.
• Das Arbeitstagebuch dokumentiert beide Zyklen – technische und UX-bezogene Entscheidungen werden nachvollziehbar.

So entsteht ein Kreislauf der Verbesserung, der weniger auf großen „Releases“ als auf stetigem Lernen beruht.

Die Rolle von Teamgrenzen: Warum „Was zeigen wir dem Kunden?“ die entscheidende Frage ist

Oliver betont explizit, dass Frontend-Teams wissen müssen, „was wir dem Kunden anzeigen möchten“. Diese Formulierung verweist auf eine Kernarbeit, die häufig unterschätzt wird: Kuratieren. Nicht alles, was verfügbar ist, gehört in die Sicht der Kundinnen und Kunden.

Um das richtig zu entscheiden, braucht es:

• Gemeinsame Definitionen von Relevanz: Welche Informationen sind entscheidungsrelevant?
• Kohärente Sprache: Welche Begriffe sind für Nutzer selbsterklärend?
• Feedback-Schleifen: Wo ist die Darstellung noch nicht klar genug, wo fehlen (oder stören) Signale?

Das Frontend wird so zum Ort, an dem abstrakte Anforderungen in konkrete, lesbare und bedienbare Flächen übersetzt werden. Olivers Freude an der Teamarbeit signalisiert, dass genau diese Übersetzungsleistung bewusst gepflegt wird.

Usability als Prinzip: Implizites Lernen bewusst machen

„Genau solche Sachen kann man halt implizit auch in seine Arbeit einfließen lassen.“ Dieser Satz über die Beobachtung haptischer Gegenstände ist fast ein Manifest: Usability entsteht nicht erst im Figma-Board oder beim ersten Nutzerinterview, sondern jeden Tag – durch geschulte Wahrnehmung.

Wir empfehlen, diese impliziten Beobachtungen explizit zu machen:

• Notiere im Arbeitstagebuch konkrete Alltagsbeispiele für gutes (und schlechtes) Feedback in physischen Produkten.
• Übersetze jedes Beispiel in eine digitale Entsprechung: Was wäre das UI-Äquivalent?
• Prüfe beim nächsten Prototypen: Wo fehlt das Echo für eine Benutzeraktion? Wo ist es zu leise, zu spät oder mehrdeutig?

So wird das, was Oliver als „implizit einfließen lassen“ benennt, zur systematischen Ressource.

Kleine Änderungen, große Wirkung: Der Wert der „Quick Usability Wins“

Oliver nennt explizit „kleine Änderungen, die einfach die Usability verbessern“. Diese Formulierung verdient Hervorhebung. In vielen Teams schieben sich Großprojekte in den Vordergrund, während Reibungen – zu viele Klicks, unklare Labels, schwache leere Zustände – liegenbleiben. Trogers Perspektive erinnert daran, dass solche „kleinen“ Punkte oft die größte tägliche Wirkung haben.

Pragmatischer Ansatz für Teams:

• Eine kontinuierliche Liste mit „Quick Usability Wins“ pflegen.
• Jede Iteration 1–2 Punkte aus dieser Liste fix einplanen.
• Erfolge im Arbeitstagebuch und in Changelogs sichtbar machen.

Die Summe dieser Maßnahmen zahlt direkt auf Nutzerzufriedenheit und wahrgenommene Produktqualität ein.

Größere Tasks: Funktionsübergreifend denken

Wenn „größere Tasks … ganze Features übergreifend implementiert werden sollen“, wächst die Komplexität. Genau hier zahlt sich die Verbindung aus Refactoring, Prototyping und Teamarbeit aus.

Praktische Leitlinien – kompatibel mit Trogers Aussagen:

• Vor dem Start Prototypen nutzen, um Erwartungen zu klären.
• Während der Umsetzung regelmäßig prüfen, ob die UI die relevanten Informationen tatsächlich sichtbar und verständlich macht.
• Nach der Auslieferung im Journal notieren: Welche Annahmen haben gehalten, welche nicht? Was lernen wir fürs nächste Feature?

So entstehen wiederverwendbare Muster, die die Entwicklung beschleunigen.

Learning durch Abgrenzung: „Nicht meins“ als Motor

Für viele Karrierepfade ist die Erkenntnis „das ist nicht meins“ schmerzhaft. Oliver zeigt, dass sie produktiv sein kann. Der Schritt weg von Rendering Pipelines hin zu Informationsvisualisierung – und weiter ins Mobile Engineering und Frontend – wirkt geradlinig, weil er ehrlich ist. Er knüpft an das an, was ihm liegt: Klarheit, Struktur, Nutzersicht.

Diese Ehrlichkeit nutzt nicht nur dem eigenen Fokus, sondern auch den Teams, mit denen man arbeitet. Wer weiß, was er oder sie nicht will, kann Ressourcen und Energie effektiver investieren.

Zitatgalerie: Die Sätze, die hängen bleiben

Zur Einordnung haben wir die Kernaussagen aus „Oliver Troger, Front End Developer bei smaXtec“ von smaXtec animal care GmbH in Erinnerungssätze verdichtet:

• „Visual Computing ist nicht so meins, vor allem Rendering Pipelines.“ – Interessen ernst nehmen.
• „Refactoring … um den Kunden bestmöglich die Informationen zu liefern.“ – Codepflege als Service am Nutzer.
• „Prototyping … damit wir gewährleisten können, dass der Kunde die beste Usability hat.“ – frühes Testen statt spätes Hoffen.
• „Mit anderen Teams in Kontakt … da wir wissen müssen, was wir dem Kunden anzeigen möchten.“ – Frontend als kuratierte Schnittstelle.
• „Ein gewisses Auge für Design … und die Lust, sich damit zu beschäftigen.“ – Gestaltung ist kein Beiwerk.
• „Wie gibt [der Toaster] mir Feedback?“ – Signalgebung als universelles UX-Prinzip.
• „Ein Arbeitstagebuch … damit man immer sieht, was man macht.“ – Fortschritt sichtbar machen.

Fazit: Ein pragmatischer Kompass für Frontend-Teams

Die DevStory mit Oliver Troger zeigt, wie geradlinig ein Weg wirken kann, wenn man ihn konsequent um die eigenen Stärken baut. Von Medieninformatik und Visual Computing zur Informationsvisualisierung, dann ins Mobile Engineering und schließlich ins Frontend – das ist kein Zickzackkurs, sondern eine Klärung: Gestaltung, Struktur und Nutzbarkeit sind die Achsen, an denen er arbeitet.

Im Alltag übersetzt sich das in drei Arbeitsschwerpunkte – Refactoring, Feature-Entwicklung, Prototyping – sowie eine Grundhaltung, die auf Zusammenarbeit und Nutzerfokus setzt. Dazu kommt ein Werkzeug, das uns besonders überzeugt: das Arbeitstagebuch. Es schafft Überblick über Tage, Wochen und Monate und stützt damit Entscheidungen, Kommunikation und Lernprozesse.

Für Entwicklerinnen und Entwickler, die in ähnlichen Umfeldern arbeiten, ist die Essenz aus „Oliver Troger, Front End Developer bei smaXtec“ (smaXtec animal care GmbH) klar:

• Sei ehrlich zu deinen Interessen und justiere den Kurs, statt gegen die innere Evidenz anzurennen.
• Denke Frontend als Verbindung aus sauberer Technik, kuratierter Information und klarer Rückmeldung.
• Mache Fortschritt sichtbar – es ist die Grundlage für nachhaltige Verbesserung.

Diese drei Punkte sind ein robuster Kompass – und genau der, den Frontend-Teams brauchen, um Nutzerinnen und Nutzern „die bestmöglichen Informationen“ in verständlicher Form zu liefern.

• 

  

  Manuel Frech, Teamlead Hard- & Firmware bei smaXtec

  Teamlead Hard- & Firmware bei smaXtec Manuel Frech spricht im Interview über den Aufbau der Entwicklungsabteilung, welche Technologien dort im Einsatz sind und wie das Recruiting und Onboarding abläuft.

  Jetzt ansehen

• 

  

  Johannes Pesenhofer, Data Scientist bei smaXtec

  Johannes Pesenhofer von smaXtec spricht im Interview darüber, wie er zu seiner aktuellen Arbeit als Data Scientist gekommen ist und was seiner Ansicht nach wichtig für Beginner ist.

  Jetzt ansehen
• 

  

  Matthias Thym, Back End & System Engineer bei smaXtec

  Matthias Thym von smaXtec gibt im Interview Einblicke in seinen Background als Back End & System Engineer, wie seine aktuelle Arbeit abläuft und was für Anfänger in diesem Berufsfeld wichtig ist.

  Jetzt ansehen