Mozy File Restore

“There was a 30% reduction in support tickets in the first month after launch compared to the previous six months. Not bad.”

Overview

Mozy was a cloud backup service for more than 6 million individuals and over 100,000 businesses, allowing for continuous, manual, or scheduled backups. Users can retrieve their data through any device.

The Mozy file retrieval process was difficult and unreliable. A survey showed that 45% of respondents considered the experience unsatisfactory and 25% expressed extreme dissatisfaction, a 7% increase from just 3 months prior.

“How might we improve the Mozy file restore experience to make it easier for users to access their data?”

Year
2010
Industry
Data Storage

The Situation

The Mozy file retrieval process was difficult and unreliable. Through a customer satisfaction survey, we discovered that:

  • Almost 45% of respondents considered the restore experience unsatisfactory
  • Over 25% of respondents expressed extreme dissatisfaction
  • There was a 7% increase in users who reported being extremely dissatisfied from Jan 2010 to Apr 2010

The Impact

  • Lost revenue due to service cancellations. Almost 7% of users who had cancelled their subscription did so due to restore issues.*
  • Increased costs due to additional support calls

*Based on 2010 YTD data

“How might we improve the Mozy file restore experience to make it easier for users to access their data?”

Project Goals

  1. Reduce abandonment rate
  2. Reduce support costs
  3. Increase user satisfaction

The Team

  1. My role: Lead UX Designer
  2. Product Manager
  3. Dev Lead
  4. Development Team

Research

Support Ticket Analysis

A support ticket analysis was done in 2010 to identify the top reasons customers called for support. They are:

  • Help migrating restored data to new pc (25% of restore tickets)
  • User doesn't know how to do the restores (10% of restore tickets)
  • Not seeing a deleted file in web restore (10% of restore tickets)
  • Note: There was a 5% increase in the number of users who did a restore because they wanted to access files remotely from another computer from Jan to Apr 2010

Scenario Development

Through our research we identified the primary scenarios we needed to address:

  1. To perform a full restore to a new machine. Same Platform. Same OS.
  2. Full restore to a new OS, private key
  3. Secondary drive failure. Five failed files during restore (error messaging)
  4. Perform a pick-and-choose DVD Media Restore. Media encrypted.
  5. Restore to previous file versions
  6. Remote access data retrieval

Design Principles

This solution combines user interface, system performance, and system automation. Following are a few design principles we wanted to emphasize for the project:

  • Simplicity: Users will likely perform restores during distress, such as the loss of a machine or vital data. In addition, users do not typically conduct restores daily or even weekly. As a result, there is a general lack of familiarity with the restore process. We must create a solution to reduce complexity and walk users through the steps required to restore their data.
  • Continuity: This solution is one of several key interfaces our customers use to backup and restore their data. The user experience should be consistent across each interface. Areas of consideration include branding, system behavior, messaging, and layout. All integration points with other Mozy interfaces/systems should be seamless – from a user perspective, this should look and feel like one service, not several.
  • Accuracy: The restore process signifies much of Mozy’s customer value. Returning accurate data and setting proper expectations are critical to creating value. This feature should promote trust and confidence in the process. All selected files should be available to restore, the solution should communicate any problems to the customer, and progress/status should be timely and accurate.
  • Speed: One of the most frequent complaints about uploads and downloads targets slow speeds. We must account for performance in our solution and allow customers to make essential decisions such as order and priority.

Process Development

The team collaborated to determine the most logical order of steps: start with the higher-level questions (which device?) and work down to the more specific ones (which file version?). We developed a model that reduced the steps needed for most scenarios, removing as much friction as possible for most users.

We brought the top scenarios together, refined and aligned to our new process diagram, and mapped each to our proto-personas.

Prototyping (low fidelity)

I built a prototype of the desired experience, using screenshots to show the progression of steps:

Deployment

I worked with developers to create the UX Design handoff to engineering.

Results

There was a 30% reduction in support tickets related to restores in the first month after deployment compared to the average number of ticket in the previous six months. Not bad.

Reflection

Showing the value of UX: At the time, no one on the project team had ever worked with a UX designer. There was concern that incorporating design into the process would slow things down. Through collaborative design workshops and scenario development, the team learned the value of understanding our users and developing a concept before coding. In fact, UX helped reduce development time.

Next Steps

Optimize the desktop restore app installation: When a user loses a computer or gets a new one, they have lots of software to load, including ours. Currently, there are too many steps required to install our app. We need to evaluate how to reduce the complexity of the current installation process.