Welche Rolle spielt Technologie für dich im Gestaltungsprozess? Inspiriert sie dich, schränkt sie dich ein – oder beides?
Karen: Sie ist oft beides, sowohl Einschränkung als auch Inspiration. Mittlerweile beginnen fast alle Gestaltungsprozesse für mich mit einer Auseinandersetzung mit den Technologien, die im Prozess aufkommen oder die ihn strukturieren. Dort, wo Reibungen auftauchen, wo ich auf Grenzen, sperrige Funktionen und unklare Logiken stoße, geschehen oft die spannendsten Momente und unerwartete Artefakte, und mit ihnen neue Ansätze. Häufig wähle ich bewusst ein Tool mit begrenzten oder sehr spezifischen Möglichkeiten, um in diesem Rahmen die Grenzen auszutesten. Außerdem bringt jede Entscheidung für ein Tool bestimmte ästhetische Optionen mit sich und schließt andere aus. Dinge wie Farben, Formen, Typografie und Effekte sind abhängig von der gewählten Infrastruktur. Eine Publikation, die mit CSS entsteht, folgt anderen Logiken als eine, die in InDesign gestaltet wird.
Technologie kann jedoch auch auf eine andere Weise Gestaltungsansätze inspirieren. Ich interessiere mich in meiner Arbeit sehr für die Materialität digitaler Technologien – ihre physische Beschaffenheit ebenso wie ihre ökonomischen und ökologischen Voraussetzungen. Wo Gestaltung häufig die Aufgabe zugewiesen bekommt, diese Bedingungen zu verstecken, ist es spannend, sie stattdessen auch über visuelle Entscheidungen greifbar und sichtbar zu machen und in die Gestaltung einzuschreiben.
Und schließlich prägen Technologien den Gestaltungsprozess schon viel früher, vor jeder ästhetischen Entscheidung, indem sie Voraussetzung für die Arbeitsweisen innerhalb eines Prozesses schafft. Welche Macht- oder Wissens-Hierarchien gibt eine Technologie vor oder erfordert sie? Kann man ein Werkzeug überhaupt kollektiv verwenden? Welche Abhängigkeiten zu anderen Institutionen oder Personen schafft eine Technologie? Auf diese Weise formt Technologie Beziehungen zwischen den Beteiligten, noch bevor überhaupt gestaltet wird.
Um ein Beispiel zu nennen: Wenn Schreib- und Gestaltungsprozesse getrennte Aufgaben sind und alle Personen spezifische Programme verwenden, die nur sie bedienen können, wird die Zusammenarbeit anders sein als wenn ein Projekt mit einem gemeinsamen Workshop zu einer Open-Source startet, in der nicht nur Inhalte, sondern auch Teile der Gestaltung kollektiv in einem Pad geschrieben werden. In solchen Momenten wird deutlich, dass Technologie mehr umfasst als Software, sondern auch analoge Werkzeuge, Methoden oder kleine Protokolle der Zusammenarbeit einschließt.

War dein Projekt filetree2print ein einmaliges Experiment oder würdest du das weiter erforschen? Wie entstand das Bedürfnis, Adobe den Rücken zu kehren?
Karen: Viele Gestaltungsprozesse bewegen sich ganz selbstverständlich innerhalb der Infrastruktur großer Technologie-Unternehmen, ohne dass deren Rolle hinterfragt wird. An Design-Hochschulen wird oft vermittelt, wie man Tools benutzt, aber selten, warum gerade diese Tools benutzt werden und woher sie kommen. Es gehört zu fast allen Lehrkonzepten, Grundlagen für Adobe Cloud Programme, insbesondere InDesign, zu vermitteln. So erlernen Studierende spezifisches Wissen, welches sie an die kostenpflichtige Software bindet. Gleichzeitig wird wenig darüber gesprochen, wer sich diese Zugänge überhaupt leisten kann und welche Abhängigkeiten daraus entstehen. Der Druck, Adobe Programme zu nutzen, ist auch deshalb groß, weil Adobe mit geschlossenen Dateiformaten arbeitet. Ein derartiges System wird auch walled garden genannt: Es ist in sich geschlossen, und dort erstellte Dateien sind kaum kompatibel oder editierbar mit Software anderer Unternehmen. Eine Zusammenarbeit mit anderen Studierenden ist also ebenso kaum möglich, möchte man kein Abo abschließen. Grundkenntnisse in Adobe Cloud Programmen gehören zum Standard in Ausschreibungen für
Designberufe. Auch wenn es beispielsweise in der Selbstständigkeit nicht vorgeschrieben ist, gibt es den Druck, der Konkurrenz von außen standzuhalten. Dafür braucht es die effizientesten und produktivsten Programme, um mitzuhalten. Gestalter:innen werden also schon im Studium auf diese Bedingungen am Arbeitsmarkt vorbereitet, anstatt sie zu hinterfragen oder alternative Umgangsweisen zu suchen.
Aus Frustration über diese Bedingungen entstand das Projekt filetree2print. Für meinen Bachelorabschluss war ein gedrucktes Portfolio über die bisherigen Studienarbeiten erforderlich. Üblicherweise wird dieses in InDesign erstellt – mit einer Software, deren Kosten sich mit Abschluss des Studiums verdoppeln. Parallel dazu habe ich begonnen zu programmieren und bin dadurch auf Open-Source Projekte gestoßen, die mit offenen Dateiformaten arbeiten und in techno-kritische Communities eingebettet sind. Für filetree2print habe ich dann die Javascript web-to-print Bibliothek 🌐paged.js verwendet, mit welcher sich komplexe Print-Publikationen aus dem Browser generieren lassen.
Die Idee, das Portfolio direkt aus meinem Dateisystem zu generieren, lag der Frage zugrunde: Was passiert, wenn nicht ich entscheide, was sichtbar wird, sondern die Struktur meiner Arbeitsweise? Mit Python habe ich zunächst meine Ordner mit all ihren Unordnungen und kryptischen Dateinamen durchsucht und in eine HTML-Datei geschrieben, welche wiederum mit paged.js ein PDF generiert.
Das Projekt war kein einmaliges Experiment, sondern eher ein Anfang. Die Auseinandersetzung mit Open-Source Tools und mit Formen des Publizierens, die Prozesse sichtbar machen, begleitet meine Arbeit bis heute.

