OtterTune
Case Study: IAM Role Access
About OtterTune: Founded in 2021, OtterTune built a web app optimizing Amazon RDS and Aurora database performance, helping customers reduce spending and improving efficiency in their AWS accounts through automated tuning and recommendations.
Intro: One of my first tasks as principal designer was to redesign the user flow providing OtterTune with access to a user’s AWS and IAM permissions. Without this, the product was useless and the user unable take advantage of OtterTune’s features.
Who was the user: OtterTune focused on non-professional level DBAs with a working knowledge of SQL and MySQL/Aurora databases. This would allow them to choose between AI or manually applying recommendations to optimize their Amazon RDS and Aurora database performance.
Project Goal: With the IAM role success rate hovering around 15%, the goal was to improve this to at least 25% or higher. Due to the challenges described below, as the number of customers increased with the new improvements, we could monitor growing traffic to make further iterative improvements over time.
My Role
As OtterTune’s principal designer, I met weekly with engineering, product management, senior executives and customers to gathering information and feedback.
With this data I was able to build out a series of wireframes and Figma prototypes to present at internal product discussions and customer demos.
After sign off from Product and senior executives, I worked closely with engineering throughout the development process. Engineering referred to my Figma designs and prototypes for product and style requirements.
My primary design tools throughout this project were Figma (wireframing, rapid prototyping), Pixelmator (graphic design imagery when needed) and an HTML editor to code up related emails generated by the feature. I also worked regularly with Jira and Confluence.
White-boarding session with product and engineering.
Primary Challenges
Key obstacles in this project included the following:
The user had to start the IAM process within the OtterTune application, jump to AWS in a new tab to create a stack and then return to OtterTune to confirm a successful connection. It goes without saying that it is easier for the user to stay within OtterTune entirely if possible.
The completion rate for setting up a user’s IAM permissions was 15%, which we were certain was due to the split nature of this flow. A non-professional DBA may have found it confusing to make sense of this and were likely abandoning the application entirely.
A user must give OtterTune access to their IAM permissions on AWS in order to use the application. Without this, they were completely incapable to use any of OtterTune’s product features.
The main issue was to simplify and have the user understand why they needed to go to AWS to create a stack that linked OtterTune to their AWS account.
Fortunately, two facts were in our favor: OtterTune was able to structure the stack creation form on AWS. And we found that some users felt more secure in going to AWS to grant permissions for database access.
Version 1.0 Issues
On OtterTune
The original IAM setup page was too long and technical for the user OtterTune was targeting. To learn more about the feature, they were asked to open up a help section to read through, which users tended to ignore.
Some information on the page, such as External ID and IAM Role ARN could be handled by OtterTune itself without asking the user to copy and paste it into the AWS side of the flow, thereby reducing the number of tasks required of them.
And there was simply too much text for the user to weed through (not including support docs). User experience videos on HotJar typically showed users scrolling up and down the page and pausing for long periods of time, often not engaging with the application at all. Often users would just drop off and OtterTune would lose that potential user.
Original IAM Role Form on OtterTune
On AWS
On the AWS side of the IAM permission flow, the user needed to create a stack containing information provided to them on the OtterTune side in order to link their account.
My discussions with the engineering team brought out the fact that essentially only two values were required to link AWS back to OtterTune: ‘IAM Role Name’ and ‘External ID’. The rest of the fields in the very long form were essentially optional. And OtterTune could include the External ID into the form for them instead of copy and pasting.
The user should mostly just have to review the simplified Stack creation form and submit instead of having to fill it out themselves. The rest of the information could reside in the background.
Original Stack Creation Form on AWS
Version 2.0 Solutions
On OtterTune
The original IAM setup page was too long and technical for the user OtterTune was targeting. To learn more about the feature, they were asked to open up a help section to read through, which users tended to ignore.
Some information on the page, such as External ID and IAM Role ARN could be handled by OtterTune itself without asking the user to copy and paste it into the AWS side of the flow, thereby reducing the number of tasks required of them.
And there was simply too much text for the user to weed through (not including support docs). User experience videos on HotJar typically showed users scrolling up and down the page and pausing for long periods of time, often not engaging with the application at all. Often users would just drop off and OtterTune would lose that potential user.
The user could still access the support docs, but the aim was to still provide some form of information about what to do and why they could trust OtterTune with monitoring their database performance.
New IAM Role Form on OtterTune
After the user has successfully created a stack on AWS, they then return the OtterTune tab in their browser and see that their new setup is now processing.
Results
The north star metrics for the updated IAM role page were as simple as monitoring completion rate. If user was unable to complete the flow, OtterTune lost that customer. The updated IAM flow resulted in a roughly 10% uptick and after an additional modification to the page (cleaning up form layouts resulting from front-end dev errors), that increased to over 20%.
Unfortunately, we did not have another chance for another round of updates before I departed the company.
Performance Results:
Early Stage Designs
As mentioned above, the focus of this case study is on the redesign of the fleet dashboard. But I did work on redesigning the rest of the site and below are screenshots of some of those sections.
Based on engineering originally believing there to be API tools allowing the stack creation step to be housed within the OtterTune application, I created some initial mocks and prototypes on how that might look. When it was determined that the API tools were not available, this was abandoned.
The right column was intended to educate the user what each field in the stack creation form was without having to open the help support document.
And at the top of the page would be a stepper showing the user the overall flow.