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.
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.
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.
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.
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.
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.
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.
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.
To see if putting scheduling power in the customer's hands was worth the squeeze.
To learn about what info our customers needed to change DNS successfully.
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.
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.
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.
Work About