Your team likely uses more SaaS applications than you realize. The time your administrators spend vetting and approving applications sanctioned for use can suddenly be wasted when users sign up for alternative services and store data in new places. Starting today, you can use Cloudflare for Teams to detect and block unapproved SaaS applications with just two clicks.

SaaS applications save time and budget for IT departments. Instead of paying for servers to host tools — and having staff ready to monitor, upgrade, and troubleshoot those tools — organizations can sign up for a SaaS equivalent with just a credit card and never worry about hosting or maintenance again.

That same convenience causes a data control problem. Those SaaS applications sit outside any environment that you control; the same reason they are easy for your team is also a potential liability now that your sensitive data is kept by third parties. Most organizations keep this in check through careful audits of the SaaS applications being used. Depending on industry and regulatory impact, IT departments evaluate, approve, and catalog the applications they use.

However, users can intentionally or accidentally bypass those approvals. For example, if your organization relies on OneDrive but a user is more comfortable with Google Drive, that user might decide to store work files in Google Drive instead. IT has no visibility into this happening and the user might think it’s fine. That user begins sharing files with other users in your organization, who also sign up with Google Drive, and suddenly an unsanctioned application holds sensitive information. This is “Shadow IT” and these applications inherently obfuscate the controls put in place by your organization.

Cloudflare Gateway routes all Internet bound traffic to Cloudflare’s network to enforce granular controls for your users to block them from unknown security threats. Now, it also provides your team added assurance with a low-effort, high-visibility overview into the SaaS applications being used in your environment.

By simply turning on Gateway, all HTTP requests for your organization are aggregated in your Gateway Activity Log for audit and security purposes. Within the activity log, we surface pertinent information about the user, action, and request. These records include data about the application and application type. In the example above, the application type would be Collaboration and Online Meeting and the application would be Google Drive.

From there, Gateway analyzes your HTTP request in the Activity Log and surfaces your Shadow IT, by categorizing and sorting these seemingly miscellaneous applications into actionable insights without any additional lift from your team.

With Shadow IT Discovery, Cloudflare for Teams first catalogs all applications used in your organization. The feature runs in an “observation” mode first - all applications are analyzed, but default to “unreviewed.”

Your team can then review the applications found and, with just a couple clicks, designate applications approved or unapproved — either for a single application or in bulk.

This allows administrators to easily track the top approved and unapproved applications their users are accessing to better profile their security posture. When drilling down into a more detailed view, administrators can take bulk actions to move multiple newly discovered applications at once. In this view, users can also filter on application type to easily identify redundancies in their organization.

Another feature we wanted to add was the ability to quickly highlight if an application being used by your organization has already been secured by Cloudflare Access. You can find this information in the column titled Secured. If an application is not Secured by Access, you can start that process today as well with Access for SaaS. (We added two new tutorials this week!)

When you mark an application unapproved, Cloudflare for Teams does not block it outright. We know some organizations need to label an application unapproved and check in with the users before they block access to it altogether. If your team is ready, you can then apply a Gateway rule to block access to it going forward.

While we’re excited to help IT teams stop worrying about unapproved apps, we also talked to teams who feared they were overspending for certain approved applications.

We want to help here too. Today’s launch counts the number of unique users who access any one application over different time intervals. IT teams can use this data to check usage against licenses and right size as needed.

Without this feature, many administrators and our own internal IT department were losing sleep each night wondering if their users were circumventing their controls and putting them at risk of attack. Additionally, many administrators are financially impacted as they procure software licenses for their entire organization. With Shadow IT Discovery, we empower your team to anticipate popular applications and begin the assessment process earlier in the procurement lifecycle.

We’re excited to announce Shadow IT and can’t wait to see what you’ll do with it. To get started, deploy HTTP filtering for your organization with the Cloudflare for Teams client. In the future, we’ll also be adding automation to block unapproved applications in Gateway, but we can’t wait to hear what else you’d like to see out of this feature.

Today, we’re announcing a new feature within the Teams Dash. We called it “Home”. We created Home with a simple goal in mind: design an adaptive and informative landing page where users can see a round-up of their environment.

In this last post of our series, we’ll show, rather than tell, how we collaborated as a team that rows in the same direction and towards the same goal — to create a great user experience.

