Kapitel 1

28. August 1997

So früh fange ich natürlich nicht wirklich an, eine kleine Einleitung in meinen Weg zum Interfacedesign möchte ich aber trotzdem geben. Keine Lust auf Geschwafel? Kein Problem: Weiter zum ersten Projekt.

Bevor ich in 2016 an der Fachhochschule angefangen habe, habe ich mehrere Jahre für ein Kölner Marktforschungsinstitut gearbeitet. Dabei war ich neben der mehr- oder minder erfolgreichen Gestaltung der hauseigenen Webseite → auch an zahlreichen Marktforschungsstudien beteiligt; und die Mitarbeit dabei hat mich nachhaltig geprägt. Zu sehen, dass NutzerInnen so fernab von den eigenen Vorstellungen denken, konsumieren, fühlen und interagieren war – und ist immernoch – überraschend.

Bei einigen dieser Projekte ist mir die Relevanz von gutem Interfacedesign bewusst geworden. Ich erinnere mich gut an die Frustration, wenn ProbandInnen erfolglos versuchen den Testaufbau nachzuvollziehen, und das einfach nur weil die dazugehörige App unbenutzbar war.

Passend zu meinem Drang, diese Apps besser zu machen, habe ich in der Eignungsprüfung in 2016 das Thema „Besser machen“ gewählt, und mich direkt dem Interfacedesign-Endgegner gestellt, der Google-Startseite. Im Nachhinein kann ich sagen: mutige Wahl.

„Sketch? Wofür? Ich hab’ doch Photoshop. Das reicht!“

Die Wahl des Projektes spiegelt aber meine damalige Einschätzung von Design und Studieninhalt gut wieder. Zu Beginn des Studiums dachte ich: Ich kann die theoretischen Grundlagen des Studiums bereits, und erlerne in den nächsten vier Jahren das Praktische und die Umsetzung.

Diese Einschätzung war, zurückblickend gesehen, nicht nur töricht, sondern hat nichtmal die ersten Projektenwochen gehalten. Im Kurs „UI/UX Design Pattern“ bei Ivo Herrmann und Paul Thiele habe ich gemerkt, dass ich die Tiefe und die stetige Weiterentwicklung des Faches maßloß unterschätzt hatte. Außerdem ist klar geworden, dass meine anfänglichen Designfähigkeiten genau das waren: anfänglich.

Beispielhaft dafür, mein Endergebnis im Sesam-Kurs:

Diese Erkenntnis ist allerdings immernoch eine, die ich sehr schätze. Im anschließenden Grundstudium habe ich einmal die komplette Bandbreite des Fachebereiches mitgenommen, um ein breiteres und offeneres Bild von Design zu erlernen. Das war spannend – Schriftarten selbstmachen, Holzelefanten bauen, Mikrocontroller umbasteln; alles war dabei, und hat mir geholfen, die Grundlagen des Handwerks zu erlernen.

Aber darum soll es in dieser werk.show nicht gehen. Für mich gehört mein jugendlicher Großmut zu meiner Entwicklung als Designer, und deshalb wollte ich ihn nicht unerwähnt lassen. In den folgenden Kapiteln möchte ich aber die Projekte vorstellen, die in den Folgejahren entstanden sind und auf die ich stolz bin.

---

Kapitel 2

Ein beispielhafter Designprozess

Finn war mein erstes Hauptstudiumsprojekt. Zusammen mit Marius Claßen habe ich mich, unter der Leitung vom damaligen Head of Design bei N26, Christian Hertlein, der Aufgabe gestellt, eine digitale Lösung für Vertrauensbildung in der Bankenbranche zu finden.

Problemidentifikation

Im Aufgabenkontext haben wir uns an der Onlinebank N26 orientiert und versucht an diesem Beispiel Problemfelder mit „neuen Banken“ zu identifizieren. Dabei haben wir eine These aufgestellt, die wir im Anschluss durch Interviews so gut wie möglich bestätigt haben. Für diese These eine kurze Erklärung: wir haben die Aufgaben und Berührungspunkte einer Bank mit ihren Kunden in zwei Bereiche aufgeteilt – allgemeine Bankgeschäfte und erweiterte Bankgeschäfte.

Allgemeine Bankgeschäfte sind die täglichen Funktionen einer Bank wie Geldabhebungen, Überweisungen und Einzahlungen. Erweiterte Bankgeschäfte sind alle anderen Dienstleistungen einer Bank: Investitionen, Anlagen, Darlehen und Ähnliches.

Nach unserer Auffassung funktionieren bei alteingesessenen Banken wie der Sparkasse oder der deutschen Bank beide Bereiche – sie sind gefestigte Banken mit einem hohen Transaktionsvolumen und mit dem Vertrauen von Kunden aus mehreren Generationen. Hier werden seriöse und sichere Prozesse ebenfalls bei erweiterten Bankgeschäfte erwartet. Dieses Vertrauen fehlt bei Onlinebanken wie z.B. N26. Alltägliche Bankgeschäfte werden als seriös eingeschätzt, erweiterten Dienstleistungen wird nicht vertraut und dementsprechend wenig genutzt – das spiegelt sich in den Statistiken wieder.

