00:00:00: Jingle

00:00:11: Feli: Willkommen zurück, ich bin Feli und das ist der Public Interest Podcast.

00:00:13: Joram: Hallo und ich bin Yoram. Wir arbeiten beide beim Prototype Fund und reden in dieser dritten Staffel des Public-Infrast-Podcasts in der dritten Folge über die Menschen hinter Public-Infrast-Tech,

00:00:28: Joram: und spezifisch heute über UX-Design.

00:00:32: Feli: Joram hat gesagt, er hasst es, wenn Software nicht gut gemacht ist.

00:00:36: Feli: Wenn die Funktionen da sind, aber er sie nicht findet und 20 Mal durchs Menü klicken muss,

00:00:40: Feli: dann lässt er das mit der Software.

00:00:42: Joram: Die an sich funktionieren, aber wenn man sie nicht bedienen kann, dann sind sie so gut wie nicht funktionabel für mich.

00:00:47: Joram: Wie ist das für dich? Gibt es manchmal Sachen,

00:00:49: Joram: wo du dich bei Software schon mal durch schlechte Benutzbarkeit davon abgehalten bist, sie zu benutzen?

00:00:55: Joram: Ich habe schon ein paar Sachen, die ich nicht benutzen kann, und schlechte Benutzbarkeit davon abgehalten, sie zu benutzen.

00:01:01: Feli: Also ich komme ja aus einer Generation, wo das eher so war, dass das bei den LehrerInnen passiert ist,

00:01:05: Feli: Und ich glaube, für die würde ich mir wünschen,

00:01:07: Feli: dass Software häufig einfacher zu bedienen ist,

00:01:10: Feli: damit die auch wissen, wie man im Film dann wirklich stoppt und nicht nur auf Pause klickt. Oder das Beste ist ja auch bei YouTube, also wenn man dann das Video zu Ende geguckt hat und dann verstehen Dossierende manchmal nicht, dass sie dann auch dieses Autoplay ausstellen müssen, so zum Beispiel.

00:01:24: Joram: Dann geht's immer weiter.

00:01:26: Feli: Also bitte liebe UX-Designerin, könnt ihr das verbessern, weil es ist echt anstrengend.

00:01:31: Joram: Hast du Snapchat damals verstanden in der Benutzung? Weil du ein Stück... Genau, du bist halt ein Stück jünger als ich und das...

00:01:33: Feli: Ich bin mit dem Handy in der Hand geboren worden quasi.

00:01:38: Joram: Das war nämlich der Punkt, wo ich das erste Mal das Gefühl hatte, dass so eine App mich abgehängt hat. Ja, Snapchat, da bin ich irgendwie nicht darauf klargekommen, das zu bedienen.

00:01:47: Joram: Und später habe ich gelesen, dass es bei Snapchat auch mit Absicht gemacht wurde, dass durch diese erschwerte Benutzbarkeit, die vor allem dadurch funktionierte,

00:01:56: Joram: dass sich dann Schülerinnen das gegenseitig erklärt haben, wie das geht, auf dem Schulhof, man bestimmte Nutzergruppen, ältere wie mich, ausgeschlossen hat,

00:02:04: Joram: weswegen das halt ein attraktiveres Netzwerk eben für jüngere Leute geworden ist.

00:02:07: Joram: Weil dann eben nicht irgendwelche Social Media Marketing Manager, die 35 Jahre alt sind, diese App benutzen können.

00:02:14: Joram: Weil die dann so, was passiert hier eigentlich? Und deswegen, diese ganze Anekdote, glaube ich, dient uns nur dafür, irgendwie klarzumachen, dass UX-Design, nämlich die Gestaltung der Benutzbarkeit von Software,

00:02:26: Joram: einen riesen Einfluss darauf hat, wer die App benutzt und was man damit erreichen kann,

00:02:31: Joram: ob es Spaß macht oder nicht. Wie in meinem Fall, wie oft ich mich darüber ärgere über

00:02:36: Joram: irgendwelche Sachen, wo der Button an der falschen Stelle ist und ich es nicht finde.

00:02:39: Joram: Und deswegen wollten wir da mal drüber sprechen. Und gerade in Open-Source-Software ist das,

00:02:44: Joram: glaube ich, ein wichtiger Faktor, denn das ist was, was immer wieder gesagt wird.

00:02:48: Joram: Dass Open-Source-Software nicht ganz so attraktiv ist in der Benutzbarkeit, also dass sie vielleicht,

00:02:53: Joram: funktional mithalten kann mit kommerzieller Software, aber dass gerade wenn es darum geht, wie sie sich so anfühlt und wie sie aussieht, nicht auf dem gleichen Level stattfindet wie,

00:03:01: Joram: bestimmte kommerzielle Produkte. Und da habe ich eine Studie gefunden, die Open-Source-Survey, die hat GitHub gemacht in 2017 und da haben die Leute gefragt, welche Qualitäten von Open-Source-

00:03:12: Joram: Software denen besonders wichtig sind und da war User Experience, also die Erfahrung bei der Benutzung die drittwichtigste Qualität hinter Stabilität und Sicherheit, die man wahrscheinlich erwarten würde, wenn man fragt, so was ist dir wichtig an Open Source, dass du sagst,

00:03:25: Joram: ja, sie soll stabil funktionieren und sicher sein. Und User Experience ist laut dieser Studie sogar wichtiger als die Kosten. Also, dass Open Source Software meistens kostenlos ist, ist weniger wichtig, als dass Open Source Software sich gut bedienen lässt oder auch wichtiger als als Kompatibilität und Transparenz, die direkt danach genannt worden sind.

00:03:45: Feli: Ja, das ist interessant. Ich hätte, glaube ich, genauso abgestimmt. Cool. Du hast dann mit Eileen gesprochen, oder?

00:03:51: Joram: Genau, ich habe mir eine Expertin gesucht, Eileen Wagner. Und Eileen Wagner war selber mal beim Prototype Fund, hat dann später auch eine Förderung erhalten vom Prototype Fund für ein Projekt. Da reden wir auch so ein bisschen drüber in dem Interview.

00:04:05: Joram: Die App heißt Fullscreen und sie hat zusammengearbeitet dann mit dem Prototype Fund als UX-Coach. Sie ist nämlich UX-Designerin und hat einen Fokus auf human-centered Design,

00:04:15: Joram: und auch auf Local First. Und was genau Local First ist, das habe ich mit ihr im Interview gesprochen. Meine erste Frage an sie war aber, was bedeutet für dich eigentlich gutes User Experience Design bei Software Projekt.

00:04:28: Eileen: Zunächst mal die Software muss nützlich sein. Und dann gute UX bedeutet für mich auch, die Software wird gut erklärt. Also ist auf den ersten Blick klar, was sie macht und warum das wichtig ist.

00:04:39: Eileen: Und dann natürlich der eigentliche Gebrauch, also der Prozess der Nutzung, der soll reibungslos sein.

00:04:45: Eileen: Jeder Schritt wurde bedacht. Ich habe alle Informationen, die ich brauche, zu jedem Zeitpunkt. Und ich habe auch die volle Kontrolle, also eine gewisse Entscheidungsfreiheit auch in der Nutzung.

