Mike Long
Product Designer & UX Leader

User Onboarding

Provide a simple entry point to a complex system.

Through close collaboration with the Marketing team, Docs team, and others, I was able to release a hands-on getting started experience that felt integrated with the brand.

Clickable Prototype — Final Result

It all started with a tweet.
User Onboarding
It's Complex-icated.

Lots of use cases. So many personas.

In order to create an opinionated "getting started" experience, I had to focus on the core value proposition and a primary persona.

User Onboarding

Simplified diagram of Pivotal Platform.

User Onboarding

The Molecule: User, Problem, and Solution.

Who do we do it for?

A simple tutorial that achieves the goal will need to focus on one user, who has a painful problem, and they want a solution.

User Onboarding


I extrapolated a scenario based on the inciting tweet and decided the proto-persona should illustrate a female protagonist as a reminder that we're designing for genders other than male.

Interim Experience Principles

  • A web search for Try Pivotal Platform will result in finding a canonical tutorial.
  • Success can be achieved in 15 mins or less.

    • Success = deploy and manage a sample application
  • The onboarding experience will reveal a path to learn deeper concepts.


What have others done?

With the experience principles in mind, I looked at other products in the space and compared them against each other.

User Onboarding


IBM's Bluemix onboarding

Videos. Lots of videos.

User Onboarding


Heroku's onboarding

This workflow definitely helped a new user deploy an application. However, the sample application placed the user into a loop, where the call-to-action was to get started with Gradle, again.

User Onboarding

Red Hat

Red Hat's OpenShift onboarding

Conflicting advice based on operating system led to confusion or significant blockers to progressing since some issues had to be researched in Google searches and Stack Overflow posts.

User Onboarding

Google Cloud

GCP's onboarding

After a pretty intensive sign up process and billing approvals, this onboarding also required the user to know Docker. After going through a Docker onboarding experience, I could imagine this process taking a day (or more). It also wasn't clear how to dig deeper into further concepts.

User Onboarding


Pivotal's onboarding

In the previous onboarding, in order to glean the core value of Pivotal's platform, a new user must first deploy to an underlying cloud infrastructure. This could take over three hours to complete and incur hundreds of dollars in costs.

User Onboarding

Competitor Findings

Opportunity for improvement

Heroku stood out among all competitors. An opportunity emerged to make the further learning activities more hands-on and free of snags.

Revised Experience Principles

A successful onboarding experience enables:

  • A web search for Try Pivotal Platform will result in finding a canonical tutorial.
  • Success can be achieved in 15 mins or less.

    • Success = deploy and manage a sample application
  • The onboarding experience will reveal a path to learn deeper concepts.
  • NEW: Deeper concepts will be demonstrated via hands-on-keyboard activities.

Information Hierarchy & Workflow

I wanted new users to understand both the ease of app deployment and the ease of app management with Pivotal Platform.

To this end, I created a Google Doc so the stakeholders and the team could contribute to a conversation about the steps in the tutorial.

We tentatively settled on the following workflow.


  • What is this for and why should I care?
  • What are the prerequisites?

Install the CF CLI

  • What else do I need to keep going?

Deploy the sample app

  • The "aha" moment.

View the Logs

  • How do I monitor or troubleshoot the app?

Connect a database

  • Apps need a database.

Scale the app

  • What else can this platform easily do for me?

Next steps

  • Demonstrate further that this platform can provide critical capabilities.

Copy/paste commands from browser to terminal. 

More than one interface

I had to consider that the getting started experience involved two interfaces: a web browser and a terminal.

For this reason, I made sure that users could easily copy/paste commands from the browser window to the terminal.

I wanted users to directly interact with the platform at every step and at every turn.

Prototyping Begins
User Onboarding

First prototype

In this iteration we called it a "guide". We would later call it a "tutorial" for search optimization.

This first prototype was made with Sketch and Invision. I have since moved the prototype over to Figma.

Usability Tests
User Feedback
User Onboarding

Why do I have to start the app locally?

  • App Developers
  • Feel: Doubtful

A short-coming of an existing sample app utilized in this tutorial. Some stakeholders felt this was outside of the scope of this project, and I agreed we could release the first version without sample app improvements.

What does the ellipsis (…) mean?

  • App Developers
  • Feel: Confused

People would initially mention this out loud and eventually realize what it indicated: That some output had been redacted/truncated for simplicity. This feedback came up again in later iterations, and I eliminated the approach; it later proved to be unnecessary.

When I triple-click in the box, it selects everything. I just want the command after the '$' [so I can copy it].

  • Stakeholder
  • Feel: Annoyed

I worked with a web developer from the marketing team to find a solution that would make each command after the '$' selectable via triple-click.

How do I find the actual URL to my app?

  • App Developers
  • Feel: Confused

An opportunity to show users where to find their application URL in the program output.

User Onboarding

Second prototype

This second prototype was made with Sketch and Invision. I have since moved the prototype over to Figma.

User Feedback
User Onboarding

I want to know how to view the logs before I learn how to scale the app.

  • App Developers
  • Feel: Confident

The team had a bit of an internal argument about whether demonstrating the scale command was more important than viewing the logs. 

In this version we shared two options with users: One had 'Scale the app' after the deployment steps and the other had 'View the logs' after the deployment steps.

Unanimously, every user told us 'View the logs' was more important to them because this would help with troubleshooting the application if it didn't start or if it crashed.

'Scale the app' would eventually come after 'Connect a database' since users felt databases are the next most important concept to understand.

Publish and Measure
unique visitors
pushed the sample app
Responding to Feedback

Experience Principle #5:

Deeper concepts will be demonstrated via hands-on-keyboard activities.

Progressive disclosure

The improved sample app responds to application configuration changes and links to specific areas of the docs. App developers can now dig into deeper concepts and engage in those concepts with more hands-on activities.

This approach addressed a gap that I identified in the competitor exploration.

User Onboarding

Lessons learned

When I started this project, I never would have guessed our Customer Success teams would use this project for classroom-based workshops.  

I was also surprised that it became the number one channel for new sign ups on Pivotal's public cloud offering.

Takeaway: Thoughtful and intentional design can influence an organization in positive and unexpected ways.


One regret I have about this project is that we didn't further validate our assumptions about who would benefit most from the getting started experience and test solution ideas with those specific people, e.g., the "Java Jane's" of the world. 

The biggest regret I have about this project is that we didn't use this opportunity to make our docs site better. Rather, we side-stepped the docs site (but not the docs team) entirely to expedite our release.