1) Summary
| Company | ResearchGate GmbH |
| Product | Android Mobile App |
| Team | Product Department → Design Team |
| Roles | Senior Product Designer I |
| Scope | UX, UI, design system |
| Tools | Figma |
| Timeline | July - December 2022 |
| Overview | I designed ResearchGate's Android app from scratch, including the login, feed, profile, publications, and navigation experiences to increase engagement with the platform as well as alleviating the primary need of keeping up to date with new research being published. |
2) Product and business context
Product overview
ResearchGate is an online platform that allows scientists and researchers to access over 160 million publication pages and stay up to date with what's happening in their fields, as well as networking with their community, sharing their research, fostering peer collaboration, and getting in-depth stats of the impact of their work, by scoring their influence and keeping track of their citations.
RG is currently used by 25 million scientists around the world, as of 2023. It is considered the largest professional social network for scientists and researchers by active users.
Initially designed for undergrad and graduate students, RG's main motivation has been to provide free access to scientific publications to make knowledge accessible.
The challenges
The RG iOS app, which was created at some point in the 2010s, was not supported anymore due to lack of usage. Users back then were not engaged enough in mobile behaviour and only used ResearchGate on its web app version.
However, with the increasing trend of mobile usage, the need to revive it became a business priority - and with that a brand new team of Mobile Engineers, a Product Manager, Engineering Manager, and myself were hired to bring it back to life, as well as creating the brand new Android version.
• How to make the app interesting became also a priority - how to display so much publication data so that it didn't overwhelm the users was a constant question from the stakeholders, as well as what could be done to keep the users hooked.
We could identify some pain points with the iOS app via support tickets and app store reviews:
• De-synchronization with the web app: any interaction done with publications (recommending or saving them) was not synced to the web app and only kept locally in the mobile app. 😠 This was especially infuriating for users, since all the saved findings could never be found when using the platform on their computers.
The existing iOS app had issues that we needed to tackle:
• It lacked the visual status quo of post-2020 apps
• It displayed outdated branding guidelines
• Its performance was below average due to old technology
Success metrics
For Q4 in 2022, we set up the following:
• Playstore downloads: Reach 1 million.
• Appstore downloads: Reach 1 million. The initial download number was around 500k.
• Support ticket reduction: Ambitious but established - get to 0 complaints about the two apps.
• App ratings: Reach above 4.5 on both versions.
3) Discovery and research
The discovery process was based on the business pain point described above: How to make the app interesting while keeping the users hooked.
The primary objective of this phase was to understand:
• What were users thinking of the existing app
• What were they expecting to have present in the interface
• What device would they find more useful
• What are their behaviours to find new publications from their and related fields
Research inputs
| Source | What was investigated | Key insights |
|---|---|---|
| Support tickets (100 in Q3 2022) | • De-synchronization between iOS app and web platform. | • Saved items via web app didn't appear on the mobile app. • There was no functionality to save research on the app (at least, not obvious). |
| User interviews (20) | • Device behaviour • App expectations |
• Users tend to save publications they find interesting to read later in larger devices. • The publication's abstract and figures are the first point of attention. • The primary use of the mobile app is to find research, not to read or go through it immediately. • There was a cap as to what to find in the feed - some suggestions were perceived as irrelevant or not new. |
| Competitor analysis | • Onboarding flows • Feed organization • Publication display |
• The onboarding experience of several apps is based on selecting research topics. • The feed organization can be customized by recent or relevant publications. • The publication display stays consistent across apps: Title, abstract and figures are presented. |
Key findings
• Disguised as follow, users did not associate this functionality to "save". The wording made the feature invisible to most.
• As stated, when the users did find the functionality, the saved items did not appear on the web app. They only got saved locally in the mobile app, making the feature pointless for the primary need to read research later.
• The perception of suggested posts being not new, repetitive, or irrelevant was strong.
• Interview participants said that this is why they were not returning to the app: Every publication on their feeds from that days had been seen entirely.
“It's like the algorithm is recycling posts.”
- PhD candidate at the Max Planck Gesellschaft
“Why do I bother to fill out my interests on my profile if nothing about them gets suggested?”
- Professor associated to Charité Universitätsmedizin Berlin
Design principles derived from research
Based on the findings, we established these principles to guide the redesign:
• Standardize feature wording between web app and mobile apps.
• Present a clear information hierachy within publications.
• Clarify the logic of the suggested research, RG score, and h-score.
• Adopt a more visual language for the app, rather than just text.
These principles became the foundation for evaluating concepts and prioritizing solutions during the design phase.
Significance of this research
The discovery phase shifted the project focus from just designing a new app to solving a broader understanding problem.
Instead of designing the screens cosmetically, the challenge was reframed around:
• Providing clarity to users about terms that were a mystery in the web app.
• Improving the visual feedback when actions like recommending or saving were performed.
• Improving the publication architecture displayed.
4) Design solutions
Based on the previous findings, the entire app required a redesign. In this section, I will focus on the key features that were addressed:
4.1) Main feed
• Users felt that the publications appearing on the feed were random: It was not clear whether they were sorted by upload date or by other researchers' recommendation.
• The publication cards were not visually distinguisable - where does a publication begin and end?
• The reason why some publications appeared on a user's feed was not obvious. Was the feed populated by research interests, or by others' recommendations?
Backend:
• The backend used in the app needed to be rewritten to match the logic of the web app.
• New features needed to be developed to achieve parity with the web app.
Design and Frontend:
• The design system needed to be updated with new usability standards and the new company branding.
• The app user flows needed to be documented and updated to match those found in the existing web app implementations.
• All screens needed to be done from scratch.
Feed qualifiers
The first aspect to tackle was the feed card qualifiers to establish a distinction between what users from a user's network were posting, versus what they were recommending, versus what the system was suggesting, versus ads.
Feed card layouts
Different layouts were presented with different information hierarchy after what users had told us to be relevant for them to see at first glance.
• Variant A showed a simpler layout with full-width cards, emphasizing the figure collection attached to the publication as a grid, followed by its title.
• Variant B offered a card-based layout, emphasizing the publication title and its authors, followed by the figure collection as a grid.
• Variant C offered the same card-based layout as Variant B, but the emphasis was on the figure collection, followed by the title and the authors. The figure collection was different. It presented figures with the same size and integrated the idea of scrolling horizontally to see more of them, instead of having a grid.
In the end, Variant C proved more visual consistency and allowed for more information on scroll, so it was the chosen option by the team to be further validated.
I collaborated closely with the Head of Design and the Web App Product Designers to ensure the proposals to be aligned with the web app; as well as with the User Research Team to organize in-person interviews to validate the ideas.
• The selected feed design was released with the iOS app version 1.2 and the Android version 1.0.
• The feedback gotten via app ratings was generally positive. Some mentions included that the feed was easier to navigate and that it looked fresher.
4.2) Publication details
• Users felt that the details of a publication were scattered all over the screen. There was no real logic to read the different areas, especially when it came to reading the abstract: the figures were in a completely different place, so it was cumbersome to open the figures and then scroll back to the abstract.
• The actions related to the publication felt randomly placed.
Backend:
• New features needed to be developed to achieve parity with the web app.
Design and Frontend:
• The app user flows needed to be documented and updated to match those found in the existing web app implementations.
• All screens needed to be done from scratch.
Publication header
Different layouts were presented with the relevant information of the publication title: The title itself, authors, DOI, publication type, whether the full-text was available, date and journal of publication. In addition, the social buttons and the action buttons (to view and download the full-text) were made available.
• Variant A emphasized the publication title and the DOI. The authors were presented as a list, just like in the web platiform.
The other variants (B,C, and D) emphasized the authors, DOI, and date in that order, but explored the fact of keeping buttons or not. In this sense:
• Variant B offered the full set of buttons: Download full-text, view full-text, and the social buttons (recommend, share, save).
• Variant C offered only the social buttons.
• Variant D offered only the top app bar button, where all those functionalities could be outsourced to.
In the end, Variant C proved to be more visually appealing by its cleanliness and to provide more familiarity according to users' input. Most of users expressed not needing to download the full-text to their phones (this is more a desktop use case) or having the option to view it with most prominence either.
Publication actions
Because the file-related actions were outsourced to a drawer in the top bar, its design followed.
• These actions were the first ones to be listed in order of importance.
• Other important actions, like sharing externally (social media, email) and claiming authorship of a publication, were considered for this menu.
Publication content
As stated earlier, the main problem perceived with the contet was how the abstract was constructed: the figures were not in the same block as the text, so it was cumbersome to open the figures and then scroll back to the abstract to have continuity.
• 3 variants were created to visualize the best ways to present all these blocks.
• Variant A followed the structure given in the web version: Present the stats, then the abstract and figures, then the full-text file (if available), and the related areas (citations, references, and related research) accesses.
• Variant B presented the stats above the related areas.
• In Variant C, a tabbed approach was considered to not have so many blocks in one screen.
In the end, Variant A was preferred by the users because it was very similar to the web version, and because stats are important to see first.
I collaborated closely with the Head of Design and the Web App Product Designers to ensure the proposals to be aligned with the web app, but also with the Legal Team. Publications are a copyright-sensitive topic, and journal information display also requires specific language to be presented. Together with the Content and the Legal Teams, we established which information should be immediately visible and not hidden away in tooltips, for example.
• The selected publication design was released with the iOS app version 1.2 and the Android version 1.0.
• The feedback gotten via app ratings was generally positive. Users were only missing the capability to leave comments. This feature was however not prioritized for the first release.
5) Design system
I adapted the design system to mobile standards - and in a way, it meant I had to create a system for mobile anyway. The Design System Team was in charge of maintaining the system for the web app, but it fell under my responsibility to update and keep the mobile system up to date.
I changed the components a little bit to comply better with Android standards and WCAG, while also creating light and dark theme equivalents.
6) Impact
Business impact
On the app download side of things, the numbers speak for themselves: After the first release of the Android app and the fix for the iOS app, the downloads increased and surpassed the million, while the ratings also went up:
| App Store downloads | 1 million |
| Google Play downloads | 1+ million |
| App Store rating | 4.3 / 5 as of Q1 2023 |
| Google Play rating | 4.7 / 5 as of Q1 2023 |
With this, the success metrics were met. ✔
User impact
After the release, users were asked - and some of them just reached out to give their opinion - if they could tell us about their experience with the app. Some of the highlights were:
• They felt happiness that they could finally browse and save publications on the go.
• They felt some features were missing, like being able to upload publications, but in general, there was the expectation that this feature would come soon.
• The learning curve wasn't so hard - they could understand how to use the app quite easily.
• There were cases in which the app crashed here and there, but then after investigating, it turned out the mobiles being used were running on older, unsupported versions of Android. Users were made aware of this.
7) Reflection
What I learned
• From the technical perspective, I learned that great collaboration can be achieved by having straightforward feature breakdown sessions. Engineers are usually eager to implement and improve what product has on the cards, and having these sessions to ensure everyone was on the same page, but also inspired, to get out the best results possible.
• From the stakeholder alignment perspective, I learned the hard way that not all stakeholders will be receptive to ideas and improvements, especially when they are in management positions. Don't get me wrong, I'm not throwing shade at anyone, but the decision-making process on the app launch, the features, and the design, was at a degree not up to us, the Mobile Team, but at the CPO level, who had little to nothing to do with the process, and very old-fashioned ways to think how delivery should be done (not agile). This made me learn that in certain companies, no matter how much research you do, upper management decisions can come up one day and make you start from scratch. And one just has to adapt.
What I'd improve
If given more time, I would have prioritized and worked thoroughly on:
• The upload research feature, since this was also rated important for the users who wanted to publish pre-print publication types. This would have increased the app adoption without a doubt.
• The comment publication feature to trigger more conversations about research. That would have also increased the social aspect of the platform.