Clickable Prototype — Final Result
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.
It all started with a tweet.
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.
Simplified diagram of Pivotal Platform.
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.
Proto-persona
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.
Competitors
What have others done?
With the experience principles in mind, I looked at other products in the space and compared them against each other.
IBM
IBM's Bluemix onboarding
Videos. Lots of videos.
Heroku
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.
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.
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.
Pivotal
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.
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.
Introduction
- 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.
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
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.
2
Days
8
Usability Tests
5
Users
3
Stakeholders
User Feedback
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.
Second prototype
This second prototype was made with Sketch and Invision. I have since moved the prototype over to Figma.
User Feedback
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
Findings
45
days
8,019
unique visitors
25%
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.
46%
Java
15%
Ruby
11%
Node.js
2%
Python
Conclusion
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.
Regrets
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.