PANTHEON | First Time User Experience Redesign
I worked on redesigning the first time user experience (FTUE) in order to increase first week retention of new Pantheon developers. We started with user research to discover the common roadblocks new developers encounter. Through prototyping and testing, we defined and implemented an approach to help developers more quickly realize the work and time they can save by using the platform, resulting in a 10% key metric improvement.
Which problems should we focus on improving?
Pantheon's primary segment consists of agency or freelance developers building and maintaining websites for clients. We started with interviews and observation sessions with recently registered agency developers to learn why they tried Pantheon, so that we can invest in improvements that will have the most impact.
What roadblocks do new developers encounter during onboarding?
Developers are unsure where to start
We learned most developers want to try Pantheon by creating a new site so they can start experimenting with how the platform works, but it can take a while to find how to do this.
After signing up for Pantheon, developers land on a home screen that doesn't point them to the first action they should take.
Value proposition is unclear
When developers create their site, they choose which CMS to use (Content Management System - on Pantheon this is either WordPress or Drupal).
Developers commented that this screen is too generic, and doesn't help them understand why they'd choose to run their site on Pantheon instead of using another platform or doing it themselves.
Developers are thrown into the deep end...
Once their first site is created, developers land on the site's dashboard. Here it is likely they will be overwhelmed with all of the options to choose from and no direction for what to focus on first.
At this point, developers who have past experience with WordPress or Drupal know they need to finish setting up the CMS, but they get stuck trying to find the way to do so.
...with no guidance
If developers successfully make it past the CMS installation step, they next want to access the code respository so they can start developing. It is unclear to developers how to get to the site code, and we observed several testers give up at this stage.
We also observed several users miss the command they need to paste into their command line in order to clone a local copy of the repository, due to the noise in the dropdown.
Developers have to learn how to use differentiators on their own
Pantheon's out-of-the-box Development, Test, and Live environments and workflow are a differentiator according to current customers, but new users are uncertain when and how each environment should be used. They instead rely on documentation or the knowledge of colleagues who already use Pantheon.
Through the interviews and observations with newly registered developers, we concluded that the majority's first goal is to start experimenting on a new sample site so that they can learn how Pantheon will improve their own workflow. All of the blockers we identified come before developers can even clone a local copy of the site codebase and start experimenting.
Throughout this project, I worked with cross-functional teams consisting of engineers, product managers, and another designer
Workshop excerpt: Slide created during the discussion.
Product onboarding teardowns
I led a series of workshops to discuss what makes a successful onboarding experience, and to critically evaluate other products' onboarding flows.
We held whiteboarding and brainstorming sessions to come up with ideas addressing roadblocks observed during interviews.
In order to remove roadblocks to site development and increase user retention
1 / Show developers how Pantheon will solve their workflow problems.
2 / Use feedback loops to make next steps obvious and reinforce success.
Provide guidance to teach developers Pantheon
Since most new developers want to create a new site to start experimenting, we focused this prototype on that experience.
After the site is created, we added a button to prompt testers to install WordPress (or Drupal), instead of relying on them to figure it out.
After WordPress is installed, testers are greeted with a success confirmation, which also guides them to a next step. This message reassured testers WordPress was working correctly so that they felt confident moving on.
Once WordPress is installed, testers need to access their site code. To make this more discoverable, we distilled this area down to the essentials.
Once testers cloned the code, made a change, and pushed up a test commit, we again reinforced success and suggested a next step.
In user testing this prototype, we observed large improvements in testers understanding what to do through feedback after actions were completed successfully, suggesting next steps, and making it obvious how to take those next steps. Sequencing actions helped testers start an activity and see it through.
Proactively communicate how Pantheon is the solution to their workflow problems
We tested this new screen for users to land on after they sign up for a Pantheon account. We suggested 3 actions that we learned are the most common steps existing users start with.
Using users' own reasons, we also highlight Pantheon's value props in the descriptions. If users aren't sure what to do, we use social proof at the bottom to help them decide, which helped several testers make their decision.
We tested new copy on the Choose CMS screen to communicate the value proposition of using Pantheon to run WordPress and Drupal. Testers found this screen more informative compared with the existing version.
This is one of the user flows demonstrating how the new screen will fit in with the existing experience.
This prototype resonated with testers through moments that communicate how Pantheon solves workflow challenges they keenly feel, coupled with actions the tester can immediately perform to move them towards their goals.
We took all of the learnings and the best of the prototypes to define our product approach with a narrowed goal
The first goal of new developers is to experiment with Pantheon's workflow to learn how it can help them. To help developers meet this goal faster, we should communicate to first time users how Pantheon can solve current workflow challenges and suggest actions for users to take, so that they can make progress in solving their challenges.
Collaboration with designer Nathan Lee
Start developers with an action to move them towards a goal
When developers sign up for Pantheon, they receive the new Welcome Screen, which highlights benefits in users' own words, and prompts a starting point that helps new users make progress towards one of their goals.
Communicate how Pantheon is unique
We updated the Choose CMS screen to communicate the benefits the developer will receive by running a CMS on Pantheon.
For example, WordPress users are less likely to have experience with version control even though they know it's a good practice. They can quickly realize a benefit of Pantheon through our built-in version control. Drupal users know maintaining updates to core can be nerve-wracking, but Pantheon handles safely it with one click.
Create guiding moments
We added an empty state for the Dev environment to communicate why and how to use this environment. We included guidance on how to start development by first installing WordPress, with a clear call to action.
Explain Pantheon's differentiating workflow
Because the Dev/Test/Live environments and workflow are a Pantheon differentiator according to users, we extended the Dev empty state design to the Test and Live environments, in order to communciate how to use the entire workflow.
Once WordPress is installed and the developer returns to the dashboard, they receive confirmation the installation succeeded.
Lead to the next step - A/B test
Once the CMS is installed and the Dev environment changes to reflect their future development activity, we then guided them through the UI design to their next step with a CTA to clone the site code. We also simplified the UI in the surrounding area so that this action is more discoverable.
We implemented this particular change as an A/B test. To measure the impact, we tracked the number of first code commits, with the objective of increasing the number of first time developers who commit code.
Collaboration with designer Nathan Lee
The dropdown itself was simplified to focus only on the information developers need, and no more.
In the new design, we observed a 10% improvement in the number of new developers who make a code commit. This signals that more developers are able to reaching their first goal of trying the workflow on a new site, and evaluating firsthand how Pantheon can help them with their workflow problems.
© Kim Kiser Ramirez 2018