Mike Long
Product Designer & UX Leader

Enterprise Identity

Improve application security with a simplified configuration experience.

In collaboration with a product manager and engineers, I helped release an application security service to customers in less than 6 months.

I joined the team after the kick-off meetings

Conversations with stakeholders

I talked with the Product Manager (PM) and the Team Anchor (engineering lead) about their progress thus far. They mentioned that after two kick-off meetings they weren't much closer to a shared understanding about what the first version of this product would look like, and what capabilities it should initially offer.

The search for a shared understanding

Solve the security admin's pain points first so that application developers can just focus on code (vs. configuration).

The team needed a clearer vision around a front-end experience for security administrators, and a clearer understanding of how application developers could serve themselves for their own application security needs.

An open source authentication and authorization service already underpinned the core security model for users and services, and we'd have to work within its constraints (at least for now).

Some questions still begged for answers:

  • What were the minimum configuration choices we should offer without sacrificing security and user experience?
  • What could we push down to the system layer—away from users—to make options simpler and more obvious?
  • What could we reasonably use from the existing authentication system for application security? 

Story Mapping
Enterprise Identity

Blue = activity  |   Pink = action   |   Yellow = feedback

Who? What? Why? When?

The PM had a deep background in enterprise application security and they had a very clear understanding of the "Who", "What", "Why", and "When". 

The problem was that I did not, and I needed to in order to help the team make progress.

I turned to the story mapping technique, and I did this with the PM across several two-hour sessions.

We would later use this story map as a way to categorize user feedback.

Take a closer look

Enterprise Identity

Users who have users who also have users.

Confusion about who the user is in a given context.

The PM told me the team had difficulty understanding what "user" means and in what context.

The term "user" could mean three things:

  1. The user who signs in to the application
  2. The application developer
  3. The IT Admin who configures the services

I was further confused about if:

  • a Space Developer is also an Application Developer? 
  • an IT Admin is also a Security Admin?

Story mapping helped with these questions and bubbled up the confusion early, which made prototyping and user story writing a whole lot easier. 

This, in turn, made the next kick-off meeting go much smoother: we were using the same terms to mean the same things in better understood contexts.

Enterprise Identity

IT Admin & Space Developer User Journey

Feature goals for the first release

  • Integrate applications with SAML 2.0 based enterprise identity providers
  • Secure all types of applications (web, mobile, and native), as well as the API’s both on and off the platform
  • Single sign-on between applications on the platform
  • Secure Java applications with a single click via the SSO Service Connector
  • Multi-tenant single sign-on service that allows for segregation of applications and identities based on the unique needs of the organization
  • Easy-to-use self service administration, user interface for tenant management, and on-boarding Identity Providers for SSO
  • Role based access control for Service Administrators & Application Developers
  • Self service interface for registering applications and associating identity providers for SSO
  • OAuth 2.0 Authorization Server with support for all four OAuth 2.0 Grant Types
  • Zero downtime upgrades with blue green deployment model
  • Certified with industry-leading federated identity providers including CA SiteMinder, Ping Identity, OpenAM, VMware Identity Management, Okta, and more

Skills gap combined with a mad rush.

The team was self-described as mostly backend engineers. Fortunately, we were in the process of developing a design system and I had enough web application development experience to help fill the skills gap.

The team felt a sense of urgency. I was told I had a month to prototype, and then development would have to start.

I made a few working agreements with the team:

  • Every prototype I shared was subject to frequent changes
    • This would prevent the team from running with a half-baked idea
  • Every prototype used real code in order to be nearly production-ready
    • This would enable the team to copy/paste some of the prototype code
  • Every usability test participant worked at Pivotal (IT Admins & Developers)
    • This would speed up usability testing, and yet defer validation with actual customers.

In order to cycle through as many iterations as possible, while using real code, I resolved to use my Ruby on Rails and JavaScript skills to make the prototypes.

Sketching happened at ad hoc whiteboard sessions with stakeholders. Then, I would bring the ideas to life with "real" code in the form of working-yet-janky prototypes.

I was nervous about the approach, but I used strict time boxes and minimalistic version control to keep the exploration on track.

Prototyping Begins

First Concept

First Concept

With input from the PM, I initially believed that we could use this moment to educate IT Admins about the different OAuth strategies by highlighting the description on the right when the strategy is selected on the left. 

This first prototype represented a couple of assumptions about the interaction:

  • That IT Admins would need to know the technical term for their OAuth strategy (or strategies)
  • That the workflow would need to be broken down into steps: Create App, Auth Config, Summary (Next Steps)

Second Concept

Second Concept

Based on feedback from the first prototype, I worked with the PM to come up with more direct way to illustrate the differences between OAuth strategies.

This version tested much better in that people more easily understood which choice reflected their current goal and use case.

Third Concept

Third Concept

After we gave a customer early access to our alpha version, we received some feedback about how we organized the information on the page.

Given the number of apps this customer would register with the service, they needed API Resources on a separate tab.

Enterprise Identity

Current Version

Current Concept

As the service started to get more real-world use by customers, we iterated toward a graphical interface that touted more information density.