OtterTune
Case Study: Dashboard Redesign
About OtterTune: An A-round startup founded in 2021, OtterTune built a web app optimizing Amazon RDS and Aurora database performance, focusing on reducing AWS costs and improving performance and efficiency. The team consists of 20-25 people.
Intro: There are two types of dashboards in the OtterTune application. The top level page a user sees when they log in encompasses a user’s entire fleet or AWS account, an overview of all of their AWS databases. The second dashboard is for the individual database only. Both dashboards were intended to instantly display to the user the state of their dashboards, whether it was healthy, about to fail or somewhere in-between.
Who was the user: OtterTune focused on users that were not professional level DBAs, users that may be familiar with a working level of SQL and a general database knowledge. OtterTune could do the work for them through AI and machine learning or at least walk them through what they needed to do to maintain a healthy database environment.
Project Goal: The original dashboard designs were confusing to users. It was too text heavy and took too much reading before the user was aware of their database(s) health. The goal of the redesign was to instantly convey to the user the state of their database(s) as well as what to do to improvement.
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.
Primary Issues & Challenges
Dashboards too text heavy, no visuals to convey database health.
OtterTune didn’t have a robust list of recommendations to provide to the user to improve health. User had to click further into the app to find more granular information on database performance.
Newly enabled databases on OtterTune didn’t have a lot of data to report to the user. Could take up to two weeks to provide the user with full picture on their database health.
Dashboards should be jumping points to go deeper into the application based on presented data. Original dashboards did not allow for this easily.
Early Stage Design Ideas
I like to propose a series of possible solutions in addition to those communicated by team members internally as well as from feedback from customers. Here are a variety of designs presented for consideration to engineering and senior executives. It is also an early version of the site navigation. Here it is on the left, but in the final version it was at the top of the page in a horizontal layout
A key element of the new design was a health score as presented by a number. 85-100 was healthy (green), 70-85 indicated potential problems ahead (yellow) and anything below that was considered critical (red). The large number was an overall aggregate score while other variables (e.g. index, knobs, queries, tables, etc) each had their own health score.
The idea was for these scores to animated them in to draw the user’s eye and inform them instantly of their account’s overall health.
A tabbed layout would have allowed for more information to appear on the page without having to scroll far down the page. The fear was that a high enough percentage of people wouldn’t think to click the tabs to see the data inside. And from the start, there may not be enough data to fill each tabbed section.
This mock was experimenting with different chart types and contained a trends chart that might present to the user new angles into their data not otherwise available deeper in the application. This was abandoned as it was felt there was not enough initial data to populate this section at the start.
This was the first design proposed for consideration, with the Trends section being a new idea not present in the existing dashboard. Text recommendations and insights were presented on the right and database breakdown appearing below.
Proposed Solutions
The primary design component for the redesign was the concept of the health scores described above.
We wanted the user to see the score right away to quickly understand the state of their AWS fleet and individual database.
When the page rendered, the scores would animated in to immediately draw the user’s eye.
Below this score would be a list of recommendations that would inform the user best ways to improve their account and database.
The page loaded like a car dashboard when turning on. The main score and bar scores below would animate in to immediately draw the users eye. Hovering over each day in the chart to the right would show that day’s score and data.
Results
The redesign was released to the public and the overall response to the dashboard was a resounding yes in terms of making things clearer to the user, more functional, more intuitive. We weren’t able to get the large amount of traffic to gauge performance metrics, as the company soon pivoted to backend APIs, but management and existing users of the products were very enthusiastic about the redesign.
Old vs New Comparison: