Kentico Kontent (B2B Saas)October 2019 — April 2020

Improving developer experience in a headless CMS

Team

Collaborated closely with product manager and product team of 4 engineers. Also consulted design decisions with the UX team.

Role

Workshop facilitation, Information architecture, Prototyping, Usability testing, Interaction and Visual design

Outcome

Shipped "Environments" feature with user-validated design. Feature successfully adopted by enterprise customers.

kontentThumb thumbnail

Product

Kentico Kontent is a content management platform with a headless CMS at heart. As a B2B SaaS, it enables companies to work with content in one place and distribute it to all their channels (websites, apps etc.).

Target audience

The main audience of this project were developers integrating Kontent into their digital channels. They are an important user segment as they can become advocates for the product in companies.


Goal: Enabling safe development of changes

The problem was that developers working with Kontent had to make any changes on the production instance of the system. That was potentially dangerous as it could affect live content.

We knew that developing new functionality to a website or changing an existing one often required updating the content models in Kentico Kontent and that could result in breaking the website. Developers also needed to run separate instances of the websites: typically one for development, one for testing and a live one.

Environments: Creating a safe space for development

Environments would enable them to do that by creating a safe space for testing and migrating those changes that work without problems.

Lack of this feature was also among common reasons for losing potential customers to competitors. Solving this need would help the product be more competitive.

Why was there a clear solution from the beginning? There had been some discovery about this problem in the past but the solution never got into delivery. This time, the product team wanted to make it happen.

My role

One of the product managers reached to the team he needed a designer for this project. I took this opportunity to get involved.

My responsibility was to design the management of environments in the product and validate it with users.

I worked primarily with the product manager and product team dedicated to this initiative, but I also consulted my design decisions with the UX team.


Researching the problem space

I started my design process with understanding the problem. In this case, it was also important to know what kind of product risk we were primarily dealing with.

Studying previous research

There were previous efforts to build this feature so I didn’t start from scratch. I reviewed usability testing results of a previous design carefully to determine what to focus on when iterating on it.

I learned that developers had a hard time understanding the hierarchy of “projects > environments” in the UI and also some key functionality (such as deleting environments).

As this was a highly technical topic, I dived into reading about development workflows and I also discussed with the team to understand the problem space better. Since the product manager has previously conducted some research among our users-developers on this, I studied it to understand their needs and circumstances.

The main need was clear: to be able to develop changes and test them safely. Developers mainly feared breaking something in the live website or app.

Determining product risk

We knew that developers didn’t spend nearly as much time in our product as content editors. They would seldom go there, so the UI had to be intuitive for them.

An important part of that was establishing a mental model of the functionality. But we needed also to establish a model of the underlying technical solution which might’ve posed constraints on the design.

The value risk was fairly low here. The problems and needs were clear from previous research. Results of past usability tests showed that the biggest risk would be usability. The focus of my work was on addressing that risk.

Designing the solution

Workshop with team to uncover constraints

I involved the product team in the design process by facilitating a workshop to learn about technical constraints. We explored what the underlying technical model could look like. Which entities (e.g. users, content models etc.) would be on which level (figure 1 below).

This helped me see what kind of technical constraints I would have to work with. Establishing the model was also important for designing the navigation.

During the same workshop, I led an ideation session for coming up with ideas for the navigation (figure 2 below).

Sketching navigation structures with product team

Figure 1 (Left): Technical model draft; Figure 2 (Right): Navigation sketches

Defining main use cases

Armed with ideas from the ideation workshop, I started working on the interaction design of the whole feature. I started with defining the main use cases:

  • Create a new environment
  • Delete an environment when it’s no longer needed
  • Switch between environments

It became clear that easy access to the environment management was necessary. A project dropdown already existed in the UI and the navigation ideas usually centred around either incorporating environments into the existing dropdown or into a separate one.

Designing clear navigation

I made the decision to use a separate dropdown for environments as my hypothesis was it would better support the mental model of “projects > environments” and also provide space for a quick access button to environment management.

I explored several avenues for the placement of the environments management section. One of them was the main menu (figure 3), but it would introduce too much complexity into the navigation.

Ultimately I decided to place the management into settings (figure 4). It would help establish the hierarchy even further by showing which entities are set up on the project level and which on the environment level. Another reason for this decision was that development-related settings were already there.

Navigation to Environments in the main menu

Figure 3: Navigation to Environments in the main menu

Navigation to Environments in the Settings section

Figure 4: Navigation to Environments in the Settings section

It was important to distinguish between settings on the project level and on the environment level. I solved this by clearly separating the Settings menu to Project settings and Environment settings.

Naming of environments

The last question mark was the naming of environments. We knew there would one by default that couldn’t be changed (at least in the first release of the feature).

There were several possibilities for the name: live, production or master. Initially, I decided for “master” as it’s a familiar term for developers and therefore seemed like a good fit, but usability testing would prove me wrong later.

Other environments could be freely named as users would see fit.