In this blog post, we’ll walk you through your new Teams Home by calling out a few of the guiding principles we had in mind as we designed it. Transparency, adaptiveness, guidance and warmth aren’t only foundational words in the Cloudflare for Teams product principles — they’re part of our day-to-day brainstorming and discussion around user experience.

Here’s how the Teams Home reflects these principles.

What you’ll find in the new Teams Home is a single space to view your network and applications traffic. We wanted to build an experience that allows users to get a comprehensive view of all things protected by Teams — a single pane of glass that’s always available, and that users can quickly pull up to spot any anomalies in their network traffic. Or simply to keep it under control.

We’ve also made it simpler for you to keep an eye on user count, and added a direct link to our plans page should you need to make any changes to the subscription you’ve chosen.

The Teams Home brings all users signals into one view, threading together concepts that were once sparse across the Dash.

We called it “Home,” because we wanted it to feel like a space you visit each day that brings you clarity and peace of mind. Too often, security products can feel clinical and stark, and we wanted to avoid that. Through the use of color theory and language analysis, we actively worked to convey a feeling of approachability, while still keeping the Dash functional and straightforward.

When writing for UX, we need to be considerate of a user’s emotions as they follow a given flow in our product. Some users may appreciate certain elements as they explore the dash on a not-so-busy day; other users may not if their environment is at-risk and they simply need to identify what’s wrong, fast.

With this in mind, we’ve sprinkled bits of conversational, friendly copy where appropriate. For example, the biggest textual element in the Home page is a greeting — consistent with the header in our Quick Start page (“Welcome aboard!”), the tone is designed to be cheerful and welcoming.

Another subtle example of this is our loading screen. Nobody likes to wait, so we wanted to build this interaction for our users as well. With an animation that brings in elements representative of Cloudflare’s network, and alternating lines of copy that refer to the semantics of building and cleaning a physical home, we wanted to add a quirky touch where it doesn’t interfere with what really matters.

The Teams family has grown and expanded since its inception, and we wanted to highlight complementary features that are a key part of our user journeys. In the footer, you’ll find easy access to things like Cloudflare Radar, the Teams Help page, and a quick-start guide packed with simple starter packs. These additional features help craft a holistic picture of the Teams story.

In our product principles, we give great importance to ease of use. And we, as a team, have an ambitious goal in mind — make Zero Trust security principles approachable for everyone.

To us, a product is easy to use when it guides users to success through clear paths in the interface. This is why we’ve pre-established some of these paths — we want to help our users take their first steps within Teams. With just a few clicks from the Home and Quick Start pages, users who signed up primarily for Secure Web Gateway functionalities can add Zero Trust rules in front of their applications, and vice-versa.

We’ve also incorporated an entirely new approach to some of our empty states. Instead of just telling our users there’s no data to show, we help them take actions to start populating those empty charts.

As threats on the Internet evolve, so will the needs of our users. Throughout this process, we thought critically about how the Teams Home could be flexible in nature, and scale was a key priority. We’ll continue to ship new features — and when we do, those features will have a place in the Teams Home, in large part due to the modular approach we adopted. Moving forward, we will continue to add more data signals into the Teams Home and aim to put more control into your hands to customize your unique Home experience. We’re also integrating easier ways for you to give us feedback on the overall experience and are excited to learn more from our users.

The Teams Home is available today for all users on the Teams Dash. If you don’t have a Cloudflare for Teams account yet, click here to get started.

You’ll know you’re Home when you see the Welcome Page.

Starting today, your team can use Cloudflare Access to build rules that only allow users to connect to applications from a device that your enterprise manages. You can combine this requirement with any other rule in Cloudflare’s Zero Trust platform, including identity, multifactor method, and geography.

As more organizations adopt a Zero Trust security model with Cloudflare Access, we hear from customers who want to prevent connections from devices they do not own or manage. For some businesses, a fully remote workforce increases the risk of data loss when any user can log in to sensitive applications from an unmanaged tablet. Other enterprises need to meet new compliance requirements that restrict work to corporate devices.

We’re excited to help teams of any size apply this security model, even if your organization does not have a device management platform or mobile device manager (MDM) today. Keep reading to learn how Cloudflare Access solves this problem and how you can get started.

An enterprise that owns corporate devices has some level of control over them. Administrators can assign, revoke, inspect and manage devices in their inventory. Whether teams rely on management platforms or a simple spreadsheet, businesses can treat corporate devices as their own.

