Mobile-second: when to target desktop users first

In 2010 Google announced it would prioritize mobile ahead of desktop when developing new products. Since then, as we all know, there’s been a massive shift toward mobile-first product design. Conventional wisdom now tells us that it’s almost always best to start with mobile, because the success of your business ultimately depends on its ability to attract and retain users with an app.

But there are cases where the conventional wisdom should be ignored. Our product, Karen, was one of those. We knew that an awesome mobile experience would be crucial to our long-term success, but we intentionally focused our design and development efforts on the desktop first, investing in mobile only after users told us we had met their desktop needs. This approach enabled us to arrive at an optimal design faster and more cheaply than we could have with a mobile-first strategy. It wasn’t an easy decision, but in retrospect it was the right one. In this article, I’ll share the key reasons we took this approach and how we benefited.

The Product

Karen is a SaaS platform that helps families to care for elderly parents and relatives. The product has three pillars:

1. Action plan — Users fill out an onboarding survey which enables Karen’s algorithm to generate a custom Action Plan consisting of recommended tasks that can help them save money, time and improve health outcomes.
2. Collaboration — Families can divide and conquer on their Action Plans with collaboration tools that enable them to assign tasks, set reminders, comment, share files, etc. They can also create custom tasks that the algorithm may have missed.
3. Expert help — Families can find and collaborate with the appropriate expert for each task without leaving the app.

The Company

As a startup on a tight budget we had three key requirements for our development process:

1. Build cheaply — We didn’t know how many release cycles it would take to reach product/market fit. Therefore, preserving capital was hugely important.
2. Iterate quickly — Everyone on the team had experience caring for an elder, which gave us a great head start in terms of understanding our users. But we also knew there were limits to our knowledge. Therefore, rapid learning and iteration would be crucial to our success.
3. Make data-driven decisions — With limited runway, we knew we couldn’t risk making bad guesses; every major design decision had to be validated by data.

Given the cost and friction of mobile development, these requirements already hinted that a desktop-first approach might be the better choice.

Step 1: Customer Discovery

Even though our team had caregiving experience, we knew it was important to validate our assumptions by interviewing other caregivers. This process made it clear that we were on the right track with our three pillars, but there was also a lot of uncertainty about how to implement the workflow and interaction details. Getting these right would be crucial and could take numerous iterations — a realization that pushed us further toward a desktop-first approach.

Step 2: Development of User Hypotheses

We then developed a set of core hypotheses related to the mobile vs. desktop decision. These cemented our decision to prioritize desktop. They were as follows:

1. Karen would resonate most with a 45 to 55-year-old female knowledge worker — a group which makes up a large percentage of caregivers in the US and likely to be an early adopter of a tech-centric solution like Karen.
2. Usage would fall into two general modes: planning and day-to-day management. For example, the decision to move into an assisted living facility would likely be planning task; filling a prescription would be a management task.
3. Users would accept — and perhaps even prefer — performing planning tasks on the desktop because these require focus and contemplation, something a tiny screen used on-the-go doesn’t support very well.
4. Due to the round-the-clock nature of caregiving, users would frequently access Karen from their work PCs and laptops.
5. Compared to a user in their teens, 20s or 30s, our target user would be relatively forgiving if we lacked a mobile app.
6. Since none of our high-priority use cases required device layer APIs such as geolocation, camera, or accelerometer, we could support on-the-go usage with a responsive web app.
7. It was possible — and perhaps even likely — that each family would contain a mix of Android and iOS users. Therefore, we would need to build apps for both platforms in order for families to collaborate natively on mobile.

Step 3: Build/Validate/Iterate

Because we we were developing for the web, we were able quickly release an MVP. The feature set was limited, and the design was rough, but it was sufficient to begin testing our hypotheses. We used interviews, usability tests, analytics and test marketing campaigns in an attempt to validate as many as possible. The data told us we were on the right track with our desktop-first approach. It took several more release cycles but we were ultimately able to validate all of the hypotheses and arrive at a highly usable and engaging desktop design. In retrospect, it probably would have taken twice as long, and cost twice as much had we started with native mobile.

Step 4: Mobile Development

We are now translating our desktop product into a mobile app. This hasn’t been a straightforward process by any means. We’ve had many internal debates about the feature set, workflow and screen layout, but the learning we’ve acquired on the desktop has given us the confidence to make what we think will be the right decisions for mobile. We also have the benefit of a user base we can turn to for feedback.

Conclusion

Mobile-first is a no brainer for many products, but yours may not be such a clear-cut case. Before deciding, ask yourself the following questions:

1. Does your target user live on mobile or do they divide their time between platforms?
2. Do you know your user well enough to deliver a great user experience on the first or second release? If not, does your timeline and budget afford you the luxury of iterating over multiple releases?
3. Do your key use cases require a native mobile experience, or is mobile responsive good enough?
4. Can you attain product/market fit with either an iOS or Android app, or will you have to release both versions simultaneously?

If the answer to most or all of these questions is “no,” then you may be better off focusing on desktop first.