Scopus - Search and Discovery

@Elsevier - 2017 to Now


What is Scopus?

Scopus is an international platform, part of the Elsevier research porfolio, where researchers of all levels (undergrad, PhD students, scientists, etc.) can search/analyze literature, find experts in a field, identify trends in research, and more.

Intro

In 2017, I joined Elsevier.

Initially I worked on several small improvements to Scopus, including: a redesign to the search history page, addition of new searchable content, and an extension to facilitate the download of documents. In time, due to the nature of my projects, I became involved with Search.

In late 2018, I began my first big project; redesigning the Scopus homepage.


Redesigning the homepage

My approach to redesigning the homepage started with data we already had (analytics, previous user interviews, baseline studies, etc.).

My goal as I embarked on this redesign was to provide a more straight-forward user experience for first-time, new users (often undergrad and PhD students).

Text fields

Due to accessibility concerns, I aimed to first improve and therefore create a new standard for text input fields. For this part, I collaborated and involved many designers in the Scopus UX team, doing so we could all agree on a reusable component that would eventually be used across the site and potentially across products.


My objective in redesigning document search (and all other entities for that matter) was to make it seamless to use the features we already had in place. One of the most important and often misunderstood features was the ability to add additional search fields.

Though not popular with the common researcher, Advanced Search is a tool used by power users, mainly in the corporate sector. Users of Advanced Search often copy and paste long and specific queries, hence the taller text field.


My priority in redesigning author search was reducing the verbosity introduced in the original designs. This meant first showing the most common searching method (name, last name) and providing a way to toggle to “search by ORCiD”.


Users here are slightly different, not many researchers are tinkering with institution search, it is mainly administrators and librarians who want to know about the performance of certain institutions (including their own). To enable this use case, and get users faster to a “details” page, we introduced auto-suggest.


Document results

After many years of gathering insights on documents, I finally had a chance to redesign them. The goal here was to make documents modular and reusable. In the original designs we were using tables to represent document data, however this format did not scale well outside the document results page. The scalability issue lead to the creation of different variations of documents across the site. This was a problem.

Redesigning for documents was a highly collaborative effort. I led the discussions around the structure of a document and all the possible combinations depending on the type/kind of document. Other designers talked about the fonts we could use for the title, or the link treatments depending on the type of data (author, journal, call to action links, etc).


Filters

From here on out, I worked on the themes I outlined earlier on (filters, results, retention-driving features, etc.) in the context of the document results page.

Based on previous insights (both qualitative and quantitative), we determined which filters were used the most ( Year, Document type, authors, etc.) and how often they were used per session. During ideation and brainstorming with other designers, we came up with concepts to test.

Our aim in redesigning filters was to create a standard we could reuse across all results pages (authors, institutions, journals, patents, etc.). To do that we needed to establish a new, refreshed pattern for how filters display on the page.

The next step in designing filters was figuring the interactions. The proposals were either a drill-down (progressive disclosure) approach or a long page with tweaks to make it simpler.

I opted for a longer page as this would enable a much more efficient way of filtering by different categories. I also hid the filters with low usage under a show/hide toggle to reduce cognitive load and allow users to focus on the filters that mattered.

After testing the chosen approach for filters, I began iterating on more specific details (adding inputs for numbers to the year slider, transitions/animation, a way to clear the filters added, etc.).


80%+ of the usage on Scopus happens between two pages, the homepage and document results. The reason was that users often need to modify their searches by adding keywords or subtracting some. This process is iterative and continuous. Knowing this, we knew we needed a way to search on the document results page, but the options were a bit limited.

In the past there had been attempts at making search better by: establishing a more comprehensible query language, redesigning the homepage, introducing new features, etc. All of these ideas were focused on retaining the long-time, power user.

Throughout the years, the conversation changed to focus more on the common researcher. The common researcher had different expectations, they expected more query interpretation, more recommendations and streamlined ways to see their past searches.

Besides creating a new search field (a variation from the input/text fields created earlier on), I explored scroll behavior and details on how search would remain on the screen.

At last, I came up with more explorations to figure out the transition between an idle and active search box.


Key retention drivers

Features used on the document results page include: alerts, saved searches and analysis of results (with graphs). We saw these features correlated with more retention and engagement. The only problem was that the overall usage was low. We needed a way to highlight these more without throwing off the balance of the page.

The problem though wasn’t visibility as much as it was a lack of understanding. Icons on their own wouldn’t work and icons with labels were a bit too verbose on the page. I opted for a different solution which gave us a bit more room to explain the value of these features.


Desktop - table view

After testing a quick prototype with the new document results, we found there was still a need for a table format. It wasn’t as common, but some users (mainly editors and librarians) would compare meta data on the document results page. To achieve this in a more efficient way, I integrated a way to toggle between table and list results view.


Previewing authors from document results

While looking for documents is the primary use case of the document results page, there are some instances where users look for seminal papers to find important, influential authors in a field. To preview this information without having to go to a profile page, I conceptualized the idea of “previewing” authors from the document results page.

For this part, I collaborated with the author profile designer to decide what information users prioritized when looking at an author. The answer varies depending on the intent, but for the most part it is a combination of seeing metrics and their latest published documents.


Conclusion

In the last 3 years, I have led the discussion around Search but haven’t been the only one working on it. Many designers, in different teams and across products, have worked together with me in defining our vision and pushing the envelope in what we can do in collaboration. Many of the themes I discussed on this case study have been tested and integrated into our design system, some introduced/implemented across different pages on the product (e.g. author profile, homepage, document details, etc.)

The document results page is still in development. It is a massive undertaking after all. The final product is changing slightly and the end-result will be out by next year.