That visibility and management does not apply to a personal device — and we are all glad that is true. However, that same value causes problems when enterprises need to restrict data or access to applications to only a corporate device. If I’m able to login to a system and download data on a personal device, I have created a new headache for IT and security.

Single sign-on (SSO) providers and SaaS applications make it easier to make that mistake, intentionally or not. Users can login to a corporate application by simply reusing their passwords. Even if the organization enforces multifactor methods like hard key authentication, a user can just plug their key into a personal device.

We’re excited to give any team the ability to maintain control over data by ensuring it stays on corporate devices. Cloudflare Access is a comprehensive Zero Trust platform that administrators can use to build rules by identity and other signals. Teams can build rules for self-managed and SaaS applications. Every request and login is captured and all of it is made faster for end users on Cloudflare’s global network.

You can now use Cloudflare’s Zero Trust platform to build a new type of rule: only allow connections or logins from a corporate-owned device. You can use your own inventory system, whether it is a simple spreadsheet or API from an MDM platform. Our Cloudflare for Teams agent runs on the device and gathers details about the hardware, checks it against your inventory, and Cloudflare’s edge makes a decision instantly.

Enforcing corporate devices in Access takes about 20 minutes to set up and only requires that you have a list of corporate devices’ serial numbers.

The first step is to establish and import your list of managed device serial numbers. Serial number lists can be uploaded in bulk or created manually directly in the Teams Dashboard. Many inventory and asset management tools provide a straightforward way to export device serial numbers.

It is also possible to to upload new serial numbers over the API allowing for automation when new devices are purchased.

The next step is to deploy the WARP client across your corporate machines. Users can download and install the client themselves or it can be installed via an MDM solution.

That’s all that is required to begin enforcing Zero Trust access for only corporate devices! You will now be able to build Access rules that check if a device’s serial number is in the managed devices list.

Now even if a user moved their hard-key over and installed WARP on their personal device, they would still be blocked because they’re not in the corporate serial number list.

If you would like to start locking down applications to only corporate devices, sign up for a free Teams account up to 50 users. If you are an existing customer, this is available in your Teams Dashboard today and can be set up with the following guide.

Cloudflare for Teams was first announced in January 2020, along with our acquisition of S2 Systems. It was an exciting day for everyone at Cloudflare, but especially my team, who was in charge of building Teams.

Here is the story of how we took Cloudflare for Teams from initial concepts, to an MVP, to now a comprehensive security platform that secures networks, users, devices, and applications.

When I joined Cloudflare in April 2019, I was excited to have an impact on helping to build a better Internet. I was fascinated by the intricacy of how the Internet works, and wanted to untangle that complexity to provide our users with the best in class experience, with a simple and concise design approach. Little did I know that I would have the opportunity to launch a product that would impact thousands during a time when people need the Internet the most.

We started conceptualizing what would eventually become Cloudflare for Teams in July 2019, with a big vision and a small team. Coming off the excitement of 1.1.1.1, the team began thinking about how to bring this functionality to small, medium, and enterprise businesses. Our goal was to bring protection to anyone and everyone by extending the same security technology the app offered. After months of brainstorming sessions, design iterations, and testing, we had an MVP version of Teams: offering customers a way to protect their network from security threats on the web using DNS filtering.

But we didn’t stop there. Access had been helping customers secure their applications using a zero-trust security model since 2018. This functionality existed in Cloudflare’s core dashboard, but was constrained to a site-based model, while customers used Access as an account-based platform. This led to lots of confusion for many of our users. Bringing this functionality into Teams felt like a natural fit — Access would act as a bouncer standing in front of the door, checking identity, while Gateway would be a bodyguard, keeping your team safe as you navigate the Internet.

Bringing existing functionality into a new experience is no easy feat. The largest question to answer was: how can these two powerful security technologies not only cohabitate, but complement each other? We started by taking a step back and auditing what user problem we were solving with each piece of Access. This helped us understand where Access would fit under the Teams family, and how it could best integrate with Gateway.

From there, visual and design iterations began. Using the existing patterns and styles we created in Teams, we modified the look and feel of Access. However, not all of these changes were cosmetic. We focused on improved task flow, accessibility, and creating a seamless user experience.

Little did we know that it was just the beginning of what Teams would become.