Inwiefern hat Programmieren deinen Blick auf Design verändert? Gibt dir Coding neue Möglichkeiten, Ideen umzusetzen, die sonst nicht machbar wären?
Karen: Mit dem Programmieren hat sich mein Blick auf Design langsam verschoben. Zunächst, weil ich viel mit meinem Bachelorstudium gehadert habe. Ich hatte häufig Angst vor dem weißen Blatt und habe mich im Grafikdesign eher fehl am Platz gefühlt. Programmieren hat mir da einen neuen Zugang ermöglicht, weil ich mich stattdessen an Strukturen, Systemen, Logiken und ihren Fehlern entlang bewegen konnte.Dann hat Programmieren mich auch zu neuen Perspektiven gebracht, die mittlerweile eine viel größere Rolle für mich spielen. Über das Lernen, Verstehen und Nichtverstehen von Technologien habe ich zu techologiebezogener queerfeministischer, antikapitalistischer und dekolonialer Kritik an den bestehenden Verhältnissen gefunden. Und darin lag für mich die Frage, wie Designprozesse diese Kritik aufnehmen können. Wie schon erwähnt, kann es bedeuten, die politische Dimension und Materialität von Technologien sichtbar zu machen: die ausbeuterische Gewinnung von Rohstoffen wie Kobalt oder Coltan im Kongo für die Herstellung von Hardware, oder die umweltschädliche, wasserintensive Kühlung von Datenzentren in Marseille, in welchem der Server steht, der eine Webseite hostet. Es kann auch bedeuten, schon früher im Prozess nach nachhaltigen Hosting-Modellen oder Druckverfahren zu suchen. Und es kann auch bedeuten, sich dagegen auszusprechen, überhaupt eine Webseite aufzubauen, wo es vielleicht gar nicht sinnvoll oder nötig wäre. Die verstärkte Auseinandersetzung mit Technologien führt so nicht immer zu mehr Möglichkeiten, sondern begründet manchmal auch bewusste Einschränkungen.
Beim Erstellen von Webseiten begegnet mir diese Reibung häufig. Mittlerweile lassen sich mit zahlreichen Bibliotheken und Frameworks fast alle denkbaren Effekte umsetzen. Oft erfordert das komplexen Code, Rechenleistung auf den Endgeräten der Besuchenden sowie viel Bandbreite. Häufig muss dafür das Standardverhalten des Browsers deaktiviert werden, oft zum Nachteil von Accessibility. In solchen Fällen versuche ich stattdessen, Lösungen zu finden, die produktiv mit den Bedingungen des Browsers arbeiten, nicht gegen sie. Das geht in eine ähnliche Richtung, wie deine erste Frage zur Inspiration durch (Sebst-)Einschränkung, weil dieser Ausgangspunkt interessante Prozesse anstoßen kann. Dabei bleibt es wichtig, diese Knappheit nicht zu romantisieren. Hinter der selbst gewählten Limitierung steckt die reale Prekarität anderer, die ich als europäische Gestalterin nicht erlebe – und die erst einmal nicht dadurch angefochten wird, dass meine Webseite kleine Bilder hat und von einem  solarbetriebenen Server gehostet wird. [* Dazu bringen Aymeric Mansoux, Brendan Howell, Dušan Barok, Ville-Matias Heikkilä in ihrem Artikel 🌐Permacomputing Aesthetics: Potential and Limits of Constraints in Computational Art, Design and Culture spannende und wichtige Gedanken zur Sprache]

