The Problem

Managing user identities across cloud platforms is one of those problems that sounds boring until you're the one doing it manually every single day. For org admins, any time a role changed, a new user joined, or someone left — they had to go update things separately on the Teradata side. It was repetitive, error-prone, and didn't scale. And to make things more urgent: Teradata's competitors already offered automated identity sync. This wasn't a nice-to-have. It was a gap.

Users & Context

The people I was designing for were org admins within Teradata's enterprise customer base. These aren't casual users — they're technical, they're busy, and they're responsible for making sure the right people have the right access at the right time. For them, SCIM wasn't just a shiny new feature. It was about getting a tedious, high-stakes task off their to-do list. One of the first things I did was map out the questions I didn't yet have answers to. Things like: Do users even know what SCIM is? Are they familiar with the terminology? Which parts of this process can they do alone, and when do they need someone else — like a second admin or Cloud Ops? I wasn't going to assume I knew the answers. I needed to go find them.

Discovery & Research

I held a project brief with the stake holders who explained the details of the new feature that was projected to be fully finished in 2026. A series of meetings was held between the Cloud Engineering team, Software Development team, and the Product design team; I tried to gather a full understanding of the technology that would be involved with this feature.

EDIT: During the time of research, I incorrectly misunderstood what JWT meant. It stands for 'JWT stands for JSON Web Token', a secure method for transmitting identity data between systems.

Jobs to Be Done

I used a JTBD framework throughout this project to keep the focus on user goals, not just features. The core job was clear: When I'm transferring roles and groups from my current IdP to Teradata's systems, I want an automated process that updates information in real time — so I can reduce errors and save time when provisioning users.

For Phase 1 specifically, I narrowed it down further: When I provision SCIM and create a Service Principal, I want to quickly gather the credentials I need to copy into my IdP — so I can move through the task without friction. That focus on "without friction" was important. Org admins are task-oriented. They're not browsing. They come in, they need a thing, they need to get out. The design had to respect that.

Design Process

JTBD+Outcomes

I started with mapping out each step for setting up SCIM. This helped me understand the full picture before zooming into Phase 1. For each step a user would have to take, I created a Jobs to be Done statement and an outcome statement.

• The JTBD statement says what the user wants to accomplish with each step: "When I configure mapping and start syncing with SCIM, I want to have automated processes, so I can reduce effort and time."

• The outcome statement is all about showing the predicted outcome of each step and mapping how well the design achieves it: "All tokens and URLs are retrieved quickly through the API."

User journey

This is where I went in-depth with the user journey, asking myself what an organization admin would do before, during and after the setup. I referenced a runbook given to me by the engineering team and incorporated that into the flow while trying to improve the process. This is where I had to keep technical restraints in mind, such as designing around fixed processes and so on. The journey is broken down by: what prerequisites are needed to begin provisioning, what actions the Cloud Ops team would have to take to configure settings, and what steps the customer would have to take.

I moved into medium-fidelity wireframes using Teradata's updated design system based on Covalent components in Figma — keeping things detailed enough to convey the ideas clearly, without over-investing in polish before the concepts were validated. I also flagged questions directly in the Figma file as I worked, because there were real open UX questions worth calling out: Should the button say "Enable" or "Provision"? Should there be a link back to the SCIM provisioning page after the user returns from their IdP? Small things, but the kind that matter when you're building for technical users with zero tolerance for confusion.

The Solution

With the medium-fidelity screens made (with premade Covalent design components), I presented my work to the design team, the CloudOps and Engineering team, and two high level stakeholders. This would be a stepping stone towards the completion of Phase 2 and the beginning of a transformative feature that would save not only time, but also money for prospective and current customers.

The screens below focus on the Service Principal setup, a critical component of the SCIM provisioning flow.

Challenges & Constraints

I'll be honest — this project had some organizational friction baked in from the start. There was active debate about whether SCIM provisioning was the right priority given the amount of technical debt already on the backlog. The team eventually landed on a phased approach — Phase 1 and Phase 2, delivered months apart — which was the right call, but it meant our scope was constrained from day one. The bigger frustration, though, was that the design team wasn't looped in during planning. By the time we had a seat at the table, the timeline was already compressed. That kind of late involvement is something I've seen derail projects — not because designers can't work fast, but because good UX thinking takes time, and rushed discovery leads to rework. I flagged it, I worked within the constraints, and I got Phase 1 done. But it's something I'd push back on earlier if I were doing it again.