Prototyping for usability testing

As my role was to validate the design with users before releasing it, I started organising a round of usability testing.

I formed hypotheses we wanted to test:

  • Users understand the hierarchy of projects vs environments when interacting with the navigation (especially in Settings).
  • Users have no difficulties managing environments (e.g. creating new, deleting, switching between them etc.).

With the help of our researcher, I designed test scenarios. Based on them I prototyped the solution, but I limited the prototype only to what was necessary to test my hypotheses.

Detail of the navigation dropdown in the prototype

Figure 5: Detail of the navigation dropdown in the prototype

My tool of choice was Axure as it enabled me to work with variables. The prototype had to change the environment name in the navigation elements pictured above (as it would in a real product) so that users wouldn’t be needlessly confused during testing.

Check out the whole prototype. (note: the prototype has been iterated since the usability testing based on the insights)


Usability testing

I recruited developers from our respondent pool and conducted remote usability testing sessions with them. I also made sure that there was one engineer from the team present for each session, to build more empathy in the team.

The whole study gave us several important insights:

  • Proved that the separate dropdown and the whole navigation worked well: Developers understood the hierarchy and navigated around the system with the new functionality without problems. The “Manage environments” shortcut in the drop-down was used by pretty much everyone to navigate to the relevant Settings section. It helped with navigation a lot.
  • “Master” didn’t work as name for the default environment: Developers associated it with a git workflow which wasn’t exactly the mental model we needed here. Based on this, we later changed the name to “production” as a more appropriate term.

There were a couple of other smaller insights into how the UI could be improved to be more intuitive. More importantly, though, we received good overall feedback and validated that the interaction design as a whole worked with only minor changes necessary.

I gathered the team to share the testing results with them. I wanted to create a shared understanding of the changes I was about to make to the design. The aim was also to strengthen the idea of how important user feedback is during the design process.

Iterating based on real insights

Iteration is an important part of the design process. With insights from the usability testing, I worked on improving the design. Most of the changes involved writing a clearer and more concise copy which I worked on with a technical writer to perfect.

I also submitted the whole solution for a design review from the UX team to identify any other possible issues.

In the end, we iterated on several things in the design:

  • Changed the name of the default environment went from “master” to “production” to avoid association with a wrong mental model.
  • Removed accordion navigation (see figure 4 above) to simplify the whole navigation panel as it caused some confusion during testing.

Then, the design was ready to be groomed with the development team.

Environments management section after a few iterations

Figure 6: Environments management section after a few iterations

Grooming with the team

The team and I gathered for a whole afternoon to examine the design from a technical perspective. We discovered potential difficulties and identified several ways of implementing the feature. They were all tied to the underlying technical model.

We agreed on an implementation that would allow the earliest possible delivery without compromising the interaction design we worked so carefully towards.

Defining ETP

We also defined several ways of evolving the functionality in future releases. One of them was the colour coding of environments – while users found it interesting during the testing, we decided it was not necessary in the ETP (earliest testable product) version.

I documented the whole solution in a handoff document for the team describing all the interaction details with including links to visuals in Zeplin. I made sure to capture all the different states of screens in the design.

Preview of the handoff document with the detailed solution description

Figure 7: Preview of the handoff document with the detailed solution description

However, I didn’t rely only on a document. I made sure to be in contact with the team during development to address any questions or concerns that were arising.

Validated design ready to be implemented

This was a really technical design challenge and it was a lot of work, but we ended up with a design that was:

  • Small enough to be shipped early
  • Validated thoroughly with users
  • Accommodating various technical constraints

The first point was especially important as this was a highly requested capability in the product and we wanted it to deliver it to the customers as soon as possible.

Environments creation dialogue


Shipping and impact

It took us about two months to go through the design process. In the meantime, the team worked on some technical pre-requisites for this feature. Then in May 2020, we shipped environments to our customers.

As the release date neared, I also participated in a webinar where our head of marketing, product manager and me introduced the feature to our customers.

Since the release, several enterprise customers adopted this feature. It greatly improves the developer experience of Kentico Kontent and makes the product more competitive.

One customer said this about environments:

“We’ve been using Kontent environments and migration scripts on our agency website to make, test, and deploy large changes to the underlying content model. Our team of content strategists and developers are happy to be out of production, and to leave that to the marketing folks creating content. Instead, the team can experiment in a safe Kontent environment that’s connected to a separate non-production build.”

Michael Kinkaid, CTO, Reason One

Read a blog post about Environments by Michael Kinkaid, Kentico Kontent’s customer.


What I learned

1. Make the team a part of the design process

Developers have good design ideas. Especially when it’s about a feature that’s highly technical and complex like this one was.

Having a shared first-hand experience during the usability testing makes communication around the whole design much easier.

2. Usability testing can always prove you wrong

While confirming some hypotheses, it revealed several gaps in the design. I could’ve easily said I fixed all the issues that arose during the testing of the previous design.

However, by testing the new design again I still gathered some important insights.