Getty's Research Collections Viewer

The Getty is an art museum in Los Angeles, California housed on two campuses: the Getty Center and the Getty Villa. In 2021 the Getty launched the Research Collections Viewer (RCV), an application that provides a new way for researchers and Getty staff to explore collection finding aids and access digitized images.

I played a key role in two major phases that significantly improved the usability of the original MVP.
UX/UI Designer
September 2022–Ongoing
Project Link
Phase 1
Overview
Since its beta launch, users reported persistent challenges with navigating the finding aids and locating the materials they needed. The updated interface and navigation of RCV, while intended to modernize the experience, often conflicted with users’ expectations based on traditional finding aids.
To address these issues, we identified key problem areas and implemented changes to RCV that aimed to bridge the gap between researchers’ traditional mental models and our vision for a modern, user-friendly finding aid. The goal was to improve usability while preserving the familiarity that researchers rely on.
Understanding researcher needs
To better understand where users were struggling while using RCV, we conducted two remote contextual inquiries with researchers who were using RCV for some of their work. By watching users interact with the application based on their individual work styles and project needs, we were able to see directly how specific use cases weren’t being adequately addressed.

We coalesced our key takeaways into 3 main problem statements:
Problem statements
1
Users have to hunt for necessary information that would help them gain access to materials and give them context about the finding aid and what are its contents.
2
It's easy to lose your place and get lost in the hierarchy of the finding aid.
3
The current digital materials icon doesn't adequately distinguish between where in a finding aid users can actually view materials and where digital material simply exists.
Sticky breadcrumb navigation
One need we heard expressed time and again from researchers was to maintain hierarchical context while navigating through a finding aid. One solution our team came up with was to incorporate a sticky breadcrumb at the top of the page that updated as the user scrolled down, indicating where they were at all times within the hierarchy of the collection.
Existing breadcrumb component
The design mirrored that of an existing component and was relatively straightforward to create for desktop, but adapting for mobile posed a formidable challenge. The design needed to accommodate hierarchies that went as much as twelve deep, as well as collections that had especially long titles. While there was ample space for this amount of text on desktop, the limited screen size of mobile meant that we needed to rethink how this could be displayed.
Example of a collection with a deeply nested hierarchy and long titles
I experimented with different ways to reduce the visible text on mobile, from truncation with an ellipsis to a text fade out to a swiper assistant with scroll functionality. We decided to keep the text to one line and truncate it from the left, always anchoring to the deepest or current level. A blue chevron on the far right allows users to click to view the full hierarchy in a dropdown, or they can scroll horizontally to view the text without expanding.
Design iterations for mobile
For both desktop and mobile we knew that creating a prototype would be essential to test whether this concept was at all useful to researchers while navigating the page. I created prototypes that mimicked the functionality as closely as possible and ran a series of remote usability tests with 9 usertesting.com participants and 6 Getty researchers.
Mobile prototype interaction
The results of our testing confirmed the following:
  • The majority of users understood what the breadcrumbs were indicating and felt that the feature had some level of helpfulness
  • The mobile version was generally seen as less useful; further testing on a mobile device needed to confirm
  • Many users assumed the breadcrumb text were jump links
After making a few changes to the design based on the feedback we received – as well as making the breadcrumbs jump links – we sent to development to implement and planned to test the efficacy of the mobile design post-launch.
Final designs for mobile and desktop
Adding box and folder information
Traditional finding aids include a container list of the collection materials alongside a box and sometimes folder number (i.e., where the physical materials are located within the archive). This location information had been removed in the first iteration of RCV and many researchers noted that this omission made their job more difficult. We therefore had to find a way to reincorporate this information into the new design, which, due to a more visual and increasingly indented display, meant that we were working with limited screen real estate.
Example of a container list on the old finding aid viewer
A round of preference testing followed by a usability test with usertesting.com participants as well as Getty researchers showed us that none of the early design options were adequately meeting user needs. Getty researchers in particular didn’t like the placement of the box and folder information (either next to or below the title of the item), so I created another design that more closely mirrored the placement in a traditional finding aid (in its own column).

