Erzählung eines Bauherrn

Ursprung

Ich gravierte, um früh zu Frontend, weil es die Oberfläche, wo Absicht trifft die Realität: Pixel, Latenz, Kopie, und Fluss entscheiden, ob jemand weiter geht oder ruhig verlässt. Das ist ein demütiger Ort, um zu arbeiten – Sie können sich nicht hinter Abstraktionen verstecken, wenn der Benutzer das Ergebnis anstarrt. In den Jahren, in denen Instinkt in ein wiederholbares Objektiv verwandelt wurde: Welchen Job macht dieser Bildschirm, welche Einschränkung ist nicht verhandelbar, und was ist die kleinste Änderung, die wir versenden können, dass messbar verbessert Vertrauen, Klarheit oder Geschwindigkeit? Ich schreibe immer noch UI, aber die Frage hinter der UI ist, welche Skalen über Teams und Produkte.

Evolution

Bei Luma Health verbrachte ich sinnvolle Zeit im Kommunikations-Hub – ein schwerer, hochraffic Workflow, bei dem Performance und Klarheit nicht polieren; sie sind Teil der Pflegekoordination. Das Produkt hatte Schichten von UX Reibungs- und Legacy-Code-Pfade, die jede Änderung fühlen sich riskant, so dass Teams verlangsamen, ohne zu bemerken. Ich half Refactor, dass die Oberfläche so die Erfahrung fühlte leichter für echte Benutzer, und wir nutzten Feedback-Kanäle (einschließlich Benutzerberichte), um zu bestätigen, dass wir das, was Menschen tatsächlich fühlten - nicht nur, was einfach war, auf einem Armaturenbrett zu messen. Parallel behandelte ich die Sicherheit als Teil des Nutzererlebnisses: nutzergenerierter Richtext ist ein klassischer Fußgewehr für XSS, wenn man nur „anders“ sanitiert. Ich half, kritische Exposition zu beseitigen, indem ich Inhalte vor der API-Verarbeitung und wieder an Rendergrenzen sanitierte, und ich trug zu gemeinsamen Komponenten APIs und Design-System-Entscheidungen, so dass andere Quads nicht die gleichen scharfen Kanten wiederfinden mussten.

Produktdenken in der Praxis

Einige meiner hochwertigsten Arbeiten sitzen dort, wo UX, Backend-Verhalten und Operationen aufeinandertreffen – wo eine spröde Integration Tickets, Churn oder eine späte Nacht-Seite wird. Ein Beispiel: Eine SFTP-Broadcast-Pipeline, in der „es funktioniert auf meiner Maschine“ nicht genug für Kunden auf sensiblen Datenflüssen war. Ich habe es neu gestaltet, so dass Teams externe → interne Feldmappings in der UI mit Validierung statt Erraten und Überschwemmung Unterstützung konfiguriert. Misconfiguration Tickets fielen scharf, und wir schützten eine Beziehung, die keine schlampigen Handaus leisten konnte. Bei Sisnet arbeitete ich an einem kuratierten Marktplatz, wo die Inhaltsgeschwindigkeit genauso wichtig war wie die Codequalität. Ich baute ein AdminJS CMS auf Node.js so Marketing und Ops können Kopie, Bild und Styling ohne Engineering für jeden Tweet versenden – wöchentliche Feuerbohrer fiel auf “fast nie”, und das Team konnte sich auf Abonnements, Stripe und Klaviyo und Produkttiefe über Routine-Publishing konzentrieren.

Membrus — Gebäude mit echten Gemeinden

Außerhalb meiner Vollzeit-Rollen habe ich Membrus gegründet: eine Plattform für Kirchen, um Mitgliedschaft, Kommunikation und Operationen in einem kohärenten System statt eines Patchworks von Tabellenkalkulationen, Gruppen-Chats und Ad-hoc-Tools auszuführen. Die Arbeit war nicht “eine weitere CRUD-App hinzugefügt”. Es war zu verstehen, wie Pastoren und Mitarbeiter tatsächlich durch eine Woche bewegen – wer braucht Zugang zu was, was bricht, wenn Daten unkonsistent sind, und wie man admin Workflows, die nicht-technische Menschen besitzen können zu versenden. Ich besaß Produkt und Lieferung über Oberflächen: öffentliche Präsenz, mitgliederorientierte Erfahrungen und interne Werkzeuge, iteriert mit Kirchenführern, die großzügig mit ehrlichem Feedback waren. Das ist die Art von Produkt, das ich bauen möchte: in realen Einschränkungen geerdet, an reale Benutzer versendet, in der Öffentlichkeit verbessert – nicht Slideware.

Nachhaltiges Tempo unter Druck

Bei Shifting arbeitete ich in einem kleinen Team, das einen Ticketing-Marktplatz unter realem Umfang Druck verschiffte – Geschwindigkeit war wichtig, aber auch nicht brennte Menschen aus. Ich fungierte oft als die Person, die wählen musste: Was schneiden wir, was härten wir aus und was weigern wir uns, Kompromisse zu machen? Meine Voreingenommenheit war in Richtung Versand gut, nicht chaotischer Versand: tägliche Entsperrung, konsequente Code-Review so Feedback war vorhersehbar, und kleine DX Verbesserungen, die die nächste Woche einfacher als die letzte. Ich baute auch interne CMS-Stil-Tooling, so dass nicht-technische Teamkollegen Inhalte ohne Engineering zu einem Engpass iterieren konnten. Das Ergebnis war nicht nur „wir lanciert“ – es war ein funktioneller Marktplatz, der in einem nachhaltigen Tempo geliefert wurde, mit einem Kunden, der sich wirklich gut bediente. Dieses Ergebnis ist mir genauso wichtig wie jedes technische Detail.

Diese Website – als Produkt gebaut

Diese Seite ist absichtlich mehr als ein statischer Lebenslauf. Es ist i18n-first, teilt UI über die Monorepo, und das Layout priorisiert lesbare Hierarchie und Abstand so lange Seiten wie diese bleiben angenehm zu lesen. Lucas AI ist Teil der gleichen These: ein Assistent, der in der ersten Person beantwortet, aber nur aus dem hier veröffentlichten strukturierten Kontext – Projekte, Erfahrungen und wie ich an Trade-offs denke – so dass sich die Exploration anstatt generisch geerdet fühlt. Wenn Sie so weit lesen, sehen Sie das Handwerk Argument in Miniatur: Erzählung, Systeme und eine Produktoberfläche, die Tiefe einlädt.

Wie ich baue

  • Starten Sie vom Job-to-be-don des Nutzers, dann entwerfen Sie die kleinste Schleife, die das Risiko reduziert und den Wert frühzeitig beweist.
  • Behandeln Sie Sicherheit, Zugänglichkeit und Leistung als UX – Menschen fühlen sie sogar, wenn sie das zugrunde liegende Problem nicht aufzeigen können.
  • Vorziehen klare Verträge und wiederverwendbare Primitiven über eine einmalige Anpassung; ein Design-System sollte multiplizieren Lieferung, nicht dekorieren.
  • Entscheiden Sie sich bewusst unter Druck: schützen Sie Qualität, ohne das Tempo und die Gesundheit des Teams zu opfern.
  • Treat Tickets, Unterstützung und qualitative Rückmeldung als Produktsignale – und schließen Sie die Schleife, so dass die gleiche Klasse von Problem nicht leise zurückkehrt.