00:04:55: Eileen: Ich glaube, die Software macht genau das, was sie verspricht und auch nicht mehr.

00:04:59: Eileen: Das ist auch immer so.

00:05:00: Eileen: Man denkt immer, das sollte eigentlich selbstverständlich sein, ist es aber nicht.

00:05:05: Eileen: Aber tatsächlich, das Versprechen soll auch gehalten werden.

00:05:10: Eileen: Und was das Design bzw. die Ästhetik angeht, ich glaube, das ist für mich so ein bisschen

00:05:14: Eileen: Sahnehäubchen.

00:05:15: Eileen: Natürlich, wenn es schon ausschaut, ist es auch nicht verkehrt, aber das ist erstmal,

00:05:20: Eileen: nicht unbedingt das Wichtigste für mich in der UX.

00:05:23: Joram: Hat das UX-Design einen besonderen Stellenwert in Public Interest Tech oder ist es vergleichbar mit anderer Software auch?

00:05:29: Eileen: Also ich denke, es ist vergleichbar mit anderer Software. Also es ist genau derselbe Stellenwert wie UX in anderen Technologien.

00:05:37: Eileen: Ohne gute UX ist auch die beste Technologie nicht nutzbar

00:05:40: Eileen: und wird somit nicht genutzt.

00:05:41: Eileen: Das heißt, wenn wir alle wollen, dass auch Public Interest Tech genutzt wird,

00:05:45: Eileen: dann sollten wir auch gute UX bereitstellen.

00:05:48: Eileen: So sehe ich das jedenfalls.

00:05:50: Joram: Es ist ja ein häufiger Vorwurf, also Open Source Software wird immer wieder vorgeworfen,

00:05:54: Joram: dass es nicht so hübsch anzusehen sei, aber vor allem auch nicht so hübsch zu bedienen

00:05:58: Joram: sei, wie jetzt proprietäre Software oder kommerzielle Software. Wie siehst du das?

00:06:04: Joram: Findest du, das ist ein gerechtfertigter Vorwurf?

00:06:07: Eileen: Ja, also ich glaube, das stimmt leider. Also es ist tatsächlich so, zumindest wenn man sich anschaut, wie viele Menschen in Open

00:06:14: Eileen: die nur Entwicklung machen und kein Design, dann ist es tatsächlich so.

00:06:19: Eileen: Beziehungsweise Menschen, die gezwungen werden, Design zu machen,

00:06:22: Eileen: obwohl sie das gar nicht machen wollen. Aber das ist auch gar nicht so verkehrt im Sinne von, wenn wir uns anschauen,

00:06:31: Eileen: warum kommerzielle UX oft besser ist, ist es ja tatsächlich nicht nur,

00:06:37: Eileen: weil kommerzielle UX, weil die Leute irgendwie da besser sind oder so,

00:06:42: Eileen: sondern einfach nur, weil die ein Business Model haben, wo Nutzerzahlen eine Rolle spielen.

00:06:46: Eileen: Also je mehr Nutzerinnen ein Produkt hat, desto mehr verdient diese kommerzielle Software.

00:06:53: Eileen: Und das ist ja meistens in Public Interest Technologies nicht der Fall.

00:06:57: Eileen: Und vielleicht ist es auch gut so, dass wir auch nicht immer auf Nutzerzahlen gucken.

00:07:02: Eileen: Ich denke manchmal so an ein typisches Beispiel, deutsche Post oder so.

00:07:06: Eileen: Wir wollen ja alle Bereiche, alle Gebiete beliefern.

00:07:10: Eileen: Das heißt nicht, dass je mehr Leute die Deutsche Post nutzen, desto besser oder die Deutsche Post,

00:07:17: Eileen: sondern tatsächlich wollen wir, dass eben allen Menschen das als Dienstleistung, ja.

00:07:23: Eileen: Einfach angeboten wird. Und insofern sehe ich das so, dass Public Interest Tech tatsächlich

00:07:30: Eileen: nicht unbedingt an Nutzerzahlen gekoppelt werden sollte, aber das so ein bisschen zumindest erklärt,

00:07:36: Eileen: warum man im kommerziellen Bereich bessere UX findet. Und dann denke ich, es ist auch einfach ein kultureller Unterschied.

00:07:43: Eileen: Also Public Interest hat einfach oft nicht so viele Product Menschen

00:07:47: Eileen: wie in der kommerziellen Software. Und das erklärt auch so ein bisschen,

00:07:52: Eileen: warum diese Fragestellungen überhaupt keine Rolle spielen.

00:07:54: Eileen: Ich weiß nicht, ob das jetzt zu ausgeartet ist, aber das ist so ein bisschen meine Sicht der Dinge. Ich glaube, das hat gute Gründe, warum auch die UX nicht so gut ist.

00:08:02: Joram: Aber um jetzt konkret auf deine Arbeit zu kommen, du schreibst auf deiner Website, dass du Local First UX Design anbietest. Was bedeutet denn das?

00:08:11: Eileen: Ja, das ist, das ist mein neues Lieblingsthema. Also stopp mich, wenn ich so viel erzähle. Aber Local First. Ja, es geht um Software, die sowohl online als auch offline funktionieren

00:08:24: Eileen: soll. Das heißt Local First, aber Remote Second. Also heißt nicht Local Only. Das funktioniert.

00:08:31: Eileen: Mit neuen Datenstandards, den sogenannten CRDTs, die erlauben es, ich sag mal jetzt,

00:08:37: Eileen: einfach Änderungen asynchron zusammenzuführen. Und das ist besonders wichtig für flexible

00:08:44: Eileen: Teamarbeit, denn momentan nutzen wir sehr viele Tools, ich denke so an Google, Nextcloud,

00:08:51: Eileen: Notions, Slack, also alles, was man so für Produktivität braucht, die irgendwo auf einer,

00:08:57: Eileen: Cloud sind, meistens in dieser AWS-Sinfrastruktur. Das heißt, ich muss eigentlich immer online

00:09:02: Eileen: sein, um arbeiten zu können. Aber es gibt ja eben auch gute Gründe dort aufzusteigen.

00:09:07: Eileen: Für mich sind die Gründe dreierlei. Also erstens wollen wir nicht mal online sein

00:09:13: Eileen: oder können das gar nicht. Das ist manchmal der Fall, wenn wir auf Sicherheitsgründen

00:09:18: Eileen: zum Beispiel offline sein müssen oder wir haben keine gute Verbindung, wir sitzen im Zug oder,

00:09:23: Eileen: wir arbeiten in einem Bereich, der eben schlechte Konnektivität hat. Das ist in vielen Bereichen,

00:09:31: Eileen: vielen Geografien der Welt auch in der Fall. Zweitens wollen wir vielleicht nicht alle unsere

00:09:37: Eileen: Daten auf Amazon, also an Amazon abgeben und dort speichern. Das ist so ein bisschen der Punkt,

00:09:43: Eileen: Datensouveränität. Wir wollen eigentlich oder ich möchte zumindest Kontrolle und Verfügung über

00:09:49: Eileen: meine eigenen Daten haben und diese zentralisierte Infrastruktur ist da eben nicht aus politischen

