SCIM Provisioning — Phase 1 (UX Case Study | Teradata VantageCloud Lake)
At Teradata, I worked on a feature that honestly doesn't sound that exciting on the surface, identity provisioning. But once I understood the problem, I got it. Enterprise org admins are the unsung heroes of any large company's data infrastructure. They're the ones controlling who gets access to what, making sure the right engineers, data scientists, and analysts can actually do their jobs. And before this project, that process was entirely manual.The SCIM project was about changing that. SCIM (System for Cross-domain Identity Management) is an open standard that automates user and group management across systems and our goal was to bring that capability to Teradata's VantageCloud Lake platform, so that changes made in a customer's Identity Provider (IdP) could sync to Lake in real time, without anyone having to do it by hand.
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
Walking into this project, there were a lot of unknowns — and I wasn't afraid to write them all down. I put together a sticky stack of open questions covering everything from the technical flow (how much of this is SCIM's established configuration process versus Teradata's own?) to the operational reality (where do users actually run these commands? what terminal? is this in Lake's SQL editor?) to the competitive landscape (how are other platforms implementing this, and how do we make ours better?).I also ran stakeholder interviews, asking cross-functional partners about their role in the process, what friction they'd encountered, and what an ideal experience would look like. The goal was to get everyone on the same page before a single wireframe was drawn — because the last thing you want is to design something beautiful that doesn't match what engineering can actually build.
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
I started with storyboarding — mapping out the full user journey from Before, through Doing, to After — across nine steps. This helped me understand the full picture before zooming into Phase 1.The full flow looked something like this:User discovers SCIM via a banner or notification in Lake's consoleThey navigate to the SCIM Provisioning page and click to enableThey're taken to the Service Principal page to begin setupAfter creation, Client ID and Client Secret are returned for use in the IdPUser exits Lake and configures their IdP using the SCIM base URL and credentialsUsers and groups begin syncing to Lake's Tenant SCIM VMGroup-to-role mapping is configuredUser checks sync statusUser has the option to pause or stop syncFrom there, I moved into medium-fidelity wireframes using 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
....The outcome was a focused experience that treated the org admin's time as valuable, and got out of their way.
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.
Reflection
This project taught me a lot about designing in ambiguity — when the technical requirements are still being figured out, when stakeholders have competing priorities, and when the timeline isn't generous. What I'm most proud of is that I didn't wait for perfect conditions. I asked the right questions early, documented my unknowns, and used frameworks like JTBD and journey mapping to keep the team anchored on the user even when the conversations got pulled toward the technical.If I'd had more time, I would have loved to do usability testing with actual org admins before shipping, and I was just starting to get into Pendo when I left — so tracking how users actually moved through the flow post-launch is something I didn't get to see. That's the part that still lingers for me. But Phase 1 shipped, it addressed a real gap, and it laid the groundwork for everything that came after it.