Overview

Zoofari is an app that zoo visitors can use to plan their day and gamify their experience at the zoo. During research our team found that parents with kids needed a simple way to access scheduled events. And zoo visitors of all ages needed a fun way to learn about animals at their own pace. We designed a concept app that addressed these user needs with an eye for adventure and delight.

Process

The project began with research and continued with Design Studio activities to help us converge. As a project manager, I coordinated our team's week-to-week tasks and meetings. We used a Trello Kanban board to keep track of our progress and deadlines. While we all contributed to various stages of research and design, we chose to divide the workload and each focus our efforts on separate stages of design. Most of my energy went into research, but I also contributed to sketching, wireframing and mockups. Others in the group managed the low and high fidelity mockups.

Constraints

We worked on the project remotely from start to finish. Our meetings and collaborations took into account that one of our team members lives in India while we were working in Canada. We communicated in a WhatsApp group and Zoom meetings and worked synchronously on InVision and Figma.

Discover

We were given the task of building a prototype for an app that makes going to the zoo a more enjoyable and educational experience. We wanted to make something that would be both fun and useful, complementing the physical experience of the zoo.

‍To find our angle into this problem space, we performed competitive market research and qualitative research to identify user needs and begin the design studio process.

After a brainstorming session focused on research methods, assumptions, questions, and ideas, my team member Tee and I began research. This included an interview, analysis of existing zoo apps, and visits to both indoor and outdoor zoos. Based on this research, we created empathy maps and personas to keep our designs focused on user needs.

We uncovered a significant amount of information about user needs and habits for different age groups. Zoo visitors wanted a way to keep up to date with daily events at the zoo. They also wanted to feel like they had options. And, contrary to what we assumed, many didn't mind carrying their phones in their hand for long periods of time at the zoo.

My Interview

I interviewed a family of five—2 parents and 3 adult children—who used to live in Toronto and regularly visited the Toronto Zoo as part of their homeschool curriculum. The interview took place in the family living room. Most of my prepared questions were answered in the conversation that we had.

Competitive Research

I looked for zoo visitor apps already on the market on Google Play and the Apple App Store. Reading through reviews for each app, I made a list of positive and negative comments to help me identify user needs and pain points that our team could take into account in designing our own prototype.

Field Observations: Zoo Visits

Tee and I each visited a zoo space to think about the intersections of an app user experience and the physical zoo experience. Tee visited the Montreal Biodome, and I visited the outdoor Eby Farm in Waterloo Park. Even though Eby Farm was empty for the winter season, I still came away with insights from my observations.

Empathy Maps

I made two empathy maps, drawing from my interview responses and from my competitive research, based on user review comments of other apps and on my interview responses. This helped me visualize who our users are and the pain points they face in existing user journeys.

User Needs

I discovered many user needs from my preliminary research. To avoid overlooking any user needs, however small, I listed as many as I could, generating over 30. Later, I grouped as many of those needs together as I could, creating two bigger-picture needs, shown in blue below.

Problem Statements

I considered the many user needs from our research and wrote two problem statements that our prototype might focus on. In addition to those two problem statements, I wanted to include related, satellite user needs that would inform smaller design decisions.

Personas

Tee and I drafted two user personas that correlate with our two problem statements. These personas reflect two types of users: young professionals looking to have a fun day out with friends and a parent with kids visiting the zoo.

Explore

As project manager, I organized design studio activities that would help the team converge on understanding the problem space and designing solutions that would address user needs.

How Might We Questions

To help our team narrow our scope for the project, I turned user needs into how might we questions. Then, I grouped the HMWs into broader categories. Team members then chose certain categories they felt were important to pursue.

Dot Voting

Our team dot voted on the HMWs that we had individually chosen. The two features that garnered the highest priority were a scheduling tool and educational quizzes.

Build

After voting on solutions, we designed a clickable prototype, getting there by creating sketches, wireframes, a user flow, user stories, and branding guidelines. Tee and Arham took the lead on this phase of the design process, while I helped as needed.

The Features We Chose to Build

User Flow

This diagram describes how users move through the two main features of our prototype.

Sketches

I sketched out the navigation map as it would look for zoo navigation and the scavenger hunt. We wanted to make the map customizable. Thus my experimentation with filter buttons.

Low Fidelity Wireframes

We converted our sketches to low fidelity wireframes on InVision. This helped us generate ideas for visual design, interactions, and the hierarchy of information.

High Fidelity Mockups

At this stage, we applied typography, colour, and other visual design elements to our wireframes.

User Stories

Tee created these user stories that explain how our personas would interact with the two features we built out in the prototype.

Our Clickable Prototype

We built two task flows to demonstrate key functionality for the solutions to our original two problem statements. We used this prototype to demonstrate the app in a pitch to two product designers.

Reflections & Takeaways

Would you like to know more about this project?

This case study is an overview of the work I did for this project. If you're interested in learning more about this project, please contact me by email or through LinkedIn.