Case study: Improving the dog-adoption process
Introduction
This case study is a modified Google Ventures Design Sprint, where an Agile approach was taken to identify and solve UX issues quickly and efficiently in a 5-day process.
Scenario: CityPups is a (fictitious) new startup that wants to help people living in cities find the perfect dog to adopt. They are a 3rd party company that finds dogs from organizations/shelters. The design constraints given were that the solution must be a desktop or web app.
The project begins after CityPups has taken the liberty of performing research, interviewing participants, and creating a persona — Ellie — a 27 year old living in NYC who lacks confidence that she’ll find the right fit for her situation.
Day 1 (Understand/Map)
Problem: Through research and interviews, CityPups determined that people living in cities struggle to find the right dog to adopt due to their unique needs.
CityPups Goals:
- Increase adoption rate
- Happier owners (customer satisfaction)
- Better “forever” homes for the dogs (decrease dissatisfaction/return rate)
Research Synthesis: Below is a chart I created that helps visualize 4 areas of concern that interview participants commonly mentioned:
Pain Points
After carefully listening to participant interviews and watching usability testing with CityPups’ original prototype, pain points in the user journey were identified:
User Map
After much consideration and review of research synthesis, the following user map was designed as a quick and efficient ideation for an end-to-end experience that both addresses the user’s needs and mitigates pain points.
The reason this approach was taken was to minimize total time (cost) spent understanding the customer journey while still putting myself in the user’s shoes enough to relate to their struggles.
Day 2 (Solution sketch)
After identifying key pain points and creating a user map as a framework, day 1 was in the books and day 2 was spent performing a solo version of a lightning demo (competitor analysis) and then ideating physical solutions.
Lightning demo
To better understand how other organizations have solved a problem similar to CityPups scenario, a quick round of searching the internet was performed to see existing solutions and improvise them to solve our own problems.
In the problem CityPups is attempting to resolve, the user has a specific desire (dog), wants to search a website to find it, and be presented with choices that match their specific needs. 3 existing products who excel at this are: Care.com, Tinder, and Apartments.com; all exist to match users to a specific goal (babysitter, partner, home, respectively)
Crazy 8’s
Based off of existing solutions, the crazy 8’s method was used to ideate the most critical screen users would be utilizing for the CityPups platform.
This approach was used again for consideration of time (respecting the nature of a design sprint): by quickly ideating solutions to the above user map & pain points without harping too much on making it look pretty, a balance was achieved of creating an effective yet resourcefully-conservative solution.
Solution sketch
After deciding which screen in the above crazy 8’s was best suited to serve as the critical screen for the CityPups prototype, the screens immediately preceding and following the critical screen were sketched to obtain a more well-rounded idea of how can strengthen the user experience of this solution.
The critical screen (center, below) that was chosen was inspired by the solution commonly seen in dating apps. The user journey of adopting a pet is not far removed in commonality from the way we date in the 21st century. So naturally, a user would want to filter their ideal match before-hand, then see their “best matches.”
I felt that seeing one match at a time would particularly make the overall experience more intimate for the user.
Day 3 (Decide/Storyboard)
Now that we understand the user’s needs and have a preliminary idea of the salient user flow, day 3 was spent creating a storyboard to help fully visualize the user journey and potentiate low-fidelity solutions that can be quickly turned into a functioning prototype.
Considerable attention was paid to the pain points discovered in day 1 when drafting the above solution. The following are hypotheses that I hoped to validate with user testing:
- Personally editing choices [size, age, energy levels, etc.] eliminates the burden of choices that don’t align with the user’s needs (saves time).
- Users will have increased confidence that they found the right fit (more details specific to dog).
- Optimum end-to-end experience — appointment scheduler included in user interface minimizes cognitive load, which should increase usability.
Day 4 (Prototype)
Before testing the aforementioned hypotheses, I had to swiftly design a rough prototype that could be utilized to validate my design choices and assess how well my solution addressed CityPups goals and objectives.
The software I chose to use for this prototype was Figma. The reason Figma was best suited to create a prototype is the utility of UI kits concomitant with the built-in prototype feature, so everything could promptly be done in one place, which saved lots of time and energy.
I decided while creating this prototype that the user could potentially have more control and freedom (heuristic assessment) if given the choice to edit preferences [user flow #1] OR answer questions [user flow #2].
Why? Some users might want to have tailored results, however they may lack confidence in what they actually want or need; By having the option to answer questions, those users now have a sense of assurance that they are being matched with a good fit!
User flow #1 — Individually select preferences > recommendation
(better for users who want more specificity, know exactly what they want).
User flow #2 — Answer questions > recommendation
(better for users who aren’t exactly sure what they want).
Full Prototype
Here is the fully functioning prototype if you would like to try it for yourself!
Day 5 (Test/Validate)
Testing Begins: After performing some dry runs through my prototype and ensuring that the red routes were functioning correctly, it was time to test the interface with 5 participants.
These interviews were structured using Google Ventures 5 Act Interview as a loose framework to abide by. Participants were encouraged to think aloud as they walked through each step of the prototype, with reassurance that any critical input is valuable, and that no feelings would be hurt.
Participants
The participants in this user testing consisted of coworkers and friends I inquired who most closely fit the description of the user base of CityPups, ie. individuals who have personally been through the process of adopting a dog or who would be interested in the prospect of adopting a dog.
Those who have never owned a dog or were uninterested in the adoption process were not included in user testing. Below are some characteristics of the 5 individuals who agreed to participate:
Jeremiah — 22 y/o, male, lives in a house (near city) with family, owns a dog.
Heather — 46 y/o, female, lives in a house (rural area) with family, owns a dog.
Brain — 30 y/o, male, lives in an apartment (in city), does not presently have a dog, but has a family dog at parent’s house. Interested in future adoption.
Keira — 27 y/o, female, lives in an apartment (near city), no present dog but grew up with a family dog, interested in future adoption.
David — 50 y/o, male, lives in a home (suburbs), owns 3 dogs.
Key Takeaways
Usability testing with this prototype was relatively straight-forward; each of the 5 participants were able to successfully perform the given task of “find a dog based off of your individual preferences and schedule an appointment to meet them” without any redirection, assistance, or hints.
Regarding the initial pain points noted from user interviews on day 1 of this sprint, participants in the prototype usability testing did not air the same concerns.
Participants reported they particularly liked the idea of filtering their preferences then having a system that matches them to dogs.
There was some critique by participants regarding the UI of the initial prototype, which was to be expected considering the limited time constraints under the design sprint pressures and parameters. One critique was that the UI felt too powerpoint-esq. A few hours were spent after the testing phase to address this and reorganize the prototype interface. If given additional time, this is something that would be even further addressed.
Last notes / Lessons learned
If more time and energy was to be allotted to this project — I would further develop the interface for users who would prefer to see all dogs at once, then incorporate a filter that eliminated choices from the pool of results. Additionally, I would like to further design a user-flow that allows users to speak to a real-time expert (this could be AI as well).
This project certainly proved valuable to understand the principles and procedures of a Design Sprint approach to solving UX issues in a practical scenario. One aspect of this process I particularly enjoyed was that each day built off of the previous day’s work — this compartmentalized approach lends structure without limiting intuitive creativity — still allowing freedom to make non-linear changes.
