How I rebuilt a 10 years old SaaS Product
My Experiments while rebuilding Monyog Experience
Monyog is a MySQL monitoring tool that gives DBAs real-time insights for optimizing the performance of MySQL servers. It was designed with the focus to provide a unified view of the health, security & performance of the entire MySQL server environment. But as the company grew, a new vision evolved: to create a simplified and efficient technological environment for companies across the globe.
While the original product served as a great tool for over 10 years, the new one had to be an even more Simple, Secure and Scalable tool making it as easy as humanly possible for companies to manage their servers and databases. The entire tool had to be re-designed from scratch. The entire codebase had to be re-written. It had to be built in such a way that the 35,000 companies across the globe already using the old product could migrate to the new product without any data loss.
My role was to define the product strategy (the WHAT & the WHY) and to design the new Monyog — the tool which was going to make the working life of DBAs simpler & more productive.
IDENTIFYING PAIN POINTS
The goal was to create a new Monyog that would work for large enterprises who have deployed hundreds of MySQL servers to small businesses with only a handful of MySQL servers. To create something for everyone, we risked helping no one. There needed to be constraints to prevent this from happening. So we did a whole load of user research to decide on which targets to aim at. We interviewed our existing customers and spoke to our sales & support teams. This helped us identify what key areas needed focus.
“How do I see the queries running for the last two hours?”
“What queries were running when this peak occurred?”
Charts are the heart of Monyog. But most of the users interviewed felt that the Charts tab is very confusing and doesn’t do what they expect on a basic level from it. Most of them felt that with so many charts for different servers along with so many view & filtering options, the information presented is overwhelming but not-at-all intuitive. A major group also complained about the inability to zoom into a single chart or view the queries from the time-range selected on a chart. They also requested for more customization options for individual charts related to resizing, viewing specific charts, etc.
“Where do I search for a specific server?”
All the users interviewed felt that displaying too many servers made it hard to navigate and have a granular view. Searching or scrolling through the large number of servers in the list both tagged or untagged was quite painful. Also they felt the need for an option to see all the activity going on in a server at a single place along with the ability to customize them with ease.
“How do I set a warning alert for this?”
Almost 80% of the users interviewed used Monitors on a daily basis. But they felt that setting up alerts and configuring email notifications using the same was very painful. The graphs in the Monitors section were almost impossible to customize & appear in conflict with the ones in the Charts section, thus very confusing. Some users complained that comparing trends for two different metrics for different servers was not possible in a single graph and needed the same. Others also requested to make setting up alerts and generating reports to be easy, as expected from Monyog.
“Monyog is powerful, complex and unwieldy. It has all the features required and more, but it’s not intuitive.”
“The interface is too busy. It is difficult to understand the workflow.”
“Which are the top 5 queries across all servers?”
“How do I see the slow queries running at this point?”
Monyog is extensive with fast switching capability. This is its biggest advantage. But this left the user with very less customization option. The user had to scan through too much data which is sometimes not even desired by him in the first place. There were some minor usability and interface issues also as told by users. Wayback Machine was useful but the interface and layout made it hard to use. The interface was very distracting in case of processlist and left the user puzzled. Query Analyzer presented all the demanded queries at once and left it to the user to figure out what to do with those.
DESIGNING THE SOLUTION
The findings of the user research brought to light the crucial places where Monyog was lagging. After processing the insights we defined a few design principles to help guide design decisions.
Avoid the Visibility Gap
The new Monyog needs to help uncover valuable MySQL server performance insights within minutes. From getting a bird’s-eye view of the data tier to blowing up a particular chart to identify what caused a spike, the user experience must be seamless.
Achieve Faster Resolution Time
The new Monyog needs to make monitoring MySQL databases easy. It must help users uncover the problematic queries across the server setup and fix performance problems in the complex data layer without much mind-boggling.
Large Server Clusters over Small
The new Monyog needs to work for everyone ranging from enterprises to small businesses to home users. But the features and the information architecture must be designed with DBAs monitoring server clusters on the range of 500–1000 in mind.
UP NEXT
The design insights & principles helped a lot to drive the design and development process of the new Monyog. Each time I was stuck on how to approach a problem, I’d come back to the principles for helping me get on track.
Here’s a sneak peak to how the new Monyog shaped up.
Stay Tuned for the Upcoming Part 2 in the series of Rebuilding Monyog Experience
Thank you for reading! This article is based on the work I did as a Product Designer for Monyog. If you enjoyed reading it, then please hit the little 💚 green heart down there to help others find it. Do let me know your thoughts in comments 💬 down below.
