- Kontext: Zusammenarbeit mit einem Indie-Webentwickler, der die Web-App Sportsdate.app erstellt und betreibt.
- Meine Rolle: Redesign des UX-Konzepts und User-Interface der potentiell gesamten App.
- Meine Tools: Miro, Figma
- UI-Komponenten-Framework: Ionic
- Zeitlicher Rahmen: Noch andauernd, Gestartet im Februar 2024
Inhaltsverzeichnis
- 1. Das Thema verstehen: Was ist der Status quo der App? Was können wir von der Konkurrenz lernen?
- 2. Antizipation des Umfangs: Definieren verschiedener Arten von Edge-Use-Cases und Skizzieren erster Ideen in Wireframes und Task-Flows.
- 3. Zwischen abstrakt und detailliert: Iterationen von App-Architektur, Wireframes und Benutzer-Interaktionen.
- 4. First implementations: Menu navigation restructured
- Work in progress: Visuelles/Corporate Design, Higher-Fidelity, Tests/Feedbacks und Iterationen, schrittweise Implementierung
1. Das Thema verstehen
1.1 Aktueller Stand der App
Sportsdate ist eine Web-App und PWA, die in Berlin organisch mit einer engagierten, wenn auch kleinen Nutzergemeinschaft wächst. Die App wurde entwickelt, um sportliche Aktivitäten jenseits der Grenzen sozialer Medien besser zu organisieren. Sie richtet sich zunächst an Beachvolleyball-Fans, ist aber für eine Vielzahl von Sportarten gedacht.
Typische Anfragen in entsprechenden Social Media Gruppen.
1.2 App audit
Auf der Grundlage einer anfänglichen Frage-und-Antwort-Runde über die Motivationen, Problempunkte und Visionen des Gründers erstellte ich einen umfassenden Bericht über die App. Die Ergebnisse lassen sich in zwei Bereiche unterteilen. 1. UX- und UI-Grundlagen und 2. spezifischere konzeptionelle Fragen.
1.3 Von anderen Apps lernen
Es gibt bereits Apps, die dabei helfen, sich in Gruppen für den Sport zu organisieren. Eine umfassende Recherche hilft uns zu verstehen, warum wir Sportsdate noch brauchen, von welchen positiven Ansätzen wir lernen können und wo wir uns abheben können.
1.4 Erkenntnisse und Konzept
2. Den Umfang abschätzen
2.1 Den Kopf frei bekommen
2.2. Komplexität eines User Flows
Ein erstes hypothetisches User-Flow-Diagramm, das den gesamten Prozess der Erstellung einer Aktivität in der App beschreibt. In diesem Schritt war ich mehr daran interessiert, die mögliche Komplexität zu verstehen, um sie später bei Bedarf zu verkürzen oder in verschiedene Flows zu unterteilen.
2.3 Grenzfälle der Anwendung
In der bisherigen Auseinandersetzung sind verschiedene Anwendungsfälle der App sichtbar geworden, die aber noch nicht im Detail beschrieben wurden, was jetzt nachgeholt werden sollte. Darüber hinaus wurde eine schematische Skizze erstellt, welche UI-Komponenten die einzelnen Fälle darstellen könnten.
3. Zwischen abstrakt und detailliert
Wichtig ist an dieser Stelle noch einmal zu erwähnen, dass eine mögliche Umstrukturierung der gesamten App, einschließlich der zugrundeliegenden Informationsarchitektur und der Sitemap, möglicherweise gewünscht ist.
Um weitere Designentscheidungen treffen zu können, war es daher wichtig, die App ganzheitlich aus der Vogelperspektive und im Detail zu durchdenken.
3.1 Helikoptersicht
Nachdem der Funktionsumfang mit Hilfe der Edge Cases skizziert wurde, können verschiedene Varianten der Infoarchitektur durch Sortierung von benannten und farblich gekennzeichneten Karten miteinander verglichen werden.
3.2 Das Kleine verstehen, um das Große zu hinterfragen
Die Gewissheit, die das Card-Sorting verschaffte, machte das Skizzieren erster Bildschirme wie von selbst. Je weiter man eintauchte, wurden Aspekte sichtbar, die sich wiederum auf das Große und Ganze wiederspiegeln.
3.3 Große Entscheidungen nicht leicht gemacht
"Die Fokussierung der App auf eine Sportart würde sie wahrscheinlich stärken, ..."
Die derzeit in der App angebotenen Sportkategorien folgen keinem bestimmten Schema und sind im Laufe von rund fünf Jahren organisch gewachsen. Einerseits spiegeln sich diese „nur“ in den Filtermöglichkeiten für Aktivitäten und Orte in der App wider – andererseits orientieren sich Nutzergruppe, Marke und Identität der App an der Sportart. Eine Fokussierung auf eine Sportart würde die App wahrscheinlich stärken, ist aber derzeit nicht die Absicht des Entwicklers.
3.4 Mobile first
Die derzeitige Web-App hat einige kleinere Schwächen in Bezug auf die Darstellung auf verschiedenen Bildschirmgrößen, die sich im Menü (oben/unten) und in der Übersichtlichkeit der Seitenlayouts zeigen. Um dies bei der Neugestaltung besser lösen zu können, sollte hier frühzeitig eine Orientierung geschaffen werden.
3.5 Besucher zu Nutzer
"Wie Besucher die Web-App sehen und nutzen können im Vergleich zu registrierten Nutzern..."
3.6 Wie man die Karte liest
Die App verfügt über eine Karte, deren Orte die Nutzer entdecken, vorschlagen oder zur Planung von Aktivitäten nutzen können. Die Flaggenmarkierungen der Orte sollen über den Namen hinaus auf den ersten Blick weitere Informationen liefern, zum Beispiel ob dort eine öffentliche Aktivität geplant ist, oder ob an dem Ort generell häufiger welche stattfinden.
"Noch einmal: Fast alles hängt zusammen - man muss die einzelnen Bereiche der App bis ins Detail untersuchen, um das große Ganze zu verstehen."
3.7 Das Herzstück - die Aktivitäten
Das Herzstück der App ist die Planung von Veranstaltungen. Das Erstellungs- und Teilnahmemanagement soll den Nutzern je nach Anwendungsfall und Kontext verschiedene Möglichkeiten bieten - der Prozess soll so umfassend wie nötig und dennoch so einfach wie möglich sein. Diesem Thema wird im weiteren Verlauf noch viel Aufmerksamkeit gewidmet werden müssen.
3.8 A-B-C-Varianten
Einige Entscheidungen sollten auf der Grundlage eines Vergleichs der möglichen Optionen getroffen werden. Hier stellt sich die Frage, wie die verschiedenen Möglichkeiten der Erkundung von Aktivitäten - Karten- und Listenansicht - am besten miteinander interagieren.
4. Erste Implementierungen
Nachdem in der vorherigen Phase eine umfassende Vision der App und ihrer Teilbereiche erarbeitet und skizziert wurde, fühlt sich die nächste Phase wie ein kleiner Rückschritt an.
Es erscheint jedoch realistisch, die bestehende Anwendung zunächst „aufzuräumen“ und sie dann Stück für Stück „neu aufzubauen“.
4.1 Navigationsmenü
Es hat sich als besonders fruchtbar für das gegenseitige Verständnis mit dem Entwickler erwiesen, mit Screenshots der bestehenden Anwendung zu arbeiten, sie zu zerlegen und in neuer Form wieder zusammenzusetzen.
Vor- und nach der ersten Implementierung
4.2 Top-Nav-Bar
Wie spiegelt sich die Menüführung von Haupt- und Unterseiten in der oberen Navigationsleiste wider? Das hier gezeigte Design kann eigentlich als bewährte UX/UI-Basis bezeichnet werden und ist nichts Ausgefallenes.
Wird fortgesetzt.