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.
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.
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
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.
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.
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.
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.
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.
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).
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.
• 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).
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.
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.
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.
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! 🤘