This case study is protected by NDA

Think of Terraform Modules as the "recipe" for repeatable chunks of infrastructure, and the registry being the recipe books.

Modules are reusable, self-contained packages of Terraform configuration. You define one once and use it many times, which keeps infrastructure code DRY (Do not Repeat Yourself). They come in two flavors: public, pulled from the Terraform registry, and private, managed inside an organization.

The authors of modules lack the ability to natively manage the lifecycle of their infrastructure modules.

Terraform modules, like any software, evolve through versioning (think iOS 17 to 18). Organizations release new versions to address security, bugs, and improvements. The challenge is getting users to upgrade. Different roles and skill levels create gaps in how people experience these updates.

The separation in these two personas is what makes this tricky. Lets consider the following scenario:

Customers work around this native feature through anti-patterns that do not scale well.

There are two core ways to approach this problem currently, which was told by customers. Each have downfalls and are indicative of the level of cloud maturity of the customer.

I assumed authors and consumers worked on the same team, but they rarely do!

My EPD team approached this by examining the gap between module authors and module consumers. To build empathy, we joined customer calls to see how organizations were truly structured.

I initially assumed both personas sat on the same DevOps or cloud infra team. In reality, authors were usually platform engineers on central SRE teams, while consumers were app developers or SWE’s seeking quick, self-serve infrastructure. This revealed how communication could easily break down. These groups often never interacted directly, making alignment much harder.

Customer calls unveiled a need for deprecation and revocation well after a module version is first published.

These customer calls and the problem statement helped us to devise some basic user flows. The parts of the flow that was highlighted are "new" areas.

I decomposed the overall flow into 2 core goals.

From here it was clear that we needed to build something within Terraform to help this core persona of the module author. To help understand how to create a solution we had to decompose the problem a little bit more.

Presenting information in context

Challenge: How might we give information in context in a way that is noisy enough to notice, but not overwhelming?

Decision: Use shortened accordions, with alerts to draw attention

Decoupling messaging from a run

Challenge: Users don’t always kick off runs in a set cadence, and sometimes informing them there might be too late. How might we provide information more statically?

Decision: 2 new indicators of module health that is decoupled from the run was included.

Zooming out and tying it to general workflow

Challenge: What are broader Jobs To Be Done that encompass these workflows, how do they fit in?

Decision: Module health data included in the explorer, greater change request flows.

Crafting a CLI Experience

Challenge: The CLI is often the golden workflow for users, how can we create a minimal viable design for the CLI?

Decision: Use verbose messaging in the CLI, and summarized in the UI.

The full prototype from module author persona to the linking with the module consumer persona.

This project tackled a problem many organizations face at scale. Hearing how mature organizations solved it in bespoke ways, and seeing where our solution could help, was a highlight. The core skill I built was listening intently and tuning through the noise, which matters when a research effort this size throws off an overwhelming number of signals.

Another milestone was seeing this unveiled at HashiConf, HashiCorp’s annual user conference. You can check out the recording here!