Im Laufe des Problemfindungsprozesses haben wir auch eine Umfrage mit rund 35 Nutzern unter dem Titel „Du & Deine Bank“ durchgeführt. Dabei hat sich unsere These bestätigt – der Vertrauensunterschied zwischen Hausbanken und Onlinebanken ist immens.

Unser Vergleichswert (da sich Vertrauen nicht in einer bestimmten Einheit messen lässt) ist hier sehr eindeutig: Hausbanken tragen einen Vertrauenswert von 7.9.

Der Gegensatz dazu, Onlinebanken wie N26 und Revolut, haben einen Vergleichswert von 6.1 – also fast zwei Punkte weniger.

Zielgruppenfindung

Nach diesen Interviews und Umfragen war eine klare Definition der Zielgruppe erforderlich, um möglichst schnell Kontakt zur ihr aufzubauen und frühe Nutzertests auszuführen.

Unsere Zielgruppe haben wir anhand von zwei Faktoren festlegen können:

• 1. Sie muss alltäglich mit hohen Summen Geld umgehen.
• 2. Sie muss grundsätzlich in die Zielgruppe von Onlinebanken passen.

Dadurch konnten wir unsere Zielgruppe schnell eingrenzen, haben allerdings zu Beginn noch den Fehler gemacht, in zu großen Zielgruppen zu denken. Begonnen haben wir also mit der Zielgruppe Junge Unternehmer, Studiumsabsolventen & StartUp-Gründer und nach einigen Konsultationen hatten wir die Zielgruppe fertig definiert: StartUp-Gründer, die ein höheres Darlehen von einer Onlinebank erhalten und bank- beziehungsweise technikaffin sind. Durch diese Eingrenzung konnten wir früh im Prozess Kontakt zu Personen aus der Zielgruppe aufnehmen und unsere Idee direkt testen.

Interviews

Im Anschluss bauten wir schnell Kontakt zu zwei Berliner StartUps auf, die eine gute Grundlage für akute Problemfindungen im Finanzsektor für StartUps geboten haben.

Die interviewten Gründer, die aufgrund der genannten Finanzdaten anonym bleiben möchten, haben uns aufgezeigt, was in ihrer Anfangsphase nach dem Darlehenserhalt falsch lief. Die meist genannten Probleme sind der enorme Zeitaufwand und die Komplexität, die das Finanzwesen eines StartUps in Anspruch nimmt.

• Beispiele für häufig genannte Probleme
• Wir haben keine Zeit dazu. Wir vertrauen unserer Finanzabteilung und Steuerberater, die uns immer über die Schulter schauen.
• Am Anfang wollten wir unsere Idee einfach verwirklichen und nur das drumherum hat uns am Anfang die Energie genommen.
• Cool wäre es, wenn alles automatisiert ablaufen würde, so dass wir Geld ausgeben können, ohne auf das Geschäftsjahr im Voraus schauen zu müssen.
• So wären wir auch schnell informiert, ohne diesen Wulst an Formularen durchblättern zu müssen.
• […] und an uns nur die wichtigen Berichte zusammengefasst und sie uns verständlich liefert.
• Anna schreibt sämtliche Ausgaben im Notizbuch und am Freitag gibt es ein Shutdown. Hier präsentiert sie alle Einnahmen und Ausgaben, die in der Woche ausgefallen sind.

Im weiteren Interview-Verlauf sind auch einige Wünsche genannt worden, provoziert durch Fragen wie „Wenn Du dir einen Finanzdienstleister selbst bauen könntest, was könnte der alles?“.

• Beispiele für häufig gewünschte Features
• Ha! Er sollte sämtliche Finanzen einsehen und wachsam über Ein- und Ausgaben sein.
• Cool wäre es, wenn alles automatisiert ablaufen würde, so dass wir Geld ausgeben können, ohne auf das Geschäftsjahr im Voraus schauen zu müssen.
• Mit anderen Worten, ein Subprogramm, dass an das Geschäftskonto verknüpft ist und automatisch die monatlichen Steuern einreicht, bezahlt und an uns nur die wichtigen Berichte zusammengefasst und sie uns verständlich liefert.
• Wenn ein Tool für uns Alles erledigen könnte, wäre klasse! Allerdings ist Anna zu skeptisch, da sie einige Tools ausprobiert hat und am Ende musste sie 3 bis 4 gleichzeitig nutzen.
• Das war uns alles zu langwierig und kompliziert. Wir hatten eine Idee und wollten sie schnell umsetzen. Wir sprechen alle gemeinsam ab und machen es einfach, wenn es sich lohnt.
• […] ein Tool, das uns alles automatisch organisiert. Uns alle Anfragen und Geschäftsaspekte ausspuckt, organisiert und tja... vielleicht auch am Ende des Monats mit dem Finanzamt bequatscht.

