Creating the Connection Panel in Cloud Managed Databases
overview
As the product designer in a cross-functional team, I identified and resolved issues faced by new users of Cloud Managed Databases to reduce the customer churn rate.
ROLE
User Research, Interaction, Visual design, Prototyping & Testing
Project Time
4 weeks (before handoff to development)
The Design Process
Our design process at the company was based on the double diamond framework and lean UX process. It is a continuous process of discovery, definition, ideation and implementation.
Problem Space
From the analytics systems, we observed that a significant portion of new users create a database cluster, then delete it and stop using the provider's services altogether.
We wondered what could discourage users from continuing to use our product.
Understanding User Flow
I have recently joined the product team and have never used cloud managed databases myself. As the product is mainly targeted at engineers I conducted a series of expert interviews with my colleagues to get a deeper understanding of user flow.
Afterwards, I came up with this chart representing the perfect flow of a new user:
.png)
We had two hypotheses:
1. Users have problems filling out Cloud Managed Databases form.
2. Users have problems with connecting to Cloud Managed Databases.
Talking to Users
In order to understand our new users' problems we decided to talk to them. To test our hypotheses I set up semi-structured interviews with 10+ users. We learned that our clients had problems with connecting to a Cloud Managed Database.
To simplify this stage for new users, our platform had a connection panel with example scripts on the cluster overview page. Users could copy these scripts and connect to the database via the console, even if they have limited experience with cloud databases.
Old UI with “Connection” section at the bottom of the“Settings” page
During interviews it became clear that this feature wasn't meeting users' goals. I identified three main pain points of our clients:
- users could not find connection panel in the interface as it was at the bottom the “Settings” page which was already overloaded with data. Users were expecting to find this section at the top of the page;
- users couldn’t find scripts for the programming language they needed as there was only one presented in the interface;
- users wanted to see DNS addresses not only for master node, but also for replicas.
Main Objective
This feature was important for us to improve in order to relieve pain points of our new customers, especially at the beginning of their user journey.
We determined that our main objective is to decrease churn rate and increase user interactions with connection panel.
Starting with Questions
We started with “How might we...” questions to find the best solutions to meet our users' goals. How might we:
- make our connection panel more discoverable?
- better communicate connection process to users?
- inform users of our new connection panel?
Low-Fidelity Prototyping
First, I started with figuring out where the Connection Panel would be more visible. Since from the user interviews it was obvious they were looking for it at the top of the screen, I came up with three options and did user testing with our support team members who had little to no experience using the Cloud Managed Databases.
1. Connect button at the top right of the page opening a modal.
.png)
2. A link opening documentation page at the top left.
3. A separate tab.
.png)
While the first option is the one most commonly used in the market (e.g. by our main competitor - Yandex.Cloud) we have discovered that users find it misleading: when pressing the "Connect" button users expected to be connected to the Database straight from their browser but they were redirected to a modal with Connection scripts instead.
Information Architecture
Before getting into prototyping I wanted to structure all the information needed for users to successfully connect to a database in a clear way to then publish it in the newly added Connection tab. First, I spoke to our engineers to get an understanding of the essential steps for a successful connection to a Cloud Managed Database.
.svg)
I sketched a draft of the tab structure and asked my colleagues to review it to ensure everything was technically correct. From our analytical tools I saw that almost no clients used IP addresses to connect to Cloud Managed Databases, besides DNS addresses are more reliable from the technical point of view, so we decided to only have DNS addresses in the interface.
At this point we had to decide what programming languages we wanted to cover with this feature. We quickly ran a survey to find out which programming languages our clients used most often. Then our engineers started working on sample scripts for those languages.
High-Fidelity Prototyping
I created a couple of prototypes and quickly tested them on our colleagues from support team. After deciding on a prototype that most successfully solved users' problems during testing, I sent it to my designer colleagues for a review. Then I made a couple of final edits and the final prototype was ready:
Final version of the interactive prototype
.png)
Changes made to old UI
Success Metrics
Usually, once the final prototype is ready, I begin designing success metrics for the interface in Amplitude and PostHog. In this case we wanted to see if users were more successful in finding connection information with the introduction of this new tab than before. We also wanted to gather some useful data for the future UI improvements: data on what programming languages our users copied scripts for and whether or not they used SSL.
Results in a Month
- A 12% decrease in the churn rate.
- An increase of threefold in the number of users copying information from the Connection Panel.
- A 75% decrease in the number of support requests regarding the connection process.