00:09:56: Eileen: Gründen auch schon keine gute Lösung, finde ich. Und drittens einfach nur ganz banal gesagt.

00:10:04: Eileen: Diese Infrastruktur ist auch einfach langsam. Ich weiß nicht, ich gehöre noch so ein bisschen zu der Generation der Millennials, die zuerst Sachen lokal auf dem Rechner gemacht haben. Also die

00:10:15: Eileen: erstmal Dokumentenverarbeitung oder Excel-Sheets oder Bildbearbeitung, war alles erstmal lokal,

00:10:24: Eileen: ging total schnell und wenn ich es teilen wollte, habe ich es mit anderen Leuten dann geteilt. Aber

00:10:29: Eileen: wenn alles, wenn die ganze Bearbeitung auf einer Cloud stattfinden muss, auch wenn ich mit hier 5G,

00:10:35: Eileen: rumrenne, ist es immer noch nicht so performant wie einfach Sachen lokal auf dem Rechner zu machen.

00:10:42: Eileen: Und das will eben diese Local First Infrastruktur ändern. Dass wir sagen, nein, die Dateien und,

00:10:49: Eileen: die Bearbeitung dieser Dateien passiert immer noch lokal, aber wir wollen trotzdem

00:10:55: Eileen: Synchronisierungsmöglichkeiten haben, dass Sachen geschmeidig zusammen, realtime

00:11:00: Eileen: zusammengeführt werden können. Und das ist eben total spannend für mich, dieses neue Paradigma.

00:11:06: Eileen: Und was ich daran mache, zu deiner Frage, Local First UX heißt, ja, da sind einfach sehr viele

00:11:14: Eileen: UX-Fragen noch offen, wenn ich jetzt diese Infrastruktur habe. Wie zeige ich für Zögertänderungen,

00:11:19: Eileen: Änderungen an. Wie werden syntaktische oder auch semantische Konflikte gelöst, wenn ich eine

00:11:27: Eileen: Datei habe, die automatisch mit anderen Dateien synchronisiert wird. Was bedeutet das? Das ist

00:11:32: Eileen: alles noch total offen. Ich arbeite eben an ersten Lösungsansätzen. Das ist so die Zusammenfassung

00:11:39: Eileen: von Local First UX.

00:11:42: Joram: Das ist ja glaube ich auch so ein bisschen widergespiegelt in dem Projekt Fullscreen, an dem du mitgearbeitet hast. Das ist ja auch ein Projekt, das gefördert wurde vom Prototype Fund. Worum geht es denn da? Das ist ja dann, glaube ich, eine konkrete Anwendung, die diesen Local-First-Ansatz dann in die Tat umsetzt.

00:11:57: Eileen: Ja, genau. Also dort haben wir eine Whiteboard-App gebaut, die eben local first sein soll. Das heißt, man stellt sich vor, man hat so eine Whiteboard-App wie Mirol, kennen vielleicht viele.

00:12:07: Eileen: Das ist so eine, man hat so ein Infinite Canvas und kann Sticky Notes draufstellen und mit anderen zusammenarbeiten.

00:12:13: Eileen: Das ist immer sehr hilfreich in so Team-Meetings und so weiter, wenn man nicht gerade das X-Dead Google Doc irgendwie öffnen möchte,

00:12:21: Eileen: kann man eben alles ein bisschen grafischer, visueller gestalten. Aber diese App funktioniert eben auch im ICE.

00:12:27: Eileen: Also man kann sozusagen offline auch Sachen bearbeiten und wenn man wieder Internet hat,

00:12:33: Eileen: werden Änderungen einfach zusammengeflickt. Genau, und das hat ganz gut geklappt.

00:12:38: Eileen: Das war so ein bisschen prototypisch, haben wir eben ausprobiert.

00:12:40: Eileen: War ein sogenanntes Proof of Concept.

00:12:44: Eileen: Wir haben zwei Libraries genutzt.

00:12:46: Eileen: Einmal diese Whiteboarding Library TLDRAW.

00:12:50: Eileen: Das ist ein sehr cooles Projekt. Und das andere nennt sich YJS, wird auch hier in Berlin entwickelt. CRDT, wahnsinnig cool.

00:13:01: Eileen: Und wir haben eben diese zwei Sachen zusammengeführt und haben daraus eine App gemacht und ein

00:13:07: Eileen: bisschen UX probiert. Das war ganz cool.

00:13:10: Joram: Ja, das würde mich interessieren. Was ist denn die UX-Arbeit, die ihr da dran gemacht habt?

00:13:15: Eileen: Genau, also für uns war die wichtige Frage, also erstmal, wie sieht das aus? Weil wir

00:13:20: Eileen: wollten eigentlich schon Webtechnologien nutzen und wusste nicht genau, ob das eine Webapp,

00:13:26: Eileen: allein sein sollte oder doch eine Native App.

00:13:29: Eileen: Also die erste Fragestellung war eben, wie ist das Verständnis von Local First?

00:13:34: Eileen: Und das andere war, ja, wie genau würden wir diesen Flow nochmal, also wie erklären

00:13:40: Eileen: wir, dass Sachen lokal synchronisiert werden?

00:13:44: Eileen: Die Lösung war, also die UX-Lösung für uns war, tatsächlich ein eigenes Fullscreen-Dateienformat,

00:13:51: Eileen: zu entwickeln. Also die Datei.Fullscreen haben wir sozusagen dann immer.

00:13:58: Eileen: Man arbeitet im Browser und wenn man eine Board eben speichern möchte, kann man die

00:14:02: Eileen: Datei einfach runterladen.

00:14:04: Eileen: Diese Datei kann man dann in einer Native-App wieder öffnen, weil wir haben dann, das ist

00:14:09: Eileen: auch so ein bisschen, das haben wir durch Tasten herausgefunden, dass tatsächlich die,

00:14:13: Eileen: nicht unbedingt verstehen, dass etwas lokal ist, es sei denn, man öffnet das in einer Native App.

00:14:20: Eileen: Im Browser irgendwas lokal zu haben, das verstehen die meisten Leute jetzt zu diesem Zeitpunkt noch,

00:14:25: Eileen: nicht. Das heißt, wir haben eine Native App noch gebaut und dort konnte man eben diese

00:14:29: Eileen: Datei öffnen und dann stellen wir die Frage, wird diese Datei jetzt weiter synchronisiert oder,

00:14:35: Eileen: soll sie als Kopie geöffnet werden? Das heißt, zu dem Zeitpunkt kann man dann sich entscheiden,

00:14:41: Eileen: okay, das ist eine Teamarbeit, die ich weiter hier in der native App führen möchte oder ich möchte

00:14:46: Eileen: eigentlich nur sozusagen diese Board ACV'en und das weiter öffnen für mich selbst. Und diesen

00:14:51: Eileen: Flow, also diese UX, das haben wir so entwickelt und ich kann mir gut vorstellen, dass eben andere

00:14:56: Eileen: ähnliche LocoFrist Anwendungen sowas auch einsetzen können. Also von Dokumentenverarbeitung,

00:15:02: Eileen: Exaust Sheets, Bildbearbeitung, was habe ich gerade noch gesagt. Also typische Sachen,

