This case study is protected by NDA

The UI of the product had organically lagged from feature development, and felt dated.

Developer tools are known for poor interfaces, as if the field is allergic to products that are both powerful and nice to look at. So I was glad to be tapped for UI improvements on HCP Terraform, a managed service for deploying and tracking cloud infrastructure. I’d mostly done feature work at HashiCorp, but I’m a proponent of continuously improving the overall experience. This project became a lesson in managing scope creep and turning an ambiguous brief into a redesign of the 4 highest-traffic pages.

Hearing “make this look nicer” usually makes a designer’s eyes roll, but this time I welcomed it. Terraform Cloud’s UI had only seen incremental updates since its 2018 launch. Six years is a long time in design, and the product showed it.

The challenge, familiar to many SaaS companies, was balancing new feature demands (to reduce churn and win contracts) with addressing design and tech debt. While the project had executive backing from design and engineering, it lacked full company buy-in, most notably from product. This absence of true product management ownership reflected the fuzzy EPD structure around the project.

This theme of unclear ownership shaped much of what followed.

I wanted to root all the potential UI changes that I was proposing in real customer problems, and less gut feeling. To do this I started out with understanding sentiment in product through two main methods: cognitive ethnography and direct feedback form.

I conducted cognitive ethnography through social media, a method chosen for its efficiency in time and cost. Leveraging HashiCorp’s user base provided quick, free insights that formed a foundation for optimization. I supplemented this with ad-hoc feedback via anonymous Reddit surveys and in-app Snowflake forms.

Additionally, I analyzed familiar design patterns practitioners already use. By reusing these patterns, I reduced the need for relearning and made the new UI more efficient.

Creating an affinity map allowed me to stank rank ideas and weigh tradeoffs. UI Changes carry more weight than you think, when considering customer adversity to change.

Next I engaged the internal liaisons for customers: the field and PMs. Both could point me toward larger UI pain points that had been collected but not prioritized, which helped justify the work. From there I built a simple affinity map and took a first pass at what an improvement could look like.

We needed high level themes to make this project feasible, and ensure scope doesn't blow up.

From this design goal, we had a couple key parts of this project to decompose our ideation into:

This allowed me to think more clearly about some of the pain points that exist and translating that to the new UI.

The first concept for this stemmed directly from the usability improvements that we had highlighted.

We used our internal SME's and power users to yield insights which informed our first concepts. With this, I tried to push the bar as much as I could visually, to see how customers would react.

Customers overwhelmingly liked the direction, but there was small nitpicks around presentation.

The next step was ensuring the designs met the goals we set out to do. This was done through several customer calls where we went over the proposed designs and captured sentiment.

We also circulated the designs to customers through the field. The feedback was overwhelmingly positive, and I felt we were close to delivering something valuable.

Despite customer feedback, our product org believed the proposed designs were too radical of a change, and therefore would necessitate longer discovery.

Then we hit a roadblock. Product management grew uneasy that there was no product involvement, and what the blowback might be. Their fears were rooted in reality, and while frustrating, I saw their points:

1. Who would own this if it went spectacularly wrong?
2. Did this go through formal product development processes that we have internally?
3. What level of discovery was done here?
4. Why was this done in a silo?

I could have aimed to rebut each question, but rather than looking at it as an us vs them situation, I aimed to answer their core concern, which is risk.

With UI based changes, the risk matrix often will tell the tale that it is not worth pursuing, in that often it can be categorized as low impact and high risk. After all, users likely won't buy your enterprise infrastructure software because of the UI, but existing customers absolutely will be upset if the UI changes drastically for the worse.

My first approach was scaling back degree of change by creating a consistent design language product wide.

This included auditing patterns across the product, and workshopping a consistent language for how our product should look.

So really, our goal was to disprove the assumption that this UI project was low impact.

The surest way to de-risk a design is a large sample of users validating it, which gives you too much evidence to reject. I set out to do this two ways:

Our sales and solution engineering teams approved of the changes.

Internal awareness started with the people closest to customers: sales and solution architects. I reached out to 10 reps across different customer segments and ran concept validation tests, walking them through the designs.

A large scale (n=1184) survey showed that 65% thought the new designs was an improvement, while 23% said it was a substantial improvement.

My most daring bet was de-risking through a direct customer survey. If I could reach 1k+ users and get sentiment that the designs were a true improvement, I’d be confident they were safe. I pulled a list of active users who’d provisioned a workspace through the UI, confirming they were my target persona, then ran it through Marketo to exclude anyone who’d opted out of communication.

Finally, leadership started to see the value of changing UI. Under one condition: keep engineering committment low.

With those two steps done, leadership was easier to convince. I’d proved the designs were better and worth building, and got buy-in org-wide to invest engineering capacity. I had to concede on headcount though: only 1 FTE was allotted.

After another round of careful iteration from the feedback gathered through validation, I was able to deliver the following 4 screens. Here is the before and after.

The new design focused on minimalism, which was the new design standard that was being brought through in other areas of the product, while trying to keep the pages as actionable as possible.

The full prototype of changed pages.

More than the UI changes, I learned how to advocate for a design I believed in, and influence others to make a change.

This refresh touched a product used by tens of thousands of practitioners daily, so the impact was wide and immediate. The hardest part wasn’t the design work, it was convincing others that change was necessary. Early concepts and visuals did that better than any argument, showing what a modernized Terraform Cloud could feel like. The UI turned out to be more than surface polish. It reinforced how mature and trustworthy the product felt at scale.