01IBM · Terraform

Making read-only access clearer in Terraform

Timeline: May–Aug 2026
Role: Product Design Intern

During my Product Design internship at IBM, I worked on Terraform’s read-only experience for users who could review configurations but didn’t have permission to change them.

What seemed like a permissions change affected much more than the Edit button. Across the product, removing editing controls could also remove context people needed to understand what was configured.

My contribution

I owned the workflow audit, interaction design, concept exploration, and usability testing for this work. Research was a team effort; my part is noted in that section.

Scope: 41 configuration routes
Tools: Figma
UserTesting
Jira
Terraform
Focus: Enterprise product design
UX research + testing
Interaction design
Systems thinking

01The problem

Read-only turned out to be more than removing the edit button.

Terraform’s role-based access control decides who can view a setting and who can change it. Making a setting read-only raised a harder question: what should stay visible once the controls are gone?

EditRead-only

Value Current configurationSelected value Context idepends on the value above Editing SaveCancelRemoved in read-only

EditableCurrent value + Context + Editing controls Read-onlyCurrent value + Necessary context − Editing controls

The real design question became: what context still matters when someone can look, but not edit?

Full case studyPassword protected

Go deeper into the work.

The full case study includes the 41-route audit, research findings, design explorations, Terraform-user testing, and the recommendations I handed off to the team.

Password Don’t have the password? Contact me for access: allisonqiu10@gmail.com

Inside

0141-route audit
02Research findings
03Design explorations
04Terraform-user testing
05Combined direction
06Recommendations + handoff

Full case study Unlocked — the full project continues below.