Adopt-a-pet case study

“Millions of animals are currently in shelters and foster homes awaiting adoption. Design an experience that will help connect people looking for a new pet with the right companion for them. Help an adopter find a pet which matches their lifestyle, considering factors including breed, gender, age, temperament, and health status.”

Research

At the beginning of the project, I wanted to find out certain information so that I could prioritize it in the interface, according to what a small research population would say. For that, I sent out a questionnaire and received 14 answers. That number is not very high, and normally I would be cautious about extracting conclusions with these few answers, but in this case study I just wanted to validate some of my assumptions.

These two were the most important questions of the survey, because the answers tell us about what people are looking for in a pet and what they are looking for in a shelter. For the pet question I hypothesized that people would care more about how the pet is (species and behavior) first. For the second question I hypothesized that people would be more focused on distance to their home and other people’s opinions.

What do you look for when trying to find a pet?

The hypothesis turned out to be only partially correct, as the answers reveal that people do want to focus on the pet in terms of behavior and species, but they also look at other characteristics like age and size, and health. These five characteristics (species and breed, age, temperament, health, and size) should be the first information users get in the information about the animal. I’m thinking the information in a list, or when browsing the available animals. The rest of the information, while some of it still important, could be hidden in a details page or section, more out of the way.

What are the things you’d like to know about a shelter?

These results tell me that while people still want to know the practical details of a shelter (location, opening hours, etc), they also care about what other people’s ratings are more than their opinions, and how the shelter treats the animals that are there. After looking at the answers, I decided not to have a very powerful tool to find shelters, but rather a simple one that shows ratings from other users, some kind of approval seal for good treatment of animals, distance, and easy links to their website and practical details like opening hours.

Takeaway

After the research I realized that the core functionality of the tool will be a list of adoptable pets and a list of shelters, and how they relate to each other. Users will be able to search animals by some characteristics and then see in which shelter they are, or vice versa, search for a convenient shelter and then find out which animals are there. A good evolution of the product could be a tool that helps you find your ideal pet based on your lifestyle and preferences.

The problem

People who are looking to adopt a pet from a shelter face a series of problems that get in the way. Getting to know the pets, visiting the shelter, finding out if the kind of pet they’re looking to adopt is available at a shelter, etc. In order to explore those issues, I did a how might we (HMW) session.

Definition of the problem

After the HMW session, I could define the problem more clearly: How can I create a digital solution that allows users to find a pet, to get information and see the pet without having to visit the shelter every time, and to choose a shelter?

I think these are the three most important aspects of my MVP, the functionalities it should provide, because those are the main jobs the users want to get done, the reason why they would download the app and use the product. Some of the HMWs in the whiteboard are also pretty important, so I’m going to take them into account, and some of them can be combined either with the priority A HMWs or with the priority B ones. This is the final list:

Priority A

• HMW allow users to find a pet?

• HMW allow users to get information about an animal, and visit them without having to travel to the shelter?

• HMW help users to choose a shelter?

Ideation and sketching

After I decided what the HMWs I will focus on are, it was time to move on to the ideation phase.
In the Design Thinking approach, the ideation phase is where we challenge assumptions and create new ideas. In the Design Sprint methodology, a few methods are proposed for this phase, which is called the Sketch phase. Firstly, I’m going to perform a comparable problem exercise, where I’ll research already existing solutions as a warm-up, followed by a crazy 8’s exercise.

A comparable problem

I did some research about adoption apps and websites, focusing on 2 in particular: Petfinder (opens in new tab) and WeRescue (opens in new tab).
Both are very similar in terms of functionality, with Pathfinder having a more comprehensive search functionality than WeRescue.
As inspiration, both of the products were very inspiring, and identifying what works and what I would do differently in both was a very good exercise. Some of the HMWs are addressed by those products, and some aren’t, which helps with questioning my assumptions and with testing them. In particular, I think that they focus on the pets, while I also considered the convenience for the user and how they would want to look for shelters first instead of pets. Both products allow users to contact shelters and know in which shelter a pet lives, but looking for a shelter is a more hidden (or absent) functionality.

Crazy 8’s

There are a few interesting ideas in these crazy 8’s that stand out to me and I marked them in the voting part of the method.
These ideas are:

• A map of the shelters that shows users where they can find a shelter in their vicinity

