Plan and make the most of a trip to the Art Institute of Chicago

This project was not authorized by, or otherwise connected to, the Art Institute of Chicago.


The Explore AIC mobile application provides visitors to the Art Institute of Chicago (named the "Best Museum in the World" by TripAdvisor!) with tools for organizing their visit, navigating the museum's nearly one-million square feet, and engaging with the Institute's magnificent and massive art collection. 


Our project's scope was focused on user research and the implementation of those findings in the design of the app's information architecture.  We produced a testable prototype in Axure.


Sketch mockup of app's "home screen," based on our last iteration


INITIAL RESEARCH & USER STORIES First, my team conducted contextual inquiries with museum visitors that fell into our 2 user types, Tourist and Repeat Visitor. From our large board of findings, we drew insights from which to create our user stories and personas. [Click images to enlarge.]


CONCEPTUAL ANALYSIS Next, we conducted a conceptual analysis of our project proposal. The diagram below consists of solely the concepts to be included in the product, as determined by our user research, user stories and requirements. We focused on minimizing references to specific technologies we might use in our product in order to give ourselves more design possibilities. From these diagrams, we brainstormed appropriate interface metaphors and interaction types to bring these concepts into our final product.


CURRENT EXPERIENCE I created the journey map below to map the experience of one of our personas, Sara O'Connor, a high school English teacher and mother of two, as she plans and experiences a visit to the Art Institute of Chicago with her children. The map's touchpoints and emotional considerations were valuable references when we began our app's design, as they helped us ensure our app addressed key actions and frustrations.


MORE RESEARCH Next, we engaged users again to determine how to best group these concepts in our app. We first conducted a round of open card sorts, using Optimal Workshop's online card sort tool.


The results of our open card sorts made us realize our users might be seeing the uses of our product very differently. Did some see the same tools as being for pre-visit use versus during their visit? 


We created a set of category titles that we felt reflected the category titles given by the first round of respondents, and then conducted a closed card sort with Optimal Workshop's online card sort. Our closed card sort results dashed several assumptions we held and, with some discussion, produced the navigation map below.


WIREFRAMING With a researched architecture finally set up for the app, I was ready to wireframe our screens. I aimed to establish hierarchy and consistency across screens to reflect the navigation map and create an intuitive user interface.

Designing the ticket purchase process, we found it helpful to relate to the purchasing process provided by the AIC on their website. We combined AIC’s ticket purchasing process with a simplified mobile design. This simplified mobile design broke the process down, providing one step per screen in the app. We were able to eliminate clutter (particularly overwhelming on a small screen) and the need for additional sub-menus.


Axure prototype in progress

PROTOTYPING  Our Axure prototype was used in one round of usability testing, in which users were tasked with buying a ticket to the museum, and navigating to "Fullerton Hall." [Some other app features and capabilities are not yet implemented in this prototype.]


USABILITY TESTING Our first round of usability testing confirmed design choices and created a list of definite changes to be made or researched further in future iterations.

All users were able to successfully complete the given tasks.

Eight out of nine users said that purchasing tickets was "fairly easy," but most expected screens to auto-advance upon making a selection. 

Our team, after great discussion, went against card sort responses when deciding where to place the navigation tool in the app. In testing, most users struggled to locate the navigation tool. Once they had accessed the tool, however, many users found it had great value and appreciated its design over other navigation interfaces they had encountered.

NOTE: Our Axure prototype was used in one round of usability testing, in which users were tasked with buying a ticket to the museum, and navigating to "Fullerton Hall." [Some other app features and capabilities are not yet implemented in this prototype.]

Political debate fact-checking in real-time


Cookie Jar is a user-driven application for fact-checking political debates as they happen. As a high-stakes debate unfolds, the audience can use the app (on phone, tablet or desktop) to create and view posts with the perfect video clip or research study to refute a false statement, an exaggeration or a bald-faced lie, catching the debater's hand in the proverbial cookie jar.

This project was focused on Axure prototyping across mobile, tablet and desktop layouts, as well as usability testing and visual design.

[When exploring the prototype, adjust your browser size to see the app adapt across mobile, tablet and desktop layouts.]

THE LANDSCAPE Cookie Jar is entering a landscape that includes social media and discussion forums Twitter and Reddit. These services' users can converse with and amplify the audience for each other's comments (via "retweets " or "upvotes") around particular issues. Conversations are organized by hashtags or forum headings.

In early October 2015, Twitter also rolled out "Moments," short, accessible summaries of trending topics, made up of leading tweets and lots of multimedia ("vines," gifs, images and video) through which users can swipe to get an overview of the topic, without having to seek out and "follow" thought leaders/other important figures that are tweeting about the topic. The "moments" are temporary, as the list of topics represented is updated throughout the day.

Cookie Jar, like Twitter or Reddit, is updated in real time while a debate is occurring. Like Reddit, users' posts can be "upvoted" (or "downvoted") to make supported claims rise to the top of user's feeds, instead of getting lost in chronologically ordered feeds.

Cookie Jar debate feeds are closed a short time after the debate ends, and are then archived, to be accessible for users' later reference (users are also able to search content by politician's name). The focus of our app is solely on political fact-checking, and the app allows for multimedia posts - photos, videos, links, .docs or .pdfs-- to substantiate users' fact-checking claims.

