Musication

Wer kennt das nicht? Es herrscht eine ausgelassene Stimmung in einer Gruppe von Menschen. Eine Person beschließt, die Stimmung mit Musik zu unterstützen und startet dafür eine Musiksession mit einem der Streaming-Dienste. Leider ist das nicht immer einfach, denn die Musikgeschmäcker können bekanntlich unterschiedlich ausfallen. Wenn die Geschmäcker sogar zu weit auseinander liegen, können sich die Beteiligten schlimmstenfalls unwohl fühlen und die Stimmung ist nicht mehr dieselbe. Wie wäre es denn, wenn sie die Musik als Gesprächsthema gezielt nutzen und die Musik als zentraler Abschnitt der gemeinsamen Interaktion mit einfließt?

Hört zusammen. Erlebt zusammen. Das ist die Devise unserer Applikation, die wir Musication getauft haben. Eine App, die als Ziel verfolgt, Menschen durch Musik zusammenzubringen und einen Raum zu schaffen, wo man offen über die Musik und die Gefühle sprechen kann.

Wenn es um die Gestaltung und Konzeption von Dienstleistungen und Produkten geht, ist der sogenannte Design Sprint eine bewährte Sammlung von Methoden. Der Design Sprint, der in fünf Phasen unterteilt ist, wurde in diesem Projekt genutzt, um mögliche Problemstellungen zum Thema “Gemeinsames Musikhören” zu erarbeiten, prototypisch umzusetzen und anschließend in Nutzer:innengruppen zu testen.

Sprint Monday - Map

Am allerersten Sprinttag ging es darum, ein langfristiges Ziel zu definieren, welches als Orientierungshilfe über unseren gesamten Projektprozess hinweg aktiv zu verfolgen ist. Unser Ziel ist demnach, ein Produkt zu schaffen, das Menschen durch Musik zusammenbringt und sie dazu anregt, darüber zu sprechen. Anschließend sollten auch sogenannte Sprintfragen formuliert werden, die Annahmen und Szenarien zu unserem Projekt beinhalten. Dabei soll man auf Bedenken und Zweifel eingehen, die unser Vorhaben zukünftig gefährden könnten und die es im Laufe des Projekts zu beantworten gilt.

Um die Interaktion der Nutzer:innen mit dem Produkt visuell aufzuzeigen, haben wir anschließend ein Flussdiagramm erstellt. Mit dessen Hilfe stellen wir nicht nur einzelne Akteur:innen grafisch dar, sondern verorten damit auch wichtige Schlüsselszenen in der Interaktion zwischen Mensch und Information, die wir anvisieren sollen.

Einsichtsreiche Interviews mit Proband:innen, die wir zufällig in Schwäbisch Gmünd angetroffen und zu ihren Erfahrungen und Bedürfnissen befragt haben, haben wertvolle Nutzungssituationen geliefert und die erste Datengrundlage für unsere Zwischenergebnisse gebildet. Sogenannte “How Might We”-Fragen haben noch unser Fragenkatalog vervollständigt und uns dabei geholfen, Zielperson und Schlüsselmoment aus dem Flussdiagramm für unseren weiteren Projektverlauf zu bestimmen.

Am Ende haben wir also beschlossen, dass wir jüngere Altersgruppen ansprechen und die Schlüsselmomente der Raum- und Gesprächsführung der App unter die Lupe nehmen wollen.

Sprint Tuesday - Research & Sketch

Am zweiten Tag hat eine Marktrecherche zu Produkten und Services, die einen ähnlichen Funktionsumfang und Zweck erfüllen, Aufschluss darüber gegeben, wie wir die Abgrenzung zu bereits bestehenden Angeboten zu wählen haben und mit welchen Lösungen wir unsere App zielgerichtet ausstatten sollen.

Der restliche Tag war dann äußerst kreativ ausgelegt, als jede:r einzelne von uns in einer viergliedrigen Sketching-Session grobe Ideen gesammelt, Varianten zu den besten Ideen gebildet und diese wiederum als Zeichnungen in einem Storyboard verewigt haben. Hier lag der Fokus weniger auf dem ästhetischen Wert, sondern vielmehr auf der Verständlichkeit und dem Detailgrad der Storyboards, welches die besten Produktideen zu einem geeigneten Anwendungsfall, dem Use Case, präsentieren soll.

Sprint Wednesday - Decide & Merge

