Muse
During the second phase of DesignLab’s UX Academy, I was tasked with designing an end-to-end educational application. I decided to draw on my background in Visual Art and my experience while visiting museums during my college career to design an application to connect museum visitors with information about the artworks around them.
Research
The main inspirations behind Muse were the existing websites of various art museums, which provided a wide catalogue of displayed works but weren’t suited for use while within a museum. While a museum’s website had plenty of information about artworks on display, the website format isn’t well-suited to active use during a tour. I wanted to focus on designing an alternative that would be unobtrusive, but prioritize accessibility.
To begin my research, I analyzed the most prominent websites and mobile apps that served as my initial inspiration. I tried to identify what features were shared between the two formats, and why certain ones were not. While desktops sites often had comprehensive search systems for their catalogs, mobile sites streamlined their selection of available works by only listing artwork currently on display or listing work by gallery. Another mobile feature which stood out to me was the prevalence of interactive maps. These maps made navigating each museum extremely simple, even when viewing remotely. However, I found that it was difficult to tell what artworks were in which wings except as a broad generalization. While desktop sites usually had the comprehensive information I desired to connect users with, mobile sites had the streamlined navigation and ease of use I wanted to prioritize.
By the end of my competitive analysis I determined that Muse should focus on quickly connecting a user within a gallery with the information of the artworks they were currently observing. This conclusion lead me to explore alternate means of mobile navigation, ultimately leading me to the idea of scannable QR Code-based labels that would evolve into one of Muse’s core features.
Identifying The Users
Although the original idea for Muse grew from my past experience as a Visual Arts major and a passion for art history, I wanted to make my app concept as accessible as possible. When developing my personas I focused on identifying the needs of potential users that may not be as well-informed or as knowledgeable about a museum’s gallery or contents as a college student. During my research I noted that tour-focused apps were designed to be quickly navigated, and usually only provided the bare minimum of identifying information for an artwork or put greater emphasis on a museum’s layout than the specific contents of the collections within.
I identified three major persona ‘types’ that Muse needed to cater to:
Experienced museum-goers who already had context and information, but needed a method to organize or quickly access it
Moderate users who may be familiar with a museum, but do not have full context of it’s collections and need a method to quickly discover only the information they desire without being overwhelmed
Visitors or casual users who know nothing about a museum, it’s galleries, or the artworks collected within but who need a method to find artworks they’ll enjoy seeing
The commonality I identified between these three was ease of access to information, which became the core value to direct Muse’s final design.
Finding The Flow
Before outlining Muse as a whole, I used my personas and competitive analysis to decide on what functionalities I wanted to prioritize for my end-to-end app design. Originally I pictured Muse as being focused around interactive maps that would show, on a room-to-room basis, what artwork was currently on display and provide information on a work selected within the app. However, after receiving feedback from my Designlab colleagues and additional research I decided that such a design would be too ambitious and a simpler method to select artwork was necessary.
This led me to making ‘scanning’ the core feature of Muse. My app would be paired with QR codes integrated into gallery labeling, eliminating much of the time needed to navigate my prospective application without compromising accessibility. By turning my attention away from designing an interactive map, I was able to focus on designing supplementary features that would encourage scanning and engagement within a museum’s gallery.
User Priorities
After determining Muse’s core functionality, I moved on to ensure that the priorities of my users were still met. Since I was designing a mobile app, I ensured that user and task flows could be completed quickly and with the least amount of steps possible. I wanted Muse to keep my users engaged with the museum’s displays instead of distracted with their phones.
Page Hierarchy
Initially I struggled with the limitations imposed by designing a mobile app. Unlike a desktop site, Muse could only have a small number of parent categories available. Too many, and my app would become bloated and my emphasis on quick navigation compromised. Additionally, switching from an interactive map to a scanning function as my core design feature required me to rethink how the screens of my app would interact with each other. By the end of my planning stage, I decided to keep my parent categories simple so that interconnectivity between screens could be streamlined.
Wireframing Relationships
The screens of Muse needed to connect it’s users with information about whatever artwork they were viewing, beginning with the artwork itself. Along with basic identifying information and supplementary commentary from imagined museum staff, each artwork’s screen would contain multiple lists of suggested related artwork. Suggestions would be artworks made by the same artist, or displayed within the same collection, or about similar subject matter or in the same artistic medium. The goal of these suggestions was to create connections between individual works and contextualize what the user might be seeing around them. Though being informative was one of Muse’s main goals, creating context was equally important.
Polishing The Layout
When taking Muse from low- to high-fidelity, I tried to keep my app’s interface minimalistic and unconstructive. Because each screen would be home to a lot of images, audio files, or text they had to be easy to read and navigate. To prevent users from scrolling endlessly, I decided to use horizontal scrolls for categories I anticipated would be ‘endless’, such as artwork suggestions, museum highlights, or summaries of collections. I tried to maintain a balance between keeping the artworks accessible and avoiding drowning out any single work by the sheer volume of other artwork.
Creating The Prototype
To create the prototype for Muse, I wanted to make sure it’s core features were fully blocked out. Because Muse is supposed to give the illusion of a fully realized app, it was difficult to determine what to include. Since I couldn’t create an entire museum gallery on my own, for my prototype I focused on creating the core flows first and built the remaining screens around those flows. Through this method, I was able to create a prototype that could be interconnected without needing to waste development time creating multiple similar, but time-consuming pages.
The core feature of Muse is it’s ability to scan any artwork in a museum’s gallery and display all relevant information about that work. This includes historic information, provenance of the work, and audio or video recordings from museum staff highlighting important aspects of the piece being viewed.
Along with it’s scanning function, Muse also contains a full listing of artworks currently on display organized by gallery, artist, and searchable by keyword. Each artwork entry also lists the work’s location within the museum, allowing a user to discover and track down similar artworks within a related group or by the same artist. Artworks can also be favorited for later reference.
The Final Prototype
The final prototype of Muse was well-received by my testers, who felt that it’s features would be a perfect supplement to a typical self-guided museum tour. Of the missing features, most testers expressed a desire for a clearer way to see where individual pieces were located. While the gallery lists were clearly laid out and easy to navigate, scrolling endlessly through artwork searching for a specific piece proved to be a common dislike that multiple testers brought up as feedback. For a future iteration of this project, I’d want to combine the browsing and map feature into one screen, but that was beyond my abilities as a designer during the period I tackled this project.
Conclusion
I chose the name Muse for this capstone project because I felt it was appropriate for an app designed to provide context for displayed artworks, rather than just an app designed to be a catalog of information. Although it was difficult to design a project within my allotted timeframe that met this goal, I believe designing Muse helped contextualize the difficulties of end-to-end app creation for me quite clearly. While my original idea behind this app was too lofty to be tackled within the constraints of this capstone, I believe that the final product still captures my original intentions and is a good demonstration of the user flows I initially set out to model. While compromises were necessary, I did not need to compromise on creating an app to connect people with the same art that often inspires me.
All images of the artworks used for this project were sourced from the Metropolitan Museum of Art’s website under their Open Access policy. The original entries for each artwork can be viewed on the original site: https://www.metmuseum.org