During Zero Trust week, we introduced three new capabilities into Teams. We expanded on our DNS filtering capability by adding in L7 inspection of traffic for threats that hide below the surface. We launched the Teams WARP client, extending the same security Teams offers to our end-users’ corporate devices. And lastly, we expanded our Zero Trust offering to support SaaS applications, giving users a consistent level of visibility and security across all of their applications.

So what does massive product growth look like behind the scenes, from a design perspective? Rapid iteration, testing, and lots of collaboration with Engineering. A key goal was to design with scale in mind. How will these experiences grow in six months, one year, or three years? Keeping this at the forefront of how we design means integrating UX patterns that can account for that scale and growth.

While Teams as a product was growing, I was also focused on hiring my own team to design the future of our product. The vision I had for Teams was greater than what I could accomplish on my own. Being strategic about how and where I was hiring was a key goal of mine — how could I enable each designer to be successful, while also contributing to the growth and success of Teams? By November 2020, I had hired three designers to partner with me on crafting the rest of the Teams story.

This brings us to the end of 2020, both a tumultuous for all and traumatic year for many. Through it all, I grew two things that are near and dear to my heart: my own design team and the Teams product. I began to think about where both of them would be in 1-3 years, and how a deep partnership between Product, Design, and Engineering could help get us there.

Being strategic about our product growth would help us with three things:

• Collaboration. Strategic thinking helps the entire team aim for a common goal, which means working together, as opposed to developing a myopic view of the outcome and working separately.

• Efficiency. A shared vision gets us both quality and velocity. If everyone's rowing in the same direction, we get there quicker.

• Longevity. Lays the foundation for a scalable product that grows to include additional experiences over time.

Getting the opportunity to build a product from the ground up has been exciting, rewarding, challenging, and thrilling all at once. I’m proud of what we have been able to accomplish, and can’t wait to share with y’all what we’ve been working on over the past few months. Stay tuned!

My name is Alice Bracchi, and I’m the technical and UX writer for Cloudflare for Teams, Cloudflare's Zero Trust and Secure Web Gateway solution.

Today I want to talk about product voice — what it is, why it matters, and how I set out to find a product voice for Cloudflare for Teams.

On the Cloudflare for Teams Dashboard (or as we informally call it, “the Teams Dash”), our customers have full control over the security of their network. Administrators can replace their VPN with a solution that runs on Zero Trust rules, turning Cloudflare's network into their secure corporate network. Customers can secure all traffic by configuring L7 firewall rules and DNS filtering policies, and organizations have the ability to isolate web browsing to suspicious sites.

All in one place.

As you can see, a lot of action takes place on the Teams Dash. As an interface, it grows and changes at a rapid pace. This poses a lot of interesting challenges from a design point of view — in our early days, because we were focused on solving problems fast, many of our experiences ended up feeling a bit disjointed. Sure, users were able to follow paths within any given feature, but those features did not always work across the Dash in a seamless way.

Early this week we talked about how we’re leaving our “solution pollution” days behind and moving towards a design-led approach. To me, as the writer on the team, this means it’s time to step up our UX writing game and find our own product voice — a unique voice that reflects our product identity and speaks to our users in a recognizable “Teams way”.

As users, we love experiences and products we recognize. We’re loyal to them. It’s all about consistency, and the sense of familiarity that comes with it. When design and copy work hand in hand to convey a consistent feel, we soon learn to recognize the personality of an interface. Because every little detail has been curated for us, we’re rarely caught by surprise  — our experience just feels smooth.

Think about it in terms of human interactions. When picking up a call from a friend, we immediately recognize their voice. We don’t think about the why or how — we just unconsciously do, and start chatting away. However, imagine that friend suddenly uttered a sentence in a completely different voiceprint (spooky, right?). Imagine they started using words or expressions that never belonged in their vocabulary. We would notice right away.

Interactions through UX writing work in a similar way. Users notice right away when a piece of copy doesn’t sound as it should. So when working on copy for our interface, we need a consistent, recognizable product voice. A product voice is a set of principles and guidelines that standardize how we sound to our users. It will determine whether we put exclamation marks in our greetings (“Welcome!”), whether we include interjections in our error messages (“Uh-oh!”), whether we address the user with “you” or prefer a more impersonal approach. It will show our personality and shape what users can expect from us.

And the Teams dashboard needed just that — to find its own voice.

