Tailwind: UX & Mobile UI
A mobile app made for the Dina Wind Power of Art Hackathon at the Philadelphia Museum of Art, 2018
Typically, art museum visitors arrive wondering where to start, and how to find objects they like. Once they find an object they like, visitors want to understand it and find their connection to it. Gather crowd-contributed data to create a game or guide that leads visitors to discover objects in an entertaining and engaging way. Your solution should grow with repeated use by employing techniques such as machine learning, recommendation systems, and/or crowd-sourcing.
Discovery & Definition
Our team engaged with in-depth discussions with a handful of museum staff (curators, docents, and educational and programming staff) throughout the entirety of our project. We wanted a holistic view of how they understand the ways visitors engage with their collections. By studying their successes, challenges, and tactics, we could glean insight on how our app could contribute to a rewarding experience for diverse audiences.
We knew we wanted the app to be user-centered. It was also essential to incorporate new technologies related to machine learning and crowd-sourced data collection.
After considering a few different routes, we agreed to center our app about a robust recommendation engine that uses crowd-sourced information to curate works of art for visitors. It starts with a brief preference survey to get to know the user. Their answers determines placement on one of four teams: Scholar, Creative, Spiritualist, or Adventurer. The app then suggests an object for the visitor to view along with directions. It gauges their response to the object and suggests other pieces based on the visitor's reaction, in addition to the reactions of other visitors with similar profiles. The app also includes brief activities for participation to provide an immersive experience. The back end uses a custom API and is powered by Python/Django.
Now that we understood our tasks and scope, we distributed the work. On our team of six, we had a back-end architect, a front-end developer, two content specialists, and a product designer (me).
I mapped a user flow to outline the app architecture and user journey. The user flow centralized our team and was our blueprint. It informed me on what screens I needed to design, it let the developers know what needed to be built and how, and let the content specialists know what the major sections needed to be filled in.
Once our team signed off on the user flow, I jumped right into designing mid-fidelity wireframes due to time constraints. By this point, we had about two weeks to submit our final project.
Early styling concept
My first idea was to use Google's Material Design framework with cards to organize content. I admire Material Design's systematic flexibility, and I thought the recognizable patterns would make user onboarding easier.
Challenges in defining visual direction
Another teammate wanted to explore an illustrative style with a fully characterized docent. Our group convened over both concepts to decide a visual direction, as well as the features, functions, and user flow implicated with our respective designs.
I wasn't entirely sold on either proposal under consideration, including my own. Time was limited and we had to make a decision, but I couldn't help but think we could do better. The major challenge here was that, while we wanted to create a personal digital docent, we also wanted to keep the app simple and elegant.
Since all of us participated in the hackathon last year, I scanned the lessons we'd learned in our previous project, Time Bandit. One of the challenges we ran into that year, and looked like we were running into this year, was about how to balance the app experience with the museum experience. Creating an app that was visually compelling and engaging ran the risk of distracting the user away from the works of art right in front of them, undermining their reason for going to the museum in the first place. We wanted to guide users around the collections, not take their attention from it.
With this in mind, I considered ideas about a much more stripped down interface. Perhaps the app could serve better as a complementary experience to the museum rather than a competing one by reducing the amount of information presented at once. My team was into the idea, so I got away to mocking up new screens.
As I mentioned earlier, I'd considered a Material Design interface. One of advantages of using Material Design is that it's established and recognizable, requiring as small learning curve as one can expect. Abandoning this ship to to something more abstract begged the question:
How do we provide an intuitive interface without relying on an identifiable design system?
The solution I ran with was to design minimally with a limited number of visual elements. Keeping the variation between elements small would mitigate user uncertainty about what is expected of them while proceeding through the app. I also discussed with the content strategists about introducing these UI elements in the onboarding process to familiarize the user with them early on.
(To make our hardworking front end developer's life a little easier.)
Our team hopes to continue working on Tailwind to refine the experience for users. Because the recommendation engine relies, in part, on user responses, we hope to test the app with PMA visitors to feed the engine. The app is scalable and requires little work on the museum's end to customize the experience, so we would love to be able to take this model into a variety of institutions.