Monica Crusellas | Redesigning Stax onboarding experience
I’m Monica, a product designer from Barcelona with a focus in UI and interaction design. Finding user-centred solutions to solve real problems for people it’s something that makes me really happy. While I’m not designing I’m learning code, practising German or reading books.
product designer, UI designer, interaction designer, prototyping, UX designer, visual designer, technology, startups, Barcelona, Berlin, Europe
22033
portfolio_page-template-default,single,single-portfolio_page,postid-22033,ajax_fade,page_not_loaded,,select-theme-ver-1.8,vertical_menu_enabled,wpb-js-composer js-comp-ver-4.3.4,vc_responsive

Redesigning Stax onboarding experience

Stax is a startup based in Melbourne, Australia, that’s building a platform that helps individuals, teams and organisations to create a cost efficient, secure and healthy Amazon Web Services cloud. One of the recent projects I took on at Stax was redesigning a crucial piece of the onboarding experience.

 

The goal of this project was to make it easier for new users to complete the free trial sign up process.

 

My Role in The Team

I worked closely with the technical UX Designer, the PM and the GM to define the problem and validate ideas. As product designer with a focus in UI, my responsibilities on this project were sketching, prototyping and testing interfaces, as well as preparing final designs and specs for the developers and conducting QA testings before going to prod. Additionally, I made the illustrations series that guided users through the new onboarding flow.

 

Stax team rooftop

Myself on the left!

 

 

The Problem

From a design and technical perspective, the onboarding experience in place -which was the MVP- felt very manual and confusing, and resulted in a relevant portion of users dropping off or contacting support.

 

Stax has a critical technical constraint, which requires people to link a specific type of AWS account to the app. Without that step successfully completed, we can’t provide real data, since we still don’t have their AWS information, so it’s a key step in the onboarding process that needs to be completed.

 

The flow in place

To provide a bit of context, in order to link an account, new users had to follow these steps:

• Download PDF with documentation guide
• Download a CSV template
• Do some work on the AWS console
• Open CSV and fill it with required info
• Go back to Stax and upload CSV
• Wait for account to be linked

 

Research and Goals

Speaking with our support team and checking our data analytics helped us identify that indicated new users were dropping off without linking their first account successfully. We talked to some of them to better understand where and why they were struggling and we identified some of the problems they were encountering when trying to link an account.

 

From this research, we detected three major problems:

• People were making mistakes when filling the CSV and the error messages and the help documents were not super useful for them to understand how to fix them.

• Technical people (engineers) complained about the process being too manual and time consuming, since it required to go back and forth between different tools (Stax, Excel, PDF help document and the AWS console). The task required too much effort upfront without providing enough value.

• Most of non-technical people (stakeholders, managers, finance) didn’t have access to their AWS account details and didn’t quite understand what they should do to link an account.

 

In order to solve these problems, we decided to redesign that piece of the onboarding experience by defining and prioritising the following goals and tasks:

 

• Simplify the whole task making it as much automated as possible, avoiding tasks being performed outside the app. 

• Create smarter error communications to help people understand what went wrong and how to fix it.

• Provide a clearer path for people without AWS technical knowledge.

• Improve our help documentation.

 

Design Process

Based on our findings and due to the the nature of the product, it was a critical step to acknowledge and investigate the technical constraint – the need to ask users to provide their AWS information. We had several discussions with the engineers on how we could technically make the existing process smoother and remove friction. Our discussions centered around creating an interaction that would minimise users leaving the app while working around AWS technical constraints. Finally, we found a way that would simplify the process and would reduce the number of times users had to interact outside the app to just one.

 

flow-wireframes

New flow: Log into AWS from Stax > Template is automatically filled. People just need to click the ‘create’ button > Back to Stax and wait for the account to be automatically linked

 

Smarter error messages
In order to make sure that people were able to solve encountered errors while linking their AWS accounts to Stax, we mapped out all the possible things that could go wrong and prepared specific content and suggestions to solve each of them, as well as improved and updated our help documentation articles.

 