Introducing: Finn

Durch die Recherche und die Interviews ist ein klarer Gedanke zu unserem Dienst entstanden, der früh von uns mit einem Namen getauft wurde. Finn ist hierbei ein abgeleiteter Eigenname auf Financial Assistant. Das beschreibt Finns Tätigkeitsbereich auch gut:

Finn hebt sich von anderen Banking-Apps durch seine vielfältigen Einsatzbereiche ab: Finn analysiert die vergangenen Zahlungen, schlägt darauf basierend Aktionsempfehlungen vor, die seine Prognose der Zukunft beeinflussen können.

Finn macht die ersten Schritte

In zahlreichen analogen Iterationen haben wir versucht, auch anhand von bereits bestehenden Banking-Apps, einen Überblick über benötigte Features zu bekommen. Dabei haben wir besonderen Wert auf Informationshierarchie und Relevanz von angezeigten Informationen gelegt.

Die erste digitale Iteration war eine Art Wireframe, das wir genutzt haben, um ein Verständnis für den benötigten Platz zu bekommen und um herauszufinden, inwiefern Finn als reines Icon oben rechts genug Ansporn zur Kommunikation bietet.

Basierend auf dem Wireframe haben wir einen ersten, recht ähnlichen High fidelity-Prototypen gebaut, mit dem wir die ersten Nutzertests (mit Zielgruppen-fremden Personen) durchgeführt haben.

Der Fokus auf der ersten Iteration lag auf der Farbigkeit und zeigt die ersten Aspekte des Notification-Moduls, das später der Hauptbereich von Finn werden wird. Auf dem zweiten Screen erkennt man die grundsätzliche Funktion von Finn: Finn analysiert die Vergangenheit und gibt dem Nutzer, natürlich hierarchisch nach Priorisierung und Relevanz sortiert, kuratierte Benachrichtigungen, die den User auf dem Laufenden halten ohne große Interaktion zu erfordern.

Nach ersten Nutzertests, bei denen eindeutig klar wurde, dass ein absoluter Informationsüberschuss herrscht, haben wir versucht die dargebotenen Informationen zu reduzieren und übersichtlicher zu gestalten. Wir haben eine klarere Linie in Richtung Farbigkeit angestrebt und versucht, eine für den Nutzer klare Aufteilung mittels Farbcodes zu schaffen.

Schwarz dargestellte Zahlen repräsentieren die ersten beiden Tätigkeitsbereiche von Finn, nämlich Vergangenheit und Gegenwart. Sie zeigen demnach vorangegangene Zahlungsein- und ausgänge auf dem Konto an. Alle cyanfarbigen Zahlen stellen eine Prognose von Finn dar, die Finn aus den Kontobewegungen der letzten 6 Monate errechnet hat.

Wofür ist eigentlich die Transaktionsliste?

In einer Feedbackrunde nach der dritten Iteration gab es für uns einen klaren Bruch, der sich schon in den Nutzertestings abgezeichnet hat: die Hauptinteraktion des Service, sowohl inhaltlich als auch gestalterisch, findet mit der Transaktionsliste auf der Startseite statt. Das bezieht sich nicht nur auf unseren Service, weil es der Industriestandard zu seien scheint.

In unseren Tests ist aufgefallen, dass die Transaktionsliste quasi nicht benutzt wird. Es ist augenscheinlich das wichtigste und prominenteste Feature in der App, kommt aber in der tatsächlichen Interaktion kaum zum Einsatz. Informationen sollen von Finn aufgearbeitet werden und priorisiert werden – eine chronologische Auflistung aller getätigten Transaktionen ist dabei störend und lenkt den Fokus ab.

In einem komplett neuen und analogen Ansatz haben wir neu gedacht: wie sieht eine Banking-App aus, wenn sie keine Transaktionsliste mehr hat? Welchen Inhalt bietet Finn dann an? Klar ist geworden, dass Finn in den Vordergrund rücken muss. Die Analogie die uns in der folgenden Entwicklung geholfen hat, ist die des Social Media-Feeds: nicht chronologisch sondern nach Relevanz sortierte Meldungen, die in einem Modul-Feed mehr Interaktionsmöglichkeiten als eine pure Liste bieten kann.

In den nächsten Iterationen hat sich also unser Home-Screen von einer typischen Transaktionsliste zu einem interaktiven Feed entwickelt, der den Nutzer mit dem ersten Blick informiert und zur Handlung auffordert.

Der Input der Users erfolgt durch eine Texteingabe, die die Keywords filtert und automatisch in die Marke einträgt. Dadurch entsteht das Gefühl einer Kommunikation, in der der Nutzer dieselben Informationen eintragen kann aber sich nicht stur durch die Maske klicken muss.

