Simplifying Access Management

Following a workforce reduction, I was the sole designer tasked to multiple teams when a contractor from the Identity and Access Management (IAM) team approached me for visual designs.

When I brought up the request to my Project Manager, I was assured that they only needed a login screen. Given that the clean energy project was being built with Salesforce, there wasn’t a lot of flexibility with that experience.

I quickly prepared a branded out-of-the-box design for login; However, this was not what the IAM team needed. The security team from the business stakeholders considered Salesforce's login and user management protocol inadequate for their needs.

My other teams had a dedicated scrum master and business analyst, but the IAM team was comprised of developers only. With a lack of available resources, I performed triage where I could. I gathered Program Managers and Trade Partners and conducted end-user interviews to uncover business goals, security constraints, and end-user needs.

Due to time constraints, the interviews on the business side were limited to those most integral to the first programs available in the clean energy platform; However, this was a big mistake. When other Program Managers were able to join the sprint calls, I realized that we had built for the easiest scenario rather than the most complex. [insert fear of failure here]

While the dev team could have argued over implementing the pivot later, when the other more complex programs were introduced, they opted to apply the changes immediately.

We rebuilt the program application flow to scale for more complex scenarios where users could be applying for multiple large commercial and industrial energy incentives despite being only ready to launch electric vehicle programs. Even if the filters became more complex, their location would be the same and the interaction would still load a list of relative programs (versus an endless list of checkboxes). The goal was to stay scalable while not forcing users to learn a new interface when program expansion began.

As the project continued, I battled a growing scope not just within the project itself, but also the ask from every team I was a part of. Normally this is where I’d try to reduce time spent in meetings, but instead I opted to join one I’d never been invited to: the scrum masters call.

Everyone else was on track but the IAM team. One of my other teams was even ahead. Despite being a video call, I could feel the heat rising from the primary business sponsor as he lashed out over growing deadlines and the developers fought to defend themselves. When the sponsor said it looked like the team was going to fail, I seized the opportunity.

“Yes, we’re going to fail...”

The digital room fell silent.

“...because we need your help. The other teams have dedicated support from a Business Analyst and Scrum Master, but this team doesn’t.”

The shortcoming meant we were trying to tackle business and story-writing requirements, which took away from design and development time. It’s easy to deflect or defend, but to admit failure and ask for help gave everyone had a chance to be the hero. The tension was immediately replaced with vigor and relief as two volunteers stepped forward to carry the weight.

As the first iterations of design were approved and the dust settled, it became clear that the developers were battling a new problem: no one was truly proficient in front-end development.

While the style guide I had created had aimed to ease front-end styling, the developers were using two Blazor component libraries, causing style conflicts. The discrepancy between the design and implementation began to fill the backlog with corrections.

I provided support by inspecting the latest build, identifying conflicts, and documenting them in the relevant user stories. Though I couldn't resolve every issue, the lead developer appreciated my efforts and began reaching out to me directly. Working together, we battled the deadline and won.

Unfortunately, I’m not always kept on project/contract once design is completed. While I wasn’t present for user acceptance testing, I was told:

I should have asked for help when I realized the scope was larger anticipated. While I survived several weeks functioning as a business analyst, scrum master, and a designer, I should have asked for support sooner instead of risking burnout.