An information architecture study.
Why weren't people using the website?
In our discovery interviews, users said they hear of the Esplanade's events through their friends. None of them wanted to use the site to find out what's on. We tested why.
The steps to find a dance workshop was simple. We went to workshops, and clicked on the dance filter, which turned out to be a link going to the performances page. So we did a full usability test of the site with seventeen scenarios comprising basic tasks like finding a ballet show or joining the membership club.
Despite the clean visuals and dynamic animations which gives the site energy, its system usability score was 33.3/100, which was below the 'C' average of 68. Five of nine users failed to find an upcoming jazz event.
HIGH LEVEL TIMELINE
A two-week sprint of discovery research, info architecture, and prototyping.
MAKE OF THE TEAM
I worked with my project manager and prototyper.
To make the site user-intuitive.
My role was to lead the information architecture study, after we discovered that to be the problem area. We began with a content audit and map of the current site. Through this, we discovered multiple problems of inconsistency, navigability, and ambiguity.
Next, I proposed an open card sort so we could see what header categories was best for users. This didn't yield significant results, so I decided we focus on restructuring the content ourselves. We then validated our choices with a series of tree tests, rather than a closed card sort. I made this decision as tree testing allowed us to study the paths users took in finding a page - something a card sort couldn't do.
I made the decision to begin user testing our prototype only after three rounds of tree testing, as it didn't make sense to design something when the site's structure wasn't ready. This eased the process by minimizing wasted design work, evident when our system usability score rose from 33.3 to 83.5/100 on the first usability test of our prototype.
UNDERSTANDING THE USER
Not just art connoisseurs, but
Our primary users were people interested in the arts scene, or anyone intending to catch a performance at the Esplanade. We wanted to help them find upcoming events easily, instead of overwhelming them with multiple options in the site - one of the common pain points. We also noted how the information architecture of the mobile site was different than the desktop's. All of our users had even more trouble finding a ballet event on mobile, since the regular art genres were not under the 'performances' menu. Instead, the names of festivals were listed - names even performing artists didn't recognize.
An interesting user base that resulted from our interviews was those who passed by the area desiring a drink with friends. This is also supported by the Esplanade's annual report where the mall made up a quarter of its income.
'I wish there was a way I could find specific musical events quickly and easily on my phone.'
BREAKING DOWN THE PROCESS
User and business goals first.
Refining info architecture.
Before we tackled the site's information architecture, we studied the Esplanade's annual report to see which areas of the site were important to them. We then conducted user testing and assessed how critical each scenario's failure rate was based on the task's importance.
In the information architecture phase, we did a content audit, a site reclassification, and finally a series of tree tests to validate our classification decisions. Vague headers like 'explore' and 'what's on' were removed, our site's breadth shrunk from ten to seven branches, and our site's depth collapsed from six to four levels.
For each prototyping round, we staggered mobile testing a day after desktop testing. This allowed us to refine any small info architecture changes based on the desktop version's results, in addition to fixing usability issues with each iteration.
THESE WERE SOME MAJOR LEARNINGS OR POINTS WE WANTED TO CALL OUT
Venue hire button
100% of our users found the 'Venue Hire' page on our tree test, since it was a separate button from the global navigation. Similarly, 100% of our users had trouble finding the same page on our usability test for the same reason - the separate button made it difficult to spot.
We wanted to remove the parking deals section as it prevented us from putting the 'Deals' page under the category 'The Mall'. Nonetheless, we discovered parking was the fifth largest source of income making up 7% (1.5M USD) of annual income. Hence, we couldn't.
No free shows please
None of our users wanted to check the 'free' filter under shows. The type of show mattered more than the price.
But for F&B, users wanted a deals filter since half of them directly clicked on 'Eat & Drink' without checking the 'Deals' page.
While a tour serves to educate, most users didn't think the 'Group Tours' page belonged under 'Learn'. The directness score for this task was only 38%. Hence, we moved it to 'Visitor Info'.
Users didn't want a floating sidebar filter. Instead, they wanted a floating filter bar at the top of the page, so there would be more space to see the visuals of the events. Moreover, they wanted an expandable date picker that didn't compete for screen space with the events.
TITLE OF THE CALLOUT BLOCK
In this study, I learned the importance of involving my prototyper right from the beginning of the process, even though prototyping was the final stage of the study. With both my project manager and prototyper involved at each major sub-stage in the info architecture phase, it was easier to convince them of the changes needed since we saw the results together. There was no need to explain why we went back-and-forth on certain decisions like fixing the 'Venue Hire' button, since the context of the different testing methods was clear. Moreover, having the prototyper understand all key decisions gave him agency to emphasize important elements (like indentations, shade variations, and line breaks) to improve the structure of the global navigation menu at the visual level.
I also saw the benefits of taking a step back. Conducting a third tree test made my team fall behind schedule, but I insisted it was necessary to save unnecessary work in the prototyping phase. That extra test allowed us to overhaul the site's structure, which gave us a strong foundation to work with in the prototyping and usability testing phase.