Iteration 05 hat eine weitere wichtige Erkenntnis integriert, die wir aus Nutzertests gewannen: die Information zum aktuellen Kontostand hat keine so relevante Bedeutung, weshalb eine so prägnante Position auf dem Startscreen gerechtfertigt wäre und verschwindet demnach auf die Übersichtsseite von Finn. Weiterhin hat sich Finn insofern verändert, dass er neben einer Such- und Interaktionsmöglichkeit gleichzeitig relevant erkannte Statistiken anzeigt.

Dieser Screen wurde wie die ersten Versionen des Homescreens schnell als überladen erkannt – die Informationen sind zu zahlreich und zu unübersichtlich gestaltet. Diese Erkenntnisse haben sich in der finalen Version deutlich verbessert.

Finn, als Prototyp

Nach abschließenden Nutzertests der fünften Iteration sind die letzten Projektwochen mit der Erstellung des letzten und finalen Prototypen verbracht worden. Fokus lag hierbei auf einer natürlichen Interaktion und einer hierarchisch aufgeräumten Darstellung der neuen Navigation.

Die neue Navigation hat ein neues Pattern, das die Relevanz von Finn stärkt – sie ist der wortwörtliche Dreh- und Angelpunkt.

Zusammengefasst ist das Symbol eines türkisen Kreises am oberen Bildschirmrand. Finn kann mit der typischen Swipe-Bewegung nach unten gezogen werden, um auf das Dashboard von Finn zu gelangen. Ein erneutes Drücken auf Finn startet die Kommunikation mit Finn und bietet dann die Möglichkeit, Tätigkeiten wie Überweisungen oder Anweisungen für eine Prognose einzugeben.

Das mit der Navigation erreichte Dashboard bietet einen Überblick über stets relevante Zahlen wie den Kontostand und seine Entwicklung mit Analyse und Prognose. Dabei kann der Nutzer direkt auf erweiterte Analyse-Ergebnisse zugreifen, ohne mit Finn interagieren zu müssen.

Über das Dashboard erfolgt ansonsten die gesamte Kommunikation mit Finn. Möchte der Nutzer eine Überweisung tätigen, eine Analyse starten oder eine Prognose abrufen, so kann er das per Texteingabe in direkter Kommunikation mit Finn tun.

Eine beispielhafte Überweisung sieht folgendermaßen aus. Finn erkennt die Eingaben des Nutzers und ordnet sie der Überweisungsmaske automatisch zu. So wird gewährleistet, dass der Workflow nicht unterbrochen wird und der Nutzer die geplante Tätigkeit einfach aufschreiben kann, ohne sich an der Maske zu orientieren.

Ein weiteres Beispiel ist ein Planspiel, das mit Finn ausgeführt wird, siehe hier. Das Dashboard ist allerdings nur die passives Erscheinungsbild von Finn, das eine Interaktion von Seiten des Nutzers erfordert. Die eigentliche Startseite ist der Modulfeed, in dem Finn kuratierte Meldungen ausgibt, um den Benutzer in möglichst kurzer Zeit auf den neusten Stand des Kontos zu bringen.

Dafür gibt es verschiedene Arten: Module, die eine Interaktion des Nutzers benötigen, sind farbig markiert und werden oben im Feed angezeigt. Sie sind außerdem nach Farbigkeit gestaffelt, rot bedeutet eine besondere Dringlichkeit.

Was ich aus 'Finn' gelernt habe

Die wichtigste Erkenntnis ist die enorme Relevanz einer umfangreichen Konzeptionsphase in der die Idee auf Herz und Niere getestet wird, bevor die eigentliche Umsetzung beginnt. Um diese Falle auszulassen haben wir versucht bis zum maximal möglichen Grad analog zu arbeiten und Screens erst gegen Ende des Projektes zu gestalten.

Das hat dafür gesorgt das wir zahlreiche Iterationen durchgehen konnten und offensichtliche & große Fehler ausmerzen konnten – so zum Beispiel die Transaktionsliste, bei der wir in einer der Iterationen geprüft haben, ob sie überhaupt eine Daseinsberechtigung in Finn hat.

Auffällig war auch das wir aufgrund der Komplexität des Themas oft viel zu tief in die Thematik abgetaucht sind. Ein Grundverständnis ist wichtig um Themen wie Trust & Education überhaupt angemessen bearbeiten zu können, in unserem Fall ging es aber häufig um komplexe Registrierungsprozesse für das Darlehen und um umfangreich durchgerechnete Szenarien, die nicht förderlich für die Entwicklung des Service waren.

Neben der wichtigen Konzeptionsphase konnten wir auch die Bedeutsamkeit von Motion Prototypes feststellen: die Einführung eines neuen Patterns wie zum Beispiel die Navigation ist komplex genug und wird nicht einfacher durch die bloße Darstellung durch Screens in einer Dokumentation. Animierte Screens, die die Bewegung innerhalb von wenigen Sekunden erklären können, waren dort wichtig und konnten unser Navigationskonzept gut darstellen.

