What If We Work Together? Fostering Reflections on Designer Inclusion in Open Source Software Through Speculative Design
Dieser Beitrag nutzt spekulatives Design durch zwei fiktive Gesellschaften, um bei Praktizierenden freier Software eine kritische Reflexion anzuregen, mit dem Ziel, den entwicklerzentrierten Fokus der Community zu hinterfragen und ein inklusiveres Umfeld für Designer zu schaffen.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich Open-Source-Software (OSS) als eine riesige, geschäftige Baustelle vor. Seit Jahrzehnten wird diese Baustelle ausschließlich von Ingenieuren und Architekten geleitet, die besessen davon sind, das Gebäude statisch sicher zu machen, die Wasserleitungen zu verlegen und den Stromfluss zu gewährleisten. Sie sind darin brillant. Doch weil sie sich so sehr auf das „Innere" des Gebäudes konzentrieren, vergessen sie oft, die Wände zu streichen, bequeme Türklinken zu installieren oder sicherzustellen, dass die Räume leicht zu navigieren sind.
Infolgedessen ist das Gebäude unglaublich leistungsfähig, aber wenn Sie kein Ingenieur sind, fühlt sich ein Betreten an wie der Versuch, ein Labyrinth im Dunkeln zu navigieren.
Diese Arbeit fragt: Was wäre, wenn wir die Innenarchitekten auf die Baustelle einladen würden?
Die Forscher stellten fest, dass Designer helfen möchten, sich jedoch nicht willkommen fühlen, von den Tools verwirrt sind und oft hören, ihre Arbeit sei keine „echte" Arbeit. Um dies zu beheben, verfassten die Forscher nicht einfach eine Liste von Regeln. Stattdessen nutzten sie eine Methode namens Spekulatives Design. Stellen Sie sich dies als den Bau von zwei „Was-wäre-wenn"-Zeitmaschinen vor, die dem Bauteam zwei völlig unterschiedliche Zukünfte zeigen, in der Hoffnung, sie zu wecken und dazu zu bringen, anders über ihre heutige Arbeitsweise nachzudenken.
Die zwei „Was-wäre-wenn"-Welten
Die Forscher schufen zwei fiktive Gesellschaften, die als Spiegel unserer aktuellen Realität dienen sollten:
1. Der Schwarm (Husia): Das ultimative Team-Huddle
Stellen Sie sich eine Welt vor, in der alle Teil einer einzigen, glücklichen Familie sind. Es gibt keine „meinen" Designs oder „deinen" Code; alles gehört der Gruppe.
- Wie es funktioniert: Wenn ein neuer Designer eintrifft, zeigt ihm ein freundlicher Roboter-Guide (die „Zentrale Tafel") sofort genau, was zu tun ist, und weist ihm Aufgaben zu, in denen er gut ist. Sie arbeiten in einem High-Tech-Raum, in dem die Wände mit ihnen sprechen und sie an die Bedürfnisse der Nutzer erinnern.
- Die Lehre: In dieser Welt streitet sich niemand darum, wem die Anerkennung gebührt. Der Fokus liegt rein darauf, der Gemeinschaft zu helfen.
- Der Realitätscheck: Die Forscher nutzten dies, um zu zeigen, dass zwar „Anerkennung geben" wichtig ist, das aktuelle System Designer jedoch oft das Gefühl gibt, unsichtbar zu sein. Sie zeigten jedoch auch, dass, wenn man Anerkennung vollständig entfernt, einige Menschen sich fragen könnten: „Warum sollte ich so hart arbeiten?"
2. Die Reputation-Stadt (Reetar): Das Spiel mit hohen Einsätzen
Stellen Sie sich nun eine Welt vor, in der Ihr sozialer Status eine Währung namens „Reputationspunkte" ist. Sie verdienen Punkte durch gute Arbeit und verlieren sie, wenn Sie Fehler machen.
- Wie es funktioniert: In dieser Welt sind Designer unverzichtbar, denn wenn das Produkt schlecht aussieht, verlieren Sie Punkte. Entwickler und Designer müssen eng zusammenarbeiten, denn wenn sie dies nicht tun, sinkt ihr „Punktestand". Das System zwingt sie dazu, miteinander zu sprechen.
- Die Lehre: Diese Welt hebt hervor, dass Designer derzeit unterbewertet werden. In dieser Zukunft ist ihre Arbeit der Schlüssel zum Überleben.
- Der Realitätscheck: Die Forscher zeigten, dass dieses System zwar Respekt erzwingt, aber auch ein gnadenloses Umfeld schafft, in dem sich Menschen möglicherweise mehr darauf konzentrieren, „Punkte zu sammeln", als sich tatsächlich gegenseitig zu helfen.
Was geschah, als sie diese Welten zeigten?
Die Forscher luden 12 Personen ein, die tatsächlich an Open-Source-Projekten arbeiten (7 Designer und 5 Entwickler), um diese beiden Welten zu besuchen. Sie fragten nicht nur: „Gefällt Ihnen das?" Sie fragten: „Wie fühlt sich das für Ihren aktuellen Job an?"
Das Ergebnis war ein Lichtaugenblick für alle. Hier ist, was sie begriffen:
- Der „Open"-Mythos: Alle dachten, Open Source sei bereits für jeden offen. Doch beim Betrachten dieser Welten begriffen sie: „Warte, der Code ist offen, aber die Tools und Prozesse sind hinter einer Mauer aus technischem Fachjargon versteckt, die Designer abschreckt."
- Das Missverständnis: Entwickler erkannten, dass sie oft denken, Designer würden nur „Dinge hübsch machen". Die Szenarien zeigten, dass Design tatsächlich darum geht, Probleme zu lösen, genau wie beim Programmieren.
- Die Anerkennungs-Krise: Designer erkannten, dass sie sich unverstanden fühlen, aber Entwickler erkannten, dass es ohne eine Möglichkeit zu verfolgen, wer was getan hat, schwierig ist, zu wissen, wer ein „Danke" verdient.
Das Fazit: Wie man die Baustelle repariert
Indem sie diese extremen Zukünfte betrachteten, entwickelten die Teilnehmer praktische Ideen, um ihre aktuelle „Baustelle" für Designer besser zu machen:
- Bauen Sie eine bessere Willkommensmatte: Genau wie die „Zentrale Tafel" im Schwarm benötigen Projekte klare, einfache Anleitungen für Designer, damit sie sich im Code nicht verloren fühlen.
- Geben Sie Designer einen Platz am Tisch: Warten Sie nicht, bis das Gebäude fertig ist, um einen Designer zu bitten, die Türen zu reparieren. Lassen Sie sie von Tag eins an beim Planen des Grundrisses helfen.
- Erstellen Sie ein „Design-GitHub": Entwickler haben ein System, um Codeänderungen zu verfolgen. Wir benötigen ein ähnliches System, in dem Designer ihre Zeichnungen speichern, teilen und aktualisieren können, ohne ihre Arbeit zu verlieren.
- Sagen Sie laut „Danke": Wenn ein Designer eine Benutzeroberfläche verbessert, sollte das Projekt dies lautstark verkünden, genau wie sie es tun, wenn ein Entwickler einen Fehler behebt.
Das Fazit
Die Arbeit argumentiert, dass man Menschen nicht einfach sagen kann, sie sollten „netter sein" oder „härter arbeiten". Man muss die Kultur ändern. Indem sie diese imaginären „Was-wäre-wenn"-Geschichten nutzten, halfen die Forscher der Open-Source-Community, ihre eigenen blinden Flecken zu erkennen. Sie begriffen, dass sie, um Software zu entwickeln, die jeder nutzen kann, aufhören müssen, Design als Nachgedanken zu behandeln, und beginnen müssen, es als Kernbestandteil des Teams zu betrachten.
Es ist wie die Erkenntnis, dass ein Haus nicht nur ein Dach und vier Wände ist; es ist ein Zuhause. Und um es zu einem Zuhause zu machen, benötigen Sie sowohl Ingenieure als auch Designer, die von der allerersten Ziegelstein an zusammenarbeiten.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.