Project Summary
Imagine trying to sell a SaaS Enterprise product with no free trial.
That was situation my company, Elastic Path, was in.
We needed to increase our leads, expose partners and prospects to our product and help onboard folks who otherwise would have to dig deep into the documentation to understand it.It was never designed to allow for a free trial, nor had the architecture to support it.
So what did we do?
Over the course of six months, I worked with a cross-departmental team in order to develop our first public-facing free trial of our eCommerce Product offering.
We researched, designed, built, tested and finally launched the free trial in September 2018.
What was the result?
So how did we get there? I lead the design through six key phases: research, journey mapping, prototyping, UI design, user testing and final polish.
Challenges
Elastic Path’s Commerce platform was single tenant, which means one prospect per trial. There was no way this could scale effectively.
Also, our sales team had no way of determining if a prospect was worthy of a demo or not.
We didn’t really know if prospects wanted to learn more about our software before buying. But we did know that customers found the interface difficult and cumbersome to use with no guidance or instruction.
Research Phase
Initially, my job was to understand the problems more thoroughly, both from a company perspective as well as prospect perspective. I conducted two brainstorming sessions with the presales technical consultant to understand what a “five star” experience would be like. We looked at a high level systems view to understand the various touchpoints and which products would be involved.
Additionally, I looked at modern SaaS companies offering similar free trials, both for ecommerce as well as outside our industry. I mapped out their journeys on a high level, and identified what I thought were the winning aspects that enticed visitors and created more opportunities in the sales funnel.
I explored the web analytics and search words for “elastic path demo” to see what level of desire existed in the marketplace.
Finally, I worked with our product marketing, customer success and support teams in order to identify and solidify our Technical User persona. I gathered data from support requests, partner integrators, as well as chat conversations from our chatbot to create an empathy map and truly understand their needs.
Identifying Pain Points
It turns out that the current system of getting qualified prospects to try out the Product was tedious and required the cooperation of many people. It was time consuming and left room for human error. To help identify the key pain points, I mapped out a user flow and highlighted areas of friction.
Key pain points:
- NDA took time to generate
- time to generate demo environment was long
- who is the owner of the demo?
- no one to guide user through the journey
- confused customers overwhelm support with questions
- customer have trouble learning how to deploy
Mapping the Customer Journey
As this project would encompass multiple departments, I wanted to understand what the complete journey would entail from an end-to-end experience.
Based on our target persona, we wanted to allow the user to experience both a user friendly interface, as well as have the freedom to explore the ecommerce backend and see how their input affected the system.
Over the course of two session, collaborated with six different teammates from support, sales and education by completing a white- boarding exercise. Everyone wrote down an element of the user journey that they identified as being important to the experience.
We then clustered the cards together based on similar characteristics. Those that were seen as beneficial to the user’s journey were written on yellow stickies, and those areas that highlighted possible friction were written on blue stickies.
Our six phases included:
- The Discovery Phase – the marketing campaign and ways to promote the trial
- The sign up Phase – capturing the user’s data
- The initialization Phase – where the user would introduced to the Product and follow the initial learning guides
- The Customize Phase – where the user would be able to change certain store items, adjust settings, etc.
- The Review Phase – where the user could take a step back and see their updates applied to a real-time storefront setting
- The Migration Phase – where, ideally, the user would want to take their “starter store” to the next step and migrate to a more feature complete trial further down the sales funnel
Wireframe / Prototyping Phase
To save time, I created the wireframes directly in Axure, because I wanted to capture more than simple screen flows. I wanted to convey the individual wireframes as well as the flow in the same prototype. I also wanted to prototype consistent variables that would be shared across the experience.
Working on the UI
After multiple rounds of feedback and testing, I art directed the work of an external designer to create the final look and feel of the dashboard, while remaining consistent with our newly created brand.
The Waiting Period
One issue that arose during the prototyping phase was the realization that due to technical challenges, the user would be presented with a static screen for 7-9 minutes while the instance was being generated.
We were concerned during user testing that they would potentially bounce during that period of time and the trial would not continue.
To mitigate that happening, I suggested we produce a quick getting started video that would keep prospects engaged on the page, and give them a preview of what they might expect once they gain access to the learning environment.
The technical development team also proposed spinning up pre-instances in a queing system that would be ready instantaneously. This would work well, provided we could manage the maximum number of signup requests per day.
