Style Guide

Good afternoon, everyone. And welcome to the inaugural episode of Style Guide. I'm your host, Dan Hollinger. Here, the point of the show is to talk through some of the kind of leading design and UX issues of the day. With me, I'm joined by Bethany Sonnefeld, lead product designer at Cloudflare, as well as Ryan Boy, a lead product designer at Unity Technologies and an ex-Cloudflare employee. And ideally, John Donmeyer joins us here shortly as well, also a product designer at Cloudflare. So keep in mind, we will be taking questions. Feel free to email them at livestudio at Cloudflare.com. If you'd like to pick the brain of any of our guest designers about the design industry, best practices, and jumping into the field. So with that, I'm happy to go down the line and begin with introductions. Bethany, can you tell us a bit more about yourself? Sure. Hey, everyone. So my name is Bethany. I'm currently working as a lead product designer at Cloudflare. My focus for the past year that I've been here has been on the Cloudflare for Teams platform. So that initially started as a product launch known as Gateway, and then we've since expanded it. And we continue to kind of build off of different capabilities. We acquired a company called S2 Systems in January of this year. And so we've been partnering really closely with them to kind of bring in some of that functionality to the Teams family. I've also been working on building out the design team in Austin. So when I started, there were just two of us, and we've since hired three more. So it's super exciting, and I'm really happy to have the opportunity to build out a team. The Austin office in total is growing a lot as well. And then prior to Cloudflare, I was at a company called RetailMeNot. You may be familiar with it. It's a promo code website. So I was focused more on consumer -focused products. And then prior to that, I was at IBM, and I was part of the inaugural team that founded the Carbon Design System, which is, at the time, it was a design system for IBM Cloud products. And it's since kind of expanded to be the design system across all of IBM. So it's super cool for me to kind of track some of the progress of where it's gone since my time there. And yeah, it's just, it's super exciting to be here, and I'm excited to chat with y'all today. Sounds great. Well, welcome to the panel. And John, how about yourself? Sure. I'm John. I also work at Cloudflare. I'm the lead product designer in the San Francisco office. I started at Cloudflare last November, so still relatively new here. But in my past life, I just got done with a roughly four-year stint in government service. So I worked for an agency called 18F, which does digital services things for all across the federal government. Worked on a lot of different projects there. Like I, for some period of time, led the design on Login.gov, which is a shared identity platform and authentication service for government services. And I also worked on the US web design system for a period of time, which kind of like Bethany's carbon design system situation, they've got to see grow from like this very small thing that was kind of built for, you know, a smaller set of products. And then, you know, the next thing you know, it explodes to tons and tons of stuff using it. And I guess before that, I've worked in a number of different startups, kind of anywhere from being the first hire to up to the 150-person phase where they start to not feel like startups anymore. And that's kind of how I got to here. Interesting. Definitely maybe something we can touch on is the difference of product design startup versus product design at a much larger firm. So, on that note, Ryan, do you want to introduce yourself? Sure. Thanks, Dan. So, my name is Ryan Boy. I'm a lead product designer right now at Unity Technologies. I've worked for a number of companies in the Bay Area doing product design, usually on SaaS products and usually dashboard related things. As Dan mentioned, actually, in a past life, I did work at Cloudflare. I actually designed the version of the analytics dashboard, which, for better or worse, appears to still exist today, which is exciting. So, that's cool. So, yeah, I currently work at Unity Technologies, the game engine and game platform. I lead the design for the services dashboard. So, it's actually kind of like Cloudflare apps, but for game development. So, game developers can go in there and connect their game to a variety of online services. Awesome. Well, thank you for taking the time. And thank you, everybody, for joining the panel. And thanks to the viewers, whether you're catching this live or watching or recording. Again, hopefully, this is interesting and topical information, and feel free to ask questions. So, with some of the housekeeping out of the way, happy to dive into the main theme of today, which is redesigns. I thought this was a key topic and a nice one to kick off the first episode with, given that we've, over the past few months, been experiencing a lot of change, a lot of disruption. How do we handle that, both in our personal lives, as well as at the product level when we're redesigning how we're going to work, how we're watching TV, and really get a sense of pros and cons, trade-offs, what's been a good redesign in your experience and in your career, what's been a bad redesign, what can people take away from this? So, happy to throw that out to anyone who'd like to kick things off. What do you think, guys? Do you want to kick it off? I have some thoughts I could share. Go straight ahead. What would you say is the first question there, Dan? So, really, what makes redesigns difficult in your perspective? Yeah, that's an interesting question. From my perspective, I would say managing the transition for your customers is always a challenging aspect. I think, usually, if you're doing a redesign, it usually means that you're either introducing a lot of new functionality or you're making a significant change to the way your app works. So, transitioning some of those legacy features can be a challenge, too. So, yeah. I think, also, users typically don't like change, and that's very hard with enterprise software, when people get super familiar with using a product on their day -to-day, and then they all of a sudden come back one day and things are changed. I think, from a designer's perspective, so much work goes into a redesign that that work often isn't exposed to our customers, because we just want them to have the new and improved version. So, I've seen a lot of backlash, especially with brand redesigns, sometimes, when it comes to companies changing a logo or a particular style of their website. But with product redesigns, I think it's also tricky, because you're fundamentally changing or shifting things around, and that can cause some confusion for users, because they're having to relearn a behavior that they already have established and that they're already familiar with. So, especially with, I think, an older generation of folks, I've seen it a few times where it's just a sense of frustration. So, from a designer's perspective, there's, I think, things that can be done in order to help prevent that, like a slow rollout, lots and lots of testing to make sure that the changes that you're making are warranted in research and you're changing things for the better, not just for the purpose of changing things. Yeah, I think that last point about changing things for the better and not just for the sake of changing them makes me think of one of the most challenging things I see is how much do you bite off for a redesign, and to what degree do you need to redesign everything or a portion of something? Is it a re -skinning of something where, you know, maybe from a CSS style sheet perspective, it looks different, but under the hood, the information is still architected in the same way? Or is it the other way around, where it's like you completely move everything around, but it looks the same? And the connotations of those, of both directions there. And, you know, when visual change happens that's apparent to non-designers, that means something to them. And, like, it's a signal to look for other things, look in new places, things like that. And I think that it's hard for teams to sometimes come to consensus for how to go through these multiple phases. And do you do the kind of big bang kickoff of a redesign, or do you slowly sneak it in over the course of a year or two? It can go a lot of different ways. Along those lines, do you guys feel that there's a concept of technical debt when it comes to designs? And so, in understanding that scoping, you know, can you peel back the layers? And there's the things that can be changed easily, and they're potentially minor. And then, obviously, bang off, there's some kind of design debt that will ultimately lead to a much more productive change for the end user. What are your guys' thoughts there? Yeah, John, you kind of touched on that point with the difficulty of kind of managing the redesign from, like, an internal team perspective, I think. I totally agree with what you're saying. How much you decide to bite off, there's no agreement there. There's constantly challenges, pros and cons, you know, on either side. Yeah. I also just wanted to agree with something that you had said there, too, Bethany. I think one of the most interesting things about redesigns can be, like, especially the context in how your product is used in somebody's day -to-day. Oftentimes, they're going to come in, maybe it's something that's relevant to their day-to-day, or it's how they're getting their work done. And they're sitting down with a purpose in mind, and then suddenly everything's different. And that moment is incredibly frustrating for those users. So, being able to manage that transition, I think, is really key. Yeah, I think something I hadn't spent as much time thinking about as I probably should have until I started working in the world of government services and things like that is, you know, oftentimes, I think with consumer products, you take for granted that these transitions will, like, just naturally occur, and people will either learn new behaviors, or they'll drop off. And sometimes that drop off is a calculated risk that you make as a business. And people have, you know, there's value to them being on their service, maybe there's network effects you're trying to achieve, or dollar values attached to how much they pay you for that service. But when you're providing services that are sort of mandated, for lack of a better word, but they have to exist for everyone, and you really have to approach things differently. And I think, like, you know, I saw how many times we would roll out some changes and see, like, that there is this whole, like, interface training infrastructure that was built around, you know, you might want to change, like, a signup flow, because we had the data that said it was easier for users to do it that way. But what we didn't know is, like, one of our partner agencies had built out all this documentation on how to do the training flow, and they've trained, like, their customer representatives on how our products training flow works. And I think I took a lot of that for granted earlier in my career when I worked on more consumer-facing things. So, that's an interesting thing to have perspective on. I agree with that. I feel like oftentimes it's not the design itself that's challenging, really, at all. Like, anyone can redesign something. It's how you're actually rolling it out and actually making sure that all the dependencies and everything are all taken care of. Any thoughts there on managing customer perception? So, you know, on the one extreme, you do have a training team or you do have some infrastructure in place to hold the end user's hand a little bit more in that migration. On the other extreme, you know, potentially a startup, you don't have that infrastructure. You are hoping that end customers can go through the journey quickly or independently. Any thoughts there on managing that balance? I mean, so, I've seen a few patterns before with redesigns, and I think Cloudflare has actually done this, where there's, like, a toggle where you can, you know, message to the user, like, hey, we've made some changes, we've made some updates, like, you know, click here to check them out or, like, toggle the old UI versus the new UI, and then that way they can start to get familiar with it. I don't know how that works on a smaller scale, and I don't know if there's, like, a right answer for what pattern to use. I think it's just most important that you are messaging that to your customers as early as possible versus, like, they arrive at the product they use every day and everything has changed. That can be a very, very jarring experience. So, just like we do design reviews with our engineering teams very frequently, you should be doing that same thing either with your customers or letting them know, messaging to them, like, there's going to be some changes that are coming. We would love to have you as a beta tester. We would love to get your feedback on that particular thing. I think that's why user research is so important and so fundamental to a lot of these redesigns is that you want to make sure that, again, I already mentioned this, but, like, the changes that you're making are rooted in, like, actual user needs versus just, like, oh, we are changing the look and feel of this. Because often with redesigns, I think it's more than just cosmetics, and people tend to think it's just, like, oh, they changed the visual style of something, and it's, like, well, it's probably actually really beneficial in terms of user flow. There could also be some changes made to the code. Like, getting rid of, like, old, crufty code is also, in my opinion, like, a redesign in its own. So, it couldn't just be related to the visual aspect. It could be related to cleaning up code, making sure it's more consistent and faster for the performance of your product or service. Have you all seen the beta opt-in thing? Huge fan of that. We use that here at Unity. We're actually going through a giant redesign right now, and that's a really easy way to both get testing, get an evangelist on your side from the customer base, as well as not having it be too jarring. So, big fan of that. And do you feel there's a benefit to that since the end user is actually opting into the change as opposed to having it forced upon them? So, there's that sense of control as opposed to something more abrupt. Certainly, in the transition period, I think it gives you an opportunity to slowly roll it out, get feedback. You can even do some iteration on that based on what the feedback is, but I think it just allows people to see it coming. I think that's the big win. Eventually, you have to force it on them, but usually it's been up for a while, but they're not that surprised. Yeah, it's interesting to think how truly rare it is in the world of design that you don't have that tipping point where you have to force it on a larger user base to some degree. I guess one example that comes to mind is I know the company Basecamp, when they were still a part of 37signals, they iterated on Basecamp enough and they wanted to fundamentally change the architecture of that product and how it worked. At least as far as I know, I think they're so committed to this concept of Basecamp Classic that I don't think you can sign up for it new anymore, but if you were a user of it, you can still use it, as far as I know, or at least they did that for many, many years past that initial launch. I think the fact that that's one of the only ones I can think of really speaks to how rare it is for people to do that. It's work to maintain that too. It's both server costs and support and other things. John, when you said Basecamp Classic, it made me think of the Wayback Machine. As a designer, I just feel like it's so endearing to look back on old products and how far they've come because oftentimes the classic design or the original version, you're just like, oh, wow, look at that. It's almost like this retro feeling that you're tied to. It's really, really interesting to see the progression of products throughout the years and how they've changed and grown. Outflier used to have a really cool, I wouldn't call it quite skeuomorphic, but it was kind of skeuomorphic, old analytics dashboard. I don't know if they have any images of that floating around in there somewhere, but that thing was really cool. Dig into the archive somewhere. Yeah, I actually think it's in some current documentation. We probably still have some pictures of it. Nice. That just speaks exactly to John's point about keeping the documentation updated. On the point about the Basecamp Classic, yeah, I think the challenge is if you're committing to doing that, you're committing to running two product teams because we had that at a previous company I was at where we, man, we really tried. The hearts were in the right place there because we wanted to maintain that classic version. We launched a new one, but I saw over the years, it's just increasingly one after the other. You get some resources pulled away from maintaining this classic piece. Oh, those customers aren't as important, et cetera, et cetera. Eventually, those customers just suffer, which is kind of the saddest thing to see, honestly. You watch them just churn out and you wish that the company had the audacity to just cut it off. I was going to say, along those lines, you see it more as a band-aid so it's better to rip it off quickly and deal with the disappointment from that cohort, or is it the same as putting in the change and you go slowly, you go as early as possible, and you try to reduce the pain, but ultimately, it's just dragging it out over the life of essentially the redesign. Yeah, I think it depends on different use cases and user bases and how large they are, why they're there in the first place. Are they paying you money? Are you providing them an essential service? All kinds of different things can go into play there. I think back to the early era of Instagram when Instagram was growing as a company and there were all these other filtered camera apps and things like that and Hipstamatic existed. There's this conceptual model of that app isn't necessarily your social space. It's the thing where you create the thing to have that social moment. I think companies like Instagram that had to take a gamble on that to say, well, what if we brought that space into here and created a burgeoning social network out of this tool that people saw as a tool? If they would have tested that forever, they might have missed that opportunity. I think you have to see where you are and see what your goals are. Along those lines, does anyone have an example of a particularly disastrous redesign that they went through and had to suffer the wrath of the end customers? Your internal customers, what did that look like? Yeah, we fucked one up, for sure. This is not Cloudflare, don't worry. At this other company I worked at, we were - You don't have a delay. We can't beep you here. Oh, sorry. Yeah, we launched a new revised data dashboard. This was one of those almost superfluous visual refreshes. It didn't really have a product purpose. Essentially, what one designer did was they just totally changed all the ways that all the data charts looked. They made it super flashy, like your stereotypical idea of, well, some engineer's bad experience with design, basically. We just rolled it out instantaneously. There were all new charts. The customers freaked out, understandably, because it wasn't really tested with the users. There were some designs implemented that basically just didn't- The designer chose to remove a lot of stuff that ended up being quite important, like access labels, bar labels, access grid, all these things that, for these financial dashboards, were actually critically important. We heard that from users loud and clear via our support channels. We were just able to iterate on it and improve that post-launch, so it didn't take too long. That's, I think, one check mark, I think, to support what Bethany and John, you guys were saying before about having- When you do manage that redesign, having the right communication is really key. Having the right support channels there are also really, really helpful, basically, to catch things like this. It really helps cover your bases as you roll out changes to users. I don't know if it's classified as a redesign, but we definitely had disastrous and failed design attempts, where what we wanted the users to do and interact with, they just completely ignored. We could not figure out, for the life of us, why people were not interested in this particular thing that we wanted them to be interested in. I think that maps back to just not doing enough proper research and understanding, fundamentally, what their needs are, and then building something that fits those needs. We just took a shot in the dark, and we called them experiments. We were just trying things out, shipping really rapidly, and then we didn't get the results that we had hoped for. That was sad, because we had spent a lot of time and effort on it without actually seeing value from our user set. I haven't been a part of a huge redesign that was disastrous, but definitely failed a lot as a designer. There's no doubt about that. Yeah, I think my sort of most failed redesign experiences kind of harkens back to Bethany's point earlier about who are you designing this for, and is there a purpose that you're redesigning around? I think of an early-stage startup where I feel like redesigning our homepage was kind of like our version of spinning a pen. Your brain is just thinking, and we're like, we don't know what direction to take this product. Let's just redesign our homepage. I think we went through that cycle a lot of times, as opposed to actually addressing some of the core product. We were looking at how we were pitching this product and assuming the pitch was failing, and it was the product that needed more work. I think that was hard to see in the moment, but a lot easier to see in retrospect. I guess if you've seen that commonly, or maybe not commonly, but in your career where leadership will ultimately point to, well, it's a design flaw. We need to alter how we're approaching or how customers are interacting with our product, as opposed to a product flaw. If so, how do you move evidence one way or another to try to be on the hook, or if it is a design issue, make the appropriate changes? I think people, and when I say people, I mean the design and product community as a whole, has gotten better at this. My career isn't super long, but 10 years over a decade. If I look at where the broader design community was 10 years ago, I feel like people doing the building didn't always have the same sense of what do I need to build to reach certain milestones, where I have better understandings of my customer. I think there's been a lot, whether that's the lean startup movement or other just people showing by doing, by releasing very early stage stuff and throwing it up on Product Hunter, Hacker News, or someplace where they want to get feedback. I think people as a community are learning that you can build less first and not have to see these milestones for yourself, but I don't think it's a solved problem either. I think there's still teams that run into that and large orgs that run into that at a much grander scale too. Yeah, I mean, designs always sell really well, I think, in a meeting or something, so they tend to get approved by leadership teams. I never thought about it like that before, John, but I think you made a good point there. I think I would tend to agree. I think I'm seeing a lot more leadership teams these days, a surprising understanding of the user and really, really digging into wanting to see metrics and having the product move metrics as opposed to blindly approving things that look pretty. So, shifting gears a little bit, first, again, a reminder to those watching, we're open to taking questions. Feel free to send them to livestudio at Cloudflare TV and we'll address them at the end of the session. Meanwhile, happy to kind of jump back into the conversation with Stephanie, John, and Ryan, and we're going to touch on weaknesses or issues that can arise with a redesign. Switching gears, can you highlight any companies you've either worked for or appreciated that have done a redesign really well and some of the aspects that you appreciated about that? I think one that sticks out to me from a brand redesign perspective is MailChimp. So, they had to have been like three years ago, maybe. There comes a point where design gets super trendy and everything starts to look the same. Like, there's this running joke that like all websites look the same nowadays, and so I think when MailChimp did their redesign, they took a very different style of visual language. Like, they were doing illustration styles differently. They were kind of loud and bold, and that was kind of the first step towards now kind of what we're seeing a lot of other companies follow suit. Like, Dropbox had a really big redesign as well, and I think what I valued most about those redesigns is the fact that they were trying to be different because as designers, like, we were drawn to like similarities, and it's very, very common to kind of pick up on patterns and trends that are emerging in the design community and say, hey, I think I could bring that into my product, and that's not a bad thing, but I do think it lends to then products looking very similar, and so when companies like MailChimp and Dropbox do things drastically different, I'm always curious like how that ties to product and how that sort of brand redesign, how do we see that translate, that boldness, the kind of loud, flashy, different type of style, how does that translate into some of the products, and what I've seen Dropbox do, I think they released paper a few years ago, and that was kind of like, I see that as like an opportunity to start fresh, right, whereas when you have a product like your core product that you're having to redesign to match some of the brand refresh work, I think that takes more time, there's more stakeholders involved, there's more, you know, crufty code to work through and update, whereas like newer product initiatives can kind of pick up on those things, the brand redesigns faster and kind of trial those out in product and see how that relationship fits together. Yeah, I think some of the redesigns that impress me the most these days are probably the ones that have the most legacy behind them, that just because I know as a designer how hard it is to build around long histories, I'm really impressed with the Windows 10 team and different parts of that experience, because there's just, there's so much debt in Windows, like technical debt and design debt, and it's like a very tough challenge to break that apart and like, you know, affect meaningful change, and I think parts of it are, you know, there was a big visual shift from like when Windows Vista came along, and I think people saw through that and saw that like, you know, a shiny visual experience isn't going to like erase the core that's beneath it, and I think that the team on Windows has taken this approach with these like, multiple times a year sort of mini releases that they've been doing and starting to see Windows less as like, the thing that is your working experience, but the thing that like brings everything together. So, you know, just the, there's this app that they have for Android called like your, I think it's called Your Phone, but it essentially like connects to the like Android phones then to have this like, direct connection between your phone and the operating system, and you can like send your messages straight from the status bar, and you get your notifications coming in, and like app level notifications, and screen sharing, and all this other stuff, and I think like the way they've just been like piecing things like that together. It's going to be a long journey, but I would be very surprised if I, as a designer, am not using Windows as my main machine in three years. Like, I feel like it's going to happen. Did you guys catch the redesign recently of Slack? I don't know if you guys use Slack in Cloudflare or not. We don't use Slack, but I use Slack for other purposes, so yeah, I definitely, they've been making a lot of improvements. Yeah, I really like, I guess, I mean, I don't know if you'd be able to qualify it as a redesign per se, but I think it kind of was. They released a new version of Slack a few months back, and that was really amazing. I don't know, sometimes it's a really hard target to hit, but if you really can like perfectly understand your users, it's very well tested, and you really, really understand your audience. I think sometimes you don't even have to do a transition, Dan. Sometimes you can just, you literally know exactly what the users want, and you just ship it to them, and that's kind of what Slack did in this case because I know a couple friends of mine got it earlier than some others, but I think most of us got it all at the same time, and we were all equally impressed. Just right off the bat, it was like, whoa, this is way better, and that's exactly what you want from your users. Now, could some of that have been the, you know, kind of a duck on the water where ultimately you weren't seeing all of the user studies behind the scenes, some of the beta testing, experimenting, and of course, you just get the end product of a beautifully well-designed, you know, redesigned scenario that you get to experience. Certainly. My other example for that would be Facebook, I think. Maybe less so, but one thing I do admire from Facebook is given their audience size, there's like tens, if not more, versions of Facebook constantly. All of us probably have a different one, and it's always being tested, and so by the time things actually do come out, they're very, very thoroughly vetted and tested, and certainly Slack has gone through that process. It's pretty evident based on how accurately they hit the mark, I think. I'm always jealous when people get the redesign of a product before me, and I'm like, let me refresh my phone. Let me redownload the app. Let me refresh the website. Good deal. Waiting for the redesign to hit me. I start to see cohort jealousy now that there's enough information out there. You're like, oh, man, I'm not in the new cohort. This is crap. If customers are saying that, then you're doing something right. Yeah. And so do you think an element of these successful redesigns is kind of that constant iteration, you know, small changes, constantly improving and iterating, kind of to the lean design principles and lean startup principles mentioned earlier, where you are taking small steps, getting feedback and readjusting. You see that as just a more modern approach and more successful approach? I think certainly as you increase the scope of what you're changing, you increase the risk. Sometimes, to John's point earlier, it's unavoidable. You have different strategies depending on what you're trying to change. Sometimes you just can't release it in piecemeal. There would be no way for Windows Vista to make piecemeal changes and become Windows 10. But yeah, if you're going to do a really big bang release, that comes with a lot of risk for sure. Yeah. I think thinking of other sort of impressive redesigns, like the most recent Facebook redesign is like for a product that large and that widespread, like it's impressive the bet that they're sort of making on that. Or at least like what I see is that, you know, I can only infer what I assume is their strategy behind things. But, you know, I log in and I see this experience where it's kind of shifted to like really elevating these what were formerly considered like subcategories of Facebook and like things like groups and the marketplace and other like community related things. And I feel like I've heard rumblings over the years about like user research around those things and like how, you know, group engagement is like those cohorts of like people that are strongly engaged in their community groups or like better, more longer term users of Facebook. And it really seems like they took a big gamble on that kind of research where it was it would have been a lot easier to just like continue like chipping away at the feed and like rounding corners and, you know, increasing this, you know, the prevalence of this type of post x percent and all those sort of like micro changes and to start to see if you can like actually affect behavior on a gigantic platform like that over the long term is is pretty interesting. I think Facebook's in kind of a unique position there where like, I mean, I don't I can't really imagine any of our SAS products kind of suffering the same problem. But for Facebook, it's just such like a lifestyle product. And over the course of its lifetime, it's like users are just interacting with it and thinking about it differently. So yeah, it's like, I agree, John. It's like they're taking this investment now on saying that seems like people don't really interact as much with their loose group of friends that maybe they made in college or high school or what have you, that maybe they're more connected with these local communities or these communities to find online. And it's very interesting to see companies back that up and really change direction of their product. Now, kind of on the other end of the spectrum. So now that there's often easier paths to get data to cut into multiple cohorts, you know, have you seen the opposite problem where people start to kind of bike shed or focus on how do we get this tiny little feature to eke out two, three, you know, even 1% improvement in some criteria or some variable, and then you're just kind of chasing those tiny incremental improvements, not the kind of loss of a broader vision or kind of a bigger redesign. I think it's more of a team problem, I would say. I think like you need you need quality product leadership for that. And by product, obviously, I do mean product managers, but I also mean product more broadly. So design leadership, engineering leadership, everyone's involved on this business, everyone's involved, really, the more that you cannot be siloed in your business in your office, I feel like that really helps. Because if everyone's really focused on their particular teams and their particular feature, that's going to be reflected in the product as the small iterations that don't really work together. You need to have a lot of like cross collaboration amongst your broader team so that you can make these product switches. Yeah, I think the tooling around using data in product decisions has changed and improved so much over the years that it's like, I think everyone's still still learning how to make it a part of their development lifecycle and how they plan out their roadmap and things like that. I guess the, you know, as in, in my position, I'm always open to like any signals that I think are valuable. But the thing I try to key in on is like, do I ever feel like teams are leaning on data because they want to avoid a hard conversation? And, you know, it's it if it becomes easier to say, like, I don't know which direction to take, we should just AB test it, then I like to, I want to try to dig deeper into that. And like, you know, what are you going to do about that if version B comes out ahead? Like, how does that? How does that change how you think about our whole strategy? You know, especially when whatever these multiple versions in this multivariate test are like, drastically different in some way. So I think it's like, it's good to use that, but also like, dig into why you're asking those questions in the first place and, and make sure you're like, comfortable with that and aligned on that as a team. There's been times to where I've ran an AB test, and then the version that I I'm like rooting for one of them over the other, like, I tend to get very emotionally attached to my work, which is one of my flaws, but whatever. And so like, in that case, when the version that you don't think that you think is going to be like, astronomically better users are actually like preferring the different version, you're like, Oh, man, I was wrong, like, really keeps you in check. Yeah, in those cases, it's almost like you're betting on a horse. And you want the one either you worked on or the one you personally find better to win, and then ultimately being disappointed at the at the outset. All right, well, with that, I'll shift over to a few of the questions we've collected. And again, a reminder to the audience that we're talking with a panel of product designers from Cloudflare and Unity Technologies, feel free to submit questions, and we'll be kind of addressing them over the next 10 minutes. So just live studio at Cloudflare.tv. And we'll they'll get surfaced to our chat over here. So with that in mind, I'll toss our first question out to the panelists. So this comes in from Nikhil. The question is, what are some suggestions or advice you would give product managers and engineers on how to best enable and work with designers? Particularly of interest is frameworks or process improvements you found were useful with working with those two teams? Like, this is the eternal question. I mean, it may seem like a simple answer, but I feel like I don't know if communication is a framework. But I think a lot of teams like there's just a baseline communication level that sort of needs to be met in some capacity. And, you know, thinking about like, you know, do I want my engineering manager and product design manager to be equal partners in this initiative that I have going on? If yes, do I invite them all to the same, like decision making meetings to do we all have the same information? I think it's easy to sort of silo ourselves into our own world of the information that we have to help us make decisions. And sometimes forget that the information that you're latching on to, to do your job can also help other people do their job too. So if I'm thinking through redesign work and coming up with a couple different options, like, if I can be transparent and open about what those thoughts are throughout the process, then, you know, I might have an engineer be able to latch on to that and say, like, oh, I know you're sort of have all these things up in the air, but option C would be incredibly easy to implement. And, you know, that's the thing that if I just sat there by myself and sort of never showcased some of that thinking, then they would have never been able to jump in. So that's, that's one thing that stands out for me. Yeah, I think John's right here. Like, trust me, I'm a very process driven person. And it's very hard for me to pinpoint like one particular thing that I've done that has helped me build relationships with my product managers and engineers. I think it's, it's just, it takes time too, which is also really frustrating, because I'm very impatient. But it takes time to build those relationships with people you're working with, it takes time to build trust, it takes time to build a sense that you can feel vulnerable sharing, like, hey, I did this design, it's really ugly, but will you look at it? Because I would love your feedback. Like, those things are hard to do. But I think over time, you develop those working relationships with people where you can be candid with each other, you can say, like, I don't think this is working, like we can do better. And then that's ultimately leads to a better product. So I think it's a lot of like, just taking the time to get to know people as humans taking the time to share frequently and often taking the time to answer questions. And for me, like, I'm not a super technical person. So it takes me some time, especially working on a product as complex as Cloudflare, it takes me some time to get familiar with the space that I'm working in. And what's been so beneficial is that mostly everyone here is willing to take the time to explain things, right? Like, why does it work this way? And once you develop that shared understanding, again, it just makes for a better product. So I don't really have a good answer for you other than like, just building those relationships and making the time and making the space to allow that to happen. Yeah, I would definitely agree with all that. Like, design is not like an assembly line. I mean, well, I mean, it can be for different things. But in this in this case, based on the question, the waterfall process, come on, everyone still uses the waterfall process, right? Yeah, like, I'm assuming you don't want to just kind of like throw the it, you're not going to get great results if you throw the product spec all and then expect them to kind of throw back a design that's going to be perfect that you're happy with. Like, I think, to the point John was making, you need to have that constant communication and collaboration with your team to be able to know, just to kind of jam on it, it's kind of a shared, shared working relationship, shared goal. And also to agree with the point that he was making, without that sort of deeper relationship on the team, there's not going to be that kind of candid relationship where people feel free to speak up. And if there's not that, if people don't feel comfortable speaking up, then you're not going to get really critical feedback about areas of the product. For instance, if I don't feel very comfortable with the product manager, I'm going to really temper, you know, potentially the feedback that I'm giving around how successful a feature is, especially, you know, is it their idea, you know, we really need to kind of, the whole team needs to kind of have a good relationship there so we can work together. So, so continuing down that thread, any thoughts or ideas of building those relationships or maintaining them, particularly in more of a remote workforce or, you know, Zoom based work style? How do you kind of make those same connections and same relationships that you might have in person? One thing that we do at Unity, which is the, it's the first company I've seen do this. I think it's a really cool kind of cultural avenue that we take on this is just that, you know, we're really big on building relationships around the company. And, you know, companies I've worked for the past, I've always kind of taken the idea of like a one-on-one meeting as more of like a business kind of perspective. Like, am I showing up with an agenda? Here's what we'll discuss. Maybe we'll end early. At Unity, it's more of a thing like, you know, it's encouraged to set up one-on-ones without even really any sort of business agenda. It's just to maintain the relationship. You know, I could set up a one-on-one with you, Dan, we could talk about like things that had nothing to do with work, just how's life going? How's things happening? That just helps you with a shared understanding to, especially in the era of COVID and we're all just over Zoom, you know, you're a real person, you just real things going on in your life. It's really good to kind of maintain that baseline level of personal connection. Yeah, to Ryan's point, like you could be having a one-on-one with someone that, you know, that is your cross -functional partner and they could be having a really shitty day or same with you. And I think like creating that sense of vulnerability and getting to know that person as a human being, like we're all just doing the best we can right now with everything going on and it's really important that we're truly asking people how they're doing instead of just as an opener to your conversation and then directing straight towards, you know, a work topic. Like I've been on calls with folks where we don't talk about what we were meant to talk about during that meeting until like, you know, 10 minutes left and it's actually refreshing to just chat with them as a human and it'd be like if you were to go get coffee with someone, right? And so I love that suggestion that Ryan mentioned of like making sure that you're just setting up one-on-ones without, they don't need an agenda always, you know, we can just chat like we normally would if we were in an office setting or if we were grabbing lunch together and that's been the hardest thing I think to mimic in a remote working environment is when you're talking at a screen, you feel like you have to talk with purpose but sometimes you can just talk and that's okay. Yeah, I think some of those things that were mentioned were things that I, my last job was a fully distributed team so I feel like I've learned a lot of things through that experience that I've hopefully been able to start to apply here but I think there's a lot to, it's at the organization level, it's worth looking into the tooling that you provide, people to communicate because little things within that tooling can drastically affect the distributed culture that you're building. I think Slack is a really powerful tool not just because it's pretty robust as a chat application but there's a lot of like little things in there that can influence how distributed teams grow and build. Channel discoverability is like a huge thing, you know, just being able to see like oh here, they do some like more automated nudges like people who join the baking channel also join bread making or something like that and you can sort of see these culture focus channels but then also like other ways that you build camaraderie that you wouldn't expect like Slack has the custom emoji feature and I think a lot of times like, you know, we started off using that to often like add in more inclusive emojis when they didn't exist yet and then as the Unicode specs sort of improved over the years and like a lot of that was addressed on the broader emoji level, they became a space for like in jokes too and like different teams sort of had their team culture represented in custom emojis that they would make and I think that stuff really affects how teams work in a climate like this and you know, so tooling choices are important. Yeah, I think cloud layer actually had a few examples of that back when we were on HipChat, you know, Atlassian's HipChat tool. Yep, there were quite a few custom emojis across the teams, some of them, you know, quite proudly displayed or essentially becoming a nice in joke within that team and how well they translated or I think there was some moments of sadness in the transition to our new chat app and the loss of some of those custom emojis. All right, so we're nearing the end of time. I'm checking questions real quick. Maybe a quick round of, you know, what steps do you think are best to take if someone would want to get into the product design field? Build something, I think. Yeah, you took the words out of my mouth, like practice by doing, like get your hands dirty, like try those daily UI challenges but also try more complex ones, like, you know, solve a user problem or go through some design challenges. Yeah, I would say definitely the doing aspect and also, like, think critically of the world around you. Like, you know, you use a lot of products already. They were all built by product designers or UX designers, people like that. Try to just spend some time thinking about, like, how did they get to here? Why might they have gone in this direction? If you're lucky, you might actually find the answer through some blog post or something where they actually talk about their process, but even if you don't, just going through that thought exercise I think is really valuable as you're growing as a designer to just, you know, virtually design things in your head and, you know, run through the steps that you would have figuring out how things work. Yeah, I think it's important to fail. Like, you know, whether you're building something from scratch, whether you're trying to improve something you use day to day that maybe you think can be changed or improved, I mean, if you land on a solution, that's wonderful, and potentially maybe that's something you should sell, but I think it's totally okay and it's the baseline to, you know, not totally succeed. It's just it's something you learn. It's something you can try, and it's a discussion point for the future, and that's things that we love to see in interviews. So, you know, even if you have a side project or something you're working on, that's something real. That's something you thought through, and it's really cool to hear more about that. All right. Well, again, thank you, everyone, for taking the time. Thank you, panelists, Bethany, Ryan, and John. Hopefully we had an interesting and great discussion for those watching live or those watching the recording. As always, we'll have this style guide session once a week, talk about design, UX, any issues that the team kind of wants to bring up, and with that, I'll kind of transition back to Cloudflare TV. As I said, feel free to continue to add questions to livestudio at Cloudflare.tv, and we'll use those to inform future sessions. So, once again, thank you, panelists. Thank you, Dan. Thank you, Cloudflare. Thank you.