THE COMPETITION Several sites and apps exist to fact-check politicians and other public figures, such as the Pulitizer-Prize-winning Politifact (by the Tampa Bay Times), and SettleIt! Politifact's Argument Enderan iOS and Android phone app that lets users: see if claims are true or false, take quizzes. and "alert their friends" about claims. The Washington Post's TruthTeller is not a specific application for smartphone or desktop use, but rather, it is employed across the Post's website and displays whether facts are true or false in real-time as video is played of a speech; TruthTeller achieves this by comparing the speech transcript against a database of known fact-checking claims. offers articles, Q&As (to which visitors can send questions), and the ability to look up content by candidate.

Cookie Jar stands out in this competitive landscape by the way it blends the energy, conversation and potentially huge contributor base of social media paths with a strict focus on fact-checking political debates as they unfold.



DEVICES This app, built as a responsive web application, can be used on desktop and mobile devices alike. The mobile experience is streamlined to focus users on their primary tasks (viewing/commenting, or creating posts), so that they may focus more attention on the debate. The desktop view will allow for increased functionality per page - quick access to archived feeds, profile settings, and more. Visit the prototype (also available at bottom of this page) and adjust your browser size to see Cookie Jar's layout adapt for different devices. 


THE PROTOTYPE Our initial prototype was designed solely in a mobile (phone) layout. We used this iteration of our prototype for value testing, and to test process flows. In order to avoid outside factors when testing how users moved through the application, we gave users a specific claim to post in the feed, along with a URL to substantiate that claim.

Inspired by apps like Uber, we wanted a simple process flow that would get the user inside the app and right to where they can perform their desired task. Two screens, ideally, providing simplicity and stability. Our initial discussions led us to use a pop-up/layover screen, so that the process of logging in and selecting a debate feed didn't make the user feel like they were proceeding through several pages. Testers, however, expressed confusion at that design choice, saying they felt "uncertain whether or not [they] were in the app yet," because they could still see the login screen.

Too much color was implemented in this early iteration, however, it made it ever the more clear, that we had to be extra careful with clutter and hierarchy on small screens.


Next, we built out our prototype to create tablet and desktop layouts. 

USABILITY TESTING Our primary concern was the ease with which a user could log in, select the live debate, and create a post. Tablet and desktop layouts created new challenges as we learned where users looked on the screen for the "New Post" button. We played with different ways of signifying menus or other entities on mobile layouts, so that we could reduce the amount of words on the screen.

Zero users tested had difficulty creating a post, once the post screen appeared. However, several hesitated to find the "Add New Post" button on the desktop layout. We relocated this button and addressed its depth in the visual design stage, so that it did not appear to be a part of the post or area it overlapped.

Of five users tested, all five said they were more inclined to primarily view posts than create posts. They found it entertaining to see politicians proven wrong, but were unlikely to be the ones to "find the evidence and shout out a statement."

Cookie Jar's color palette, with green for confirmations


What is Cookie Jar? 

Visually, Cookie Jar is polished, bold. The Cookie Jar voice is intelligent and cheeky. The platform and its uses are entertaining and approachable

After establishing the Cookie Jar brand identity, the first two priorities in the visual design stage were creating a color palette, and standardizing-- standardizing word choices (Create Post, or Add Post? - these needed to be the same across the application), typography, color, lines/borders, buttons and text size (key in creating hierarchy, especially on the possibly-text-heavy feed pages). 

To create a bold, polished feel for the app, we consciously chose red and blue hues that differ from the bright red and blue commonly used to signify the Democratic and Republican parties. As hoped, one user noted these colors "made sense" for a political application, and did not suggest a party preference.

A post's vote arrows are highlighted in green (upvote) or red (downvote), when the user has voted on the post. In testing, users did not feel sure they had voted, because they did not notice the vote count change. The colors offer confirmation.

The logo changed from a closed cookie jar to an open jar (jar's color changed from blue to a neutral grey), to pair with the cheeky "Don't Get Caught" slogan.

Where the debate selector screen previously featured "Recent Debates" and "All Debates" options, we simplified it to offer "All Debates" and the current debate only.


This project was focused on optimizing the form via which a customer can reserve a clothing item in-store from a company's website. The prototype was created in Axure.

The fictional clothing company, LNDN, needs to obtain the customer's store of choice, their first and last names, and their email address.

THE FORM Filling out forms on mobile is tedious. In order to minimize dropoff, I designed a form which would suggest the customer's most convenient store based on solely their zip code. Once the store choice is confirmed, the customer inputs their first and last names and email address on a virtual "tag" for their item. A progress tracker at the base of the form indicates where the customer is in the simple, three-step process to confirmation of their reservation.

IN CONTEXT As opposed to consisting of its own page(s), this form appears as a flyout panel from the RESERVE IN STORE button. The motion of the form flying out from the button provides a sense of confirmation to the customer that they have initiated the process correctly by tapping that button. Additionally. this display of the form indicates the customer is still on the page for the specific item they are reserving. They can easily exit the process midway and resume shopping via the X button on the form, without fussing with back buttons (which might lose their color and size selections, as well) on their browser or device.

THE SCREEN The initial screen of the prototype shows the "ADD TO BAG" and "RESERVE IN STORE" buttons disabled, to indicate that the customer cannot initiate those tasks yet. Once the customer has selected a color and size, the buttons are enabled, and the customer can add the item to their bag or begin the in-store reservation process.