This project has been handed off and is expected to ship by April 2026.
In partnership with UofT Blueprint, a student-run product team that builds software for nonprofits, I served as a Product Designer for the Museum of Art and Digital Entertainment (MADE). I took ownership of an artifact lending platform that allows administrators to efficiently approve, monitor, and track inventory requests.
CONTEXT
A playable archive of your favourite classic video games
The MADE is a nonprofit museum with a vast archive of 50,000+ video games, consoles, and digital artifacts. Unlike traditional museums, it invites visitors to play with the collection, treating games not just as objects to observe but as cultural works meant to be experienced.
THE PROBLEM
So what happens between checkout and return?
Despite its scale, the MADE relies on a Google Sheet to manage its inventory. Every checkout, move, or return is logged by hand, and once an item leaves the shelf, its record can quickly become outdated. As a result, admins have no reliable way to track an item's availability and location.
USER RESEARCH
Interviewing museum staff to uncover failures in manual tracking
We interviewed Anders, the operations manager, and staff members who oversee lending requests to observe their workflow and identify where the current system breaks down. These sessions exposed three critical gaps:
Design Goal: Create a centralized tracking system that provides live visibility into artifact location throughout the lending lifecycle to preserve the museum's mission of making gaming history accessible to visitors.
First up, visualizing the full inventory request lifecycle
I transformed the museum’s informal request process into a clear, five-stage workflow. These checkpoints give admins visibility into each step of an item’s movement, allowing them to evaluate requests, track transit, and confirm arrivals. This creates accountability by establishing clear ownership at every handoff point.
How do admins evaluate requests and decide what to approve?
Building on my UXR findings, I identified the core questions admins ask before making any approval decisions. Understanding this evaluation criteria allowed me to translate admin needs into direct design opportunities that would surface the right information at the right time.
WIREFRAMES
I focused on two core screens that handle the approval workflow
My research revealed two tasks admins juggle daily: scanning dozens of pending requests then gathering enough context to make decisions. I explored low fidelity sketches that support both actions.
Admin Dashboard
Displays all requests in one place with status indicators and urgency signals.
Request Details
Surfaces important context including item location, availability, and lender message.
Since requests move through multiple stages, they need to be sorted effectively
My first instinct was to explore filters to select status categories, but this approach required constant clicking to see different stages. This felt repetitive and unintuitive because it forced admins to actively choose what to view rather than giving them visibility into their complete workload. Instead, I transformed the filtering concept into persistent status tabs that mirror the physical journey of artifacts.
ITERATION
As I moved to high fidelity designs, I received one key piece of feedback
Admins needed to view item details without opening each request. During triage, conflicts were not visible until a request was opened, forcing admins to repeatedly click in and out just to verify availability. I explored two approaches to surface item information while keeping admins in their existing workflow.
I chose the dropdown menu because reviewing item locations requires more than a brief glance. It often involves thorough examination and a dropdown allows this data to be presented in an organized way.
Consolidating ticket details to support multiple tasks
During user interviews, I learned that admins open requests for various reasons: accessing lender information, locating items for shipment, or tracking logistics. I structured the page into distinct zones so each type of information could be accessed easily without scanning the entire request.
What happens when an admin encounters a conflicting request?
Another reason admins open requests is to resolve scheduling conflicts. I tested three tooltip variations to determine how much information should be displayed and how it could guide admins towards making informed decisions.
I chose Iteration 1 because it focuses on the admin’s immediate next action: viewing and comparing overlapping requests. While Iterations 2 and 3 provide more context upfront, they force admins to exit the current request, return to the dashboard, and manually search for the conflicting requester.
BUT WAIT
Keeping digital records in sync with real-world movement can be tricky
Recall: One of the pain points we identified earlier was items vanishing after checkout. The Google Sheet captured this initial handoff, but there was no mechanism to track movement beyond that point.
Once a request was approved, the item began physically moving through the museum, passing through multiple locations and being handled by different staff members. My challenge was making sure these transitions were accurately reflected in the system without requiring admins to dig through multiple requests.
SOLUTION
I revised the status filter and defined admin tasks for each stage
By adding numbered badges to all tabs, admins can immediately see how many items need attention at each stage. Contextual CTAs within the tabs let them update requests intuitively, and these updates automatically sync across both the dashboard and the request timeline, keeping digital records aligned with movement.
FINAL PROTOTYPE
A dashboard to approve requests and track artifact movement
Understand Technical Constraints
Working with UofT Blueprint meant designing within the boundaries of what a student dev team could realistically build. Rather than limiting creativity, these technical constraints made tradeoffs more visible.
Prioritize Systems Thinking
Collaborating with another designer taught me how to contribute thoughtfully within a larger ecosystem. Clear communication was essential to avoid inconsistencies in complex products.
