CASE STUDY

Took task completion from 0 to 100% through in-product content

Have you ever had a product task that absolutely none of your users were able to complete? That was the case with ServiceNow’s UI Builder product. When we asked our users to do something as simple as create a new page, not one person could do it — that is, until we did a complete redesign.

In this case study, I’ll show how my UX writing contribution took the page creation flow from a 0% task completion rate to 100% in just one release.

My approach to UX writing is pretty consistent:

I break down complex flows into smaller messages, figure out what users need to hear and when, and structure that information in a way that helps them move forward confidently.

This case study—about improving the page creation flow in UI Builder—is a good example of how my approach delivers measured improvement to product quality.

Context

  • ServiceNow is a platform that businesses run their operations on

  • UI Builder (UIB) is a tool for creating app interfaces on the ServiceNow platform

  • The mid-skilled developer is the main UIB user — familiar with web apps but not a pro coder

Problem

  • ServiceNow is a platform that businesses run their operations on

  • UI Builder (UIB) is a tool for creating app interfaces on the ServiceNow platform

  • The mid-skilled developer is the main UIB user — familiar with web apps but not a pro coder

The full story

UI Builder is a web experience development tool that ServiceNow offers for free with its platform. Customers use UI Builder to customize the workspaces they buy. Having UI Builder for free is a huge selling point for workspaces, so it's paramount that UI Builder works very well. The better the experience, the more likely customers are to buy additional workspaces.

In fact, UI Builder has considered user experience quality one of its key business metrics. We used a measurement tool called the User Experience Quality Score, which averaged completion rates for key tasks in UI Builder and scored them from 0 to 100. Our initial score was just 11 out of 100—but within a year or two, we improved that to 69.

The case I'm sharing today is about one feature upgrade that played a key role in improving that UX quality score.

We released UI Builder in our Quebec release in 2020. At that time, we required customers to update their page layouts by directly editing CSS code. This proved to be a barrier for many developers who didn’t have the technical skills to code by hand. It favored pro-coders—people with software engineering degrees—and that just wasn’t our target audience.

So, we introduced a new, simpler way to manage page layouts. It didn’t require writing code. Instead, users could edit things like spacing and padding just by changing settings. We found this approach really resonated with users.

However, in order to use the new layout system, customers would need to fundamentally change the backend architecture of their pages. We didn’t want to force this change on anyone. Instead, we wanted to give people a chance to try it—essentially, to "try before they buy"—so they could see how the new layout system worked and decide whether to adopt it.

This led to a design challenge: create a layout upgrade flow that let users preview how the new system would affect their page before committing to it.

When I joined the project, a lot of the requirements had already been set, and another designer had created a full end-to-end flow. He wanted me to replicate it. In his version, the user would see a button to update their page layout. When they clicked it, they were taken into a preview mode where the page used the new layout system. At the top of the screen was a large green alert with a paragraph of copy—four to five lines long—and two or three buttons. It was a lot of cognitive load all at once.

After reviewing this with the team, I realized that no amount of copy editing would solve the problem. We needed to redesign the information flow.

I broke the alert’s content into distinct pieces of information:

  • Why upgrade?

  • What to expect?

  • What should the user do now?

We then designed purposeful touchpoints to deliver each message in the right place and time:

  • A modal upfront explains the why and what to expect.

  • A loading state communicates progress.

  • A minimal alert appears post-load with one clear call to action: review the preview and accept or reject the upgrade.

This approach made the transition less intimidating, especially for non-technical users.

This design was implemented in the San Diego release, and we've been tracking its success ever since. So far, we've seen about 4,500 page layout upgrades since the release. And like I shared earlier, our UX quality score improved from 11 out of 100 to 69, drastically reducing an adoption barrier for a key ServiceNow product.