00:15:06: Eileen: die man im Team machen möchte, könnte man eben auch so mit Dateienformaten lösen.

00:15:12: Joram: Funktioniert das dann über einen zentralen Server, der dieses Handoff zwischen den verschiedenen Clients macht oder ist das dann auch noch so quasi peer-to-peer direkt zwischen den verschiedenen NutzerInnen.

00:15:23: Eileen: Ja, momentan ist es so, wir haben einen Relay-Server, das heißt, diese Infrastruktur wird noch weiter existieren. Das kann man sich auch so vorstellen, also optional könnte man auch eine Kopie drauf

00:15:35: Eileen: speichern, dass man sagt, okay, die Information ist so wichtig, dass wir unbedingt noch eine,

00:15:40: Eileen: Kopie haben wollen und nicht, dass wenn Leute, keine Ahnung, alle ihren Rechner verlieren, dass da die Dateien sozusagen verschwunden sind.

00:15:47: Eileen: Das heißt, das könnte man machen, aber dieser Relay-Server, den haben wir jetzt aufgesetzt

00:15:52: Eileen: über Fullscreen, aber den könnte man natürlich auch noch federal machen. Also man könnte überlegen,

00:15:58: Eileen: zum Beispiel, wenn Leute sowieso ein Teamserver irgendwo aufsetzen, dass sie dort darüber auch

00:16:03: Eileen: die Synchronisation machen. Aber theoretisch müsste dieser Server einfach nichts speichern.

00:16:08: Eileen: Das ist schon mal total klasse.

00:16:10: Joram: Gibt es irgendwelche Werkzeuge oder Vorgehensweisen, die eure Arbeit besonders gemacht haben oder die du vor allem empfehlen kannst, wenn jetzt andere an ähnlichen Projekten arbeiten, wie ihr diese Fragestellung gelöst habt, methodisch?

00:16:26: Eileen: Wir haben den ganzen Prozess mit einem Design-Sprint begonnen.

00:16:31: Eileen: Also wir haben das ganze Projekt, Prototype vom Projekt wirklich, erste Woche war Design-Sprint.

00:16:36: Eileen: Design Sprint. Das heißt, wir haben die UX entworfen für diesen Flow und sofort mit

00:16:42: Eileen: Programmen getestet. Das hat einfach wahnsinnig viel Zeit gespart und das würde ich wirklich,

00:16:46: Eileen: jedem empfehlen. Also wirklich ganz kurz anfangen mit Problemdefinition und erste Ideen skizzieren,

00:16:55: Eileen: Prototypen bauen und dann das einfach mit Menschen testen. Und wenn ich sage Prototypen

00:16:59: Eileen: bauen, dann meine ich Papier und Stift nutzen. Also wirklich malen und die Interfaces sozusagen

00:17:05: Eileen: so skizzenhaft wie möglich zu gestalten und zu testen. Und das war wirklich, das waren intensive

00:17:14: Eileen: Tage, so vier, fünf Tage haben wir dafür gebraucht. Aber das hat uns so wahnsinnig viel Zeit gespart.

00:17:20: Eileen: Ich glaube, das würde ich wirklich jedem empfehlen.

00:17:23: Joram: Und habt ihr das über eigenes Wissen gemacht oder habt ihr euch da externe Hilfe geholt?

00:17:27: Eileen: Das haben wir tatsächlich über eigenes Wissen gemacht, weil ich mache das ja auch mit anderen

00:17:31: Eileen: Projekten. Von daher wusste ich so ungefähr, wie man so einen Designsprint organisiert. Und wir

00:17:39: Eileen: hatten auch gute Kontakte. Wir hatten ein paar, wir haben versucht aus unterschiedlichen Bereichen

00:17:44: Eileen: die Probanden auch einzuladen. Und das ging dann recht gut. Ja, aber ich würde auch empfehlen,

00:17:51: Eileen: so externe Hilfe rein zu holen. Ist natürlich immer schön, so einen Facilitator zu haben oder so.

00:17:56: Eileen: Aber ja, den Luxus hatten wir nicht.

00:17:59: Joram: Mich würde interessieren die Probanden, die du schon gerade angesprochen hast, also die Menschen, die das getestet haben. Wie läuft denn so was ab, wenn man seine Anwendung testen möchte? Sei es jetzt ein Prototyp auf Papier oder später, wenn man irgendwie so eine,

00:18:13: Joram: 0.1 Version hat. Wie Wie testet man das mit Menschen?

00:18:18: Eileen: Ja, also tatsächlich, das erste, was man merkt, ist, die Menschen testen wahnsinnig gern Software. Man muss nicht mal einen Kuchen anbieten. Also die kommen tatsächlich zum Testen, wenn man sagt, hey, ich hab da was, kannst du mir einfach Feedback geben. Das,

00:18:31: Eileen: machen wahnsinnig viele Menschen gerne. Und was ich einfach immer mache, ist, ich male grob skizzenhaft die wichtigsten Interaktionen immer auf. Also in unserem Fall zum Beispiel,

00:18:46: Eileen: Download-Screen. Also ich bin in einem Browser und ich sehe diese Software und hier gibt es ein,

00:18:54: Eileen: Button, klicke hier, um diese Board zu speichern. Irgendwie sowas. Also jedenfalls einen wichtigen

00:19:01: Eileen: Schlüsselmoment, den ich testen möchte. So und dann lade ich die Menschen ein und ich zeige ihnen

00:19:07: Eileen: das einfach und ich sage so ein bisschen, ich zeige erstmal, wie es geht. Hier, wenn du auch

00:19:11: Eileen: Auch mit einem Finger auf diese Fläche hier gehst,

00:19:14: Eileen: ist es ein Klick. Dann zeig ich dir, wie diese Klicks,

00:19:18: Eileen: wie diese Papiere zueinander stehen.

00:19:20: Eileen: Und ich bin so ein bisschen in Software daneben.

00:19:23: Eileen: Mehr sag ich auch nicht. Ich frage tatsächlich wirklich nur Sachen wie,

00:19:28: Eileen: was glaubst du, was das hier ist?

00:19:30: Eileen: Was würdest du als Nächstes tun?

00:19:33: Eileen: Warum hast du jetzt hier drauf geklickt?

00:19:34: Eileen: Das sind so Fragen wirklich so, ja, denk einfach laut nach.

00:19:39: Eileen: Das sind nicht unbedingt Sachen, sagen würde, wahnsinnig viel erklären oder spezifische Fragen stellen, sondern einfach

00:19:46: Eileen: Leute machen lassen und dabei gut beobachten, was funktioniert und was nicht funktioniert und,

00:19:51: Eileen: einfach mal offene Fragen stellen. Das ist eigentlich die Methode, die ist jetzt nicht

00:19:57: Eileen: wahnsinnig speziell, da muss man auch nicht irgendwie Human Centered Design studiert haben

00:20:03: Eileen: oder so, sondern das können eigentlich die meisten Leute auch so machen, einfach mal so ein paar,

00:20:08: Eileen: Papierzettel aufmalen und vor Leuten hinlegen.

00:20:13: Eileen: Ja, das ist eine gute Frage. Die meisten Projekte haben eine ganz grobe Vorstellung von Zielgruppen.