Arbeitest du auch analog – zum Beispiel mit Skizzen oder physischen Materialien? Und wenn ja, welchen Stellenwert hat das im Vergleich zu digitalen Prozessen?
Karen: Auch hier denke ich an die physischen Aspekt digitaler Infrastruktur. Neben Rohstoffen, Hardware und Energieversorgung umfasst das für mich auch die Menschen, die die Verantwortung über ihre Erreichbarkeit und Instandhaltung übernehmen. Als Teil von 🌐Actinomy, einem queerfeministischen Serverkollektiv in Bremen kommen wir regelmäßig zusammen und arbeiten gemeinsam an kollektiver, selbstverwalteter, lokaler Infrastruktur. Gemeinsam fragen wir, was serving im Rahmen affektiver Infrastruktur bedeuten kann, das heißt, Infrastruktur, die die Beziehungen zwischen den Nutzenden und den Strukturen in den Blick nimmt. Physische Treffen sind fester Teil unserer Praxis; zu unseren kleinen Protokollen gehört es, zunächst gemeinsam zu essen: »A feminist server builds on the materiality of software, hardware and the bodies gathered around it« [* Dieser Satz stammt aus dem Feminist Server Manifesto]. Wir programmieren in geteilten Terminal-Sessions, erklären uns Funktionsweisen und Zusammenhänge, vernetzen uns mit anderen Kollektiven und verneinen dabei Ansprüche an Effizienz oder ständige Erreichbarkeit.
Zu unserer Praxis gehören auch Workshops, in denen wir gemeinsam versuchen, digitale Infrastruktur greifbar zu machen. In einem wiederkehrenden Format bauen wir kleine lokale Server, die nur wenige Zentimeter groß sind. Angetrieben von recycelten Batterien lassen sich darauf kleine Webseiten publizieren. Da die Webseiten nur im lokalen Netz des Servers sichtbar werden, erfordern sie Nähe und Vertrauen. Aus unterschiedlichen Materialien entsteht anschließend eine Hülle für den Server. Die Verbindung, die zwischen der Website, dem Server und dieser Verkörperung entsteht, wirft immer wieder spannende Fragen auf.

Welche Vorteile siehst du darin, eigene Tools zu entwickeln? Könnte das auch ein Weg sein, Machtstrukturen im Design zu hinterfragen oder zu verändern?
Karen: Tools sind situiert: Sie sind eingebettet in bestimmte politische und soziale Verhältnisse. Gleichzeitig schaffen sie ihrerseits Voraussetzungen und Anforderungen für ihre Nutzung. Das eigene Entwickeln von Tools bedeutet, meine eigenen Dependencies zu wählen. Dependencies im Rahmen von Programmieren beschreiben die Bibliotheken und Software-Pakete, die ich in meinen Code einbinde und die daher eine Voraussetzung für deren Funktionieren darstellen. Das ermöglicht, eine Praxis zu entwickeln, die auf FLOSS (Free Libre Open Source) Software basiert. Software, deren Quellcode öffentlich zugänglich ist und die von allen frei verwendet, kopiert, verändert und weiterverbreitet werden darf, verneint bestimmte kapitalistische Logiken und hinterfragt so bestehende Strukturen. Auch das Feminist Server Manifesto gibt uns auf den Weg: »chose your own dependencies«. Das meint, nicht nur mit Blick auf Code zu fragen: Auf welche Infrastruktur möchte ich mein Projekt aufbauen? Mit wem arbeite ich zusammen und wie setze ich mich in Beziehung zu meinen Kollaborateur:innen? Wie können wir kollektiv Lernen und Hinterfragen und Arbeitsweisen jenseits der kapitalistischen Konkurrenz ausprobieren oder imaginieren?
Gleichzeitig denke ich, dass der Wirk-Rahmen einer Auseinandersetzung mit Tools sehr begrenzt ist. Das Erproben alternativer Bedingungen in einer kleinen Gruppe oder Community bedeutet, trotzdem mit den Produktionsbedingungen von außen konfrontiert zu sein: Produktionsketten, die den historischen Pfaden der Kolonisierung folgen; wenige dominierende Tech-Unternehmen, die wirtschaftliche Macht innehaben und Staaten, die ihre Bürger:innen überwachen. Ich denke, dass es unabdingbar ist, diese Strukturen zu hinterfragen und zu verstehen, um etwas im Design zu verändern. Und, dass es notwendig ist, sich innerhalb und vor allem außerhalb des Designfeldes zu organisieren und gemeinsam zu fragen, wie eine wirklich transformative Praxis aussehen kann.

