Revamping a database for USC students and faculty
The Online Asset Database is a 3D asset database that will be used by students and faculty from the University of Southern California's School of Cinematic Arts' John C. Hench Division of Animation & Digital Arts, and the Viterbi School of Engineering's game development courses.
An MVP was developed by student volunteers in the past; our team was tasked with:
Updating the design
Updating the code base
*For the purposes of this portfolio I will be sticking to the design related work
Role: Design, Front End Development (HTML, CSS, TypeScript, React)
Defining Problems
The initial database's landing page was a "Categories" page, where the user would then select a category, then further filters to find the asset they wanted.
The stakeholder also wanted to update the UI as shown in this provided mockup:
In addition to the checkbox filters, the "Formats" dropdown already included multiple filters. The stakeholder planned on adding additional filters as well.
The main issues we uncovered in this step were:
Unnecessary step in user flow
Disorganized navbar
Updating colors
Proposing Solutions
We then proposed our solutions to the stakeholder
Streamline user flow
Instead of selecting a category then going on to select more filters, the categories should be integrated with the other filters.
Organize navbar
The navbar had too many elements on screen, and as the stakeholder was planning on adding more filters, the navbar required more flexibility for expansion.
The navbar initially had a dropdown (with multiple categories) and a series of checkboxes to the side. With additional filters planned, there wasn't enough space left on the navbar. By referencing the Unity Asset Store, we came up with ways to re-organize the different filters.
Iterations: Navbar
The navbar went through multiple iterations as shown below:
(a) Colors were updated to match stakeholder's mockups
(b) Moved search bar to make room for additional filters
Separation of filtering and account management (Sign In / Sign Out)
(c) The stakeholder planned for more filters to be added in the future. Individual dropdown menus for each would bring more clutter, so we moved the filters to the side
(d) Though the official project ended at (c), I revisited the design to enhance usability. The collapsible filter menu from (c) would fit better on mobile screens. For desktop, a standalone menu offers more accessibility.
Iterations: Upload Form
The upload form has also undergone several iterations:
(a) Introduced Google's Material UI for a standardized design
(b) Updated colors as specified by stakeholder
(c) Though the project officially ended at (b), I updated the form for more visibility and accessibility
Iterations: Asset Card
Here are the asset card's iterations:
(a) Initial design
(b) Updated to match stakeholder's mockups
(c) The official project stopped at (b), which shows two download buttons. The database will eventually support 5+ download formats, so I implemented a dropdown that would ensure flexibility for future additions.
Improving Accessibility
These were the colors that the stakeholder gave us in their initial mockups:
Contrast was lacking in a majority of the color combinations, so I updated them for better visibility. All elements now pass WCAG AA standards.
Measuring Success
Departmental Approval
The current database lacks storage as it is currently being hosted on the stakeholder's personal account. The current database will serve as a proposal to be submitted to USC's newly established Thomas Lord Department of Computer Science. Upon approval, the database will be hosted on the department's servers and receive ample storage for future expansion. Approval is expected late 2024.
KPIs
As the database will be used in university courses and assignments, the number of users or downloads won't serve as viable metrics. Rather, once students and faculty start using the database, further usability testing can be conducted to make tangible improvements.
Lessons Learned
Remote Stakeholder Communication
The entire project was conducted remotely; our only routine meetings were held once a week. Our stakeholder, who is currently a senior lecturer in the Computer Science Games program, was often busy as well. In order to make the most progress possible in between the weekly meetings, our team maximized each session by coming up with as many questions to clarify requirements.
Remote Teamwork
Having a kanban-style system helped to keep track of our progress, even as we were working apart.