---

Kapitel 3

Eine ganzheitliche User Experience gestalten

Eine andere, wichtige Erkenntnis über Design habe ich in einem weiteren Projektwochenkurs gelernt. Der Kurs „Getting back your identity“ im Einstein Center of Digital Future, geleitet von zwei MA-StudentInnen der FH;P und finanziert durch die Bundesdruckerei hat uns vor die Aufgabe gestellt, innerhalb von zwei Wochen einen eigenen Escape Room zu bauen.

Zwei Wochen war ganz schön knapp bemessen, weil wir als Kurs vor dem eigentlichen Gestalten erstmal verstehen mussten, was ein Escape Room eigentlich ist. Dafür gab’s also viel Research, Ausprobieren in „echten“ Escape Rooms und Interviews mit „echten“ Escape Room-DesignerInnen. Dann folgten Baumarktbesuche, klägliche Versuche an der Bandsäge, und viel Trial-and-Error.

Spannend für meine Entwicklung als Designer war das Projekt, weil es mir das erste Mal klar gemacht hat, dass man nicht einfach nur eine UI baut und sich damit zufriedengeben sollte. In dem Escape Room war klar, dass jedes Detail stimmen muss, damit der Raum überhaupt funktioniert. Jedes falsch platzierte Element stört die ganze Erfahrung und kann damit das Spiel theoretisch ruinieren. Das ist zwar extremer bei Spielen als bei normalen UX-Gestaltungen, lässt sich aber vergleichen. Auch nicht-unterhaltende UI muss einwandfrei und ganzheitlich gestaltet sein.

Die Erkenntnis hat mir in späteren Arbeiten, insbesondere im Berufskontext, oft geholfen. Zum Beispiel beim Hinterfragen von äußeren Umständen. Was macht eine NutzerIn eigentlich, bevor sie die App runterlädt? Sollten wir diese Erfahrung auch gestalten, oder erst wenn die App gestartet wurde? Das lässt sich zwar nicht immer beeinflussen, das Hinterfragen ist aber wenigstens ein guter Anfang.

Die Ergebnisse des Kurses sind ziemlich cool. In den zwei Wochen haben wir einen Kellerraum des ECDF vollständig umgebaut und in einen zwei-geteilten Escape Room verwandelt. Die BesucherInnnen wurden vor dem Raum in die Geschichte eingeweiht und haben den Auftrag bekommen, den Server der bösen Firma „BioCodex“ zu hacken. Mitten im Raum, geschützt durch ein Laken, saßen wir Controller und haben den Raum mit Licht, Ton und Panik bespielt.

Die Videos aus Spieler- und Controller-Perspektive zeigen das Geschehen super, und verdeutlichen auch, wieso Kleinigkeiten die ganze Erfahrung ruinieren können. Have a look, es lohnt sich:

Spielersicht· 14 min

Controllersicht · 10 min

Ein besonderes Projekt, weil es die Grenzen des Digitalen gesprengt hat und für mich Türen insbesondere in Richtung Microcontrolling und Produktdesign geöffnet hat. Physische Gegenstände können eine Nutzererfahrung nunmal genauso beeinflussen wie ein digitales Interface, und das betrachte ich seit diesem Kurs anders.

---

Kapitel 4

Wie ich verstanden habe, auf User zu hören

+ 2 Talks über Design

Im Sommersemester 2018 bin ich das erste Mal mit „ordentlichem“ User Testing in Berührung gekommen. Der Kurs, in dem ich zusammen mit Donatus Wolf und Felix Westphal den Sprachassistenten VIA gebaut habe, wurde geleitet von Christian Wendrock-Prechtl, Managing Director für UI bei der commerzbank.

Wie VIA entstanden ist

Bevor Brainstorming digitalisiert werden kann muss – logischerweise – erst verstanden werden, wie analoges Brainstorming funktioniert. Dafür hat sich ein frühes User Testing angeboten. Dabei sind elementare Erkenntnisse entstanden: insbesondere ein klares Bild über die Struktur.

Das User Testing wurde dabei genutzt um verschiedene Fragen zu beantworten: Wie wird Brainstorming derzeit genutzt? Wie wird ein Sprachassistent in diesem Zusammenhang angenommen? Kann der Test unsere Idee validieren? Welche Sprachcommands werden intuitiv genutzt, wenn keine vorgegeben werden?

Dafür wurden zwei Gruppen á 3 Probanden aufgefordert, ein Problem via Brainstorming zu lösen. Die erste Gruppe hat dabei die regulären Utensilien eines Brainstorming-Workshops zur Verfügung gestellt bekommen, also Post-Its und Stifte.

Timekeeping und Moderation übernahm dabei ein von uns simulierter Sprachassistent. Dafür wurden alle Funktionen von uns von einem Observationsraum aus simuliert und mittels Lautsprecher und Beamer den Brainstormenden zur Verfügung gestellt.

