Tag Archives: Teams Dashboard

The Teams Dashboard: Finding a Product Voice

Post Syndicated from Alice Bracchi original https://blog.cloudflare.com/the-teams-dashboard-finding-a-product-voice/

The Teams Dashboard: Finding a Product Voice

The Teams Dashboard: Finding a Product Voice

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”.

The Teams Dashboard: Finding a Product Voice

But what exactly is a product voice?

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.

The Teams Dashboard: Finding a Product Voice

Hundreds of sticky notes

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.

The Teams Dashboard: Finding a Product Voice

The words behind 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.

What about our voice?

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:

The Teams Dashboard: Finding a Product Voice
  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.

The Teams Dashboard: Finding a Product Voice

What I learned

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.

The Teams Dashboard: Finding a Product Voice

What’s next

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!

The Teams Dashboard: Behind the Scenes

Post Syndicated from Abe Carryl original https://blog.cloudflare.com/the-teams-dashboard-behind-the-scenes/

The Teams Dashboard: Behind the Scenes

The Teams Dashboard: Behind the Scenes

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.

Building a house

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.

The duplex problem

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?

The Teams Dashboard: Behind the Scenes

Leading with Design

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.

The Teams Dashboard: Behind the Scenes

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:

The Teams Dashboard: Behind the Scenes

What’s next

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.