• A live stream of the pet

• Users can pick their location, and they can filter the results of the search

• The organization by sections, with Favorites, Pets, and Shelters

Solution sketch

After the ideation phase I had a clear idea of what I wanted to build, but I needed to make it into concrete sketches of a solution so I could start assessing their usability and how well the solutions that I had in mind tackled the problem. My approach was to make a rough prototype that I could present to at least one or two users to decide if the direction I was taking was good enough so I could course correct if I needed to. In a Design Sprint setup, each participant would sketch one solution, they would present it, and then there would be a round of voting to decide what and how gets made into a prototype. In this case study it’s only me participating, so I decided that I would sketch a few solutions so I could replicate the process.

The final sketch

These seven screens show the main functionalities of the app. Starting on the left, we have the search tab that doubles as home page. This is the first thing the users would see and so it shows the newcomer pets and the closest (or best) shelters. It’s a simple screen that goes straight to the point. It also shows the five menu options at the bottom.

Next to it we have two screens that show the favorites tab. This tab shows the user the animals that they have saved as possible pets, and it features a bigger card that shows more information at first glance than the smaller ones in the pet and shelter tabs. The second favorites sketch shows the map functionality, where the user can see where the pets are located in a map. This would be useful not only when searching for a pet, but when going to visit one, getting directions when on the move.

The pets tab and the shelters tab are similar in functionality but they look a little different. The pets tab features a more dense results page (we can safely assume that the number of pets will be way higher than the number of shelters) and it has a horizontal slider at the top with categories to quickly filter the results by species. Both pages have filters and they also show a map.

Next up is the settings tab. Here, the user will be able to tweak the app to their liking. I want to mention the accessibility tab that I think is quite important, not only because good products should be accessible, but because there’s potentially visually impaired users who want to find a guide dog, or older users who want a pet for company and also have trouble seeing. I want also to develop an interface option that makes it easier for left-handed users to use the app.

And finally I wanted to show how a modal would look like, in case I decide to use one instead of a screen.

The prototype

It’s now time to create some screens to build up a prototype. Based on the final sketch, I created 6 groups of screens to build up the functionality. I left out the modal because I don’t need it to perform a usability test of the prototype, so I will keep it in the back burner as an idea for the future.

Loading

This screen is a simple empty background with the logo of the app. It will have a spinner or a loader to indicate to the user that the app is loading.
Once loaded, it transitions to the landing screen, the search bar the doubles as home page, as stated above.

Home / Search

This screen shows the user a selection of pets and a selection of shelters, and an option to see more pets and to see more shelters. These two buttons take the user to the respective screens, and are functionally identical to the menu option. Duplicating this functionality serves here to avoid the paradox of choice and state clearly to the user what the app does. Especially useful for first-time users.

The selections of pets and shelters are presented in twin horizontal slider galleries.

There aren’t any options in the mockup screen to filter the elements shown, but in the final product there will be an option where the user can specify what they want to see in this home screen. Some options that I thought about were: latest added pets, most visited pets, least visited pets, pets closest to my location, best rated shelters, closest shelters, etc.

The search functionality returns a selection of both pets and shelters that match the keyword(s). Visually, these results will be presented in the same way as they are in the pets screen.

Favorites

These two screens show the animals and the shelters the user has favorited.
As the research shows, the concerns in terms of information are different, so these screens diverged in the mockup from the initial sketch shown in the previous section. Due to space requirements, the pet card is much bigger than the shelter one, and it shows also a bigger image. The shelter card shows the necessary bits of information: rating, distance and opening hours. It also shows the logo because a visual helps with remembering. However, the user can already make a choice and dive into the shelter screen to get more details.

Same happens with the pets, but in this case the visuals are more important, as users can establish already emotional connections with the animals, so the photo has to be bigger. In order to make the card more attractive, informative and succinct, I have created some icons to show the size, health status and personality traits, so I can help the user make a decision of which pets to get for information about. The personality trait icons are not immediately recognizable as such, and I’m aware that it would take some time to build that recognition, but my idea is to have those icons next to the trait inside the pet card. With time and by browsing the pets, the user will recognize the different icons. I also think that they are playful enough that the user would be interested in opening cards with personality icons they don’t recognize to see what it means, increasing engagement with the app. This is a hypothesis that I would like to test in the usability test.