00:20:13: Joram: Und wie entscheidest du, welche Menschen du dazu einlädst?

00:20:24: Eileen: Das heißt, bin ich vor allem im akademischen Kontext unterwegs, möchte ich es Patientinnen

00:20:32: Eileen: anbieten, möchte ich, ne, also da hat man schon ein bisschen mehr Hintergrund und kann dort auch

00:20:38: Eileen: spezifischer Fragen. Es hat auch ein bisschen damit zu tun, welche Art von Feedback man haben möchte,

00:20:45: Eileen: weil sehr oft ja die Fragestellungen einfach sind, finden Leute diesen Button. Also übersehen sie

00:20:52: Eileen: hier diesen Button oder verstehen sie das hier gerade nicht. Und da würde ich einfach mal gucken,

00:21:00: Eileen: also wenn es wirklich nur um Interface-Feedback geht, ist es eigentlich egal, kann ich meinen,

00:21:06: Eileen: WGE-Partner fragen oder wenn ich aber sehr spezifischen Kontext brauche, also verstehen,

00:21:14: Eileen: wie gesagt, woran denke ich gerade? Patienten in Daten. Also wenn ich hier Patient bin,

00:21:21: Eileen: was für Hintergrundwissen muss sowieso schon da sein? Sind diese, möchte ich testen,

00:21:26: Eileen: ob diese Begriffe die richtigen Begriffe sind und so weiter? Es hängt so ein bisschen

00:21:30: Eileen: noch von der Art der Fragestellung.

00:21:34: Joram: Und gab es da irgendwelche überraschenden Erkenntnisse in dem Testing, die du quasi gedacht hast, ach, das ist doch ganz klar und dann hat das jemand getestet und es war überhaupt nicht klar.

00:21:43: Eileen: Ja, also für mich war das absolut der Moment, wo ich gemerkt habe, Local und Browser kommen einfach nicht zusammen, in keiner Form.

00:21:54: Eileen: Man kann den Leuten noch so lange erklären, so nein, nein, das sind deine lokalen Dateien, die in diesem Browser funktionieren.

00:22:00: Eileen: Und alle sagen so, hä, nee, Browser ist Internet. Und ich glaube, das dauert noch sehr, sehr lange, bis sich das ändern wird.

00:22:07: Joram: Wie kommen denn deine Erfahrungen nach UX-DesignerInnen und Public Interest Tech EntwicklerInnen

00:22:12: Joram: zusammen.

00:22:13: Eileen: Ja, selten. Also ich glaube, das ist tatsächlich ein ungelöstes Problem.

00:22:19: Eileen: Es gibt so diverse Initiativen. Ich bin zum Beispiel Teil der Open Source Design Community.

00:22:25: Eileen: Da versuchen Menschen so ein bisschen systematischer,

00:22:28: Eileen: diese zwei Gruppen zusammenzubringen. Aber tatsächlich ist es sehr schwer.

00:22:33: Eileen: Also Designerinnen, die dann an Türen klopfen und sagen, hey, ich möchte hier was machen,

00:22:40: Eileen: die stoßen meistens auf so einfach Verwirrung.

00:22:43: Eileen: Also wie UX, was wollen wir machen?

00:22:46: Eileen: Also da ist meistens nicht mal eine Struktur vorhanden, wo man reinarbeiten kann, weil

00:22:52: Eileen: es eben sehr, sehr Entwicklerinnen getrieben ist.

00:22:56: Eileen: Aber ich glaube, diese Public-Tech-Projekte, die eben ein bisschen mehr Product-Mindset

00:23:02: Eileen: haben, die werden halt auch schnell versuchen, UX-Menschen reinzubringen.

00:23:07: Eileen: Ich glaube, das war eher die vielversprechendere Art, sozusagen die Designerin reinzubringen.

00:23:15: Eileen: Das war besser immer in meiner Erfahrung.

00:23:19: Joram: Also ich möchte jetzt quasi nicht Schuld zuschieben, aber auf welcher Seite hapert es da mehr? Ich hab mit ein paar UX-DesignerInnen im Vorfeld mal gesprochen und gefragt, ob die sich schon mal mit Open-Source-Technologien,

00:23:31: Joram: auseinandergesetzt haben, und viele von denen haben gesagt,

00:23:34: Joram: ja, nee, nicht wirklich. Und gleichzeitig weiß ich halt eben auch aus der EntwicklerInnen-Community, dass dort halt Designgedanken oft nicht die ersten sind, die so fallen.

00:23:45: Joram: Wo würdest du sagen, wo lohnt es sich mehr, so ein bisschen mehr Education zu machen, EntwicklerInnen zu überzeugen, dass man frühzeitig

00:23:53: Joram: sich DesignerInnen mit reinholt oder DesignerInnen zu überzeugen, dass es vielleicht lohnenswert

00:23:57: Joram: ist, sich Open Source Technologien mal anzuschauen und da vielleicht mitzuarbeiten und Teil

00:24:03: Joram: von Projekten zu werden.

00:24:04: Eileen: Also ich glaube beides. Ich glaube, man kann nicht immer nur das eine machen, weil so sehr wir wollen, dass wir einfach irgendwo einen Online-Course anbieten und sagen, hey, so funktioniert Design, Entwicklerinnen, so könnt ihr Designerinnen mit reinbringen usw.

00:24:21: Eileen: So sieht der Prozess aus. Ich glaube, da ist einfach auch noch viel mehr Arbeit, da wird viel mehr Arbeit benötigt, um überhaupt Designerinnen reinbringen zu können.

00:24:31: Eileen: Ich glaube, das liegt nicht nur am Mindset, am Verständnis von Design, sondern auch sehr

00:24:37: Eileen: viel an den inherenten Strukturen. Also es gibt ja oft in Open Source auch gar nicht so viel Projektmanagement und auch gar,

00:24:45: Eileen: nicht so viel Prozesse und Governance.

00:24:49: Eileen: Und dort jetzt wahnsinnig viele Designerinnen auf einmal reinzubringen, das bringt ehrlich,

00:24:54: Eileen: gesagt wenig. Und auf der anderen Seite finde ich auch, sicherlich muss man Open Source Tools auch,

00:25:01: Eileen: im Designbereich mehr bewerben, das ist sicherlich der Fall.

00:25:04: Eileen: Aber ich glaube auch, wie sollte man so da rankommen, ne?

00:25:07: Eileen: Open Source, gerade so Public Interest Tech, sehr viel davon ist so von Entwicklerinnen

00:25:12: Eileen: für Entwicklerinnen gemacht.

00:25:15: Eileen: Und man hat eben auch nicht unbedingt so den Kontext, dass man so sofort da in Berührung,

00:25:23: Eileen: kommen würde.

00:25:23: Eileen: Wobei, ich muss sagen, eines meiner Lieblingsgeschichten, Anekdoten, ist die Geschichte von Muscore.

00:25:32: Eileen: Das ist eine Open Source Musikeditiersoftware und da hat einfach ein UX-Designer, der auch

00:25:38: Eileen: selber sehr gerne Musik schreibt und Musiksoftware reviewed, hat einfach so ein YouTube-Channel

00:25:46: Eileen: langjährig gemacht und irgendwann hat der Muscore reviewed.