Die Ergebnisse des Vortags sollten nun miteinander kombiniert werden, indem wir ein gemeinsames Storyboard und damit die Grundlage für unseren ersten Prototypen schaffen. Gruppenintern haben wir uns dazu unsere eigenen Sketches gegenseitig vorgestellt. Im gemeinsamen Gespräch haben wir unsere Bedenken und Einwände zu einzelnen Ideen geäußert und potenzielle Kandidaten in einem Votingsystem der Priorität nach geordnet.

Damit wir am Ende zu einem gemeinsamen Use Case kommen, welcher im Testing haargenau erprobt werden soll, galt es nur noch, die profitabelsten und aussichtsreichsten Ideen entweder zu einer Gewinneridee zusammenzuführen oder sogar gegeneinander antreten zu lassen, um schlussendlich die Testingszenarien benennen und geeignete Prototypen ausgestalten zu können.

Den Tag schlossen wir damit ab, dass wir ein gemeinsames Storyboard auf Basis der vorangegangenen Entwürfe jeder einzelnen Person ausgestaltet haben. Es zielt darauf ab, unseren Interaktions- und Nutzungsablauf detailliert aufzuzeigen, die Szenen in ihrem Verlauf zu verbildlichen und den zielgerichteten Nutzungskontext unseres Produkts darzustellen. Gleichzeitig haben wir uns auch auf ein Use Case geeinigt. Der behandelt ein einzelnes Smartphone mit der App, welches als “Terminal” zentral auf dem Tisch vor die Gruppe aus 3 bis 5 Proband:innen platziert werden soll. Die Gruppe selbst ist heterogen gehalten und kann sich aus Freund:innen, Bekannten und / oder Fremden zusammensetzen. Die Verwendung der App beschränkt sich hierbei auf einen geschlossenen Raum als Testumgebung und sieht vor, dass die Gruppe vor Ort in Präsenz zusammenfindet.

Sprint Thursday - Prototype

Am Sprint Thursday wird dann unser Prototyp nach Vorbild unseres gemeinsamen Storyboards erstellt. Der Prototyp soll jene Keyfeatures und Funktionen abdecken, die im Testing auf die Probe gestellt werden sollen. Aber um diese Keyfeatures im Testing überhaupt überprüfen zu können, kommt noch ein weiterer Fragekatalog zum Einsatz, der sich aus den einzelnen Research Questions, den Forschungsfragen unseres Projekts, zusammensetzt.

Aus der zentralen Forschungsfrage “Kann ein Gespräch über Musik stattfinden?” haben wir in den von uns ausgewählten Kategorien Gespräch, Personen, App und Umgebung weitere Unterfragen formuliert, die unsere Appfeatures mit Rücksicht auf den Nutzungksontext im praktischen Teil des Testings entweder bestätigen oder widerlegen sollen. Wir haben dazu also veschiedene Annahmen beschrieben, die behandeln sollen, ob Leute beispielsweise mit dem Herumreichen eines Handys einverstanden sind oder ob die App auf emotionale Phasen des Gesprächs Einfluss nehmen kann.

Nachdem dann gruppenintern noch die letzten Aufgabenbereiche und Rollen verteilt worden sind und der erste Kontakt mit Testpersonen erfolgt ist, stand dem Prototyping- & Testingprozess nichts mehr im Wege.

Sprint Friday - Test & Iterate

Durchgeführte Generalproben haben noch letzte Schwachstellen und Unklarheiten beseitigt, bevor der Prototyp am letzten Sprinttag auch wirklich in der Praxis Anwendung gefunden hat. Nachdem feststand, dass der Prototyp alle zentralen Features abdeckt und der Katalog aus den Forschungsfragen die wichtigsten Annahmen aufführt, mussten dann noch Fragen an die Tester:innen formuliert werden, die zur Überprüfung der Forschungsfragen dienen sollen.

Zwei Gruppen mit je 3 Personen nahmen an dem Test teil, der pro Gruppe bis zu einer Stunde dauerte. Im Rahmen eines geführten Interviews wurden zum Abschluss noch die Interviewfragen an die Personen gestellt, um qualitativ wertvolle Hintergründe zu den individuellen Benutzer:innenerfahrungen und -eindrücken sammeln zu können.

Im abschließenden Teil des iterativen Prototypings wurden zusätzlich noch Verbesserungen anhand des Feedbacks aus dem Testing vorgenommen. Der Prototyp wurde damit aufbereitet, indem wir uns genau angeschaut haben, was vor allem nicht funktioniert hat, an welchen Stellen die Anwender:innen auf Mühe und Frust gestoßen sind und wo die App grundsätzlich ihren Zweck verfehlt hat.