A voice isn’t going to be very successful for a product if it only sounds right to the writer crafting it, I reasoned. It needs to ring true to the people who build and breathe the product every day — our product managers, our designers, our engineers. In the end, a product voice will truly shine only if it’s aligned with product principles. And as a product team, we’d been so caught up shipping features and solving problems that we’d never sat down to brainstorm on our principles.

So the path was clear to me.

1. First, we needed to define our product principles.

2. From our principles, we would derive a product voice that matched our core values.

3. Last but not least, we would draft UX writing guidelines on how to write in our newly found product voice.

My idea was for this process to be as collaborative as possible, so I set up a series of brainstorming sessions with my teammates. I met with the product managers first, then with designers, engineers, and finally the marketing/go-to-market team. Each group gathered around a virtual board, and received the same prompts from me. I asked participants to focus on the ideal product they wanted Teams to grow into. Everyone worked independently on their own corner of the board — I was interested in every participant’s uninfluenced inputs.

Here are the prompts I gave:

1. List all the words you associate with Teams.We called this question the “brain dump.” I gave people two minutes and a half to be  instinctive, creative, and give me all the words they could think of.

2. Teams helps users by _______.With this question, I wanted people to focus on our everyday life. What do we do for our customers? Which problems are we trying to solve?

3. In terms of experience, I’d love users to associate Teams with ____ (brand).Again, I was after instinctive associations. Ideally, I wanted a list of websites I could later explore to see whether we could draw inspiration from them in terms of content.

4. Teams is unique because [it’s] ________.I asked people to focus on the qualities that set us apart in the market. What makes the product stand out?

Once I had all the answers, I classified sticky notes by lexical and conceptual association. Some patterns emerged. We had sticky notes describing who we are, who we’re not, what we do, our features, our technology, and what we care about. Once every sticky note had been grouped, I had a pretty good idea of the themes I could work with to draft our product principles.

I labeled each theme/principle with an adjective that could represent it and that could answer the question: what kind of product do we want to be for our users?

1. Reassuring. This was the first principle I worked on. Semantically, it reflects the core purpose of Teams — we’re a network security product, so our job is to protect. Under this principle I gathered all the words pertaining to the concepts of security, protection, and reassurance. People even used metaphors to express this concept: we’re a bodyguard. An armored truck.

2. Transparent. Another popular theme was our extensive analytics features, and the visibility they give to our admin users. This principle groups words whose root is in one way or another connected to the sense of sight: observing, monitoring, visibility, keeping an eye on. Interestingly enough, other words were more oriented towards the semantics of forensics: investigate, find, detect. For the main descriptor, I finally settled on transparent, because our product is a pane of glass (another metaphor that was used) that the admin can see through and know instantly whether something needs investigating.

3. Easy to use. This is a very ambitious principle for us. Network security is not an easy topic — it is our job to make it easy. All groups I brainstormed with gave huge importance to simplicity in one shape or another. Many stated our interface needs to be clean, accessible, approachable, digestible, direct. But we also vow to be inclusive, helpful and guiding, and never to assume knowledge.

4. Trailblazing. There was a clear theme around Teams being new on the market, but already showing the way. Modern recurred in most brainstorming sessions. Closely related descriptors, but stronger, were visionary and trailblazing, which I ended up choosing as the title of this principle, because it conveys the energy of a product that’s energetic and fresh.

5. Frictionless. This principle is all about a product that just works. Some words I’ve grouped under this principle describe two ways in which Teams aims at removing friction. First, Teams should aim at integrating with other systems_._ Second, Teams should be invisible. Our product is designed to be hardly noticeable by end users, and works behind the scenes.

6. Adaptive. This principle has two sides to it. The first is represented by resilience and Teams’ ability to adapt to circumstances (think concepts like adaptable, ready to change, and built in 2020). The second side is more about our ability to adapt to user needs. Here’s where our user-centered nature comes out: we let user needs shape our evolution as a product.

I went back to my sticky notes, this time to find and group words that could help us define the product’s personality, or more specifically, its attitude towards communication. Out of those groups, I chose five descriptors:

1. Straightforward. We know the value of effective and concise language. We give the right amount of information at the right time.

2. Helpful. We offer tips and guidance, and we ensure users are never left to figure things out by themselves.

3. Friendly. We’re happy our users are around. We empathize with them. We’re the warm and welcoming ones.

4. Fresh.  We’re a new, informal, geeky product. We address the user as if they were sitting beside us. We’re like a nerdy friend offering to fix your computer.