00:25:50: Eileen: Und der YouTube-Channel heißt Tante Cruel, kann ich sehr empfehlen, ist auch sehr wahnsinnig

00:25:55: Eileen: entertaining. Und die Review, also die tatsächlich dieses einfach UX-Feedback geben von MuseScore hat,

00:26:06: Eileen: dazu geführt, dass MuseScore eben ganz offen zurückgeschrieben hat und gesagt hat, hey,

00:26:10: Eileen: ja, das sind total coole Sachen, willst du nicht mal an MuseScore arbeiten?

00:26:13: Eileen: Und siehe da, zwei Jahre später ist Tantric Ruhl Head of Design von Newscore und von Audacity.

00:26:22: Eileen: Also er hat sozusagen tatsächlich einfach nur dadurch, dass er offenes Feedback gegeben hat,

00:26:28: Eileen: sofort auch einen Open Source Anschluss gefunden. Und ich glaube, das ist ein bisschen die Stärke

00:26:32: Eileen: auch von Open Source, die vielen Designerinnen nicht bewusst ist, dass weil eben diese Communities so,

00:26:38: Eileen: offen sind, man auch sofort was machen kann. Man muss nicht irgendwie darauf warten, bis

00:26:43: Eileen: drei Product-Cycles irgendwie durchgekommen sind und man muss sich nicht bewerben und dort,

00:26:48: Eileen: erstmal eine feste Anstellung bekommen, sondern man kann einfach loslegen und meistens sind die

00:26:54: Eileen: Menschen so gut dem gegenüber gestimmt, dass Sachen einfach passieren können. Und ich glaube,

00:26:59: Eileen: das ist nochmal ein Punkt, den ich auch immer in Design-Kreisen verbreiten möchte, dass das.

00:27:07: Eileen: Einfach auch der Vorteil ist von Open Source. Wobei man dazu auch sagen muss,

00:27:11: Eileen: also es ist nicht ungefährlich, einfach ungefragt Feedback zu geben. Das ist

00:27:17: Eileen: aber auch nicht nur in Design der Fall, sondern auch in Codesachen.

00:27:21: Eileen: Die Leute reagieren ganz anders. Manche Leute sind sehr offen und neugierig und freuen sich über Feedback und andere denken so, hey, das ist mein Baby, warum,

00:27:31: Eileen: warum bekomme ich hier ungefragt ein Review oder du designs mir ein neues Logo,

00:27:35: Eileen: obwohl mein Logo eigentlich perfekt ist, auch wenn ich es alleine in den 90er in Paint gemacht habe,

00:27:41: Eileen: aber das ist unser Logo. Also das sehe ich dann tatsächlich auch sehr oft. Also man muss da auch,

00:27:46: Eileen: ja vorsichtig sein, wenn man solche Reviews macht. Aber wie gesagt, ich sage immer gerne,

00:27:52: Eileen: probieren kann man es immer und freundlich sollte man auch sowieso immer sein.

00:27:55: Joram: Das denke ich auch. Ich denke, wenn man konstruktiv was beitragen möchte zum Projekt in der eigenen Herangehensweise, dann ist es schwieriger, darauf schlecht zu reagieren, als wenn man halt sagt, hier funktioniert es nicht, hier funktioniert es nicht, hier funktioniert es nicht. Dann lädt man,

00:28:10: Joram: nicht dazu ein, mehr zu machen. Aber jetzt würde mich noch interessieren, wenn man jetzt so ein kleines Team ist, vielleicht zwei Personen und man arbeitet jetzt an einer Software,

00:28:19: Joram: wie kann man denn da sowohl Gedanken aus dem UX-Design, aber selbst so etwas Konkretes wie

00:28:26: Joram: so ein User Research mit kleinem Budget umsetzen? Also wenn man jetzt nicht in der Lage ist,

00:28:32: Joram: Leute zu vergüten oder irgendwelche grosseren Sachen zu machen, wie kann man denn trotzdem

00:28:36: Joram: trotzdem davon profitieren, sich NutzerInnen-Meinungen reinzuholen.

00:28:40: Eileen: Ja, ist eine schöne Frage. Es gibt tatsächlich ein recht bekanntes Buch von Leah Bewley, The User Experience Team of One.

00:28:50: Eileen: Und darin wird also sehr gut beschrieben, wie man eigentlich als eine Person schon so viel UX-Sachen machen kann,

00:28:57: Eileen: dass es dem gesamten Team ein Gewinn sein kann. Und ich glaube, dass es auch gerade für so kleine Teams im Public Interest Tech-Bereich sehr wichtig ist,

00:29:07: Eileen: zu wissen, dass es machbar ist, auch mit eingeschränkten Ressourcen.

00:29:11: Eileen: Genau, also ich würde sagen, erstens nenne ich immer am liebsten meine magische Zahl,

00:29:19: Eileen: drei bis sechs. Das ist die Anzahl an Interviews, die man braucht, um so 80 Prozent der UX-Probleme

00:29:25: Eileen: zu entdecken. Also man muss wirklich nicht viel Zeit investieren.

00:29:29: Eileen: Ich sage mal maximal 50 Stunden und dann hat man wirklich die wichtigsten UX-Probleme.

00:29:34: Eileen: Erstmal identifiziert. Und ich glaube, das alleine zu wissen, ist schon ein unglaublicher

00:29:40: Eileen: Gewinn. Also man muss wirklich nur mit ein paar, mit wenigen Menschen reden, um das machen,

00:29:45: Eileen: zu können und testen, testen, testen. Also wirklich mit Menschen, mit realen Nutzerinnen,

00:29:53: Eileen: die Software testen. Das ist immer, dafür muss immer Zeit sein. Und das spart dann später

00:29:58: Eileen: auch viel Zeit. Das muss ich auch immer sagen. Wie ich schon vorhin gesagt habe, Designsprint

00:30:03: Eileen: am Anfang eines Projektes immer gut, weil man später dann nicht die Arbeit doppelt machen muss.

00:30:08: Eileen: Ansonsten ist es immer machbar, also wenn man wirklich sagt, ich möchte nicht mit Menschen

00:30:16: Eileen: reden, ich hasse es, ich möchte nicht Sachen testen und ich habe sowieso kein Händchen für

00:30:26: Eileen: Interfaces und alle Design-Fragen, das liegt mir alles überhaupt nicht, dann kann man sich auch

00:30:33: Eileen: zum Beispiel im Politype Fund gibt es immer UX-Expertinnen, die da zur Verfügung stehen,

00:30:38: Eileen: einfach ein kurzes Review machen. Das ist auch, das machen viele UX-Menschen ohne jetzt,

00:30:44: Eileen: das ist so zeitintensiv, man sitzt einen halben Nachmittag dran und kann sich etwas einschauen und,

00:30:50: Eileen: und spezifisches UX-Feedback geben. Und ich denke, das ist auch noch eine Sache, die ich einfach erwähnen wollte.

00:30:58: Joram: Gibt es, und das ist so ein bisschen meine letzte Frage, gibt es etwas, was aus deiner Sicht als Designerin, was DesignerInnen allgemein von EntwicklerInnen lernen können, um quasi jetzt nochmal so die andere Sicht zu machen.

