Back

Static Sites hosting, a free product

Connect your repo, select a branch, and push your static site to the Edge
Status
Live · kinsta.com
Team
Kristóf Dombi · Head of Development Architecture
Adam Tamics · Tech lead
Vela Ferguson · Tech lead
Mo Kerwin · Product research lead

Bence Vadász · Developer
Maria Mavromataki · Developer
Michael Fuller · Developer
Christi Nickerson · Technical documentation creator
What did I do?

My role

I led the design of Static Sites at Kinsta, being the only Product Designer in the team launching the Beta in July and then we launched the final version in September.

What did I do? Research: I worked alongside the Research Lead gathering all insights and feedback. Ideation, Conceptualization, User Flows, Visual Design, Design System updates, and some cool animations for loading states.
The Challenge

Why Static Sites?

While Kinsta had a strong presence in WordPress, the company wanted to open to new products: Applications, Databases, and Static Sites. What’s the point of having Apps, Databases, and no Static Sites? Users will need to have a different hosting for the front while the decoupled backend is in Kinsta. In September, we released Static Sites after 1 month of the Beta phase.

There were some great competitors in the Static Sites universe, while some of them are pure Static Sites like Netlify or Surge, some others have the front site as another piece of their ecosystem: Vercel, Render, Cloudflare Pages, Heroku, etc.
Static Sites competitors
Kickoff

Picking up the pieces

The decision was taken, that Kinsta needs Static Sites. After that, our team, Cloudflare team was the chosen one 😍 to build the new product with the following summary: free and easy to use.

Where to start? I had three weeks to finish the design, specific research wasn't planned at the time, so I gathered every single piece of internal and external information that I could.
Competitor Analysis
I analyzed 4 main competitors: Netlify, Vercel, Cloudflare Pages, and Github Pages. I focused on the main user flow and their main features. See competitor analysis
Static Sites competitor Analysis
Competitor Analysis · Netlify and Vercel
Data
I had nothing to start with, but I found some useful data and demographics. Two interesting things: React is still the king and there are two main purposes of a Static Site: Landings (personal and informative) and decoupled applications.
Static Sites Jamstack data and demographics
Jamstack survey · 2022
Gather user insights from past internal research
I reviewed past internal research to gather insights into user needs. Some users mentioned in the past how would they like to have Static Sites in Kinsta, basically ideas and features.
“Netlify has a lot of features, but... it’s a little confusing at first if you don’t know their interface... I remember when I first got into it, it was a little overwhelming because there are like 800 options”
Also, I gathered insights from our developers and some tech leads, then I tried to understand what was their approach.

The most common requests were:
  • Forms
  • Previews: URL for previewing their deployments
  • Notifications: Slack integration, Git services integrations
  • Autodetect frameworks, and compatibilities with most of them, React, Nuxt, Next, etc.
Static Sites, old feedback and requested features
Requested features from past research
Discovery

Understanding the users and their problems

What about our users? We already had Personas representing target users of our customer-facing products, Web Developer, Hobbyist, and WordPress Specialist.

Wait, Static Sites is a new product, so in this particular case, our personas are mixed between Application and WordPress personas. don’t change, I’ll try to summarize the most important things about them:
  • Web Developers: high technical background. They prefer 1 single hosting solution for all their services. Their needs are real-time information, such as logs, performance/speed and their main pain points are that they try to avoid complicated settings and architecture, they want to automate that and they keep AWS and GCP away.
  • Hobbyist: Users with medium knowledge of development. They are always learning new programming languages and they usually look for cheap or free hosting services. As for their needs, pretty similar to Web Developers, speed/performance but they want guidance and great tutorials because of their lack of knowledge. They also try to keep away from AWS and GCP and they look for easier configurations.
Static Sites personas
Personas
Setting the goals

Back to reality, the MVP