5. Controlled. We’re in control. No panic, no crazy excitement. We do not overreact.

As a next step, I crafted a voice matrix, slightly adapting Torrey Podmajersky’s approach in Strategic Writing for UX. I assigned a column to each voice trait and defined what each of them entails in terms of content, vocabulary, syntax, grammar, punctuation, and capitalization choices. This voice matrix summarizes the dos and don’ts of UX writing for the Teams Dashboard.

As I was filling out this chart, I noticed that most guidelines I came up with for the friendly trait also worked well for the fresh voice trait. Ultimately, I thought, it all boils down to a certain feeling of warmth in our communication — a feeling made possible both by our friendly nature and by our fresh, informal approach. In the end, I decided to merge those traits into the friendly principle.

This project has been an incredible journey to the heart of the product. I cherish the many creative conversations I had with my teammates about Teams. It was a chance for us to hit pause for a second, forget about deadlines and our everyday tasks, take a step back and focus on why we’re building what we’re building. It feels really good to have our principles written down, and we want to publish them soon on our product page for you to explore them.

Naturally, the project has also helped my writing tremendously. Every time I sit down to write a line of UX copy, I don’t just refer back to these four voice descriptors and their guidelines — I also write with the six product principles firmly in the back of my mind.

I’ve bookmarked the board with our sticky notes in my browser. It’s always there for me, and it contains the raw material I fall back on whenever I need inspiration.

This is just the beginning and the high-level structure of our strategy. In time and with iteration, we’ll build out these principles to become full-fledged UX writing guidelines, as well as a set of patterns that will allow us to achieve true consistency throughout the Teams Dashboard. Keep an eye on copy changes and see if you can hear our new voice take shape.

Next week we’ll introduce our Design team and their vision. Stay tuned!

Back in 2010, Cloudflare was introduced at TechCrunch Disrupt as a security and performance solution that took the tools of the biggest service providers and made them available to anyone online. But simply replicating these tools wasn’t enough — we needed to make them ridiculously easy to use.

When we launched Cloudflare for Teams almost ten years later, the vision was very much the same — build a secure and powerful Zero Trust solution that is ridiculously easy to use. However, while we talk about what we’re building with a regular cadence, we often gloss over how we are designing Cloudflare for Teams to make it simple and easy to use.

In this blog post we’ll do just that — if that sounds like your jam, keep scrolling.

First, let's back up a bit and introduce Cloudflare for Teams.

We launched Cloudflare for Teams in January, 2020. With Teams, we wanted to alleviate the burden Cloudflare customers were feeling when trying to protect themselves and their infrastructure from threats online. We knew that continuing to rely on expensive hardware would be difficult to maintain and impractical to scale.

At its core, Teams joins two products together — Access and Gateway. On the one hand, Access acts as a bouncer at the door of all your applications, checking the identity of everyone who wants in. It's a Zero Trust solution that secures inbound connections. On the other hand, Gateway is a Secure Web Gateway solution that acts as your organization's bodyguard — it secures your users as they set out to navigate the Internet.

Over the past year, we’ve been rapidly shipping features to help our customers face the new and daunting challenges 2020 brought around. However, that velocity often took a toll on the intentionality of how we design the Teams Dashboard, and resulted in a myriad of unintended consequences. This is often referred to as a “Feature Shop” dilemma, where Product and Design only think about what they’re building and become too resource-constrained to consider why they’re building it.

In an interface, this pattern often manifests itself through siloed functionality and fractured experiences. And admittedly, when we first began building the Teams Dashboard, many of our experiences felt this way. Users were able to take singular features from inception to fruition, but were limited in their ability to thread these experiences together in a seamless fashion across the Dashboard.

Here’s an example. In the early days of Cloudflare for Teams, we wanted to provide users with a single pane of glass to manage their security policies. In order to do so, users would need to onboard to both Access and Gateway. Only one problem, we didn’t have an onboarding pathway for Cloudflare Access. The obvious question became “What do we need?”. Inherently, the answer was an onboarding flow for Cloudflare Access.

Just like that, we were off to the races.

In retrospect, what we should have been asking instead was “Why do users need onboarding flow?” By focusing on what, we polluted our own ability to build the right solution for this problem. Instead of providing a seamless entryway to our dashboard, we created a fork-in-the-road decision point and siloed our customers into two separate paths that did not make it easy for them to approach our dashboard.