00:31:09: Joram: Wir haben jetzt viel darüber gesprochen, wie UX-Design EntwicklerInnen das Leben leichter oder verbessern kann

00:31:14: Joram: und jetzt die Qualität der Software verbessern kann. Es gibt dann umgekehrt etwas, was UX-DesignerInnen lernen können.

00:31:20: Eileen: Also für mich ist erstmal wichtig zu sagen, dass die Designerinnen, die reingehen in ein Projekt und sagen, ich mache jetzt das Design, das fand ich immer, ja wie soll ich sagen, arrogant fast.

00:31:35: Eileen: Also Kreativität, Entwicklung, man vergisst immer, wie viel Kreativität, was ein unglaublich

00:31:44: Eileen: kreatives Unterfangen eigentlich Development ist. Und ich denke auch, wenn man in so ein

00:31:50: Eileen: Entwicklungsteam reingeht, sollte man immer erstmal schauen, was es schon gibt.

00:31:55: Eileen: Weil Designern sind nicht die einzigen, die gute Ideen haben.

00:31:58: Eileen: Meistens gibt es schon erste Gedanken zur Oberfläche oder es gibt auch schon die,

00:32:04: Eileen: ersten User. Das sind meistens die Entwickler natürlich. Und wenn ich an,

00:32:10: Eileen: das klassische Ingenieurswesen denke, spielt Bedienbarkeit auch,

00:32:16: Eileen: immer eine Rolle. Also ist es überhaupt nicht so, dass Designerinnen ja nur das einzige

00:32:24: Eileen: Mandat haben, dort die Überfläche zu machen. Also von meiner Seite aus denke ich, ist es

00:32:30: Eileen: überhaupt nicht nötig, immer was Teil Neues und Verrücktes zu entwerfen und es ist immer

00:32:35: Eileen: sinnvoller, auch vorhandene UX zu verbessern. Das will ich einmal so sagen und das andere.

00:32:42: Eileen: Mir auch immer einfällt, ist, ich glaube, Entwicklungsteam haben oft Prozesse, die,

00:32:49: Eileen: wahnsinnig gut durchdacht sind. Ich habe das in meiner eigenen Arbeit immer so erlebt,

00:32:54: Eileen: dass ich dadurch, dass ich mit vielen Entwicklerinnen arbeite, auch einfach viel,

00:33:01: Eileen: bessere Teamsstruktur habe. Also was wird wann diskutiert, was ist Staging und was ist ein,

00:33:06: Eileen: ein Pull-Request, was sind Ideen und Gedanken, wie kann man sie in Commits zusammenfassen,

00:33:12: Eileen: und gut kommentieren und dokumentieren. Das sind Sachen, wo Designerinnen immer noch,

00:33:18: Eileen: oft auch sehr chaotisch arbeiten. Also die sagen, wir machen mal ein Meeting und machen

00:33:21: Eileen: ein Workshop dazu und haben vielleicht ein paar Sticky-Nuts danach. Und in meiner Arbeit

00:33:27: Eileen: mit Entwicklungsteams habe ich auch gelernt, dass Tickets und Issues und gute Kommentare

00:33:34: Eileen: und PRs und so weiter, dass das eigentlich eine sehr schöne Art zusammenzuarbeiten ist.

00:33:39: Joram: Wenn Leute mehr über dich erfahren wollen, wo können sie denn das tun? Wo können sie dich erreichen?

00:33:44: Eileen: Ich habe sogar eine Website, die heißt bumble.blue und dort habe ich diverse Sachen abgelegt,

00:33:51: Eileen: Gedanken zu Local First oder neueste Projekte oder sonstige Ressourcen. Ich habe zum Beispiel

00:33:59: Eileen: Beispiel auch eine Pattern Library zu Dezentralisierungs-Sachen, na, solche Sachen.

00:34:04: Eileen: Diverse Sachen sind heute abgelegt.

00:34:07: Jingle

00:34:10: Joram: Vielen Dank, Aileen, für das spannende Interview. Ich glaube, der Ratschlag, der bei mir am meisten hängen geblieben ist, ist, dass man einfach mal als UX-Designer in, ruhig mal eine Review machen kann von der Software.

00:34:23: Joram: Und wenn man konstruktiv ist und freundlich und nett, echt durchaus was beitragen kann zu Open-Source-Projekten.

00:34:29: Joram: Auch wenn man vielleicht denkt, es ist komplizierter, damit reinzukommen. Manchmal hilft es einfach, eine Review zu machen, das zu veröffentlichen. Und dann können Leute daraus lernen und ihre Software verbessern.

00:34:41: Feli: Du hast auch mit Marta gesprochen. Marta hat sich auch einmal kennengelernt und ich weiß von ihr, dass ihr User Experience auch sehr wichtig ist. Marta ist Entwicklerin und Designerin, die unter anderem einen vereinfachten Installer für CubeOS erarbeitet hat.

00:34:55: Feli: Sie wurde damit in der elften Runde von Prototype Fund gefördert. Und auf die Frage, welche Rolle UX Design für Open-Store-Software spielt, sagt sie folgendes.

00:35:04: Marta: Ich denke, dass UX entscheidend für Open Source Software ist. Wir, Free and Open Source Programmierer, sprechen oft über Sicherheit und Privatsphäre als Menschenrechte.

00:35:16: Marta: Aber die sicheren, kostenlosen, datenschutzfreundlichen Open Source Tools erfordern von den Nutzern so viel Zeit und so viel Mühe.

00:35:25: Marta: Oft sind diese Tools komplett unzugänglich für normale Menschen.

00:35:30: Marta: Und ich meine Menschen ohne Informatik-PhD.

00:35:33: Marta: Das ganze Gerede über Sicherheit und Datenschutz erweist sich als Illusion.

00:35:39: Marta: Wenn Privatsphäre und Sicherheit ein Menschenring sind, müssen die Tools, die diese bitten,

00:35:46: Marta: von Menschen genutzt werden können.

00:35:48: Marta: Und das schließt Menschen ohne Doktortitel ein.

00:35:51: Joram: Ich fand es sehr spannend, dass sie sagt, dass gutes UX-Design überhaupt erst die Nutzung von Free- und Open-Source-Software möglich macht. Und ähnlich wie Ali das auch schon im Interview gesagt hat, ist Marte ein großer Fan von NutzerInnen-Tests.

00:36:05: Marta: Ich bemühe mich, meine Arbeit immer auf Benutzerforschung und Benutzer-Test zu stützen.

00:36:10: Marta: Ich entwerfe Tools auf der Grundlage von Interviews und Umfragen unter Nutzen,

00:36:15: Marta: Aber später, und das ist entscheidend, teste ich diese Tools mit meinen Nutzern.

00:36:20: Marta: Und zwar nicht nur mit anderen befreundeten Entwicklern.

00:36:24: Marta: Dadurch erkenne ich Schmerzpunkte, die ich sonst nie sehen würde.

00:36:29: Marta: Um ehrlich zu sein, finde ich, dass jeder Open Source Entwickler gezwungen werden sollte,

00:36:35: Marta: in kompletter Stille zu beobachten, wie eine Benutzerin seine Software zum ersten Mal selbst benutzt.

