Redesign an existing website.
Solo project. Research, define, ideate, design, prototype, and iterate.
Austin Zoo is a non-profit supported by donations. They take in animals from numerous backgrounds and provide them with a home for the rest of their lives. Their mission is to assist animals in need through rescue conservation and education. Unlike conventional zoos, each of their animals has a unique story that reflects the zoo’s dedication to their welfare. It’s the only Zoological Association of America (ZAA) accredited zoo in the Austin area. They offer family-friendly events, animal rescue initiatives, and educational programs for all ages to foster a sense of wonder and appreciation for the natural world. They boast over 300 animals representing more than 100 species
The existing website has a confusing typographic hierarchy, some accessibility issues concerning effective contrast, and could be more responsive. These can be discouraging to guests and may reduce the zoo’s ability to acquire funds.
Redesign key user flows such as planning a visit, learning about animals, and donating to improve accessibility, clarity, and responsiveness across mobile, tablet, and desktop. Focus on simplifying navigation, enhancing readability, and highlighting the zoo’s mission to better engage users and increase support
Upon initial review of the website there were multiple processes that could use a redesign, along with a lack of accessibility considerations and overwhelming aesthetic choices. To reduce the scope of this project to only two flows, a website audit was necessary. I knew what I would change – the ability to buy tickets for one thing – but what would users going to a zoo website be looking to accomplish? Once I had them exploring the site, I asked about what information or tasks they'd come to the site for. Did they care about donations or tickets? What about planning an event or any of the special programs Austin Zoo offers, such as the animal encounters or summer camps?
After speaking with five users, all five of them wanted to be able to purchase tickets online, which Austin Zoo's website does not offer.
Four out of five users:
Many of them were confused by the information hierarchy, complaining that they weren't sure where certain buttons would take them. The header font, spacing, color combos, and blurred photography also earned some comments. There were no overwhelmingly negative reactions to the site and no one declared they would never go to the zoo because of it, but all interviewees used words like "outdated."
The zoo websites I chose for competitive analysis were indirect as they were all outside of Austin. I'd been to the San Diego and St. Louis Zoos before and enjoyed my visits, so I wanted to see how their websites worked to entice customers. The San Diego Zoo is well-known for being one of the best in the United States and upon my review its website reads more like an amusement park's. Since the Austin Zoo is on the smaller side, I wanted to look at a zoo a size or two larger to see if there were elements Austin Zoo could adopt, which let me to the Oregon Zoo. The Dallas Zoo is similar in size to the Oregon Zoo, but it's in Texas. Did they do anything differently? What features are available on each zoo's site? Do they offer similar experiences?
$76 per adult ticket
$66 per child ticket
Approximately $18-22 per ticket - daily price variation
Free!
$26 per adult ticket
$21 per child ticket
Based on user interviews and the site audit, key needs emerged: the ability to easily purchase multiple tickets online and to find event planning information without having to call. To represent these priorities, I created a persona, Angela, who reflects both of these goals. She's budget-conscious, planning for kids, and wants a smoother online experience.
.png)
While the majority of users wanted the three main points mentioned above in Website Audit, everyone had other features they were interested in seeing. If they didn't name the feature outright, they spoke to one issue or another that I attempted to address in this feature set. Since this is the ideation stage, I didn't let reality stop me from writing down as many ideas as I had within 10 minutes.
Website auditors found the Austin Zoo information architecture to be confusing, so rather than keep the existing site hierarchy of the site, I did an open card sort with four participants. I used the the same words the Austin Zoo site uses for its menu items and page titles since information was associated with each. What confused auditors was how these pages were associated.
Most card sorters reduced the number of main menu options; it was condensed down from nine options across the top navigation down to five. All pages were accounted for. They didn't need to be spread across nine different categories, but instead nestled within sub-categories to reduce clutter and number of clicks necessary to find information.
Based on those results, I created a revised site map that reflects a simpler, more intuitive structure. The updated version groups related content together under broader headings, making it easier for users to navigate and understand the site at a glance.
Research revealed two high-priority tasks to focus on: both buying tickets and requesting a venue for an event. The below user flows address these needs with clear, accessible pathways.
Because the Austin Zoo site did not have a flow nor page architecture for either ticket purchasing or venue requests, I had to start from scratch, ideating as many layouts and flows as I could for both new processes. Here are some samples:
Using best practices, I created my mobile screens first, starting with the screen for buying tickets. I wanted the ticket-buying process on mobile to be condensed so it didn't overwhelm, so I hid each section until the user clicks on it. Creating the Request a Venue screen followed a similar process. Both of these flows do not exist on the Austin Zoo site. By adding them, I wanted to ensure I was improving the site, not causing more confusion. Each screen had to be very clear and easy to use.
Once I was translating my mobile designs to the tablet and laptop screens, it made more sense to leave the forms expanded as users have enough room to see multiple sections at a time.
Mobile Home Screen
Mobile Plan a Visit Screen
Mobile Buy Tickets Screen
Mobile Plan an Event Screen
Mobile Request Venue Screen
Desktop Buy Tickets Screen
Tablet Plan an Event Screen
The biggest issue uncovered in mid-fidelity testing was that not everyone made it to the end of the Request a Venue flow. The term "Events" was a large part of the issue as users wouldn't click on that main topic to open what I assumed would be the most direct route to requesting a venue. Because they didn't click on "Events" from the main menu, they looked for other routes that I had overlooked prototyping. It was definitely a lesson in making sure users have different navigational routes.
Pre-Iteration Home Screen with "Plan a Visit" Button
Updated Home Screen with "Buy Tickets" Button
Pre-Iteration Request Venue Form with Counter for Number of Attendees
Updated Request Venue Form with Field for Number of Attendees
Updates:
Pre-testing High-Fidelity screens:
Flows tested:
Stats:
User Observations/Suggestions:
Updates:
Pre-Iteration Home Menu
Updated Home Menu
Pre-Iteration Buy Tickets without Subtotal
Updated Buy Tickets with Subtotal
The button at the end of the Request Venue form was the same button that leads to the form. To minimize confusion, I changed it to look like the button at the end of the Buy Tickets form:
Plan an Event Page - Request Venue Button
Pre-Iteration End of Request Venue Form - Request Venue Button
Updated End of Request Venue Form Button
Some of the updates, like the main menu's color conflicting with the "Work with Us" section on mobile, were obvious immediately in testing as I watched user flail to even start the Request a Venue flow. Others were a little more nuanced, like the button at the end of the Request Venue form. My mentor advised that having buttons that do different tasks look different helps with learnability so users can adapt more quickly.
Final Screens:
To make sure my updates had the desired effect of streamlining the experience and reducing confusion, I had a couple more people test my high-fidelity prototype. They blazed right through each flow on all the screen sizes.
Like my txt.Texas project, this was a great example of working with a product that already exists, but this time, instead of aligning strictly with the already existing work, I was tasked to redesign. It was a fun exercise to keep the feel, colors, font, and other branding elements, but alter them enough to meet accessibility standards. What took a good amount of time was untangling their Information Architecture. My conclusion was that it is a site that was built piecemeal, so as new pages are added and connected with other pages, the hierarchy and navigation gets blurrier.
I focused most on improving my Figma hygiene and prototyping skills on this project. The high-fidelity mock-ups took me a little longer since I went over everything I'd done in mid-fidelity to make sure layers and frames, etc. were labeled intuitively. Then I made sure that all my components were organized so that by the time I actually set to work making the high-fidelity mock-ups, all I had to do was essentially place my stickers.
I learned a lot of ways to utilize variables when prototyping, specifically Boolean variables, and I managed to master quite a bit of the internal logic of prototyping dropdowns, counters, and accordion organization for the different sections of each flow on mobile. While I think my innate skills lean more towards the UX research side of UX design, I very much enjoy practicing and adding to my UI knowledge.
