by Michael Chuang
Pets.com is a simply and easy-to-use website for reporting lost or found dogs near you. By leveraging the good will and kind hearts of people and pet owners everywhere, we are able to provide a way for dogs and their owners to get reunited quickly.
Pets.com was designed over 5 weeks by a team of 5 in a UX course at the University of California, San Diego. Together, we used our combined user research, network, personas, and storyboards to create a polished product that adheres to all the key tenets of design.
Brainstorming and Needfinding
The course began with us brainstorming potential problems we would like to solve. One members suggested something related to parking, another suggested a website that sold snacks. Yet another discussed building a unified package tracking system. After a lot of discussion and debate, however, we came up with a clear winner that we could all agree on. Because everyone had a passion for making the pet community a better place, we focused our project on pets.
After finalizing our topic, we discussed potential objectives for our team. We thought about building a website that worked like an online pet shop, but this soon got replaced by an even better one: why don’t we create a website to help those who have lost their pets recently get reunited with them?
We talked about who we thought our potential audience would be. Those who have just lost their pets would be one, but who else? We discussed how those who have found a lost animal could report it on our website as well. Upon talking with other members of the class around us, it seemed as though even non-pet owners could get behind the idea.
While this sounded all great and dandy, we knew we had to check if competing services already existed. Not surprisingly, we found a plethora of businesses that filled this niche. Upon further inspection, however, it was apparent that there was a lot of room for improvement. Clunky UI/UX, missing features, and a lack of report aggregation made all of these options sub-par choices for a dog owner to use. We knew we could do better, and we set out with a plan in mind.
Interviewing and Needfinding
Designing an Interview
We designed our interview to focus on what people would do immediately after losing a pet. Would they call an animal shelter? Or would they go out and look for their pets themselves? At the end of all of our interviews we asked if they had any suggestions for our project and what they would like to see implemented.
Our first interview was with Professor Boyle, who gave great insight to our team. She wisely advised us to focus on one aspect and do it well, rather than trying to do everything. As such, we dropped support for all pets other than dogs. In addition, we went from a potential adoption facility to one that focuses solely on reuniting lost and found dogs.
Each team member interviewed 2–3 people each. To get varied results, we targeted different groups: students, parents, pet owners, and non-pet owners. By targeting different demographics, we knew that we would get a lot of information and opinions on how we should go forward with our project.
Though we expected a wide array of answers, responses were actually mostly similar. A clean and easy to use design was the most important factor in choosing whether or not they would use a site, and so we began to think of a design that fit this simple yet critical component.
Personas and Storyboards
After our interviews, we found that the demographic most likely to use a website like ours would be people from the ages of 20–40. As a result, we created personas and storyboards for what we believed would be typical scenarios where one would want to use our service.
Personas and Storyboards
Each one of our personas had different needs and wants to be fulfilled. These included:
1. Receiving pop up notifications upon nearby lost and found dogs
2. A tracking device to monitor where their dog has been
3. A way to communicate with others directly through our application
4. A GPS color to find out where their dog is at the current moment
With these needs in mind, we all created storyboards.
Prototype Design and User Feedback Processing
Initial Prototype Design
After two weeks of figuring out our user’s needs, analyzing our competitors, and generating personas and storyboards for our product, we had finally created a complete prototype, albeit a low-fidelity one. This was a major stepping stone on our way to realizing our mission.
Although our first prototype was basic in form and function, we treated it very seriously. We began by spending a lot of time on brainstorming. This allowed us to create an overview of the app, and it helped us figure out what pages and functions were needed at its core. We kept in mind that our users would be very diverse and thus would have different usability requirements.
By doing this, everyone started to have a rough, but clear, idea about what the app should look like. We began to understand the page relationships (parent-child, sibling.. etc) that held the app together. Thus, we decided to work individually at home first and then combined everyone’s work into a whole lo-fi prototype. When we completed the lo-fi prototype, we moved to next phase — user testing.
With the lo-fi prototype in hand, we were eager to find some testers to try out product. During Wednesday’s class, we paired with Team Rockit for user testing. In order to make the test as realistic as possible, we asked them to run through our app on their own accord. During this process, both users and designers took notes, and then exchanged their ideas. Our testers clearly pointed out what they liked and what made them confused. They provided us with a lot of useful feedback.
However, we also knew that we needed to take more than Team Rockit’s findings into account. We knew that we needed more evaluators in order to test out our interface and compliance with recognized usability principles, known as “heuristics.” After all, it is extremely difficult if not impossible for a single evaluator to find all usability problems — it simply isn’t likely or doable.
As such, we each had multiple users from outside our class try navigating our app. By increasing the number of evaluators, we were able to improve the effectiveness of our heuristic evaluation. By testing users not taking the course, we were able to find people who may not necessarily be aware of the 10 heuristics for user interface design that we know of from our readings, and thus could give us feedback in a more broad sense without use of the 10 aspects specifically.
With the feedback from Team Rockit, we knew where we needed to improve. In the end, our design decisions could be broken down into three categories: functionality, user accessibility, and text fix. The most important design decisions were functionality changes. The largest change we ended up making was to our control panel, where we added a page for managing reports (both lost and found) and a page for managing tracking devices (both new and existing).
Building a High-Level Prototype
Our Finished Product
In the end, we created a clean and easy-to-use website for our customers to use. It wasn’t quick and it wasn’t easy to create, but we produced a fully functional website that we were proud of.
We believe that the Shark Tank reacted positively to our project, as there were many questions and ideas that were being presented to us following our presentation. While we are unsure if we are going to continue to go forward with the project, we know that we have learned a lot from this experience and from everyone else!
Prototyping and user research are both critical for success. Without them, projects can go awry very early on. Feedback allows you to make changes early on when the cost is low, rather than taking something to production that isn’t very appealing.
I learned a lot about user design and heuristics. While someone can typically say “I know good design when I see it,” it’s nice being able to explain why something is well designed.
Personally, this was my first time taking a class focused solely on UX; it was interesting, and definitely something I would do again in the future!
— Michael Chuang