Capital One's Identity services are siloed by a single team, which means when a line of business needed to integrate login, authentication, or verification into a new product, they had to come to the Identity team directly. A single PM served as the intake point for every request, manually configuring solutions based on each team's risk tolerance, throughput needs, and product complexity. One person as the connective tissue between an entire Identity service and every line of business that depended on it was a single point of failure, creating a bottleneck that couldn't scale.
By creating a self-service Identity Platform, we could let teams access Identity-related services independently. This means a product owner can come in, describe their needs, and receive a recommended authentication configuration. A developer can view available APIs, review setup parameters, and integrate directly.
This project sits at the center of a company-wide strategic shift toward platform-based architecture led by the CEO, meaning it was high visibility and even presented at the CEO's annual town hall.
Before any UI work could begin, I had to understand the current process, its strengths, and its limitations. One of the ways to do this was by shadowing intake calls to observe what questions external teams asked and what information the Identity team needed to configure the correct solution.
The first step was to create a proof-of-concept form to gather all the information a human collected during those intake calls. If this could work without any human touch, it meant a platform was indeed a feasible solution. I found that while the form did get us most of the way there, it still had its limitations. For example, it was long enough to be fatiguing given the volume of questions that had to be answered. Additionally, not everyone had enough knowledge of Identity services to answer every question accurately.
While this was a highly technical project, I found that the hardest part was organizational. A 12-person cross-functional task force was spun up to represent different parts of the Identity ecosystem, each with vastly different competing priorities. As one of the more junior people in the room, I didn't have positional authority but what I had was Process and UX tools.
I co-designed and facilitated several workshops across the project arc, working alongside a senior design manager who provided strategic direction while I executed elements of the sessions. The format was deliberately structured to move from divergence to convergence: group requirements gathering to establish shared context, followed by Crazy 8s rounds to generate ideas quickly without overthinking, followed by presentation and riffing, followed by a second generative round to build on what resonated.
The output of these workshops was documented alignment through a shared artifact that every stakeholder had contributed to. But facilitation alone doesn't create momentum. After every workshop, the hardest question in the room was: what do we actually do next? One tool was creating effort/impact prioritization matrices to translate workshop energy into a defensible roadmap, creating a starting point for future PRDs.
The tactical reality of working junior in a senior room is that the standard tools of influence, such as title, tenure, and organizational leverage, weren't available which meant I had to get creative.
When stakeholders disagreed, I documented via meeting notes on a shared screen every session, even when we were all in the same room. By making the note-taking visible in real time, everyone could see exactly what was being captured as decisions were made. Once something was written down in front of the whole room, it became much harder to relitigate later.
Since design requirements risked getting deprioritized in the product development lifecycle, I embedded them directly into the PRD to make sure they would get addressed.
When individual influence wasn't sufficient, I escalated strategically, pulling in my design manager to add context and weight without creating conflict.
The initial design work on this project wasn't intended to be built. Instead, it was intended to create something for people to react to. In a problem space this large and this ambiguous, waiting for perfect requirements before designing is a losing strategy since requirements shift and stakeholders change their minds. People discover what they actually want by reacting to something concrete.
By producing relatively lightweight proof-of-concept screens early, the team had something to push against. Stakeholders who had nodded along to a verbal description of a feature could now say: that's not quite what I had in mind. The faster you put something in front of people, the faster the real conversation begins.
These designs were ultimately presented at a Capital One-wide town hall as part of the broader platform strategy, reaching leadership up to the CEO level.
In large, ambiguous systems-thinking projects, the hardest part is alignment across differing priorities. Solving these problems requires the same rigor and intentionality that we bring to designing interfaces — clear objectives, structured methods, iteration, and a willingness to adapt when the approach isn't working.
The lesson I've internalized across more than a decade in this industry: everyone in a corporate environment has access to roughly the same toolkit, and none of these are secret: workshops, frameworks, escalation paths, async documentation. Knowing which tool to wield only comes from practice, trial, and error.
This project reinforced something I carry into every authentication or high-stakes flow: the goal is never zero friction. It's the right friction. Users need to feel that their bank is working to protect them and the design's job is to make that feeling clear.