Gruppe 2 war die Kontrollgruppe und hat dieselbe Aufgabe bearbeitet. Hier haben aber die normalen Utensilien gefehlt – sie waren also gezwungen, vollständig mit unserem Assistant zu brainstormen. Dabei wurden ganz bewusst keine Sprachbefehle vorgegeben – um herauszufinden, welche Fragen und Befehle intuitiv verwendet werden.

Diese Art des Usertestings war für mich neu, weil es eine reale Umgebung simuliert hat. Die ProbandInnen wussten nicht, dass sie nicht mit einem echten Sprachassistenten sprechen. Bis dato hatte ich in Projekten zwar Tests durchgeführt, die aber immer offensichtlich als Usertest erkennbar waren. Ähnlich zum Escape Room (Kapitel 3 ↑) war uns aber hier wichtig, eine vollumfassende UX zu bauen.

VIA in voller Blüte

Wir hatten, durch die Förderung der commerzbank, die Möglichkeit, VIA vor zwei verschiedenen Google-Teams in Hamburg und Berlin zu präsentieren. Dabei haben uns Google-DesignerInnen und PMs Feedback zum Prozess und zum Endergebnis gegeben. Das war spannend: das Feeback aus der „Industrie“ war wesentlich anders aufgebaut als das uns bekannte Feedback aus der Hochschule. Es war realer, und kritischer an echte, digitale Lösungen angepasst.

Dieses Feedback ist dann in unseren finalen Entwurf von VIA eingeflossen. Ich darf vorstellen: VIA, ein Voice Ideation Assisstant für Brainstorming-Methoden.

VIA ist, genau wie analoges Brainstorming, in drei Stages geteilt:

• THINK, in der Ideen generiert werden.
• SORT, in der diese Ideen sortiert werden.
• VOTE, in der über die Ideen abgestimmt wird.

Jede der drei Phasen ist dabei die optimierte Version des analogen Equivalents. Das Prinzip und die Struktur des eigentlich Brainstormings wird dabei übernommen – die analysierten Pain points werden dabei allerdings ausgemerzt und verbessert. Ein Blick auf die drei Phasen:

• THINK, in der Ideen generiert werden.

• SORT, in der diese Ideen sortiert werden.

• VOTE, in der über die Ideen abgestimmt wird.

• Und finally: Export, und Sounddesign.

In diesem Kurs habe ich Voice als zu gestaltendes Interface das erste Mal wahrgenommen. Die Gestaltungsregeln, die man beim Gestalten beim Voice beachten sollte, sind teilweise sehr ähnlich und manchmal komplett anders im Vergleich zu regulären, visuellem Design.

Über Design sprechen: Talks

Ich hatte im Anschluss an den Kurs die Möglichkeit, zusammen mit Christian Wendrock-Prechtl, die gerade erwähnten Gestaltungsregeln in einem Talk zu erläutern. Passenderweise durfte ich – als „Voice-Neuling“ – im Mai 2019 an einer Konferenz in Köln teilnehmen, bei der ich von „3 Do’s“ und „3 Dont’s“ erzählt habe, die wir im Laufe des Kurses erarbeitet haben.

Wer den Talk nicht hören möchte, hier die komprimierten Do’s und Dont’s:

Für meine Begründungen hinter diesen Regelvorschlägen musst Du den Talk anschauen. FYI: das eingebettete Video startet direkt bei meinem Teil. Wenn Du den ganzen Talk mitsamt Christians Teil sehen möchtest, bitte hier entlang.

Do’s and Dont’s when designing Voice based Apps · 12 min

Talk #2: You are not your User.

Insbesondere dieser Kurs hat mir die Relevanz von User Testing deutlich gemacht. Dieses Verständnis habe ich mir nicht nur im weiteren Verlauf des Studiums zu Herzen genommen, sondern insbesondere auch bei meinem Arbeitgeber. In Oktober 2019 habe ich bei der Berliner Firma Smart Mobile Factory als UX Designer angefangen, und nach wenigen Monaten einen firmenweiten Vortrag über die Relevanz von User Testing im Entwicklungsprozess gehalten. Mehr zu meiner Zeit bei der SMF gibt es in Kapitel 5.

Auch hier gilt wieder: wer den Talk nicht sehen möchte, kein Problem. Hier eine Zusammenfassung der sechs wichtigsten Punkte:

• 1. Du gehörst wahrscheinlich zu den besten 5% im Sinne der Computerkenntnisse.
• 2. Dein Verständnis von Technik > Verständnis anderer Leute.
• 3. Bau Software basierend auf Fakten, nicht Annahmen.
• 4. User Testings sollten so früh wie möglich durchgeführt werden.
• 5. Prototypen sind – für echte Nutzer – wie das tatsächliche Produkt.
• 6. UX DesignerInnen sind billiger als EntwicklerInnen.

Für ein bisschen Background zu dieser Zusammenfassung, hier ist der Talk.