A final round of usability testing confirmed that researchers preferred the version with the box and folder information in its own column as it made it easier to scan and matched their mental model of how a finding aid is typically structured.
Notes from usability test
The addition of the horizontal grey line helped users keep their place when scanning across the page – an issue that had been brought up with the pre-RCV viewer  – and related graphically to the vertical blue lines that were being used to to mark the item levels on the far left. Lastly, I adapted the design for mobile and tablet to ensure that the additional column would fit appropriately on all breakpoints.
Final designs for desktop, tablet, and mobile
Redesigning the digital materials icon
Another user need that was revealed during the contextual inquiries was a way to know where in a collection one can view digital materials. The original RCV design indicated this with text and a number, but we found that in testing this was difficult to scan and the number indicated wasn’t relevant.
Original RCV page with text indicating digital items (highlighted in yellow for reference)
We decided to replace the text with an icon that would immediately indicate to users where they could view digital materials, as well as create an additional icon that denoted the higher-level items that contained digital materials (but were only viewable at a deeper level).
Icon design variations
After I designed multiple iterations on the icon our team selected a design that we felt most clearly indicated the relationship between the two different categories (contains digital materials versus viewable digital materials). We also added a tooltip based on an existing component to help users understand the meaning of an icon they’ve likely never seen before.
Final desktop design with tooltip
Phase 2
Overview
While the first phase focused on the container list, the second phase focused on deeper pages within the collection – object and archival file pages. We knew that users struggle with discovering digital materials and understanding the hierarchy of information on a page.
Improve intuitive browsing of digital material and optimize page layouts to provide better readability and focus.
Usability testing
We needed to evaluate users’ understanding of related data on a collection page – both its usefulness and relationship to the rest of the page content – as well as to determine how users expect to view digital materials and related content.

I wrote a script and conducted the usability tests over Zoom with four researchers (all with finding aid experience) and one author (with no finding aid experience).
Core insights
Core Findings
Recommendations
Users generally expect related materials to appear at the point of relevance
Present related materials at the relevant point of user need and align with the specific goals of the page a user is on
Users want to know why they are being shown related items and how they are being determined
Show how and why related materials are being presented
Users expect digital materials to be prioritized on archival file and object pages
Showcase and prioritize imagery within the archive
Content updates for related materials
For related materials, the challenge was less about visual design and more about content clarity. Testing revealed that users found the titles confusing and needed more contextual information, not less.

Aside from adding a gray background to distinguish related materials from primary content, the updates focused entirely on content design. I drafted initial suggestions and collaborated with content editors to refine them.

Key changes included renaming “Digital Material” to “Digital Materials in This Collection” on Collection pages and “Digital Materials in This Archival File” on archival file pages to clarify the source of displayed objects. We also added the label "objects" after the tally count to better indicate what’s being counted. While related category titles (e.g., Related Collections, Related Resources, Related People & Groups) remained unchanged, we introduced subtitles to explain how each category’s data is determined—whether manually selected or programmatically generated.
Copy updates for related materials sections
Reorganizing the archival file page
I began exploring ways to arrange the collection tree, record details, and digital materials on an archival file page, focusing on optimizing the information hierarchy. Additionally, we needed to bring these pages into our design system since they had been created prior to our design system being finalized.
Early design explorations for the archival file page
Final designs
I ultimately refined the archival file page layout to address a key usability issue that surfaced during earlier phases of this project: users losing their place within the collection when navigating deeper into file or object pages. By repositioning the collection tree to the left and consolidating file contents in a right-hand column, we aligned the design with researchers’ mental model of a traditional finding aid. This layout prioritized digital materials at the top, added two additional thumbnails, and clearly distinguished essential content from related content, which was moved to a full-width section at the bottom for better visual separation.
Archival file page before and after redesigning
By using the same structure as the new archival file page, the object page saw a huge improvement in information hierarchy. Not only did the new layout maintain the image as the key focal point of the page, but now critical data – like record details and object title – were surfaced higher on the page for easy access.
Object page before and after redesigning
Key learnings
Participant selection for testing is crucial
The importance of having relevant participants for usability tests cannot be understated. Unless participants represent potential or actual users, their feedback is essentially invalid and the testing is wasted.

We experienced this after doing multiple rounds of testing on usertesting.com, where we quickly realized that even though we set up very specific screeners, we weren’t getting relevant participants. With more niche user groups, it’s worthwhile to create a group you can trust and depend on, and offer an incentive to if necessary – something we are in the process of doing for this and future projects.

Prototyping has its limits
For more complex interactions, rudimentary prototyping only goes so far to convey what the experience is like. With the sticky breadcrumb design, for instance, the prototyping experience and scrolling interactions for mobile in particular just couldn’t be replicated effectively on a desktop.

In these cases, what made the most sense was to get enough feedback from the basic prototype to support the design and then have development implement the design while making a note to do more robust testing post-launch.