error messages

 

A clear path for people without access to their AWS console
I designed a step in the flow asking users whether they had access to their company’s AWS console or not. I then provided a path for those who didn’t or were unsure about it by allowing them to send an email invite to a technical colleague that could link the required AWS account for them.

 

path wireframe

 

invite colleague

 

Putting the pieces together
I sketched different interaction patterns for the flow. The challenge was to simplify the actual complexity of the task and, after some internal testings, we decided that the best approach would be splitting up the task into a sequence of chunks to avoid overwhelming the users and make it easy for them to follow up. I used our modal UI pattern and added a progress indicator at the top so people would always know what was coming next.

 

flow-postits

 

Testing

In order to test our new ideas, I jumped into Sketch and prepared a prototype. I always use Invision for the first round of prototyping and I create specific parts of the flow that need interaction specs in Atomic, Flinto or After Effects (I’m also learning CoffeScript so I can add Framer in my workflow).

 

flow-diagram

 

The key things we wanted to validate were:

• If the steps were clear and easy to follow

• If the process felt quick and without hassle

• If people where able to link an AWS account without getting errors

• If people would understand how to fix an error if occurred

• If people without access to their AWS would know what to do

 

 

Additionally to testing with our target audience, I always try to also show our flows to people who has nothing to do with cloud. From my experience, asking people with no knowledge on the field gives you very valuable feedback on how to make the designs more accessible and easy to understand.

 

Relevant findings:

• Some people didn’t know why they needed to link a billing account first. (For more context, there are billing and non-billing accounts in AWS and we need the billing account first because it’s the one that has the relevant information).

• People without access to their AWS account were unsure of what to do after inviting a technical colleague to connect an account for them.

• People would follow the path as they had the right access to link an account just to see what was next, even if they didn’t have access to their AWS console.

• After linking an account, people didn’t know what to do. (The data can take up to 24 hours to populate, and while we said so in the UI, it wasn’t stated very prominently, so lots of tested users missed it).

 

Updating and fine tuning the design

I collected users feedback, analysed and identified required modifications to the designs. Some of the changes included modifying the flow to remove the option of linking non billing accounts, being more specific on how the ‘invite a colleague’ flow worked and making more prominent the section in which we explained that the data could take up to 24h to be ready.

 

The design below shows one of these updates made to the designs.

 

 

Developement

Once the final prototype was updated, I sat as usual with the dev who was going to work on the project. Since I always try to involve them early on, they are already familiar with the flow and the designs, but it’s always important to spend some time reviewing the whole flow and chatting about final details and interaction before jumping into implementation phase. After the kick off with the devs, the last step for me was to break down the project in Trello tickets and assign whoever is responsible for each task.

 

Final prototype

 

 

Metrics to look at after going live (KPIs)

• Task success rate: the number of AWS accounts successfully linked by users after signing up – so people can start using the free plan, see the value of the product and potentially convert.

• Task completion time: how much time it takes for new users to link an account – so we can detect if it’s as quick as expected.

• Type of errors a new user encounters when trying to link an account – so we can understand where people are failing.

• Number of people who got an error but managed to link an account without contacting support – so we can understand if the documentation guide is useful / developers are able to help non-technical people trying to link an account.

• Number of support tickets related to the topic – so we can see if they have been reduced.

 

Results

Since its launch in February 2018, the user feedback has been positive. High technical users got in touch to say that they appreciated our hard work on “turning such a technically complex process into a beautiful and smooth experience”.

 

In a brief period of time we’ve been able to reduce the number of errors while linking an AWS account and the number of those successfully linked has increased considerably. Our aim is to continue iterating and improving Stax onboarding, focusing on the struggles of non-technical people and providing more value to new users earlier on in the process.

 

Keep observing, asking and iterating! 🤘

 

Site

Stax

Category

Illustration, Research, User testing, UX UI Design