Ein Projekt von dir – Insert Title Here – beschäftigt sich mit Website-Buildern. Glaubst du, dass sie grundsätzlich das Problem sind? Oder könnte man Zugänglichkeit zum digitalen Publizieren schaffen, ohne konventionell zu sein?
Karen: Website-Builder vereinfachen vieles, und genau darin liegt sowohl ihre Stärke als auch ihre Problematik. Auf der einen Seite verbergen Website-Builder ihre Technologie und ihre Grenzen. Anstatt eine Zeile Code zu schreiben, kann mit einem Klick das gewünschte Ergebnis erzielt werden. Ersteres würde mir wesentlich mehr über die Funktionsweise einer Webseite verraten. Ein weiterer Klick schaltet die Webseite online, ohne dass ich mir überlegen muss, auf welchem Server ich sie hosten möchte. Ich komme gar nicht dazu, mich zu fragen, was genau ein Server ist, oder eine IP oder ein DNS-Eintrag – elementare Bestandteile digitaler Infrastruktur. Mit dem Einsatz von ⌚künstlicher Intelligenz in Website-Buildern wird dieser Effekt verstärkt, weil sogar die wenigen Klicks wegfallen. Anstelle einer Programmiersprache, die auf verschiedenen Plattformen funktioniert, lerne ich, mit dem spezifischen Tool eines Unternehmens zu arbeiten. Ich begebe mich in eine Abhängigkeit, denn ein Übertragen meiner Webseite zu einem anderen Anbieter ist meist verunmöglicht.
Auch das Resultat wird natürlich über den Prozess bestimmt, weil die Plattformen meist ganz bewusst bestimmte Elemente und Effekte anbieten, welche sich an aktuellen Trends orientieren. Auch auf der Seite der Besuchenden wird die Technologie verschleiert, weil Momente der Reibung – Ladezeiten, Seitenübergänge, Datenerfassung – möglichst versteckt werden. Die verfügbaren Möglichkeiten folgen Kommerzialisierbarkeit, wodurch Templates oft überkomplex sind und sich mit älteren Endgeräten kaum bedienen lassen. Schließlich ist das Hinzufügen eines Shops noch einen Klick oder Prompt entfernt. Mit Vorschlägen für Elemente und Texte werden auch Inhalte und Redaktion an ein unkritisches System ausgelagert.
Es gibt jedoch auch eine andere Seite. Wo selbst programmieren als Gegenentwurf zum Website-Builder dargestellt wird, frage ich mich, was genau das überhaupt umfasst. In dem Text 🌐always already programming schreibt Melanie Hoff darüber, dass jedes Bedienen eines Computers auf die eine oder andere Weise dieselben Systembefehle ausführt, nur mit unterschiedlichen Schnittstellen dazwischen. Das lässt sich auf das Programmieren von Webseiten übertragen: Auch Javascript ist eine sprachbasierte Schnittstelle, die ich zu benutzen lerne – wie ich auch das Bedienen des Interfaces eines Website-Builders lernen muss. Und auch wenn ich den Code einer Webseite selber schreibe, nutze ich im Prozess der Veröffentlichung eine Vielzahl von Interfaces und Services, in der andere Menschen Dinge vereinfacht und versteckt haben, um sie für mich bedienbar zu machen. Die einschüchternde Grenze zum selbst programmieren, die häufig gezogen wird, gibt es in der Form gar nicht.
Im Publizieren steckt ein Moment der Selbstermächtigung. Zu verlangen, dass alles selbst programmiert sein muss, ist eine Form von Gatekeeping. Nicht jede Gruppe, die spannende oder (un)wichtige Inhalte veröffentlichen möchte, hat genug Zeit, erst einmal programmieren zu lernen, oder genug Geld, um eine Person dafür zu bezahlen. Nicht zuletzt können Website-Builder erste Berührungspunkte zum Programmieren sein. Viele starten mit einer WordPress Seite. Dort wird vielleicht erst einmal das Styling eines Buttons selbst angepasst und führt zu den ersten Erfahrungen mit CSS und HTML. Gerade da, wo eine Kritik am weiß-männlich dominierten Tech-Umfeld geübt wird, ist es wichtig, zu sehen, dass Berührungsängste oft auch marginalisierte Gruppen vom Publizieren abhalten.

Welche Ratschläge würdest du anderen Frauen geben, die sich für Coding im Design interessieren, aber vielleicht Berührungsängste haben? Gibt es etwas, das du gern früher gewusst hättest?
Karen: Für mich hat es immer am besten funktioniert, etwas Neues zu lernen, wenn ich mit einem konkreten Projekt angefangen habe, welches mich wirklich interessiert. Und: sich zusammentun und gemeinsam lernen. Ich hätte gern früher gewusst, dass man eine Technologie nicht vollumfänglich verstehen muss – oder kann – um damit zu experimentieren!