Timeline

November 2019 - May 2020

Role

Product Designer, UX Writer

Team

Sam Rhea, Jonathan Spies, James Royal, Sieh Johnson, Lily Craver, Sieh Johnson

Tools

Figma, JIRA, Bitbucket

Overview

Access helps organizations of all sizes secure their internal applications and resources. Essentially, it replaces corporate VPNs with Cloudflare’s network — using a zero-trust model. IT admins can build rules that tell Access who does or doesn’t have access to an application. End users are prompted to login with their team’s identity provider, then Access checks this login against the list of allowed users. 

I was tasked with bringing the existing Access experience on Cloudflare’s core dashboard into the new Cloudflare for Teams dashboard.

Problem

When Access first launched in 2018, the product lived as part of the core Cloudflare dashboard: Cloudflare for Infrastructure. This dashboard has two levels to it: account and site. Sites (hostnames or zones) are nested under accounts, and from there you can configure features that apply to that site.

However, the majority of Access features affected a users account, not their site. This caused a lot of confusion for our users, leading to headaches but more importantly—real security incidents. 

Who uses Access today?
Most of our existing Access users are in charge of managing their company’s identity and access management. These individuals usually belong to the IT or Security group. For larger organizations, this can range from Network Services to Tech Ops.

Who would be interested in using Teams/Access?
We are targeting the same user group, but smaller organizations that would be interested in Pay-Go or Free plans. At the time of this launch, we were offering Cloudflare for Teams for Free due to COVID-19 affecting small businesses.

In order to understand how to bring Access into the Teams architecture, we stripped away each piece of existing Access functionality and mapped them to user goals. What was the purpose for each, and what value did it provide to our users? After this exercise, we were able to walk away with a common understanding of each feature-set, and we moved forward with setting our goals for this project.

Improved usability + accessibility. 
Not all changes should be cosmetic. Let’s use this opportunity to audit our existing patterns and understand where they can be improved.

Develop a strategic and intuitive product architecture.
When we think about bringing the Access functionality into an already existing dashboard (with Gateway), what architecture can we build today that is intuitive, and will allow us to scale over the next 3, 6, and 9 months?

Build a product and patterns that are scalable in nature to account for new experiences and rapid growth.
Cloudflare is investing in the Teams product at a rapid rate, meaning new product experiences will be added in the next year. How can the patterns we introduce now scale to account for this? Can our tables support 5, 10, or 1,000 rows of data?

The existing policy creation was very modal-heavy. We wanted to move away from this pattern for a variety of reasons.

1. Modals make it hard to isolate a task flow for users. Our existing modal had so many configuration options, and users felt overwhelmed.

2. We wanted a pattern that could scale as our policy creation flow became more robust with added features.

3. Modals are not always the most a11y friendly - keyboard tabbing into a modal to make it accessible for screen readers can be tricky. Knowing our existing engineering constraints, we wanted to focus on what was most achievable with the current technology we have.

These are the explorations around how to navigate away from our existing pattern and present policy creation and management in Teams.

We found that users were more tied to the applications behind Access rather than the concept of a set of policies, so we abstracted them and created a clear hierarchy.

1. Applications: With Access, you can protect two types of applications: SaaS and self-hosted. SaaS applications include applications your team relies on that are not hosted by your organization, such as Slack or Airtable. Self-hosted applications include your internal tools and applications, such as Jira or Grafana.

2. Policies: Policies let you define who can or cannot access applications secured behind Cloudflare Access, based on a number of attributes. These attributes include user identity, network attributes, and device posture.

3. Rules: You can define the scope of a policy by configuring policy actions and policy rules. These are the individual expressions that make up a greater policy.
   

BEFORE

AFTER

Authentication in Access is focused around how users want their end-users to be able to login or authenticate to particular applications.

The most common user flows here are 1) configuring an identity provider and 2) customizing their end-users login page experience. Most of these experiences are a “set it and forget it.”

What improved?

• De-modaling for improved task flows

• Isolating experiences into into separate pages / stepped flow

• Consistent experience for configuring these settings

• Grouping Authentication items into a single experience

BEFORE

after

Service authentication helps users reach applications behind Access using service tokens, mutual TLS, or short-lived certificates. It’s an automated way to authenticate a user based on a token or certificate. We combined these three experiences into a single view since their core functionality boils down to controlling how users are able to authenticate into their applications through a service.

Before

after

Access Groups are a set of rules that can be defined once and then quickly applied across many applications. You can select an Access Group as an attribute in any Policy rule, and all the criteria from the selected Access Group will apply to that application.

Imagine you want to grant access to your applications to your team based in Lisbon, Portugal. In order to avoid building the same set of rules over and over across your applications, you can create an Access Group called lisbon-team, which comprises an Include rule granting access to everyone in Portugal, and a Require rule restricting access to users whose email ends in @team.com.

before

after

Cloudflare Access generates two types of logs:

1. Admin Log: Changes made to Access policies across the account.

2. Access Logs: All authentication attempts. Details include the identity provider or login method and the IP address of the user.

The existing UI did not account for the scale of the amount of logs a typical user has. We broke out each log into it’s own page and made each column data consistent across all the logs. Additionally, we thought a lot about the content we were presenting in the table view and in the expanded view.

Before

after

Before we launched Access for general availability, we ran some dogfooding sessions with our Solutions Engineering (SE) and Customer Support (CSUP) teams. These teams interact with customers and our products directly on a daily basis, therefore feedback from these groups was valuable to us prior to launch.

In each session, we had attendees run through a typical setup in Cloudflare for Teams. This included setting up a Gateway location, an Access application, and applying policies to both. We then asked teams to review the logs for these events.

Members of my team as well as our Product managers were there to answer questions, triage feedback, and open tickets. Following this session, we prioritized the bugs and feedback that was found before launching to the public.