Brief: Create a dog walking app

As part of Dribbble's 12 Week Product Design Course, my fellow students and I were each tasked with designing a dog walking app end-to-end. Part of the challenge was to determine who exactly would be the users of such an app and what needs it would have to meet.

First, I explored the problem space by conducting user research and understanding the theoretical business context. Then, moving to the solution space, I iterated through low- and high-fidelity designs to finally arrive at the app concept showcased in its entirety at the end of the case study.

Understanding the Problem Space

No app that's released commercially can exist without a viable business model to support it. Great digital product development has always been about solving users' needs with technology in a way, which works for a business. Making money is not just an afterthought but needs to be baked right into the design.

Hence, in my selection of problems I tried to solve through design, I've deliberately included not just user problems, but also two very real business problems, namely user acquisition and monetization.

These have been arrived at by interviewing dog owners and doing desk-research on the wider market.

Problem 1: Dog owners don't entrust their dog to strangers lightly

As I've found out, most dog owners do require the help of others to care for their dogs sometimes.

They go out of their way to make sure their pet friend can stay with their parents while they are on vacation, even if dropping it off there means taking a detour of hundreds of kilometers. They form elaborate self-help communities with other dog owners in their apartment buildings to watch each other's dogs while they go to work. They love their dog and need to know it is in safe hands.

At the same time, they know that one day, none of their usual suspects may be available to take care of their dog.

And finally, they do sense that entrusting their pet to friends and family, while not costing money, still comes at the price of social capital.

Problem 2: Acquiring users is hard

New users are usually expensive, hard to acquire, and maybe even harder to keep. This is why many digital services companies go to great pains to maximize the number of new users they acquire from their marketing spend and strive to keep them engaged for as long as possible after acquisition.

It is hard and indispensable to design any commercial app not just for existing users but for those who you need to turn into users, to begin with.

In the dog walking app space, different apps take different approaches to turning visitors into users. These can be compared by where in the customer journey they try to make visitors convert. Either way, a good solution for enticing users to sign-up without abandoning the flow needs to be found.

Problem 3: Dog owners and carers don't like to share their money with third parties

Many platforms generate revenue by taking a cut of the money transacted on their platform. Examples of this include eBay, Airbnb, amazon, and many others. This mode of revenue generation has a problem: Neither buyers nor sellers like to give up a share of their money and will circumvent the platform if it makes sense for them to do so.

This risk of being left out of the transaction is made worse when buyers and sellers meet each other, transactions are small, the cut taken is larger, the downside of a transaction going sideways is smaller, and so on. A few examples of platforms where this risk is severe include second-hand clothing platforms vinted, craigslist, or any of the dog walking services.

To solve this problem, companies either go to great lengths to ensure they are not left out, like Rover, or they default to a subscription model where either buyers or sellers are charged for access to the platform, like German betreut.de or hundelieb.com. Either way, a way to monetize the app needs to be found as part of designing a solution.

Exploring the solution space

Following the structure of the three problems outlined above, I will present one possible solution for each of them. This should not be understood as a fully validated set of solutions but as a set of possibilities without any glaring usability issues, as for these the designs have been tested.

Solution 1: Build confidence through trust

Dog walkers need to have confidence that their dogs will be returned to them safe and sound. This confidence needs to be built through a combination of trust and control.

Control means things like the possibility of legal or financial recourse, should anything go wrong. Trust means having confidence beforehand, that your dog will be in safe hands.

I hypothesize that building trust will be crucial to raising dog owners' confidence sufficiently for them to hand over their dogs. No amount of financial compensation will make up for a lost or injured dog, hence control-building measures can only go so far.

Early iterations explored some quite intrusive control-building measures like requiring dog walkers to wear a bodycam, to constantly share their GPS location, or to send photos regularly. These were abandoned after careful reflection for mainly two reasons: Firstly, dog walkers would rightly feel severely mistrusted while, secondly, the marginal gain in confidence would not merit the exceptional operational difficulties associated with their implementation. In the end, I settled on what can be viewed as a basic set of tried and tested control measures implemented by the likes of Airbnb and Rover: Requiring proof of identification for the dog walkers, providing safe transactions, and providing insurance coverage for the dog and any ensuing damages. As an added benefit, the latter two measures would also aid in maximizing the use of the app for payment, which will be come back to in the third solution.

