KINSTA
How smart defaults decrease time to deployment
Improved and unified the end-to-end experience of deploying services for new users
Context
Kinsta, initially a WordPress hosting service, launched an MVP for application and database hosting to meet the demand for custom solutions.
Facing a global decline in WordPress sites and slow adoption of new services due to feature gaps and brand perception, Kinsta shifted focus to make custom hosting solutions its flagship product.
This shift involves adding features like auto-scaling and observability improvements, streamlining the sign-up process, reorganising onboarding to prioritise application hosting, and investing in a brand redesign and targeted marketing efforts.
The idea was to leverage Kinsta's established reputation as a trusted WordPress hosting platform.
COMPANY
Kinsta
YEAR
2023
TIME
4 months
ROLE
Part of a cross-functional product team responsible for the application and database hosting products, product design, UI design, research, usability testing
Key takeaways
This project touched on most parts of the product and required regular alignments with security, legal, support, marketing, engineering, and other teams.
Created a unified user journey for of all products from sign-up to deployment.
Optimised the sign up process to get more users through the door quicker.
Redesigned all parts of the authentication process with the new brand.
Introduced new features like auto-scaling instances and observability improvements.
Getting a sense of the scope
Before any meaningful improvements can be made, it is important to understand the overall deployment experience. I mapped the end-to-end user journey for each of our hosting products from the perspective of a new user signing up and deploying a service for the first time.
Usability improvements everywhere
The user experience differed for each service. The main user persona was a developer testing different hosting platforms who cared about efficiency, feature set and the time it takes to see their project live in a staging environment.
For databases, the deployment process was the shortest and took the least amount of time. This is partly due to only needing to select a destination path and database size.
WordPress had the most amount of steps and took the longest to get to the first deployment. This is partly due to the configuration process of the WordPress platform, needing to sign up for a subscription plan and go through a lengthy deployment process.
For applications, the user needed to connect to a code repository like GitHub using 2FA and find the project to deploy. Deployment configuration was split into 4 steps with varying levels of nested feature modal windows and a mandatory payment step before the first deployment.
Users who deployed an application were also very likely to deploy a database.
Finding a measurement
Successful deployment times may vary from 3 to 15 minutes depending on the situation. It took an average of 8 minutes to deploy a project starting from the signup, influenced by factors like developer experience, project size and type, and pre-deployment exploration.
To understand the impact of our efforts, we chose 3 measurements.
Number of signups per month
Number of deployed projects for new users
Time from signup to successful deployment
Amongst other product, security and marketing measurements like the probability of fraud, source of origin etc.
Our goal is to enable new users to deploy applications as quickly as possible.
What is a deployment?
It helps to break down the end-to-end process into 4 parts:
Signing up and gaining access. Users enter personal information, verify their email, and complete the checkout process — about 2 minutes.
Finding the starting point. Here users usually explore the platform a little until they find the service they want to deploy — about 1 minute.
Configuring their project. Here users connect their GIT repositories, set paths for disks, choose a scaling policy and set the amount of resources they might need — about 2 minutes.
Deployment time. The project is compiled into a web application, where the time varies based on project type and complexity — about 3 minutes.
Most platform features were only used after a successful deployment.
To achieve our goal we had to improve the developer experience, remove barriers and improve guidance.
We didn’t set specific targets because the baseline could depend on how we measure it — the time frame we take into account, what user groups get included, and the size and complexity of the project amongst others.
How do we compare in the market?
Overall, we provided a middle-of-the-road experience for new users. We did not offer the shortest or the quickest way to the first deployment but we also did not put extra blockers in the middle of this first crucial platform experience.
Developers test many platforms before committing so any friction in the flow can count as a potential deal-breaker.
In short — not bad, could do better
Our sign-up flow was slowing down impatient users.
Some competitors removed all possible barriers and only prompted for more information after the first deployment was successful.
Paying before using is a blocker.
A requirement that worked for WordPress created friction for the new services. However, some competitors kept the payment flow because each time an application is deployed it uses server resources. Lots of abuse in this space from bad actors.
The manual configuration process was a small frustration.
It required interacting with most fields just to select a default value. Competitor flows felt quicker because of the default choices that were made for the user. Not much configuring is needed for the first deployment.
More steps than needed.
Yet the flow was missing key features that developers look for like auto-scaling and process scheduling. Competitors mostly had 1 to 2 steps before a deployment would initiate.
Deployment times were slower.
More than half of our competitors were able to deploy an application to a production environment faster.
Start with low-hanging fruit first
After a usability audit and competitive analysis of first-time user experiences, we decided to try an optimise and reduce friction in the current flow while in parallel working on features that have been requested by the community.
I found more than 80 issues after a usability audit of our services in our production environment.
We prioritised many small but impactful improvements instead of rethinking the whole experience from the ground up. Some of the immediate improvements were:
Reduce friction in the signup flow.
Better guide users into their first deployment.
Incentivize users to start using the service.
Unify and simplify the deployment processes for each service.
Remove mandatory payment requirements for application and database services.
Provide next steps for what to do while an application is being deployed.
Starting with the sign up
The existing signup was built for WordPress plans and it was time to adapt it for other services. The research team found a high bounce rate on the credit card step and only a small percentage of would deploy a database or an application.
If we reduce friction in the signup flow, more users would land on the platform which could lead to more deployments.
Less friction, more problems?
When you make entry into a product easy, it can attract bad actors seeking free hosting services.
Removing the credit card verification step, which acts as a fraud deterrent, raised concerns among the security team. However, prioritizing frictionless user experience led to implementing alternative abuse detection measures. For instance, limited credits were introduced for initial deployments.
Removing barriers to entry can invite bad actors to take advantage of the situation creating a security risk.
Legacy systems can also introduce unexpected constraints. For example, the implementation of the last name field was such that removing it would impact the majority of deployed projects.
Adapting for all flows
A sign-up form that is meant to be universal involves coordination across multiple product teams. I collaborated with engineers, product managers, designers, and teams from marketing and security to reduce the number of inputs, assess feasibility, and coordinate implementation efforts.
Once a concept has been approved, it has to be adapted for the specifics of each service and flow.
Navigating through a deployment
We understand that there are 2 main ways users approach application deployment at Kinsta.
Users who are less experienced would mainly follow the regular journey of signing up, exploring the dashboard and eventually selecting a service to deploy. These users would benefit from templates to experience the full deployment process.
More technical users who are examining if Kinsta works for their specific use case, would authenticate using GIT and would expect to see their own projects as options for deployment. By deploying their own project, they know where any bugs should be so they can see how the deployment process handles those.
Technical users want to test by deploying their own project because they know them inside out and want to how the deployment process handles those.
Incentivising users to start using services
An insight from the research team was that users who are testing the platform for work would be laser-focused on a specific use case while hobbyists would look at the cost.
To make sure users have all they need, we decided to have most big questions answered upon logging in. That is why documentation and platform credibility elements were put in a sidebar.
Offering free credits for the first deployment would be crucial to encourage new deployments because asking for card details would create friction. Our goal was to remove friction, not to move it around.
New users look for platform credibility, easy access to documentation, performance and cost.
The crucial first deployment
While users were largely fine with the original deployment process, we did receive feedback that improvements and new features are needed if these services would have the chance to get adopted by more people.
Most users were content with the existing flow but improvements were always suggested.
Exploring concepts
During this project, we began a rebranding initiative. The agency focused on marketing aspects but overlooked adapting it for our different services.
As a design team, we took on the task of adapting the new design language, maintaining consistency with marketing efforts and updating the design system so it can be used across all product areas.
I found that we use modal windows for all of the crucial deployment and configuration processes.
This is because originally the platform was built to support just a single service and made it easy to navigate.
The modals were generally stable, but we encountered issues where one modal would open on top of another, close accidentally, or fail to load correctly, causing users to get stuck.
My recommendation was to move functionality within a page and to use modals mainly for feature configuration. Below are some explorations.
Workshopping concepts and aligning stakeholders
As this was a high-visibility project, buy-in was necessary. I facilitated design workshops with engineers, designers and product managers to gather feedback. After incorporating it, I met with stakeholders to get buy-in for the next steps.
The proposals
Minimalist
Single screen, manual setup with advanced settings available after deployment. Only basic features are exposed. Could affect the user’s perception of the platform’s capabilities. Good for speed.
Advanced
Single screen, manual setup with advanced settings available after connecting to a repo. Main features are exposed even though are rarely used. Good for showing off existing capabilities.
Detector
Two screens, the system shows advanced settings based on the repository configuration. Requires creating a detector without providing much value as the configuration options don’t change drastically.
Two paths
Features depend on the project type. Asking the user to decide upfront creates an obstacle in the flow, especially if the user hasn’t decided on the type of project they want to deploy yet.
Alignment on a new direction
While each concept brings something valuable, it was decided to merge the minimalist and advanced concepts into one.
The motivation here was to not only show what is necessary for the first deployment but to also have advanced options available for those who need it with just a click away.
Minimalism isn’t always best for everything, a compromise can provide value for more people.
Exploring while deploying
Before we built the new build machine that deployed projects in under a minute, it took an average of 2 - 3 minutes. During the build process users could explore all the platform features.
This felt like a good opportunity to nudge users into doing simple yet useful tasks like updating their DNS records and adding account information. At the same time, these actions would showcase different features that were not visible before.
Users would observe the build process unfold and read the code from the terminal.
Developers cared about the terminal output because it would show if any failures occurred and where was the failure - either their code, either our infrastructure or the DNS settings.
One page concept goes to production
The new brand allowed me to play around with new layout ideas like a two-column layout which would neatly pack all necessary information into a single page. During the conceptual work, it was decided to not invest in developing new layouts. Once resourced were allocated for the change, the two-column layout was embraced and developed.
Reflections
I enjoy taking a big task, breaking the scope in deliverable chunks and executing.
Unifying the whole product journey is a challenging project not only because it requires alignment with each products team but also that the impact is product-wide.
This end-to-end process creates new knowledge about parts of the product that haven’t been touched in a while and offers an opportunity for house-keeping.
The time to deploy an application as a new user might go down from 8 minutes to less than 4.
Unfortunately, layoffs affected my ability to measure the actual impact. However, I built an end-to-end prototype and shared it with people to play around with to gather some signals:
The time from signup to deployment might go down from 8 to around 4 minutes.
The signup process was improved and took less than 1 minute.
Seeing documentation as soon as entering the product, made developers feel reassured that there is documentation, there are credential and certification and that customer support bubble is always available.
Offering free credits gave confidence to try out a deployment which otherwise would require committing a credit card which as I learned is a big blocker.
Users appreciated how simple it is to do a deployment but noted that without seeing the advanced features from the start they were concerned if the service would work for them.