Upgrading our users to the Flywheel Cloud

New BFT Hero

It was time to move our customers to The Flywheel Cloud—next-gen infrastructure for speed and scale. We needed our customer's help to make the switch. 

The Cloud promised faster websites and services for our customers and better margins and reliability for us. In website hosting, new infrastructure means every site needed to be migrated to new servers. All of our customers would have to change their DNS. 

Project 
The Big Flywheel Upgrade

Role
Lead designer on agile project team

Objective
Make it easy for customers to change DNS so we can transfer all websites to our new platform. 

The "DNS" challenge

flows

Problem

To upgrade our customers' websites, all sites hosted on Flywheel will have to move to Google Cloud Servers. People love Flywheel because we make technical tasks effortless, but we’re about to ask them to do a tricky, technical thing.

Transitioning to a new platform will require every single one of our customers to change their DNS for every single one of their sites.

Goals

User goals

  • Tell me why I should care about the Flywheel Cloud. What’s in this for me?

  • One or a hundred sites, make it easy for them to change DNS regardless of their tech-savviness.

Business goals

  • Margins, baby! We need to hit adoption milestones to secure the best possible pricing with Google Cloud for the long term.

  • Help our customers without requiring in-person support. We need to progressively educate our customers about how to change their DNS.

  • However, if they do need in-person support, we need to make it easy for them to connect. 

The solution: Inspired by checklists

Notifying our customers & building the case for the Flywheel Cloud

Whether owning one website or a hundred, our customers’ sites are often business-critical. So we had to give them as much notice and control as possible. Part to-do list. Part on-demand instruction wiki. The upgrade experience builds the case for The Cloud and helps users keep track of their upgrade progress as they change DNS for each site.

notifying-our-customers

Help when you need it

Each site to-do item (or card) is home to a list of domains that need a DNS change, along with collapsible step-by-step instructions. And if the user needed more help, a human is a chat away (available 24/7).

help-when-you-need-it

The messy registrar problem

The list of domain registrars is loooong—Godaddy, Namecheap, Google Domains, Hover, Host Gator, and on and on. Each has a different domain management process. We made sure our customers had instructions and a handy link for each one.

messy-registrars

Upgrading a site to the Flywheel Cloud, from start to finish

Inspired by the Checklist Manifesto, we created an upgrade center (a site-by-site to-do list) to encourage savvy folks to build momentum as they made the change. For the less technical, we offered up progressive education and help at every step.

The Upgrade Center

  • Provides an easy way to track upgrade progress.

  • A way for users to see if the DNS change was successful.

  • Offers progressive instructions and help along the way.

upgrading-a-site-to-the-flywheel-cloud

From the perspective of a site

Our users spend a lot of time on their sites. So it was necessary to provide strong status cues at that level – from upgrade ready all the way to successfully upgraded.

From-the-perspective-of-a-site

Creating urgency

Early adopters jumped at the chance to upgrade. For those needing a little nudge, we used color cues and iconography to re-focus our users’ attention on the upgrade and the needed DNS change.

creating-urgency-1

If the upgrade fails

On the rare occasion the upgrade failed, we reverted the site back to legacy Flywheel and prioritized the customer for support outreach and a hands-on upgrade.

site-fails

How we got there

We kicked off with a modified design sprint

The project was high-risk for Flywheel, so we started by digging into the problem and building alignment around possible solutions. Led by our Head of Product: two product managers, our design lead, and I booked a room. On day one, we defined the challenge and asked how we might make the experience as delightful as possible for our different customer types.

kick-off
prototypes-and-testing

De-risking by testing prototypes in small chunks

By testing out the single-site flow first, I could focus on the core of the experience—changing DNS and scheduling a site upgrade. All without the complexity of hundreds of sites.

Goals For Testing

  1. To see if putting scheduling power in the customer's hands was worth the squeeze.

  2. To learn about what info our customers needed to change DNS successfully.

Usability testing

We tested several rounds of low-fidelity prototypes in moderated usability sessions (3-5 customers per round). This helped us uncover a few key insights.

Insights

  • Once a user understood the "DNS Change" ask and got into a flow, they didn't need a ton of extra help.

  • We needed to treat the "site" as the to-do item rather than each separate domain as its own separate task. The task was to get a site scheduled for an upgrade.

  • We needed strong feedback once the site was scheduled for its upgrade.

Impact & reflections

The Big Flywheel Transfer was a complex undertaking. We didn’t know what we didn’t know. As soon as we started to outline possibilities, adoption goals became contractual deadlines, and the stakes were raised. Once we signed with Goggle for infrastructure, we had to dig deep into MVP thinking to get the most out of the time we did have.

Technical dependencies and moving parts would be uncovered along the way. I had to create the user flows while we learned about how the tech should and could work. To keep us focused on our users, I began rounds of stakeholder and project team meetings to share new design learning and help us stay aligned as balance human needs and technical considerations.

If I were to do it all over, I'd double-down on patience during the research and discovery phases—all to make more confident decisions during solution exploration and code implamintation. Given the initiative’s risk profile, I'd also ask for C-Suite representation and input during the kickoff phase. The transfer became an explicit company wide initiative and we would have benefited from a a shared starting line for key stakeholder and project team.

Ultimately, I was blown away by our calm during early stages and our determination to embue a non-negotialble ask to our customers with as much joy as possible.