The most famous word in product strategy, the MVP. This is where the team sat down and evaluated features and timings.
‍
After some meetings, these were the main decisions:
  • Let’s launch a closed Beta that will be the MVP: only for current customers. It allow us to collect feedback from a limited group of users before rolling out the product to a wider audience.
  • Our personas do have not a strong tech background, let’s make it more open to all users, and hide the deepest configurations for hardcore users.
  • We will use Cloudflare as per our CDN and Edge Caching, so we have a strong seller point.
  • Features such as forms and framework autodetection weren’t priorities. I strongly disagreed with the second part, autodetect the framework makes developer life easier and makes us a reliable product.
  • Custom domains were discarded too, wait what? No sense to not include Domains for Static Sites, but it got implemented for the final release in September.
  • Success: the user deploys a site successfully.
  • Automatic deployment on commit.
  • Qualitative research planned, Interviews and a survey after 3 weeks of the Beta phase.
Two job stories
1#
  • Situation: When I make a commit I want to see runtime logs.
  • Motivation: I want to see all deployments at once to track my work
  • Expected outcome: So I can focus on development and forget about everything else
2#
  • Situation: When I deploy a site and it crashes
  • Motivation: I want to get insights, what, why and where
  • Expected outcome: So I can successfully deploy my site
Static Sites ideation and user flows
Low level user flow, stories and features
Let’s get started

First drafts

Having a great Design System gives you superpowers when you want to start designing some drafts. This time my focus was on the setup process, I wanted to make it easy and clean, noise-reduced, not all of our Static Sites have a strong tech background.

I designed the main flow, Settings, and Deployment pages, always having in mind that this is an MVP
Static Sites, first drafts
Low level user flow, stories and features
Insights

Beta research, feedback, and interviews

The method was clear, Google forms allowed participants to report problems, requests and general feedback. I collaborated closely with the Research team and Client Experience team, and around 100 people received the invitation.

In addition to passively collecting feedback through a form, we invited users who created static sites to sign up for interviews in which we proved their experiences in more detail. Around 15 people received this invitation.
Findings
Positive overall impression
  • Six out of eight participants described the service as easy to use.
  • Two participants commented that they would love to be able to move static sites to Kinsta and host everything in one place.
  • One commented that once custom domains are available his agency will “probably use it a good amount.
Room for improvement
  • One participant reported that logs did not appear on the deployment details page.
  • Custom domains: Four participants replied that the service did not meet their needs. The main reason for this was presumably because custom domains were not yet available. Without a domain name being able to attach, the static site is mostly useless.
  • Helper text Although users generally found the service easy to use, they would have appreciated a little more guidance through the set-up process.
Iteration

Designs

Every single comment and feedback has its impact on the design, for good or bad, and I took some decisions based on the research report:
Autodetect frameworks will increase the success ratio, sure, but I wanted to make the setup process cleaner and clearer:
  • Env variables collapsed and marked as Optional.
  • Added 3 Tooltips, yes no need to include all of them as explanation, in case that the Autodetect doesn’t work, they have the proper info to set up the site.
  • Changed some copies and removed non mandatory inputs.
Deployment success or error:
  • Clearer copies including some links to the log (errors case) <- Updated the Design System here.
  • After deployment, the user lands on the Overview page (Detail page for a Static Site).
  • Build and rollout have spinners and loaders.
Static Sites creation flow, autodetection framework
Creating a site - first step
Static Sites, site details design
Site details
Static Sites settings design
Site settings
Static Sites deployments design
Deployment details
Overages

Adding overages and limits

Static Sites are free, but not unlimited. CTO and some tech leads decided to add the following limits to our free Static Sites hosting:
  • 100 sites
  • 1GB build size
  • 600 deploy minutes
  • 100GB Bandwidth
After having that initial info, in collaboration with a lead, we built a low level flow and added notifications/emails to let the user know about the limits.
Overages ideation
Ideation for Overages
The following image, is a Design, is an example of an 80% warning regarding the Bandwidth
Design of the Overages, 80% Bandwidth reached
80% Popover warning