ResearchGate Mobile
Konzeption und Design einer Android-App von Grund auf für die größte wissenschaftliche Online-Community
Das Produkt
ResearchGate ist eine Online-Plattform, auf der Forschende Zugriff auf über 160 Millionen Publikationsseiten haben und über die Entwicklungen in ihrem Fachgebiet auf dem Laufenden bleiben. Außerdem können sie sich mit ihrer Community vernetzen, ihre Forschung teilen, die Zusammenarbeit mit anderen Forschenden fördern und detaillierte Statistiken zur Wirkung ihrer Arbeit abrufen – mit einer Bewertung ihres Einflusses und einer Übersicht über ihre Zitationen.
RG wird (Stand 2023) von 25 Millionen Forschenden weltweit genutzt. Gemessen an der Zahl der aktiven Nutzenden gilt es als das größte berufliche soziale Netzwerk für Wissenschaft und Forschung.
Ursprünglich für Studierende im Bachelor- und Masterstudium konzipiert, war es von Anfang an das zentrale Anliegen von RG, freien Zugang zu wissenschaftlichen Publikationen zu bieten und Wissen so für alle zugänglich zu machen.
Projektüberblick
| Firma | ResearchGate GmbH |
| Produkt | Android-App |
| Team | Produktabteilung → Design-Team |
| Rolle | Senior Product Designer I |
| Umfang | UX, UI, Designsystem |
| Tools | Figma |
| Zeitraum | Juli – Dezember 2022 |
Ich habe die Android-App von ResearchGate von Grund auf gestaltet – inklusive Login, Feed, Profil, Publikationen und Navigation –, um das Engagement auf der Plattform zu steigern und das zentrale Bedürfnis der Nutzenden zu erfüllen, über neu veröffentlichte Forschung auf dem Laufenden zu bleiben.
Herausforderungen
Wo und wie anfangen? Die Antwort liegt immer bei den Nutzenden. Ich habe einige der Hauptprobleme der iOS-App gesammelt, zusammen mit den Erwartungen an das Verhalten bestimmter Features.
Es ist, als würde der Algorithmus Beiträge recyceln. Ich habe den Eindruck, dass sich die vorgeschlagenen Beiträge ständig wiederholen. Manche davon habe ich schon etwa zehnmal gesehen.
Promotion an der Max-Planck-Gesellschaft
Warum soll ich mir die Mühe machen, meine Interessen im Profil anzugeben, wenn im Feed nichts dazu vorgeschlagen wird? Wenn ich ein Interessengebiet angebe, erwarte ich auch Publikationen genau zu diesem Thema.
Professur an der Charité – Universitätsmedizin Berlin
Dass es 2021 keine ResearchGate-App für Android gibt, ist unvorstellbar. Warum wird iOS bevorzugt?
Forschungstätigkeit an der LMU
Die iOS-App ist sehr einfach gehalten und bietet nur den Feed. Die übrigen Funktionen der Web-Version fehlen, und das ist enttäuschend.
Forschungstätigkeit an der Max-Planck-Gesellschaft
Plan
Die einzelnen Schritte für das Design der App, die im weiteren Verlauf dieser Case Study ausführlich erläutert werden:
1) Desk Research
Benchmarking, das Lesen von App-Store-Bewertungen und das Feedback des Customer-Success- und des Web-User-Research-Teams sind die ersten Schritte, um herauszufinden, was zu tun ist.
2) Feature-Map
Für die iOS-App und die Web-App müssen Übersichten der implementierten Features erstellt und gegenübergestellt werden, um das Ausmaß der Unterschiede sichtbar zu machen und den Product Manager darauf aufmerksam zu machen.
3) Rollenbasierte Personas definieren
Rollenbasierte Personas und ihre Journeys müssen definiert werden, da bestimmte Screens je nach Rolle unterschiedlich dargestellt werden.
4) UX-Phase starten
Wireframes für die Features erstellen, die der Product Manager priorisiert, und die Varianten gemeinsam mit dem anderen Head of Design evaluieren.
5) Design-Ops-Phase starten
Auf Basis des Designsystems der Web-App muss ein neues Designsystem für die mobilen Apps entstehen – nach WCAG-Standards und inklusive Tokenisierung.
6) UI-Phase starten
Sobald Wireframes und Spezifikationen für ein Feature fertig sind und das Designsystem nahezu* abgeschlossen ist, beginnt die Gestaltung der finalen Screens pro Feature.
Recherche
🔎 3 Research-Apps im Benchmark
um zu sehen, was sie bieten: von Features über die User Experience bis hin zu Login- und Registrierungsmethoden.
⭐️ Rund 40 analysierte App-Bewertungen
um die Vorlieben und Frustrationen der Nutzenden mit der iOS-App zu verstehen.
😬 Ohne Übertreibung: mehr als 500 Feedback-Nachrichten
aus der Customer-Success-Plattform, die sich direkt auf die mobile App bezogen, dazu die Erkenntnisse, die das User-Research-Team in den Vorjahren gesammelt hatte. Noch in Zeiten ohne KI bin ich alle durchgegangen, habe eine Trendgrafik erstellt und verstanden, warum scheinbar alle die App hassten.
🗺️ Feature-Map
der Web-App und der mobilen App. Sie machte deutlich, wie viele Features in der mobilen App fehlten, und eröffnete die Diskussion mit dem restlichen Team darüber, womit wir anfangen sollten.
Erkenntnisse
👉🏻 Einige Web-Funktionen waren in der App durchaus vorhanden … allerdings unter anderem Namen, sodass sie schwer zu erkennen oder überhaupt zu finden waren. Eine einheitliche Benennung gab es weder in der UI noch im Backend.
👉🏻 Die Nutzenden erwarteten häufiger automagische Vorschläge.
👉🏻 Das Design der Publikationen und des Feeds musste sich grundlegend ändern. Das Erscheinungsbild wirkte – mangels eines besseren Wortes – fehlerhaft.
Fazit
Durch die Research-Phase verlagerte sich der Projektfokus: Statt die iOS-App einfach für Android nachzubauen, ging es nun darum, die Lücke zur Web-App zu schließen.
Mit Unterstützung des Content-Design-Teams und des Rechtsteams musste Konsistenz bei der Terminologie und den Texten in der App hergestellt werden.
Design Ops
Ich habe das Designsystem an mobile Standards angepasst – was in gewisser Weise bedeutete, dass ich ohnehin ein eigenes System für Mobile aufbauen musste. Das Design-System-Team war für die Pflege des Systems der Web-App zuständig, die Aktualisierung und Pflege des mobilen Systems lag jedoch in meiner Verantwortung.
Ich habe die Komponenten leicht angepasst, damit sie die Android-Standards und die WCAG besser erfüllen, und gleichzeitig Varianten für Light und Dark Theme mit den jeweiligen Tokens erstellt.
Designlösungen (nach Feature)
In diesem Abschnitt fasse ich die im „Vorgehen“ beschriebenen UX- und UI-Aspekte zusammen und konzentriere mich nur auf die Features, die entscheidend waren, um den Pain Point zu beseitigen, nicht auf dem Laufenden zu bleiben.
Haupt-Feed
| Problem | • Die Nutzenden empfanden die Publikationen im Feed als zufällig: Es war unklar, ob sie nach Upload-Datum oder nach Empfehlungen anderer Forschender sortiert waren. • Die Publikationskarten ließen sich visuell nicht klar voneinander unterscheiden – wo beginnt eine Publikation und wo endet sie? |
|---|---|
| Rahmenbedingungen | • Das Backend der App musste neu geschrieben werden, um der Logik der Web-App zu entsprechen. • Neue Features mussten entwickelt werden, um mit der Web-App gleichzuziehen. • Die User Flows der App mussten dokumentiert und an die bestehenden Implementierungen der Web-App angeglichen werden. • Alle Screens mussten von Grund auf neu gestaltet werden. |
Kennzeichnungen im Feed
Als Erstes ging es um die Kennzeichnungen der Feed-Karten, um klar zu unterscheiden, was Personen aus dem eigenen Netzwerk posteten, was sie empfahlen, was das System vorschlug und was Werbung war.
Layouts der Feed-Karten
Wir haben verschiedene Layouts mit unterschiedlicher Informationshierarchie vorgestellt – basierend auf dem, was die Nutzenden uns als auf den ersten Blick relevant genannt hatten.
• Variante A zeigte ein einfacheres Layout mit Karten in voller Breite und hob die Abbildungen der Publikation als Raster hervor, gefolgt vom Titel.
• Variante B bot ein kartenbasiertes Layout, das den Titel der Publikation und die Autorinnen und Autoren hervorhob, gefolgt von den Abbildungen als Raster.
• Variante C bot dasselbe kartenbasierte Layout wie Variante B, legte den Schwerpunkt aber auf die Abbildungen, gefolgt von Titel und Autorinnen und Autoren. Auch die Abbildungen wurden anders dargestellt: alle in gleicher Größe und statt in einem Raster mit horizontalem Scrollen, um weitere anzuzeigen.
Letztlich bot Variante C mehr visuelle Konsistenz und mehr Informationen beim Scrollen. Deshalb entschied sich das Team für diese Option, um sie weiter zu validieren.
Ich habe eng mit dem Head of Design und den Product Designern der Web-App zusammengearbeitet, damit die Vorschläge zur Web-App passten, sowie mit dem User-Research-Team, um persönliche Interviews zur Validierung der Ideen zu organisieren.
Hier eine kurze Aufnahme der Interaktion im Feed:
• Das ausgewählte Feed-Design wurde mit Version 1.2 der iOS-App und Version 1.0 der Android-App veröffentlicht.
• Das Feedback über die App-Bewertungen war überwiegend positiv. Unter anderem hieß es, der Feed sei leichter zu navigieren und wirke frischer.
Publikationsdetails
| Problem | • Die Nutzenden empfanden die Details einer Publikation als über den ganzen Screen verstreut. Es gab keine echte Logik, wie die einzelnen Bereiche zu lesen waren – vor allem beim Abstract: Die Abbildungen befanden sich an einer völlig anderen Stelle, sodass es umständlich war, sie zu öffnen und dann zurück zum Abstract zu scrollen. • Die Aktionen zur Publikation wirkten willkürlich platziert. |
|---|---|
| Rahmenbedingungen | • Neue Features mussten entwickelt werden, um mit der Web-App gleichzuziehen. • Die User Flows der App mussten dokumentiert und an die bestehenden Implementierungen der Web-App angeglichen werden. • Alle Screens mussten von Grund auf neu gestaltet werden. |
Publikations-Header
Wir haben verschiedene Layouts mit den relevanten Informationen zum Titel der Publikation vorgestellt: Titel, Autorinnen und Autoren, DOI, Publikationstyp, Verfügbarkeit des Volltexts sowie Datum und Journal der Veröffentlichung. Außerdem gab es die Social Buttons und die Action Buttons (zum Ansehen und Herunterladen des Volltexts).
• Variante A hob den Titel der Publikation und die DOI hervor. Die Autorinnen und Autoren wurden – wie auf der Web-Plattform – als Liste dargestellt.
Die anderen Varianten (B, C und D) hoben Autorinnen und Autoren, DOI und Datum in dieser Reihenfolge hervor, unterschieden sich aber darin, ob Buttons beibehalten wurden oder nicht:
• Variante B bot alle Buttons: Volltext herunterladen, Volltext ansehen sowie die Social Buttons (Empfehlen, Teilen, Speichern).
• Variante C bot nur die Social Buttons.
• Variante D bot nur den Button in der Top App Bar, in den all diese Funktionen ausgelagert werden konnten.
Letztlich überzeugte Variante C durch ihr aufgeräumtes Erscheinungsbild und wirkte laut Feedback der Nutzenden vertrauter. Die meisten gaben an, den Volltext weder auf ihr Smartphone herunterladen zu müssen (das ist eher ein Desktop-Anwendungsfall) noch die Option zum Ansehen besonders prominent zu benötigen.
Publikationsaktionen
Da die dateibezogenen Aktionen in ein Menü in der oberen Leiste ausgelagert wurden, folgte als Nächstes dessen Design.
• Diese Aktionen wurden ihrer Wichtigkeit entsprechend an erster Stelle aufgeführt.
• Weitere wichtige Aktionen wie das externe Teilen (Social Media, E-Mail) und das Beanspruchen der Autorschaft einer Publikation wurden für dieses Menü berücksichtigt.
Publikationsinhalt
Wie bereits erwähnt, lag das Hauptproblem beim Inhalt im Aufbau des Abstracts: Die Abbildungen befanden sich nicht im selben Block wie der Text, sodass es umständlich war, sie zu öffnen und für einen durchgehenden Lesefluss wieder zum Abstract zurückzuscrollen.
• Es wurden 3 Varianten erstellt, um die beste Darstellung all dieser Blöcke zu visualisieren.
• Variante A folgte der Struktur der Web-Version: zuerst die Statistiken, dann Abstract und Abbildungen, danach die Volltextdatei (falls verfügbar) und die Zugänge zu verwandten Bereichen (Zitationen, Referenzen und verwandte Forschung).
• Variante B zeigte die Statistiken oberhalb der verwandten Bereiche.
• In Variante C wurde ein Ansatz mit Tabs erwogen, um nicht so viele Blöcke auf einem Screen zu haben.
Letztlich bevorzugten die Nutzenden Variante A, weil sie der Web-Version sehr ähnlich war und weil es wichtig ist, die Statistiken zuerst zu sehen.
Ich habe eng mit dem Head of Design und den Product Designern der Web-App zusammengearbeitet, damit die Vorschläge zur Web-App passten, aber auch mit dem Rechtsteam. Publikationen sind ein urheberrechtlich sensibles Thema, und auch die Darstellung von Journal-Informationen erfordert bestimmte Formulierungen. Gemeinsam mit dem Content- und dem Rechtsteam haben wir festgelegt, welche Informationen sofort sichtbar sein sollten und beispielsweise nicht in Tooltips versteckt werden durften.
• Das ausgewählte Publikationsdesign wurde mit Version 1.2 der iOS-App und Version 1.0 der Android-App veröffentlicht.
• Das Feedback über die App-Bewertungen war überwiegend positiv. Die Nutzenden vermissten lediglich die Möglichkeit, Kommentare zu hinterlassen. Dieses Feature wurde für das erste Release jedoch nicht priorisiert.
Was ich gelernt habe
💻 Aus technischer Sicht
Ich habe gelernt, dass sich durch klare Feature-Breakdown-Sessions eine großartige Zusammenarbeit erreichen lässt. Das Engineering-Team ist in der Regel motiviert, das umzusetzen und zu verbessern, was das Produktteam plant – und diese Sessions sorgten dafür, dass alle auf demselben Stand und zugleich inspiriert waren, um die bestmöglichen Ergebnisse zu erzielen.
👥 Aus Sicht des Stakeholder-Alignments
Ich habe auf die harte Tour gelernt, dass nicht alle Stakeholder offen für Ideen und Verbesserungen sind – vor allem nicht in Führungspositionen. Nicht falsch verstehen: Ich will niemanden schlechtmachen. Aber die Entscheidungen über den App-Launch, die Features und das Design lagen zu einem gewissen Grad nicht bei uns, dem Mobile-Team, sondern auf CPO-Ebene – bei jemandem, der mit dem Prozess kaum etwas zu tun hatte und sehr altmodische Vorstellungen davon hatte, wie Delivery funktionieren sollte (nicht agil). Daraus habe ich gelernt, dass in manchen Unternehmen eines Tages Entscheidungen des oberen Managements kommen können, die einen – egal wie viel Research man betrieben hat – wieder bei null anfangen lassen. Und dann muss man sich eben anpassen.