Cloud Elements is a Denver-based cloud API integration platform that allows developers to connect, integrate, and manage multiple APIs. However, while their tools make API integrations clean and easy, their onboarding process is fraught with various difficulties and user frustrations.
Reconfigure and redesign the Cloud Elements onboarding process while also driving up 30-day trial conversion rates.
This is the story of how I began to redesign that process during a three-week internship sprint.
I collaborated with one UX designer on this project: Izzy Galkin, Kris Lunstrum, and Megan McKernan.
While the four of us worked together in the initial research phase, we split into two groups in order to tackle the two major aspects of the project: Izzy and Megan took the sign-up and log-in process while Kris and I reconfigured the education and tutorial sections of a newly designed Cloud Elements user dashboard.
Adobe XD & Photoshop
First, we met with Cloud Elements' Lead UX Designer, Greg Lindahl, who spent a good amount of time helping us understand what Cloud Elements does. Greg provided us with three personas that were based on the research he had conducted over the past four years -- a product manager, an integration expert, and a developer.
We decided to focus on the developer persona, Eric, because it best matched the scope of the project and the needs of Cloud Elements. Eric would become an anchor for all our decisions moving forward.
Usability Testing, Heuristic Markup, & Interviews
Despite having a persona to work from, we wanted to hear for ourselves what developers have to say about the current Cloud Elements onboarding process. So, we conducted three usability tests with real-world developers.
From these usability tests, two critical patterns emerged:
1. Cloud Elements’ ‘unique’ language obfuscates the purpose of their product by adding an unnecessary layer of interpretation between their tools and the developer’s prior knowledge.
As one user put it while moving through the onboarding process,
"I feel like these pages all say the same thing...this paragraph about 'Elements' and 'Formulas' has been on the past three pages I've clicked on. I feel like I'm not getting any new information here..."
While this is an issue that is found all over the Cloud Elements website, it is especially present on the developer dashboard. Consider the four icons in the red box above: each is absolutely central to the usability of the Cloud Elements UI. Yet, on this landing page, there is little explanation anywhere about what an 'Element' is, or what it has to do with the other features ("Instances", "Virtual Data Resources", and "Formulas").
Moreover, these crucial features and icons are related to the three pillars in the center of the screen...but because there is little connection between them (whether by iconography or linguistic explanation), the user is left in the dark.
Cloud Elements was founded on three primary pillars:
The ability to integrate specific cloud applications or cloud service end-points (i.e. "Elements");
The ability to model the data produced from these integrations (i.e. "Virtual Data Modeling"); and
The ability to automate workflow processes based on user-generated triggers (i.e. "Formulas").
As it currently stands, the Cloud Elements website does not explain how they are able to connect users to these pillars.
2. Heuristic guides and documentation are inaccessible, decentralized, and difficult to find. Tutorials, help documentation, and aides are not immediately accessible to the developer.
Through the usability test, it became clear that tutorials, help documentation, and other aides were not immediately accessible. For instance, it took one of our experienced developers 35 minutes to find the documentation he needed to help him make his first integration. As he put it:
"It would be helpful if a tutorial were way more front and center. It took me a really long to find anything -- a mental model, a use case -- that could help me."
Users also were concerned with the language used throughout the onboarding process, if not especially in the sign-up process. For a more detailed look at our findings in the usability tests, check out the user summary I wrote here:
Journey Map of Current Onboarding Process
Next, we created a journey map of Eric's experience through onboarding. We did this to offer a framework for Eric's actions, motivations, and emotions as he moved through the onboarding process.
Click on the map to download a .pdf.
Clarifying the Problem and Defining Opportunities
Throughout the research phase, two primary issues emerged surrounding language and access to educational materials. We decided to focus our efforts on the following opportunities:
1) Craft specific, clear language throughout onboarding that:
Increases knowledge of product and terminology
Clarifies function of integration service
2) Re-configure site information hierarchy to:
Point users to most important tools
Make useful content (such as programming documentation and key sources of onboarding information) more prominent and easier to find.
We hypothesized that, by simplifying the landing page and directing new users more effectively to walkthroughs, videos, tutorials, and other examples, many of the pain points experienced by Cloud Elements users might begin to find a remedy.
Once we defined our problem, we began to ideate on our design direction. We conducted a design studio between the four of us to generate ideas for the sign-up process. First, we whiteboarded essential information:
Next, we sketched a four-screen progressive disclosure sign-in process:
We broke up the screens so they would create a value proposition:
First, Cloud Elements will inform the user what services they offer;
In exchange for those services, Cloud Elements will then ask for user information;
Finally, once user info is submitted and authorized, an email link will send the user back to the final screen, where s/he can enter their log-in details.
Megan and Izzy created some great paper prototypes to test on developers:
From this point forward, Megan and Izzy tested, iterated, and brought the sign-up process to full mock-ups while Kris and I worked on the linguistic and educational aspects of a newly-designed dashboard.
Let's take another look at the current Cloud Elements dashboard:
Aside from the aforementioned problems concerning language and the hiddenness of education material, Kris and I observed that the current dashboard--which is the first thing a developer sees upon login--is only partly a dashboard. It is also partly a tutorial and partly a 'sandbox' where developers can monitor the status of their Cloud Elements API integrations.
We wanted to clean up the dashboard and clearly delineate what is what, so we engaged in our own design studio for the dashboard and the tutorial process.
We sketched a user interface that would tie together the iconography on the lefthand-side of the dashboard with the 'three pillars' I mentioned above ("Integration", "Visual Data Modeling", and "Formulas").
It would also provide CTA buttons that are unified with the pillar's given function (something the current dashboard does not do).
Each pillar would describe in layman's terms what purpose it served. It would answer what Cloud Elements means when it talks about "Virtual Data Modeling", for instance.
After this, we began to think through and sketch tutorial models. We moved through and detailed every step it takes a user to:
Connect their first APIs and sync their first integration,
Begin modeling the data produced from that integration, and
Set triggers or parameters for pushing/pulling info.
While moving through ourselves, we discovered that the process is 1) very long and 2) technically challenging. Moreover, as it currently stands and as mentioned above, Cloud Elements provides only one example use case as a training model (connecting Salesforce to Shopify). If the user isn't connecting these APIs, they're supposed to use them as an example to get through their own integration.
In light of this, Kris and I decided to introduce some gamification. We wondered:
By taking the user through a simplified, step-by-step tutorial model that creates a Cloud Elements integration, could we educate users in the Cloud Elements verbiage while also aiding them in making their first connection?
We developed wireframes that tackled these issues.
First, we created a more dashy-looking dashboard that includes clear definitions for Elements, Virtual Data Resources, and Formulas. By explaining them clearly, developers can connect their previous knowledge with Cloud Elements' nomenclature.
We built in links that would take the user to Cloud Elements' documentation site.
We also designed an opaque, interactive overlay screen that would act as a dashboard orientation screen. This allows users to familiarize themselves with the various tools on the dashboard page.
Reconfiguring the informational architecture in these ways allowed us to implement more educational components.
We also designed the first iteration of the step-by-step tutorial. We thought about the much-celebrated Turbo Tax model, which walks users step-by-step through a complicated and technical process. With that model in mind, we started designing.
Excursus: a UX Writing Tune-up
As I noted above, one of the critical problems to emerge from the research phase was the use of unclear and obscure language throughout the onboarding process.
Note the highlighted area of the dashboard below, where there is an emphasis put on "Elements", "Instances", "Virtual Data Resources", and "Formulas".
Our research found that these icons are crucial to the usability of the product. Yet, throughout the landing page, there is little explanation on what an 'Element' is, or what it has to do with the other features ("Instances", "Virtual Data Resources", and "Formulas").
This was frustrating for the developers we interviewed, who were left to guess and assume what these signifiers meant. Moreover, explainers or help guides could not be accessed easily.
Seeing that this concerned any immediate and intuitive understanding of Cloud Elements' product, it seemed prudent to bring in UX writing principles to the table.
Moreover, our research also found many linguistic pockets throughout the onboarding process that were off-putting because, as one developer put it, everything seemed "too market-y".
Consider Cloud Elements' home screen, where the user is met with the following:
While API integrations might indeed "suck" for developers, it's probably best to discuss it:
1) more positively,
2) in less-colloquial terms, and
3) according to a voice that echoes an established style guide.
Here is another example of a marketing-heavy voice and style, found at the end of the sign-up process:
Again, it seems strange to label a CTA button with this sort of diction. Because it lacks clarity, it could likely create anxiety in the user ("Where am I going? What am I doing? What are you doing with all of the information I just entered above?"
UX Writing Solutions
Solution 1: shape the product experience by combining clear and useful copy with meaningful CTAs
In the wireframing stage, I tried to combine multiple visual and written signifiers that would allow the developer to clue-in to the various components.
As you can see in the image below, the sidebar icons are still there, but they connect to the "three pillars" of Cloud Elements' product. Not only are Elements, Virtual Data Resources, and Formulas explained in clear copy, they are connected to CTAs that give the user a sense of utility.
Unfortunately, this approach was turned down by the UX lead, who wanted to find a middle ground: keep the original diction while offering quick-and-easy access to help.
With that in mind, I created "Cloud Elements University", which gave space on the dashboard for help materials.
Solution 2: craft copy that is more in line with developer expectations.
I tackled the sign-up CTA and gave it language that is more appropriate to the action on hand.
Since this particular CTA directs follows a form and precedes an email verification page, I decided to frame this CTA as one step in the process. In other words, the CTA now says, "Click here for the next step in the process...", and follows visual progressive disclosure cues on the page.
Concerning the Cloud Elements home page, I suggested a more positive summary of what they do that is matched with any sort of style guide.
We presented our dashboard and walkthrough tutorial wireframes to Cloud Elements CEO, Mark Geene, and Greg Lindahl, Lead UX Designer at Cloud Elements. Mark was especially impressed, noting that our flow was much more sophisticated than what he was expecting.
Greg gave us important feedback on the dashboard and the walkthrough, which gave us more fodder for design iterations. Keeping our persona in mind, Kris, Greg and I whiteboarded dashboard ideas that better-emphasized developer needs.
We added a feature that displays all possible active integrations and their history over the past 24 hours, seven days, and one month. This allows the developer to see a log history up front.
We also designed a feature that alerts a developer if anything is wrong with a current integration. The developer can click on a CTA and be routed to the problem quickly.
We also put the education materials front and center on the dashboard by designing a "Cloud Elements University" training feature. Here, developers can access the walkthrough tutorial, developer documentation, and a standard developer kit.
Finally, keeping our persona in mind, we developed a screen that greets the developer upon his arrival to the Cloud Elements dashboard for the first time. It allows him to access the dashboard if so desired, but it also encourages and routes him to the tutorial:
At this point, our project was coming together. Megan and Izzy tested and re-designed their sign-up screens three times while Kris and I brought our screens up to mock-up status with the official Cloud Elements branding.
These display only a handful of the screens we designed to Cloud Elements executives at our final presentation.