You are not your User · 15 min

---

Kapitel 5

Software designen, die dann sogar benutzt wird

„Wie, die App ist dann im App Store? Im echten?!“

Seit Oktober 2019 arbeite ich bei der Berliner Softwareentwicklungsfirma Smart Mobile Factory, kurz SMF. Wie sich vom Namen so schön herleiten lässt, spezialisiert sich die SMF auf die Softwareentwicklung von mobilen Apps. In meinen rund 15 Monaten bis dato bei der SMF konnte ich an Projekten für iOS, Android und Web mitwirken.

Fast alles, was ich in diesem Kapitel erzähle, habe ich auch in meinem Praktikumsbericht erzählt. Da klingt das zwar irgendwie alles ironischer, wer aber lieber Video-Schauen als Kapitel-Lesen mag, kann das gerne hier tun:

Praktikumsberichts„interview“ · 10 min

Neben einem beispielhaften Projekt aus dieser Zeit möchte ich auch meine generelle Erfahrung schildern, die sich erwartungsgemäß vom Arbeitsalltag im Studium abhebt. Aber zuerst ein paar hard facts über die Firma:

Seit 2009 bestehend arbeiten derzeit rund 45 MitarbeiterInnen direkt neben dem Park am Gleisdreieck bei der SMF. Die Kunden-Zielgruppe ist dabei auf Berlin fokussiert, aber nicht darauf eingeschränkt. So zählen zu den prominentesten Kunden der SMF die Berliner Stadtbetriebe, STRATO, BAUR und PONS.

Das Design-Team ist für die Teamgröße in meinen Augen vergleichsweise klein, in meiner Zeit waren wir zwischen 3 und 5 DesignerInnen. Nicht weiter schlimm, weil die Firmenstruktur sowieso dafür gesorgt hat, dass ich selten mit anderen DesignerInnen zusammengearbeitet habe. Den meisten Kontakt hatte ich mit Softwareentwickler- und ProjektmanagerInnen.

Die SMF ist, wie, vermute ich, die meisten Softwareentwicklerfirmen, ziemlich schnelllebig. Es gibt einen ständigen Wechsel zwischen Projekten und immer wieder kommt hier ein neuer Pitch, dort muss ein neues Konzept gemacht werden, da müssen neue Screens für gemacht werden; es gibt immer irgendetwas, das brennt. Und das meine ich ehrlich positiv: ich habe mich, insbesondere am Anfang, als der Vergleich zu Studienarbeiten noch extremer als heute war, manchmal wie ein Kleinkind gefühlt, das gar nicht weiß, mit welchem Spielzeug es zuerst spielen soll.

Die ersten paar Monate habe ich hauptsächlich mit der Zuarbeit zu Pitches verbracht, also Konzeptideen und Konzepte produziert, die auf die Bedürfnisse von Briefings und Lastenheft abgestimmt waren. Nach meinen vorherigen Erfahrungen im Studium, insbesondere über die Wirksamkeit von Nutzertests (siehe Kapitel 4 ↑), war das unbefriedigend: ich wusste, dass meine Konzepte wahrscheinlich Quatsch waren, konnte aber schlecht mit NutzerInnen sprechen, wenn wir noch am Anfang des Pitchprozesses waren. Das ist eine Frustration, die sich bis heute nicht gelegt hat.

Um den Aspekt der NutzerInnen mehr in der Vordergrund zu rücken, habe ich noch in 2019 angefangen, für das Thema innerhalb der Firma zu sensibilisieren. Mein Ziel war klar: wir als Dienstleister sind nicht in der Lage, die meisten Entscheidungen über unsere Software zu treffen. Bis dato werden die Entscheidungen nur mit Annahmen über die NutzerInnen getroffen, ohne aber, dass jemals jemand mit dieser Gruppe gesprochen hat. Um also unsere Kunden davon zu überzeugen, schon früh im Prozess Geld in die Hand zu nehmen um uns ausführlichen User Research und User Testings zu ermöglichen, wollte ich meine KollegInnen davon überzeugen.

Neben Engagement in einem passenden OKR Squad (→ Objectives and Key Results, eine Methode um Ziele in Unternehmen erfolgreicher umzusetzen) habe ich einen firmenweiten Talk über die Relevanz von User Testing im Softwareentwicklungsprozess gehalten. Talk + Hintergrundinformationen gibt’s in Kapitel 4 ↑. Die gesamte, restliche Zeit bei der SMF habe ich mit der Entwicklung der FRÖBEL-App verbracht.

Mitarbeiter-App für Deutschlands größte Kindertagesstätte: FRÖBEL

Seit Anfang des Jahres bin ich der alleinige Designer im Projektteam für die FRÖBEL-Mitarbeiter-App. FRÖBEL ist mit rund 200 Einrichtungen und über 4.000 MitarbeiterInnen Deutschlands größter Träger von KiTas, Kindergärten und Horten. Um den Arbeitsalltag für die Mitarbeitenden zu vereinfachen hat FRÖBEL Ende 2019 eine Ausschreibung mit der Suche nach einer Softwareentwicklungsfirma gestartet.