00:36:42: Marta: Das ist eine sehr lehrreiche und manchmal auch sehr schmerzhafte Erfahrung.

00:36:49: Feli: Ich denke, es ist ein guter Hinweis, jemandem ruhig über die Schulter zu blicken und zu schauen, wie jemand die eigene, kreative Software benutzt.

00:36:57: Joram: Und ich glaube, zum Schluss hat Martha das ganz gut zusammengefasst. Es geht nämlich darum, die eigenen Vorstellungen mit denen von NutzerInnen abzugleichen.

00:37:03: Marta: Anstatt mich über die Benutzer zu ärgern, weil sie meine Programme nicht so benutzen,

00:37:08: Marta: benutzen, wie ich es für intuitive halte, habe ich angefangen zu lernen, was für die

00:37:13: Marta: Benutzer intuitive ist.

00:37:15: Feli: Matt hat auch angesprochen, dass das Thema Inklusivität wichtig ist in Open-Source-Communities.

00:37:20: Feli: Dass man auch Teams haben kann, die einfach mehr Skills haben als nur EntwicklerInnen, sondern auch Menschen, die sich mit User Experience auskennen, aber vielleicht auch noch über die inhaltlichen Themen hinaus. Ich glaube, dann kann man auf jeden Fall garantieren, dass man ein gutes Produkt hat,

00:37:32: Feli: weil man eben so viele verschiedene Menschen hat,

00:37:34: Feli: die aus verschiedenen Bereichen kommen und die Software anders angucken.

00:37:37: Marta: Ich denke auch, dass Open Source Projekte versuchen sollten, Designerinnen und Designern

00:37:42: Marta: mehr entgegenzukommen.

00:37:44: Marta: Es gibt eine klare geschlechtsspezifische Voreingenommenheit in Open Source,

00:37:50: Marta: was ich oft auch auf Konferenzen zu Themen Betriebssystemen und so weiter sehe.

00:37:57: Marta: Ich bin oft einer der sehr, sehr wenigen Frauen dort.

00:38:02: Marta: Und die allgemeine Community kann ziemlich aus Grenzen gegenüber nicht Männer,

00:38:07: Marta: und nicht technischen Menschen wahrgenommen werden.

00:38:12: Marta: Ich glaube, wir müssen integrativer sein und anerkennen, dass Design einen großen

00:38:17: Marta: Wert hat. Auch Arbeit, die nicht reine programmierte Arbeit ist, ist wertvoll.

00:38:22: Marta: Und Designerarbeit ist wirklich entscheidend für den Erfolg von Open Source Projekten.

00:38:28: Joram: Und dann habe ich noch mit Payuvo gesprochen. Payuvo haben wir auch schon in einer anderen Folge gehört. Und eigentlich wollte ich von Payuvo wissen, welche Herausforderungen Payuvo bei der Entwicklung von Public Interest Tech sieht. Aber die Antwort passt sehr gut zu unserem heutigen Thema.

00:38:41: Joram: Technologie sollte zugänglich sein.

00:38:44: Pajowu: Für die Projekte, die ich jetzt gemacht habe, war ein ganz wichtiger Punkt, dass es um Zugänglichmachung von Technik geht. Wir haben technische Möglichkeiten, aber die sind einfach ganz vielen Nutzerinnen noch nicht zugänglich,

00:38:58: Pajowu: weil es Kommandozeilen-Tools sind, weil es irgendwelche Bibliotheken sind, die zwar sehr viel können, aber nicht direkt nutzbar sind.

00:39:07: Pajowu: Und das war der Fokus meiner Projekte, sich darauf mal zu konzentrieren. Und da ist dann aber auch das Problem, ausreichend mit NutzerInnen zu reden.

00:39:17: Pajowu: Also bei gerade dieser Art von Public Interest Tech Projekten ist es halt super wichtig,

00:39:21: Pajowu: das auf die Nutzer orientiert zu machen. Und nicht wir setzen uns dann in unser Kämmerchen und überlegen, was die NutzerInnen haben wollen,

00:39:28: Pajowu: sondern man muss eben ins Gespräch kommen, man muss mit den Leuten reden

00:39:31: Pajowu: und das braucht auch einfach wieder Zeit.

00:39:34: Feli: Ja, den Prototype-Fund ist Human-Centered Design oder User-Centered Design auch sehr wichtig. Deswegen bieten wir hier bei uns auch für die Projekte, die wir fördern, Coachings an, damit diese davon profitieren können, damit die Software einfach gut gebaut wird und dementsprechend dann auch einfach nachhaltiger ist.

00:39:50: Feli: Und diese Coachings sind bei uns eben auch im Zentrum oder sind eben ganz wichtig für uns, weil einfach User Experience generell einen großen Unterschied macht bei den durchschnittlichen NutzerInn,

00:39:59: Feli: und damit die Attraktivität von Open Source Software steigert.

00:40:03: Joram: Und ich finde es wichtig auch zu sagen, dass es auch immer mehr gute Lösungen von EntwicklerInnen gibt. Also dieses alte Bild, was ich ja auch im Interview angesprochen habe von der Open-Source-Software,

00:40:14: Joram: die ein bisschen holprig zu benutzen ist und der schickt designten, konventionellen Software,

00:40:19: Joram: das stimmt halt auch nicht mehr so. Das ist halt so ein Eindruck, der sich mal ergeben hat, wo es mittlerweile etliche Beispiele gibt, wo das anders aussieht, wo Software vernünftig zu bedienen ist, wo man sehr gut auch als Anfänger in damit klarkommt.

00:40:33: Joram: Und es gibt halt auch immer mehr Entwickler in die daran arbeiten, wie eben auch Marta,

00:40:38: Joram: dass eben so ein Tool wie CubeOS einfach zu installieren ist und zu benutzen ist.

00:40:42: Joram: Und das sorgt dann eben dafür, dass Leute in der Lage sind, Tools zu benutzen,

00:40:47: Joram: die sie unter Kontrolle haben, die sie verstehen, mit denen sie dann eben mehr erreichen können, als unter Umständen mit bestimmten kommerziellen Produkten.

00:40:55: Feli: Okay, das war's für heute von uns. In der nächsten Folge kommen wir von den nutzerzentrierten Design zu den NutzerInnen von Public Interest Tech. Dazu haben wir mit Marie vom Prototype Fund gesprochen und Warak von Stacksbin. Die erzählen uns, was man tun kann, um Open Source Tools näher an NutzerInnen zu bringen.

00:41:10: Jingle

00:41:13: Feli: Falls euch die Folge gefallen hat, folgt uns auf Mastodon, Twitter, besucht unsere Homepage oder abonniert unseren Newsletter, der erscheint alle zwei Monate, dann verpasst

00:41:20: Feli: ihr nichts.

00:41:21: Joram: Die Links dazu findet ihr genauso wie alle anderen Links von den Projekten, die wir angesprochen haben in der Folge, unten in den Show Notes.

00:41:28: Feli: Außerdem, wenn euch der Podcast gefallen hat, dann freuen wir uns riesig über eine Bewertung bei welcher Plattform auch immer ihr diesen Podcast hört. Tschüss!

00:41:36: Jingle