Cloudflare for Teams: Ridiculously Easy to Use

All right. I think we are live. Cool. Let's do it. Awesome. So, hey, everyone. I'm Abe Carryl and I'm the product manager for the Cloudflare Teams dashboard. And I will pass it to Alice to introduce herself real quick. Sure. So, I'm Alice. I'm the technical writer and UX writer for Cloudflare Teams. Awesome. And today we're going to talk to you a little bit about Teams and, you know, mostly the customer experience around it, how we think about those things, and specifically how we think about the role of content and voice within the Teams dashboard. So, one of my favorite quotes, and I think that like kind of what, you know, we view as the mission statement for our team or the charter for our team, is that at TechCrunch Disrupt, you know, I think almost 10 years ago, 10 years or more at this point, one of the things that we announced when we first launched was that we wanted to build the same tools that some of the players at the time in the space had, but we wanted to make them ridiculously easy to use. And I think that's such an important part of, you know, what's made Cloudflare Cloudflare. And I think that that's something that we wanted to make sure that that was a key point of emphasis within the Teams dashboard. And it's really cool to look back, you know, like 10 years later and think that that was such a big part of our identity. And it really validates, I think, the need for things like, you know, really careful and intentional copy and content and technical writing within our dashboard, how that translates from, you know, all the way from initial points when you learn about the product in Google search, all the way towards like it kind of like funneling through and what that experience looks like. So, yeah, that's a little bit about what we're going to talk about. Hopefully, that's interesting to you. I know it's interesting to us. So, yeah, Alicia, I kind of introduced you and you gave us your title, but I'd love to learn a little bit more about like what you do, what does it mean to be a technical writer? What does a day in your life look like? So, yeah, if you want to kind of just dive in there, that'd be great. Sure. So, the way I think about my role in general is that it's very user -centered. So, it's all about the user. So, when I sit down to write something, be it a step-by-step guide or a line of UX copy, I think the underlying mission or goal that I see there is to bring the product closer to our users. And kind of on the other side of things, kind of enable users to be successful with their products. So, I see this like furoge in like between those two hats that I wear every day and it makes my job so interesting to kind of think about, you know, user needs and what they expect from the product at which point in their user flow and things like that. So, in general, I think a big part of my job is about being intentional in the way we communicate to users and being really careful in like how we communicate according to the channel that we're communicating through. Yeah, and you talked a little bit about the user and I'm curious like, you know, when you put yourself in the user's shoes, you know, like what perspective are you trying to represent? And there's a super, I think, unique challenge in your world, which is that we talk about this all the time, but we're trying to build a Zero Trust solution in a way that's accessible to everyone. You know, I constantly talk about wanting to be able to explain or, you know, go through our team's dashboard and have my mom or my dad or, you know, like a distant friend or relative be able to go through and completely understand like what the product is and have a good sense of like what we're trying to protect. And that means like everybody from like the hobbyist who's using, you know, our team's free plan that gives you up to 50 seats of, you know, accessing gateway all the way to, you know, the more sophisticated use cases and trick ones over on that side of the spectrum. You know, I'm curious what perspective you're trying to represent and, you know, what are the challenges that come with representing all those various, you know, personas throughout? So it's an interesting question because it also, it boils down to who is our audience and our audience, as you mentioned, is really varied. And I think we're always like walking the thin line between giving too much information at the wrong point and actually finding the right home for all of this information that our users need to be successful. And so one example I can think of is the relationship between the dev docs and their dash. Sometimes it's really hard to nail at which point in which like platform to serve users with the right type of information. The risk is overloading the dashboard with too much technical details where like the action that they need to take is buried under a bunch of information. And on the other hand, like the risk is hiding this information too far away from the dashboard right in the dev docs. So I think there's no hard and fast solution here. And it always depends on like each feature, I feel. Yeah. And that's such an interesting problem because kind of the delineation between what needs to happen in the UI itself and what's better handled through, you know, a space where you have the freedom to write a little bit more and go into a more like narrative format of what you're trying to accomplish seems like a really delicate balance. And probably you mentioned the word voice in there. And I'm curious like where you kind of view, like what you view as voice in general and, you know, what its role is in product and if that varies between product and dev docs or product and marketing, you know, what that relationship looks like. Yeah. So I think it's useful to try and start by defining product voice, which may be hard to define, but it's super easy to understand. So trust me there. I'm going to try and give my definition. So what worked in the past few months for me. And I think a useful way to see product voice is to see it as a set of words that defines how a product interacts with users through an interface, you know, through the spoken words of, well, the written word in this case. And while this may sound like a very technical definition, it actually somehow mirrors what happens between humans because a voice is such a big part of how we get to know a person. It's how this person, you know, frames and kind of gives shape to their thoughts to us. And so products really, I feel they follow the same path and it's really interesting that we find ourselves sometimes kind of trying to uphold products to the same standards, social standards that we do. People, we expect certain interactions from a certain product, but not other interactions from the same product. And this all comes down, I think, to the idea of voice and product identity at the end of the day. So I kind of feel that product voice and product personality are really like two really close concepts. Yeah. Yeah. And you kind of talked about voice. And when you put it in that context, it's kind of like, or it sounds like meeting people where they're at, you know, and I think that, you know, to our earlier point, kind of the purpose of what we're going to try to deconstruct in this session is, you know, how do you make, you know, the dashboard approachable, especially when concepts are, you know, as technical as they can be. And yeah, you know, it's about learning, you know, who somebody is and what makes them who they are, and then trying to relate to them on that same level. And I think that that's a really cool kind of mission and focus point. We kind of probably like glossed over, and I'm realizing I probably made a mistake here in hopping to voice. I'm curious, like how do we even define that voice? Like what was the process for arriving at a shared voice within the dashboard? It was a really interesting process. I'm sure you remember back then, I think it was in back in December when I kind of started working on copy for the dash. I sure remember this first tickets coming in, like, okay, we need an error message for this feature. We need a description for this other feature. And I remember sitting down at my desk, kind of wondering how I should sound like, you know, in these interactions. What kind of product do we want to be for our users? And it sounds like a really philosophical question, but it's really not for a UX writer, because it all comes down to word choice or like sentence structure, or whether to put like punctuation in or not. Like, it's a lot of really, I think, concrete choices, right? It all comes down to really concrete choices. And so, I was thinking, like, do we have any product principles in place? Is there any place that I can go look for the product identity that I need to shape, you know, the product voice? And the answer was no, there was no work done yet on product principles, because, you know, we being a young product and being so focused on shipping features and solving problems, we never had, you know, the occasion to sit down and think about this in an analytical way. And so, I kind of took the chance to do it, and to kind of lead a series of brainstorming with different groups of people within the Teams org. And it was really interesting to have this type of discussion, like even, yes, philosophical discussions on what the product is, and what, which problems we're trying to solve, and what we want to be for our customers. And so, we sat down, and I tried to start with product managers, because I wanted the whole work to be product-led. And then, we incorporated designers who are really important players in how the product gets built, front-end engineers, and then a group of marketing-related people. And because I wanted to make sure that in, like, this approach that is, forgive the word, data-driven, kind of bottom-up, I wanted to make sure I portrayed as many voices as possible. How did that perspective vary between those groups? Like, did you see, did you expect to see the same themes in each bucket, or did you kind of expect them to be different, and then, like, and then were they? They were really different. I had kind of no expectations, because it was the first time I was doing something like this. So, I was ready to be taken by surprise about whatever happened, and I was really surprised to see that there were some differences, of course. So, designers were very oriented towards, like, the ease of use of the product, and how clean the product looks, and how easy to use it actually is. While on the other side, for instance, there was a focus on the technology itself from the engineering side of things. And so, it was really nice to look at these sticky notes that I gathered. I think I ended up with, I don't know, 700 sticky notes. But there were some leitmotifs as well, which were what I started to work on for, like, the product principles. So, I focused on the common areas between all these groups, and kind of went from there to isolate our, I think we have six product principles. Yeah. Wow. So, we kind of start from a point of, you know, we want to start, you know, being more intentional with copy, and with content within product, and turning that into something that's, like, a recognizable voice, or at least the need for a shared voice across these different roles, and then how those things kind of translate out. Now, we've kind of synthesized that voice in some way, shape, or form. How do you start to, kind of, to spread the seeds across, like, just, like, outside of dashboard? Because I imagine that, to your point, you know, not just with, you know, things like developer docs, where, like, maybe it's a little bit easier to have that one-to-one relationship, but things like marketing, and how people are even becoming aware of cloud-flavored teams, like, how does that, you know, relationship, and that filtration process kind of work? So, I think for this, to your point, I think it makes sense to differentiate between voice and tone. So, where voice is closely tied to a product personality, or identity, I think of tone as this voice in context. So, the voice stays the same, because it's so tied to who we are as a product, that it makes sense that our product voice stays, you know, fresh, and friendly, and accessible throughout the channels. But on the other hand, we can talk about tone in terms of a, sort of, a channel switcher. So, I was certainly guilty at the beginning of thinking of tone as a tone, or, like, a volume knob that you turn up and down, depending on the context you're in. But it's not just that, like, it's more of adapting your message, or actually your messaging, to the context you're in. And so, the developer docs, we haven't defined a strategy, me and the product content team, quite yet. We're working on that right now. But intuitively speaking, you won't have the same type of situation when browsing the dev docs, right? So, within the dashboard, you may have more variation between a conversational tone, versus a more direct tone. Whereas from the dev docs, probably what you expect is more of a flat, you know, type of undertone. But it's certainly a really hard problem, and a good one to solve. So, it's work in progress. Well, so, it's tough, because in that world, I imagine, like, it's very difficult to measure, like, what a good voice is. So, is there, like, a, is there a benchmark, or a best practice for, like, what defines good voice? Does that change, depending on, like, the environment that you're in? You know, I also imagine that it's probably really difficult to remember that, you know, and I think that we probably, you know, all struggle with this, to a certain extent, but to remember that you aren't the user, you know, and to make sure, like, for me, like, I would love for everything to be bubbly, and happy, and optimistic. But, you know, that's not always, you know, that may be self -indulgent at times. And I'm curious, like, you know, what good voice means to you? So, the way I approach this is, and it's actually the reason why I started the whole brainstorming sessions, and the whole research process. A voice that sounds good to me is not necessarily good for the product that I'm working on. And so, the way I approach this is to say, you know, does this voice sound right for teams? And does this voice help tie teams together with the brand voice of Cloudflare? Because we're still, you know, part of the, I mean, we're a product in and of ourselves, but we're still part of the product offering of Cloudflare. And so, I think a good voice is good for the product, and good for the product in relationship to the company voice. And I think what you're referring to is a really important point, like, making sure that this voice doesn't get in the user's way as they interact with the dashboard. And to that point, I think it's really useful to think in terms of tone, again, and thinking that the user, you know, what they feel, and their mood, and their emotions, they may be frustrated, their network may be under attack. We need to make sure that we are considerate of the context that we place our voice in. Cool. And I think that's such a great kind of wrap-up of what we're trying to accomplish with voice. And I think that, you know, kind of outlines, you know, starting with a content approach, and then kind of moving to a shared voice, and then, like, the delineation between voice and tone, and then getting to the point where, you know, you have to balance what you view as a good voice versus what's the best voice for the product itself. We talked about kind of, like, the collaboration that exists within that, you know, especially with, you know, really close partnerships with design. And I'd love to kind of switch gears a little bit and talk about something tactical, you know, like something that we've done recently that's shown that partnership in full effect and brings those kind of, like, three different principles together. We recently launched a new feature within the Teams dashboard called the Teams Home. And it's essentially, you know, an executive kind of style overview page, chock-full of analytics, things like how you're using Cloudflare Access, and how you're securing your internal applications, gateway to secure your network and your devices. And I'm curious, you know, like, what that process looked like, and maybe, like, some examples of, like, where you were really able to flex into that space to make that voice come alive. So, I think that Teams Home was one of the first chances that we had to collaborate, like, in such a deep way across functions. And I think what really helped me was the fact that we started very early on to plan this feature, like, cross-functionally again. And I really think there was a lot of value in those meetings that we had early on, like, understanding or talking about what the user may expect from this new feature, and how we could make it feel like a Teams feature in and of itself. So, I remember one of the first things that I wanted to include in the Teams Home was the greeting. The greeting up there is the very biggest element that you can see, and it's a textual element greeting the user into this new feature. And that was, I think, one of the nice touches that probably don't make, you know, that functional difference, but it's just there, and it makes you feel like you're part of an experience. And to that point, I really tried to keep the same tone there that we have with the greeting on top of our quick start guide. So, you know, a big greeting with an exclamation mark, that's a place where I feel we can flex a little bit in terms of tone. And another example is probably empty states that we have sprinkled across the dashboard. And I think that's a really good place where the user may be frustrated when they see that, but it's an empty state that we can feel with guidance, that we can feel with human touches that may really, you know, make the user stay at the end of the day. And I think that to me, you just hit on the most vital part, right? And it was very understated, but you kind of said, you know, it's a very little thing and kind of glossed over it, right? Like, it's a very little thing, you know, it's just a greeting message. But to me, like, that's life, right? Like, that's all of life. And if you're talking about communicating with people, you know, not with a user or a customer, you're talking about communicating with a person and meeting them where they're at. Like, the little things are all that matter, right? Like the eye contact, the, you know, the ability to relate to them and, you know, to understand who they are and like, what makes them them, you know, is invaluable. And I think that focusing on those little moments is so key. And yeah, I think that, you know, while they may seem like little things, they may go unnoticed, yeah, you know, I think that that's like part of the reason why we're doing this session is to just let people know that, you know, we are thinking about those little things. And trying to bring them to life in a, you know, in the right way. Definitely. So let me just add one thing. I think really tied to this attention to details is the importance of consistency throughout the experience. And one of the things that I'm working on right now is a UX writing system. So sort of, it's sort of a way for me to kind of componentize these pieces of UX writing that we come up with to make sure that whatever we create in the future still ties into this original idea and strategy about the team's voice and tone. Because I think details do really make a difference in user experience. And that's, I think, being more consistent is definitely one of our goals moving forward. Yeah. And you hit a little bit on empty states too. And when I think of an empty state, I think of something where you navigate to a new section of a product or a tool or an app or, you know, whatever it is that you're using. And it's a state where you maybe haven't taken an action before. So you don't have a profile set up on Instagram. You don't have a, you know, something in that similar kind of bucket. So you need a way for to communicate with the user and tell them like, hey, like this is what this page is going to become. And here's the way that you're going to do that. Maybe it's like a little bit about preparing them for success. Yeah. I'm curious about like the way that you view empty states. And then, you know, to your same point like that, there will inherently be more kind of narrative driven approach there. And I'm curious, like, you know, what that what that what that opportunity meant to to you and your team. So I think actually the empty states where it was one of the first tasks that I got assigned. So it's very dear to my heart. So I remember the partnership again with design there because I remember the conversations about putting in the visual element there. So the illustration itself. And so it was really nice and interesting to work alongside design to convey this idea of, OK, you landed here. You're a new user, probably, or you're an existing user who landed into a new feature. So let's accompany you through this experience. So let's not make you feel like this is not intentional. Right. Or you did something wrong, which you didn't. Right. So it's really a place where we can actually get to give guidance to users and like maybe draw a little bit the path for them towards success again. And this like there are different elements to this. And I think copy makes such a big difference here because people will see like something is wrong. So let me read like what's next for me. And it's both about the messaging itself. So I remember adding this little word like no data yet and kind of humanizing the empty state a bit, providing the link to the documentation itself to the right place in the docs where they can take action or they can know how to take action up to the call to action itself, like maybe a button that drives them to another place in the dashboard where they can set up a feature to see the empty state populated. And so it's definitely a very rich area of the dashboard if you think about it. Yeah. And I think that an interesting point there too is like it can be difficult to stay vigilant with things like empty states as well. Right. I think that and you see it all the with users where I guess I want to key in on that on that word yet and the variation between the empty state, which kind of says, hey, here are like the one to two to three steps that you need to take in order to get this thing hooked up. And then whenever that that step has been taken, having something that says no data yet to kind of allude to the fact that like you're on the right track, it's we're just waiting for data to get sent back. Now, it's just a process of getting that here versus no data. And I think that that word yet it shows the value of that key point of little things. Right. And it's so easy to desensitize yourself to looking at an empty state and somebody saying, OK, I don't know what no data like what no data means. And you're like, oh, that just means like it isn't and to just write it off as, oh, like that's what it means. Like, I'll just teach you what it means rather than like getting at the root of what they're saying, which is I don't know the difference between when it's a when it's a you problem or a me problem or when it's a waiting game or things like that. And yet to me, it's it's you know, it's so funny what like one word can do in order to help convey that message. Absolutely. And I was thinking about another type of empty state that we have in the team's home, which I remember talking to design about it because the approach that we wanted to take was to give a bit of context to users as to what they could achieve by just clicking that button that would create a policy for them, for instance. So the approach of like creating these paths already for users, I think really helps or actually it for us, it's a way to meet users where they are kind of not assuming that they already know the dashboard and where the features are. And yeah, I think it's it ties together really well with our principle of being easy to use and guiding in everything we do. Yeah. And to your point, you're talking about the whole the whole objective here is to deconstruct what ridiculously easy to use means to us. And I think that we've talked about when you arrive in product and you see these empty states, these areas of the product where you haven't configured something yet. Here are the steps to configure it. Now you're waiting for data. Now you have your data kind of flow. And that same kind of concept existing within the team's homepage of, you know, welcome to the homepage. Here's the information that you need. Here's what what is populated. Here's what needs to be populated. So we've kind of talked about those two things. We're kind of glossed over like a piece, which is how do they even get into the product at all? Like how do they how do they even start and where does that journey go? And I think that, you know, we'll talk about onboarding here, but I want to kind of like paint that picture real quick of, you know, a user learns about teams, a user onboards into teams, a user drops into an empty state, a user sees the team's homepage, right? Like that's the whole like that's an end to end flow. And again, like something that we really have been zeroing in on making that process approachable, regardless of, you know, where you are. And yeah, I'm curious to get your thoughts on the role of onboarding as a whole and how it like fed into those two items. It is so important. It is like the first impression that a user gets of us as a product. And so as I was drafting the copy for the very first step of the onboarding stage, this is an example of a tone that gets maybe warm or warmer than other places in the dashboard because there's no real complicated action that you need to take other than click on the next button. But that's the way that we have to greet our users into the whole experience. So I remember this was my train of thought when I was drafting the copy for that piece. And then the step that kind of stuck in my mind was the step where we asked people to enter a team name, right? So that is an example of a concept that they may not really be familiar with still, but like our job is to make the step accessible to them. Kind of comforting them, look, this is not like a forever decision when you enter the team name at this point, you will always be able to change it later. Kind of giving the right amount of context, but with like the right amount of words, because we all know that. We all skip over a copy sometimes. So it's this fine line between needing the right number of words and the right messaging at the same time. And it goes back to something that we've been kind of hitting on throughout, which is the little things, like in the little details, being so critical. Because again, it's very easy to say you're signing up for a social media app and you need a handle, you need a profile name. Why? Why do I need that? And I think that that's like, you always have to back yourself all the way into what's the purpose of this thing? Because people, when you're signing up for something, there's always hesitation involved. And the more that you can address those concerns and make sure that you're doing so in a way that alleviates that, I think is really the key. And I such an exciting process to build that. But yeah, I think that to kind of like put a bow on it and wrap things up, I think that we kind of backed into where did we start? How did we even realize that we needed a voice? What did the role of voice play in the Teams dashboard as a whole? How did we start to build that relationship between product and design and content? And what did that relationship look like? And then what are three experiences that build one end-to -end pipeline that really brought that vision to life within the Teams dashboard? So this has been an absolute blast. I'm so happy that we got to do this. Thank you for on that. And yeah, I love talking about this. I hope we get to do it more. Same here. Cool. All right. Have a good one. You too.