From an experiential perspective, we later equated this to inviting our users to a party. We give them an address, but when they show up at the doorstep, they realize the house is actually a duplex. Which doorbell are they supposed to ring? Where's the party? What will they find if they walk into the wrong unit?

That’s where Design fits in. Our design team is hyper-obsessed with asking why. Why are we throwing a party? Why should anyone come? Why should they stay? By challenging our team to lead with design, we take a questioning attitude to each of the features we contemplate building. With this approach, we do not assume a feature is valuable, intuitive, or even required. We assume nothing.

During our “Feature Shop” days, we had a bad habit of providing “bad mockups” or outlining a solution for Design to prototype. This is often referred to as “solution pollution”. For example, if I tell you I need a fast car, you’re probably going to start designing a car. However, if instead I tell you I need to get from point A to point B as quick as possible, you may end up designing a bike, scooter, car, or something entirely new and novel. Design thrives in this balance.

Now, we begin at the beginning and gather contextual data which drove us toward a given feature hypothesis. Together, Product and Design then research the problem alongside the users it may impact. More importantly, once the problem space has been validated, we partner on the solution itself.

With this new approach in mind, we revisited our onboarding experience, and this time, the solution we arrived at was quite different from our initial prototypes. Instead of creating two divergent pathways we now proposed a single Cloudflare for Teams onboarding flow. This solved the duplex problem.

This flow prioritized two key elements; preparing users for success and emphasizing time-to-value. During initial research, Design was able to identify that users often felt overwhelmed and underprepared for the configuration required during an early onboarding. Additionally, due to this sentiment, users failed to reach an initial “Aha!” moment until much later than anticipated in their user journey. To address these concerns, we truncated the onboarding process to just three simple steps:

• Welcome to Teams

• Create a Team Name

• Pick a Plan

As simple as that. Then, we created a Quick Start guide which users land on after onboarding. Let’s call this our inboarding flow. Next, we created a variety of “Starter Packs” within the guide which automate much the laborious configuration for users so they can start realizing value from Cloudflare for Teams almost instantly:

Moving forward, we will continue to expand on the Quick Start guide adding more robust starter packs and enhancing the opportunities for continuous learning. We’re also looking to incorporate intelligent recommendations based on your environment. We’ll also be releasing other improvements this quarter which apply the same underlying concepts found in our Quick Start guide to other areas of the UI such as our Empty States and Overview pages.

Perhaps most importantly, by leading with Design we’re able to foster healthy debate early and often for the products and features we consider releasing within the UI. These relationships drive us to map risks to controls and force us to build with care and intentionality. After all, we all have the same mission: to help build a better Internet.

If you’re interested in learning more about the Cloudflare for Teams design lifecycle, stay tuned. We have three upcoming blog releases which will walk you through our product content strategy, our design vision, and an exciting new feature release where you can see this partnership in action.

We are excited to launch a new UI that can be used across the entire Teams platform, but we didn’t build this dashboard just for the sake of a new look-and-feel. While migrating the Access dashboard, we focused on solving one of the largest sources of user confusion in the product.

This post breaks down why the original  UI caused some headaches, how we think about objects in Cloudflare for Teams, and how we set out to fix the way we display that to our users.

Cloudflare Access is one-half of Cloudflare for Teams, a security platform that runs on Cloudflare’s network. Teams protects users, devices and data  without compromising experience or performance. We built Cloudflare Access to solve our own headaches with private networks as we grew from a team concentrated in a single office to a globally distributed organization.

Cloudflare Access replaces corporate VPNs with Cloudflare’s network in a zero-trust model. Instead of placing internal tools on a private network, teams deploy them in any environment, including hybrid or multi-cloud models, and secure them consistently with Cloudflare’s network.

When users connect to those tools, they are prompted to login with their team’s identity provider. Cloudflare Access checks their login against the list of allowed users and, if permitted, allows the request to proceed.

Deploying Access does not require exposing new holes in corporate firewalls. Teams connect their resources through a secure outbound connection, Argo Tunnel, which runs in your infrastructure to connect the applications and machines to Cloudflare. That tunnel makes outbound-only calls to the Cloudflare network and organizations can replace complex firewall rules with just one: disable all inbound connections.

