SciVal information architecture redesign
SciVal provides bibliometrics and other academic-related data. It’s used by experts who conduct in-depth analyses for their institutions or governments.
This Elsevier tool is powerful. It displays data through dashboards, charts, and tables across many, many — many — pages.
And that was the problem.
When power becomes overwhelming
SciVal had grown a lot over the years. New content and features were added over time, to meet our users’s needs and help them craft powerful analyses about their organization’s academic performance.
However, it became so big that our users were struggling to find their way. We had ample evidence of that via usability tests and user interviews. This was not only a problem for our new user, but even for our most experienced ones.
As one of them put it:
There is a lot here and that’s part of the benefits of it.
But it’s impossible to remember all the little trees, all the little limbs that go down to every little area.
If you haven’t used it for a week or two, the first 30 minutes is getting you reacclimated, because you just can’t remember it all.
He was right. Our navigation was complex:
- Modules at the top (based on what the user pays for)
- Entities on the left (the things you can analyze)
- Pages organized in tabs and sub-tabs, which changed depending on the module/entity combination
Users had to remember what was the right combination of modules and entities that would bring the content they needed. And then, they would still need to locate the correct page within the tabs, sub-tabs and sometimes even modals.

Let users focus on what matters
We wanted users to spend their time analyzing data, not getting lost in navigation. So we set out to design a new navigation system that would make finding content simple and intuitive.
This wouldn’t be solved with just a navigation tweak, or better onboarding — we had tried those before. We needed a fundamental change to our product’s information architecture (IA), to reorganize what we had and make space for what was coming.
Understanding the terrain
We first attempted creating a sitemap to understand more detail about the navigation issues. However, the sitemap only showed us the size of the product, but it was so big it was difficult to pinpoint problems.
So I suggested we pivot to an approach we called “Deconstruct the IA”: analyzing pages for navigation patterns and content structures.
Sometimes this looked like neat diagrams. Sometimes it was messy annotations on screenshots.
The deliverable outcomes were two slide decks, where I analyzed the patterns at play and pinpointed issues. I then presented these to the rest of the UX team over multiple sessions, where we took our time to discuss the issues in depth.
This was essential for us to have a common understanding and a shared vocabulary.

Defining the destination
With a clear picture of the issues at hand, next came the fun part: a North Star workshop. A day of unleashed creativity, collaboration, and energy — my favorite day at work, ever.
We sketched possible futures for SciVal, then spent weeks refining concepts, prioritizing, and narrowing the scope. Since the biggest pain point was finding content, we focused our efforts on site navigation.
We agreed on a direction:
- Let the user start by the entity (the thing they want to analyze: an Institution, a Country, a Researcher, a Topic…).
- Clean up the interface by having the entity selection in an on-demand panel, instead of always visible. We validated with usage data that users navigated between pages a lot more than they did between entities.
- List all the pages that are available for that entity, in a unified place. That will mean that we no longer reference the modules (i.e. paid subscriptions) in the interface, and we can validate if anyone really misses that structure.

Rolling up our sleeves
Me and my teammates tackled on this project by playing to our individual strengths, and trying to work in parallel whenever possible. The UX Researcher and Product Owner organized strategy and logistics for the user research, other UX Designers handled UI design and prototyping.
My role was to make sense of the mess.
I spent two months reorganizing combinations of module vs entity vs pages. Trying different ideas, regrouping, relabeling, breaking things, fixing them, getting feedback. Rinse, repeat.
At the end, I was able to create a solid navigation structure that worked across all our different entity types, supporting different subscription entitlements the users could have.

Final design
The redesigned information architecture is composed of:
- A top-level navigation, where we replaced the previous modules with “Explore” and “Compare”.
- In “Explore”, the user starts with selecting one single entity, then browses through the available content.
- In “Compare”, we group the tools that we have for analyzing multiple entities at the same time (with no changed to the tools themselves).
- In Explore, the entity selection (which triggers a menu with all the options), accompanied by global entity search for quicker access.
- In Explore, the page menu: where we list all the pages available for that entity, with items shown or hidden depending on the user subscription – easily accessible from a single place. What was previously a scattered mess, now is neatly and consistently organized here no matter which entity you select.

Testing with real workflows
We had been testing our initial ideas via usability tests: prototype with fake content, then one or two tasks. However, when we had a more solid direction, our UX Researcher proposed we test this via a Diary Study (aka “Beta test”).
The changes we were proposing were too profound to be evaluated in a quick manner. We wanted our users to interact with the new navigation in their real workflows, with the real content they would see, so they could really evaluate if the it helped or hindered them.
We tested with 13 experienced users from all around the world, using a prototype coded on top of the actual product.
Their first reaction, in the kick-off meeting, was shock. The new structure was very different from the one they were used to.
However, after 3 weeks, all of them found it easier to use and to learn. Some mentioned it was more efficient, since pages were deduplicated. Some were also able to discover new content.
One user was even sad that after the Diary Study was over:
It will be hard to go back to the old version!
And they didn’t even think the change was that big after all, because the content was still there. For me, this was really surprising – being the one deep in the IA trenches, I was fully aware of how much had changed!
Also, our users did not miss having explicit references to the modules (subcriptions) in the interface. What really mattered was to find the pages, regardless of in which “package” it was.
Launch and beyond
After the positive results of the Diary Studies, we set out to implement the new navigation in the product.
My role during that time was to make sure that all the details of the new navigation were captured correctly in the implementation.
I worked together with the developers and business partners to make sure that we handled all the deduplication of redundant pages. In some cases, that meant making sure that important features from a page which was set to disappear, were replicated in the page that would remain. Sometimes that was a business discussion, since it involved making features available in certain subscriptions that had no access to them prior.
I mapped all such cases, and discussed one by one with the devs and stakeholders, then tested the implementation. This behind-the-scenes work was what took most development time until the release.
I also supported our marketing and sales teams with documents for their own reference, and customer-facing materials (like decks and support center FAQs).
Six months after beta, we released the new interface. For another three months, users could switch between versions to ease the transition. Now, everyone uses the new navigation.
The end?
What started as a “side project” of the UX team, was later named a non-negotiable, “breakthrough project” by our VP.
Is this the end? Not at all. There are more usability and findability challenges in SciVal I am keen to help solve. But I’m proud, not just of what we accomplished, but how: thorough, strategic, collaborative, and with meaningful validation with our users.
What I learned
- In a complex product like SciVal, there’s nothing like giving users the time to test the product in their real workflows. The methodology of the user research must match the rhythm of their work in the app.
- Organizing the content is one challenge, seeing it through to development is another.
- Big changes take time!