Diesen Pitch haben wir gewonnen, und da mein Konzept ein Teil dieses Pitches war, habe ich das Projekt danach als Designer betreut. Spannend für mich, weil ich erstmals ausführlich mit den zukünftigen NutzerInnen sprechen konnte. Leider war zu diesem Zeitpunkt die SARS-CoV2-Pandemie schon im vollem Gange, und alle Interviews fanden remote statt. Erleuchtend waren diese Interviews aber trotzdem: mir wurde, live von den ErzieherInnen in ihren KiTas, vor Augen geführt, was die Probleme mit den aktuellen Abläufen sind und welche Erleichterungen man sich von unserer digitalen Lösung erhofft.

Mithilfe der Interviews konnte ich das Designkonzept auf ein technisches Konzept weiterdenken und Fokus auf die tatsächlichen Probleme der FRÖBEL-MitarbeiterInnen setzen. Mit der App läuft einiges im Arbeitsalltag leichter: Zeiterfassung, Krankschreibungen, Urlaubsanträge; alles, was im Analogen bisher schwierig und umständlich verlief, wurde aufgenommen, analysiert, und verbessert ins Digitale übersetzt.

Das Projekt ist gerade in der Endphase, und läuft als Beta-Test bei ein paar Handvoll FRÖBEL-Mitarbeitenden. Geplant ist, dass die App noch in 2020 offiziell released wird und dann den 4.000 Mitarbeitenden zur Verfügung steht. Ein grober Eindruck zum letzten Stand des App-Designs:

Für mich ist das Projekt wichtig, weil ich in ×-verschiedenen Richtungen Erfahrungen sammeln konnte. In Richtung User Testing in realen Umgebungen, Überzeugungsarbeit und Politik um Geschäftsführung + Kunden von den eigenen Ideen zu überzeugen, Crossplattform-Entwicklung und ihre Hürden, Fehlkommunikation mit DEVs & PMs, zahllose Meetings zu den gleichen Themen, … und so weiter. Was negativ klingt, waren für mich wertvolle Learnings über den typischen Entwicklungsprozess.

Durch die Corona-Pandemie ist die Schnelllebigkeit langsamer geworden, hauptsächlich weil unsere Kunden – und wir – nur auf Teilleistung laufen können. Dennoch arbeiten wir gerade, parallel zur Bachelorarbeit und werk.show, an neuen Projekten, die im Januar 2021 an den Start gehen sollen. Stay tuned.

---

Kapitel 6

Ausblick: Und jetzt?

„Tja, gute Frage.“

Meine Zeit bei der SMF hat mir gezeigt, dass das stetige Springen zwischen Projekten nicht unbedingt mein Metier ist. Ich halte eine Zukunft als UX Designer für mich zwar für realistisch, glaube aber, dass ich langfristig im B2C-Bereich arbeiten möchte.

Konkret kann ich mir Unternehmen vorstellen, die ein einzelnes Softwareprodukt auf verschiedenen Plattformen anbieten. Das ist natürlich erstmal keine besondere Eingrenzung, davon gibt es Millionen. Viel weiter möchte ich mich auch gar nicht eingrenzen, denn bevor es aber in den Arbeitsmarkt geht, möchte ich mich noch weiter bilden. Als konkreter, nächster Schritt steht also direkt im Anschluss an den Bachelor ein Masterstudium in Köln an.

Im Oktober, zeitgleich zur Bachelorarbeit, habe ich am Bewerbungsverfahren der KISD teilgenommen und einen der 25 Plätze für den Masterstudiengang »Integrated Design« ergattern können. Die KISD funktioniert ein bisschen anders als die Fachhochschule Potsdam, und ich habe mich schon bei der Bewerbung einem von vier Clustern zugeordnet:

• Material Systems & Lab Culture
• Social & Public Innovation
• Visual Cultures & Politics
• Urban Intensities & Resources

Passend zur Bachelorarbeit werde ich also die nächsten zwei Jahre in der Kölner Südstadt eine Masterarbeit über Visual Cultures & Politics verfassen, vielleicht sogar über das gleiche Thema in ausführlicherer Form.

Die Richtung der Bachelorarbeit – Fake news und soziale Medien – könnte auch ausschlaggebend für meine Arbeitssuche sein, ich gehe nämlich stark davon aus, dass keines von beiden in den nächsten Jahren weniger relevant wird. Wenn ich sowieso also schon rund 2,5 Jahre mit dem Thema verbringe, warum dann nicht bei den Firmen bewerben, die sich tatsächlich aktiv damit auseinandersetzen?

Aber das ist dann ein Thema für Kapitel 7, nach dem fertigen Master.

• ↑ Zurück nach oben
• Impressum