To build trust, two aspects of the app were emphasized: The dog walker profiles and the process of getting to know the potential dog walker in person before handing over the dog.

In the profile, of course, ratings and reviews were included. Other than that the profile was set up to not just advertise the dog walker as a property for sale but as an actual human being. In addition to pictures, dog walkers would be encouraged to share a video introducing themselves. Besides sharing hard facts about their services, they'd be given the opportunity to share their dog-handling convictions, experiences, expectations of dog owners, and favorite dog walking sites. All with the goal of making them as relatable and human as possible.

Setting up an initial meeting for both parties to get to know each other is baked right into the first booking. This has the benefit of making such a meeting much more likely to occur due to the vastly reduced friction associated with making it happen. There's no back and forth on when and where. It also has the benefit of, at least for the first booking, keeping the app in the loop. As soon as people can talk to each other directly, there's a risk of the app being left out in favor of some other channel like texting or calling. This in turn would be highly problematic for handling transactions, as I'll explain in more detail later.

Solution 2: Show, don't tell

Like Rover, the app asks the user to sign up only when she's already far along in the process. This has two main advantages: There is much less of a need to explain up front all the myriad advantages of the app right at the initial sign-up screen. By starting to use the app, the users can quickly discover for themselves what the app has to offer. Showing is always more convincing than telling.

Additionally, signing up is usually perceived as costly by the user. People don't want to create an account unless the anticipated benefit of doing so is sufficient to overcome the inertia. Asking the user to formally become a user (sign up) at the moment when the user has already decided to become an actual user (book a dog walker) minimizes the risk of the user abandoning the flow at this crucial point.

Such a show-don't-tell approach to signing up has become quite popular with apps like Instagram, Reddit, Rover, Helpling, and others. All of them allow the user to experience the core product up until a point when interest and engagement in the app are greatest.

Testing has revealed that especially in the mobile app space, some users may not expect such a pattern of delayed sign-up. To set their expectations appropriately, the delayed sign-up was indicated on the initial screen. Also, there may be such a thing as asking for a sign-up too late, which might raise users' confusion or even suspicion leading them to abandon the flow at a suboptimal rate. Testing has not indicated this to be the case, but future especially quantitative testing should investigate it.

Solution 3: Transaction first, contact later

To solve the problem of generating revenue, the app implements a model of charging a reasonable percentage-based service fee from the dog owners at the time of booking.

I hypothesize that acceptance of such a model is greater than of a freemium subscription-based model like the ones implemented by Hundelieb and betreut.de. Dog walkers and dog owners alike may view such a monthly charge as unreasonable especially when they only use the app periodically and hence are charged even when not using the app. Negative reviews on either service mentioning the subscription model lend some support to this hypothesis. Greater acceptance and the ability to capitalize on high-usage users likely make the percentage-based service fee preferable from a revenue point of view.

To counter the risk of either dog walkers or owners circumventing the booking process of the app, the booking process was made exceedingly easy, eliminating the need for any back-and-forth between the parties. This even includes the booking of an initial meeting for getting to know each other. To make using the booking process even more appealing to dog owners, a set of added benefits like a generous refund policy or health and liability insurance were added to the booking.

What's left to do

The "Dogwell" dog walking app is nothing but a design concept for which the basic usability risk has been mitigated. It sketches solutions for the three problems of dog owners trusting carers, dog owners actually becoming users, and revenue generation.

In the spirit of de-risking before building, at least two of the solutions to the three problems could be reasonably tested before committing to building a solution.

Using a so-called fake-door-test, by launching a landing page for dog owners ending behind the fake door of a sign-up CTA leading at best to a mailing list, the demand for the "Dogwell" platform could be gauged. An even stronger signal could be picked up by building out the first steps of the flow until the signup screen. To keep things lean, stale or static data could be used and thereby vastly reducing the effort of running the test compared to building a production quality application.

Finally, it must be noted, that there are many more problems to be tackled before "Dogwell" can be reasonably be considered an adequate solution to the problem of offering dog care in a way which can sustain a business.