When you use Cloudflare, you use the platform at two levels: account and site. You have one Cloudflare account, though you can be a member of multiple accounts. That one account captures details like your billing profile and notification settings.

Your account contains sites, the hostnames or zones that you add to Cloudflare. You configure features that apply to a site, like web application firewall (WAF) and caching rules.

When we launched Access nearly two years ago, you could use the product to add an identity check to a site you added to Cloudflare, either at the hostname, subdomain, or path. To do that, users select the site in their Cloudflare dashboard, toggle to the Access tab, and build a rule specific to that site.

To add rules to a different site, a user steps back up a level. They need to select the new site from the dropdown and load the Access tab for that site. However, two components in the UI remained the same and shared configuration:

• SSO integration

• Logs

The SSO integration is where Access pulls information about identity. Users integrate their Okta, AzureAD, GSuite accounts, or other identity providers, in this card. We made a decision that the integration should apply across your entire account; you should not need to reconfigure your SSO connection on every site where you want to add an Access rule.

However, we displayed that information in the site-specific page. Cloudflare has account-level concepts, like billing or account users, but we wanted to keep everything related to Access in a single page so we made this compromise. Logs followed a similar pattern.

This decision caused confusion. For example, we add a log table to the bottom of the tab when users view “site{.}com”. However, that table actually presented logs from both “site{.}com” and any other hostname in the account.

As more features were added, this exception grew out of control. At this point, the majority of features you see when you open the Access tab for one of your sites are account-level features stuffed into the site view. The page below is the Access tab for a site in my account, widgetcorp{.}tech. Highlighted in green are the boxes that apply to the site I have selected. Highlighted in red are the boxes that apply to my Access account.

This user experience is unnecessarily complex . Even worse, though, is that confusion in security products can lead to real incidents. Any time that a user asks “am I building something for my account or this site?” We needed to fix both.

A few months ago, Cloudflare launched Cloudflare for Teams, which consists of two complementary products: Access and a new solution, Cloudflare Gateway. If Access is a bouncer standing in front of the door, checking identity, Gateway is a bodyguard, keeping your team safe as you navigate the Internet.

Gateway has no concept of sites, at least not sites that you host yourself. Rather than securing your Internet properties, like Cloudflare’s infrastructure products that rely on the reverse proxy, Gateway secures your team from the Internet, and the threats on it. For the first time, you could use a Cloudflare product without a site on Cloudflare.

Gateway introduced other new concepts which have no relation to a domain name in the traditional Cloudflare sense. You can add your office network and your home WiFi to your Gateway account. You can build rules to block any sites on the Internet. You can now use Gateway on mobile devices and soon desktops as well.

To capture that model, we started on a new UI from scratch, and earlier this year we launched a new dashboard for Gateway, dash.teams.cloudflare.com.

The products in Cloudflare for Teams should live in one place; you shouldn’t need to hop back and forth between different dashboards to manage them. Bringing Access into the Teams dashboard puts everything under one roof.

That also gave us an opportunity to solve the confusion in the current Access UI. Since the Teams dashboard is not constrained by the site-specific model, we could break out the dashboard into components that made sense for how people use the Access product.

The new dashboard untangles the tools in Access that apply to your entire account (the methods that you use to secure your resources) from the features that apply to a single site (the rules you build to protect a resource).

Merging Access into the Cloudflare for Teams dashboard, and solving the problems of the original UI, is just the beginning. We’ll be using that foundation to release new features in both Access and Gateway, including more that apply across both products.

You will also be able to continue to extend some of the configuration made in Access to Gateway. For example, an integration with a provider like Okta to build zero-trust policies in Access can eventually be reused for adding group-based policies into Gateway. You’ll see the beginning of that in the new UI, as well, with categories like “My Teams” and “Logs” that apply or will apply to both products. As we continue, we’re going to try to avoid making the same mistake of conflating account, site, and now product objects.

The new Access UI is available to all customers today in the Cloudflare for Teams dashboard. You can get started by visiting this link and signing in with your Cloudflare account.

To use the Access UI, you will first need to enable Cloudflare Access and add a site to Cloudflare in the existing dashboard. Instructions are available here. You can also watch a guided tour of the new site.

No new features have been added, though we’re busy working on them. This release focused entirely on improving how users approach the product based on the feedback we have received over 22 months. We’re still listening to new feedback. Run into an issue or notice an area of improvement? Please tell us.