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 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. And I think, from a designer's perspective, so much work goes into a redesign that that work often isn't exposed to our customers, right? 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. And 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 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 is the things that can be changed easily, and they're potentially minor, and then obviously paying off either 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 the—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. You know, 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 it comes, when you're providing services that are sort of, you know, 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 was this whole, like, interface training infrastructure that was built around, you know, you might want to change, like, a sign-up 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 product's 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 any of that? I was going to say 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 still 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, I mean, 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. I don't know what it is. 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 kind of tied to and it's really, really interesting to see the progression of products throughout the years and how they've changed and grown. Adflare used to have a really cool, I wouldn't call it quite skeuomorphic, but it was kind of skeuomorphic, like 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 could probably still have some pictures of it. Nice. That just speaks exactly to John's point about keeping the documentation updated. But 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. We had that at a previous company I was at where 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, etc., etc. And 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 would 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, and 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? Like, if they would have tested that forever, they might have missed that opportunity. I think you have to kind of 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, but 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, like, revised data dashboard, and this was one of those almost superfluous, like, visual refreshes. It didn't really have, like, a product purpose. So, essentially, what one designer did was they just kind of totally changed all the ways that all the data charts looked, and they made it, like, super flashy, like your kind of stereotypical idea of, well, some engineer's bad experience with design, basically. So, we just kind of rolled it out instantaneously. They were all new charts, and 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 sort of things that, for these financial dashboards, were actually critically important. So, we heard that from users loud and clear via our support channels, and 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 kind of support what Bethany and John, you guys were saying before about having, like, when you kind of do manage that redesign, having the right communication is really key. Having the right kind of, like, support channels there are also really, really helpful, basically, to catch things like this. It really helps, I know, kind of 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, like, what we wanted the users to do and interact with, they just, completely ignored, and 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, and I think that maps back to just not doing enough proper research and, like, understanding fundamentally what their needs are, and then building something that fits those needs, because we kind of just took a shot in the dark, and we called them, like, experiments, so we were just kind of trying things out, shipping really rapidly, and then we didn't get the results that we had hoped for, and that was kind of sad, because we had spent a lot of time and effort on it, without actually seeing value from our user set, so, yeah, I don't, I haven't been a part of, like, a huge redesign that was disastrous, but definitely, like, failed a lot as a designer. There's no doubt about that. Yeah, I think the, my, sort of, most failed redesign experiences kind of harkens back to Bethany's point earlier about, like, who are you designing, who are you designing this for, and is there a purpose that you're redesigning around? I think of, like, an early stage startup I was at, where I feel like redesigning our homepage was kind of, like, our, it was, like, our version of, like, spinning a pen, trying to, like, you know, 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, and I think we, like, went through that cycle a lot of times, as opposed to, like, actually addressing some of the core product that, you know, we were looking at how we were pitching this product, and assuming that, like, the pitch was failing, and it was the product that needed more work, and 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 not commonly, but in your career, where, you know, leadership will ultimately point to, well, it's a design flaw, we need to alter how we're, how we're approaching, or how customers are interacting with our product, as opposed to a product flaw, and if so, kind of, how do you move evidence one way or another to try to be on the hook, or if it is a design issue, you know, make the appropriate changes? I think, I think people, and when I say people, I mean, like, the design and product community as a whole has gotten better at this. If I just look at, you know, my career isn't super long, but, you know, 10 years over a decade, so at least, like, if I look at where the broader design community was 10 years ago, I feel like they're, people doing the building didn't always have the same sense of, like, you know, what, what do I need to build to reach certain milestones, where I have better understandings of, of my customer, and I think there's, there's been a lot, you know, whether that's, like, the lean startup movement, or other, just people showing by doing, by, like, you know, releasing very early stage stuff, and throwing it up on Product Hunt, or 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, and sort of 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, and large orgs that run into that at a much grander scale, too. Yeah, I mean, designs, like, designs always sell really well, I think, in, like, a meeting, or something, so they tend to get approved by leadership teams, but, you know, thinking about, 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, you know, a lot, a surprising understanding of the user, and really, really digging into wanting to see metrics, and having the product move metrics, as opposed to kind of, like, blindly approving things that look pretty. All right, 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 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, there's this app that they have for, for Android called, like, your, I think it's called Your Phone, it's, 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, 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. I mean, 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, like, let me re-download the app, let me refresh the website, 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, oh, man, I'm not in the new cohort. This is, that's crap. If your 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. Like, you have different strategies depending on what you're trying to change. Sometimes you just can't release it in piecemeal. Like, 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, 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 are, 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 pretty interesting. I think Facebook's in kind of a unique position there where, like, I mean, I can't really imagine any of our SaaS products kind of suffering this 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 it 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 they find online. And it's very interesting to see companies back that up and really change the 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 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 these small iterations that don't really work together. You need to have a lot of 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 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, 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, if it becomes easier to say, like, I don't know which direction to take, we should just A -B test it, then 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 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 make sure you're, like, comfortable with that and aligned on that as a team. There's been times, too, where I've ran an A-B test, and then the version that 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, you know, ultimately being disappointed 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 livestudio at Cloudflare.tv, and we'll get, they'll get surfaced to our chat over here. So, with that in mind, I'll toss our first question 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 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, you know, do we all have the same information? I think it's easy to sort of silo ourselves in to our own world of the information that we have to help us make decisions. And sometimes forget that the information that you're latching onto 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 a 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 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 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 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 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... 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 working relationship, shared goal, and also to agree with the point that Bethany 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 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. It's just that, you know, we're really big on building relationships around the company and, you know, companies I've worked for the past have 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. There's 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 you feel like you have to talk with purpose, but sometimes you can just talk and that's okay. Yeah, I think that 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, 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, 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. 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 if 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.