Aus dem Audio- und Schriftmaterial, das wir während der Interviews aufgezeichnet und notiert haben, konnten wir eine Vielzahl von Erkenntnissen gewinnen. Diese konnten wir dann in verschiedene Kategorien einteilen, die die Kategorien der Forschungsfragen inhaltlich erweitern sollen. [vgl. Sprint Thursday - Prototype]

1. Benutzer:innenpräferenz
2. Aufforderungscharakter (Affordance)
3. Navigation und Orientierung
4. Kommunikation und Feedback
5. Konsistenz und Balance
6. Sozial-emotionale Umstände
7. Erscheinungsbild und Wirkung

Ergebnis

Der nachbearbeitete Prototyp ist zu Beginn im Stile einer Umfrage und eines Tutorials aufgebaut worden, der die Nutzer:innen zuerst nach den Lieblingsmusikrichtungen und Lieblingskünstler:innen befragt. Anschließend werden sie durch den Prototypen durchgeführt, indem die einzelnen Funktionen der Sessionräume und der Hauptansicht Schritt für Schritt in der App erklärt werden.

Danach wechselt die App in einen Standardmodus, in welchem die App die einzelnen Songs abspielt, die auf Grundlage der Befragungen zu Beginn in einer für alle Beteiligten gemeinsamen Playlist kuratiert worden sind. Die App bietet auch mehrere Modi, die den spielerischen Charakter der App vermitteln und mit Hilfe von kleinen Minispielen die Stimmung auflockern und verschiedene Gesprächsanlässe anregen sollen. So blendet die App die Nachricht ein, die Lyrics zu vervollständigen oder den gerade abgespielten Song zu erraten. Wenn man die runde Schaltzentrale in der Mitte der Hauptansicht antippt, lassen sich die besagten Modi manuell auswählen. Individuelle Einstellungen sollen es auch ermöglichen, den Raum nach den Wünschen der Teilnehmer:innen zu gestalten.

Ausblick und Fazit

Sowohl der zielgerechte Anwendungsfall als auch die Testbedingungen erforderten einen ausgewählten Prototyp mit ausgewählten Features, die es zu überprüfen galt. Bei allen Features, die im Rahmen des Projekts nicht mehr realisiert werden konnten, handelt es sich in erster Linie um Wunschfeatures, die unsere Testpersonen in ihren Interviews geäußert haben. Hinzu kommen die vielen App-Features, die es beim Prototyping nicht über die Notiz hinaus geschafft haben oder nicht länger im Rahmen der technischen Umsetzung mittels der Prototypsoftware Figma lagen.

Wunschfeatures

• Modusvorschlag: Rückblick (Was hast du vor … Jahren gehört?)
• Modusvorschlag: Entweder-Oder
• Modusvorschlag: Stimmungs- bzw. situations- (Lernen, Lesen, …) und ortsabhängiges Feature (Musikvorschläge vor dem Eiffelturm, …)
• Featurevorschlag: Genreerfassung mit Tinderfunktion (Vorschau mit Swipen zum Liken oder Disliken)

Featureausblick

• Angemeldeter Host mit Gastaccounts (vgl. Netflix)
• Ping bzw. Pushbenachrichtigungen auf das Handy für Profile in Reichweite
• Sync-Connections zwischen mehreren Endgeräten
• …

Ähnlich wie der vorgeschlagene Modus ist auch der eigentliche Rückblick über den Prozessverlauf der letzten Sprinttage eine Erwähnung wert. Die Koordination der einzelnen Aufgaben während des Testings war hier nicht die einzige Erfahrung für zukünftige Projekte. Äußerst interessant ist auch der Vergleich der tatsächlichen Analyseergebnisse mit den zu Beginn des Projekts getroffenen Annahmen, welche Aussagen und Ansichten sich nun bewahrheitet haben oder an der Realität vorbeigegangen sind.

Darüber hinaus haben wir beide den Musikkonsum auch aus der Beobachtungsperspektive näher erfahren dürfen und viel über das mehrheitlich stimmungsgetriebene Konsumverhalten und die Bedürfnisse der einzelnen Benutzer:innen gelernt. Das Thema Musik mag uns allen vertraut und universell erscheinen, im Detail ist es aber auch ein überwiegend individuelles Thema, das stark vom Einzelnen und bei mehreren Personen auch vom Gruppenbild und Gemeinschaftssinn abhängt.