Nick Cawthon of Guage

Yeah. Awesome. Welcome back to another episode of Modern Cyber. I am your host, Jeremy, coming to you with a really interesting guest and a topic that I think we don't cover nearly enough in the cybersecurity industry. We are going to be talking about design. And if you know me, you know, I know almost nothing about design. And that is why I'm thrilled to be joined today by somebody who hopefully can educate me and educate our audience about what are some of the friction points between security and design? What are some of the considerations? I am joined today by Nick Cawthon. Nick is a designer, researcher, and strategist, user centric and enterprise scale. He is an invited speaker for SigCHI, BayDUX, Xerox PARC, Lunch@Google, Heavybit, People Nerds and others. He's also an adjunct professor for the Design Strategy MBA program and the TRIUM executive MBA, curriculum organizer for IxDA, CXPA San Francisco Chapters, and he is currently working on open sourcing sandbox.gauge.io and anchorbox.gauge.io for UX, which I just recently learned are user experience researchers. Nick is also known to wave his hands wildly and use punctuation with impunity, and has a particular issue with em dashes, which time permitting, we may get into. Nick, thank you so much for taking the time to join us on Modern Cyber today.  

Jeremy, that was a mouthful and you did wonderful. Thank you.  

I do what I can with the introductions because I like to get through them quick and get into the conversation. Now, I said at the top that I don't know a lot about design, but I know that design, and especially, let's say software usability is something that we all deal with literally every second of every working hour of the day. You know, we are all—and I say we, I think about our audience of cybersecurity practitioners. We're all working in software systems pretty much nonstop, whether that's our email or Slack or whatever we're using just for communication or for productivity or whatever the case may be. So I know design really permeates our lives and our working lives in particular. And you identify something that I think you phrase as the gap between security and usability. What is the gap as you see it? Or how do you think about kind of the trade off between security and usability?  

Yeah. I mean, I don't think there should be a trade off. Um, the, the notion—and any security practitioner will likely say, uh, I'll try not to speak in hyperbole too much, uh, just to get started—that the weakest link is the human factor. Um, that we have systems and processes that we get tired of, uh, and hurdles we get tired of overcoming every time. And that's usability—how do we make these, um, laborious tasks, the ones that again, are vulnerable to, um, to threats, uh, how do we make those easier? And that's the true nature of usability as a little bit of a backstory. If I were to have worked in my grandparents' age, it would have been called human factors, and those were physical manifestations. We didn't have software back then, um, where we're trying to determine the chair's height and the distance. And you think about how we built systems around, um, making it easy for the person to be in a physical space. Um, and that is very similar to what we do today is we try to understand where are those friction points and where are those pain points on a standard workflow task and trying to go through a burndown queue or trying to understand an after action report. And how do you make it so that it's a pleasure to do rather than cumbersome or, or laborious? Okay.  

And so, you know, if I think about that, I obviously think about things like, you know, Slack, which makes it very easy to communicate to my teams and is designed to, I think, to your point, increase my productivity or improve my productivity and the usability around that communication process. Do you have some examples, maybe off the top of your head of areas where you think usability has created security issues?  

Yeah, I used to. I was one of the first designers at Loggly. It was a Splunk competitor that was doing it in the cloud. Um, and at the time, uh, Datadog, uh, came out and it was a competitor that was in, you know, system admin, aggregate all the systems and be able to see those kinds of, um, those kinds of notifications and Datadog's model—and may still be today—was to copy Facebook where it was a time based display. And Facebook at the time was undergoing a meteoric rise to become an extremely valuable company. And they were not wrong to establish the user experience similar to a very popular product, because people knew how to use it and they were familiar with this timeline scrolling approach. But think of spectators at a tennis match where they have to look bonk, bonk, bonk. And the same thing is true with, um, trolling of that infinite scroll where your eyes are going up and down and up and down and up and down and up and down. And it's one thing to design a system so that it is sticky, uh, as we say in um, sort of parlance of, of user experience, so that people stick around and are interested in exploring and things like that. It's another thing to design a system where it's efficient. Uh, Datadog is amongst a chain of many, um, tools and platforms that system administrators need to go through every day in case there's an incident, in case there's a report. It should not be designed for a sticky, it should be designed for isolating the threat and then moving on to the next one. And that was an early example of a metaphor, a design metaphor, or a system that was reappropriated from an entirely different paradigm and now put onto, um, a really different context or scenario of use.  

Yeah. So I guess in that—in that context, I think the way, you know, if I'm hearing it right, one of the security risks that comes out of that is like, you scroll past things, right? And sometimes you have the risk of kind of, let's say, glazing over, which I know we've all had the experience of doing. You know, I've scrolled my Facebook page—not in a long time—but, you know, back when around this time frame, but, you know, back around that time frame, I've scrolled and I miss updates because, you know, they just kind of blend into the context. And if I think about that in a security world, I might have missed an important log message or an important alert or an important, you know, security event in that kind of usability thing. And it's really interesting to me because I think about like, the way one of the, you know, we're not the most amazing designers over here at FireTail. I'll be the first to admit it. I think our user interface is fine. Uh, and no, no, not to bash on our own company, but, you know, just being humble about it. Like, I don't pretend that our customers are actually going to spend that much time using our UI. I think our goal is that, you know, we do the data analysis that we do. We help you identify policy violations in your AI adoption, but you're going to consume that violation or the notification of violation in some system that you're already using for that purpose, whether that is a ticketing system or something like a Splunk or something like that. So, you know, my—my most important usability aspect is that I can help you design that policy and then help you quickly and easily, and then also help you route the output to where you want it to go quickly and easily. Right. Is that like kind of what you're getting at in terms of, you know, making it the right context for the consumption of that data?  

Yeah. Middleware. It's—it's like the middle child, you know, never gets all the attention and never gets all the love. Um, yeah, I think that is the right context. Uh, there was this notion, uh, early on, if you remember those installation CDs with Oracle 9i and all of these sort of enterprise systems. Um, and I say CDs because those are the removable media at the time that we would use. I think we had like a series of them when we were trying to put it locally. And the—the UX behind that was always so bad. And even we remember some of these early portals that were just meant to portray an extension of a database interface. Uh, and there was a—a—there was a penalty for having something aesthetically pleasing because it wasn't seen as enterprise scale or it wasn't seen as designed for engineers. It was seen as this aesthetic. And maybe the priorities were different. Maybe it looked too good to be really powerful and to be really, you know, a strong utility. That all changed, um, with the consumerization. I—I—I will attribute it to—to Apple and the iPhone where, oh, wait a minute, this—this is a very powerful device and it looks beautiful. And so the phrase "it just works" was applied to, in this case, the software on the hardware. And that kind of notion of there—there is an importance in aesthetic and a reasoning around, uh, attrition rates or in the case of hardware devices, one of the things that I've studied is return rates of devices that are perceived as being aesthetically pleasing are a third of those that are just, you know, janky or utilitarian. And so people have more patience and want to figure it out and want to understand because there has been design applied to it. So going back to FireTail's analogy, if you're assuming that there are no users willing to spend time or they want to get in and they want to get out, I do think that there is a user experience that's meant for that observability and notifications clarity. Sure. So that they can have those things. Um, but to make a distinguishing—distinguishing factor between, say, a UI, which is the aesthetic and the veneer and the colors and the brand and the clarity, typography, hierarchy and so on. And then the UX, which is how they progress through information. What we show them at any given time, when those—when those sort of data collections and data provisions occur. And that—that came out later where there was a notion of, okay, it's not necessarily how it looks anymore, but how it functions and feels. And that's the realm that I've been playing in is because, you know, design patterns and, and branding style guides are a dime a dozen these days. It's really how to design that interaction, how it actually works.  

So you really start from the kind of what is the user trying to get done here? And what is the optimal way for them to get that—to accomplish that goal? And then you apply the design guide or the UI, as you put it, right on top of that, once you've kind of figured out and so on. That UX point in particular, I'm wondering if there's, you know, particular security implications around that because I can think about some examples where I know we have friction in user experiences sometimes maybe like kind of justifiably so if I'm signing in to an important system where I have admin rights and there's a two factor experience where I do have to go in my pocket, get out my phone, pull up my authenticator app and punch in six digits. Like, okay, maybe that's like the right level of friction to make sure that, you know, I am who I say I am. And also like asking me, you know, do you really need to log in with admin credentials for the thing that you're trying to accomplish? You know, I can understand some of that trade off. Are there other examples that come to mind where you think, like, we've introduced friction in ways that are not productive or not useful friction?  

Well, those tend to be inadvertent, okay. Those just tend to be badly designed. Like, yeah, there's friction there. But just because I don't think they were intentionally applied. Okay. The, you know, even think about documentation and training. It's sort of an underrated, um, area of, of application development where somebody needs to figure out how to do the thing. If you're in a signed in state to be able to apply, uh, instead of in brackets, "your domain here" or to be able to apply, um, connection keys or organization IDs or things that are replicable for—for the logged in user. And then they're going to go off into the terminal and they copy and paste that in there, but you're saving them the—the need to select text and to go and find the organization ID and to copy and paste and put it in themselves. I mean, it's typically cascading down because an organization has a different platform for its documentation and training than it does for its application itself. Yeah. Um, but that—that knowledge is known, that data point is known is that you are logged in. We know who you are. We know what your org ID is. We know what your domain is. We know all these things. We can give it to you so that it's a one click into the diagnosis of whatever your problem might be. And that's—that's something that—that is front of mind. There's this notion of swivel chair of context shifting. Um, and think of somebody in a control room or, you know, um, you know, ground control in NASA who's moving from terminal to terminal and having to switch context or switch windows. I think that's a very typical use case for security professionals and system administrators, is that they're having to constantly move from browser to browser or from view to view. And if—even if you think about that, it's like, how does this screen work when it's collapsed to half the size of the monitor? Because I've got to go side by side on whatever's next in the chain. Uh, it's not necessarily mobile first or the, you know, the DevOps professional is going to be doing this when it's pocket. Maybe it's that it's a split screen or a shared experience between one or the other, and it needs to be in that, you know, the—the data points that need to be transferred over to the next step in the chain need to have some sort of relevance to it. There's a—I went back to—to Datadog earlier. Um, there's a different approach where if it's a card based system and instead of scrolling back up, you're, let's just say you're dismissing threats in your—in your burn down queue where you can stare and have your mouse at the same spot. You don't have to move your eyes. Um, X or Y and you don't have to move your mouse to scroll and then reposition the mouse to dismiss or escalate. But you can go in and it's, you know, like—like a woodpecker tapping into a tree trunk. Um, you can tap with very little variance and get through that queue very quickly. Um, you know, those are—those are some of the repetitive behaviors that we can make easier. Uh, in these cases where there's a lot of noise and very little signal is that we can really remove that laborious task. I've used that word too much already. Um, but to—to acknowledge where—where these kinds of scrolling and, and, uh, upkeep of, of a lot of different types of information coming through because that's the hardest thing is the fatigue of processing all this and understanding where it might go.  

Well, that's such a great point. And I want to follow up on that because, you know, there's this saying that we hear in cybersecurity all the time is that we're drowning in data, but we're starving for kind of information. Or, you know, you'll also hear about like the signal to noise ratio out of X, millions of log files that have come into my system, I need to identify the five that are potentially malicious or represent some bad behavior. So I'm curious, is there research about, um, when I'm looking at a large data set, what is the most efficient way for me to focus on something so I can make a human informed decision about this needs action? This doesn't need action, is it that, you know, don't move your mouse, don't move your body. Stare at the screen. You know, just click dismiss. Is it that kind of woodpecker thing that you said? Or is it the case that I'm actually more engaged if I have to take some action, maybe moving my mouse, maybe hitting a key on my keyboard or typing something in like where—where does the human focus better to digest that information and make a good decision about what to do about it?  

Yeah, you bring up a good point again, uh, it's the guiding of, hey, we've noticed this action to let's automate this or let's customize this because if, if even we're woodpickering—and I love that we've sort of put the mental image in people's head of the security professional, uh, tied to a tree with a long beak. Um, it's to be able to guide them to some safe searches or customized—customized experiences and to be able to acknowledge that you can't keep this up forever. It's great that it's efficient and it's great that you're reducing that noise. But let's create a safe search or let's create a condition or a quota or some—some anomaly detection so that you're not having to do this manually. And that could be buried three or four clicks into a separate page on a separate section. That kind of configuration and save. And when you're going and trying to see the abstraction of the visualization, how do you go from one very minute specific task? Tap, tap, tap into something that can again, give you confidence that it's automated and that it is giving you the full display. And that's where, uh, you know, that flow or that experience comes in is to be able to gently interrupt or gently notify to say, hey, why don't we go in here and create something, a utility that is already in place. But again, it's three steps down so that you don't have to do this or that. You can have some observability over what's happening in the future.  

So when you talk about reducing risk through user experience, I mean, is this kind of what you have in mind is that, you know, we need to be providing the right user experience that gives the—the user who is arguably, you know, a very high value security professional that your company is paying a lot of money to do their job. You actually give them the data in the most kind of informative and actionable user experience that they can get.  

Yeah. You had the analogy of the Facebook feed of, I missed an update from the girl that I loved, and she was single and I never knew. Yeah. And her relationship status changed. And that—that kind of scenario is, is real. Um, and to be able to reduce the risk to allow you to maybe follow different things at a different level. So it's not every noise isn't—isn't the same frequency. And I think that type of understanding, again, of these repetitive, laborious tasks and to be able to talk with the, you know, the junior—junior staff member whose responsibility each morning is to go through this queue and start to assess what happened and to understand which threats are really irrelevant and which ones are important, and that type of research and assessment to say, okay, well, this person is doing this for eight hours each week. Uh, and if they keep this up over the course of, you know, the months and years that they're in this job, that there are going to be flaws there and mistakes. And so how can we make it so that A, they have a personalized view of what it is they're looking for and what it is they're doing? And B, we can create these types of time savers so that they feel like they're managing things rather than just trying to bail out the boat again to—to mix metaphors here. Yeah. Uh, and that—that reduces risk is when do you understand fatigue? Um, yeah. And often this is a very male profession. Uh, yeah. And we're not good at communicating. Hey, um. This sucks. Uh, we're good at just getting it done and sort of even our introductory conversation of, um, what the rest of my day is going to be. And, uh, I think that, you know, that takes some emotional sensitivity and some balance in how we speak with one another, um, about our jobs and about where that fatigue comes in. And I think that that is, is the start. And from that emotion and, you know, there's, there's not, um, surveys aren't great at that. Um, algorithms aren't great at that, but humans are great at that of understanding where those nuances and people relating with other people are and you find these tasks that are just horrible and they happen every day and they create fatigue and, and disconnect. And that's where that exposure of risk comes in. So long, long winded answer to a very succinct question. Um, yeah, I hope I, I landed it okay.  

No, I look, I think it's such a relevant point, you know, because if I go back to the beginning of the conversation, we're all spending our whole days working in these software constructs and ah, you know, work experience is largely governed by how effective we're able to be. And then also, to your point about how satisfied we are with them versus how either fatigued or mentally checked out or just annoyed with them. And by the way, like, I don't think cybersecurity tools are the worst on the planet. If you ever have to go sit side by side with a colleague who works in finance or accounting, like I look at those tools and I'm like, jeez, I don't know how anybody does those jobs. Um, but, you know, maybe that's just a mindset thing. But you said something there that I want to dig in a little bit because as you were describing that I kept hearing in my head, well, these are psychological, uh, analyses more than they are kind of, let's say like, you know, technical analysis where I think about the location of a widget on a page or what does an input form look like? You know, these are more like human emotion and human kind of like response driven things. And I know there's a lot of talk in kind of behavioral economics about nudges and kind of nudge theory and kind of guiding users towards the desired outcomes. How do you think about applying some of that logic or motivation to design practices, especially in cybersecurity?  

Jeremy, great segue. There is something that is the cat's meow, um, these days called, um, forward deployed engineer. Uh, and it is the re-appropriation of a lot of military terminology from companies like Palantir and OpenAI, where they are able to send a team, a Delta team, as they call it. I don't know if Chuck Norris is involved. Uh, And they send them in, they send them into the client. They say, "we're going to need a conference room for a couple of months." And so there's a team of engineers inside this conference room. And the—the most affable of the group gets to do the client relationships, gets to be the forward deployed engineer and have the same kinds of discussions as you and I have been having. Okay. What's happening with the workflow? Where's the frustration? Tell me about the data. And it's becoming this sort of sales mole of the person that's listening and trying to understand what can we build and what can we charge for this client. Now the other engineers are waiting for the forward deployed engineer to come back and report. Here's what we're going to prototype. Here's what we're going to build out. And then they sort of use their generative tools. And then voila, a couple weeks later they've got a working prototype. I'm not going to knock it because it's something I do quite often in my work. Um, but that being said, um, we've now reached the stage where engineers are doing these behavioral sciences are trying to understand what qualitative research is or trying to understand where these emotional variances are happening and, and really being that tip of the spear of going from exploration to requirements and execution. Uh, my guess—I don't know this for a fact—but that the training, um, in behavioral sciences and cognitive theory is, is probably not, um, up to the standard that it was for, let's say, if you were a PhD researcher in that. Yeah. Because if you were an engineer, maybe you're not—not a good engineer. And instead you want to do this. Uh, but the same thing happened, um, fifteen years ago when UI designers like myself realized there was this thing called user experience and oh, we get to talk to the users. I like talking to the users. I like walking through interfaces and discussing design decisions that—that to me, sounds like something that would be a great adjacent to my career. And so we began to do that same thing. And so here I am now later complaining that the engineers have taken my—my lunch because now they're taking my ability to talk with the customers and understand the same thing emotional variances and behavioral sciences and nudge theories and things like that. Um, and that, you know, that's just everything's old is new again, um, is that it's all coming back around. Uh, and I think it's the importance of being able to have a conversation just as you are excellent at Jeremy, uh, to be able to understand and allow yourself the vulnerability and candor to say, here are the things that really frustrate me. Here are the things that are really confusing, and here's this downward pressure that I need to make sure that I get done, uh, or else everything falls apart. Um, to have great empathy for people in these roles, for these analysts roles of you. You talked about financial services. I don't know how you do that job where you have to do this every day. And the penalty for failure is so, so high and the turnover really high is so, so high. And, uh, you know, that kind of. "Are you sure?" Uh, you know, you're going to do this or like it that signal of, of approval and, and affirmation, um, you know, come into play when we're dealing with things like this.  

Yeah, yeah. And there again, by the way, I think like, you know, those might be jobs that have a necessary level of friction of the "are you sure?" You know, and I see it, uh, even in a lot of financial services designs right now, if you think about like the number of scams and fraud that happens around bank accounts and, and people getting scammed online, you know, the additional friction steps of, "do you really want to add this recipient? Do you really want to send them the money? I'm going to text you a confirmation code to make sure your account's not compromised." Like all those friction steps that come in there that serve a very valid purpose. And, you know, somebody had to design them. Somebody had to think about the use case, think about the fraud prevention, think about the protection and the trade offs, because that also probably reduces some of the bank's revenue if they're getting paid on transactions, you know, there's—there's some trade offs that have to happen there. So I really appreciate your thinking around this. You said something else I want to dive into a little bit, which is kind of that empathy point. I always tell our team, you know, try to have empathy for our customer. And I also tell it, you know, right now we work in AI security and kind of securing the adoption of AI within the enterprise. Every enterprise is rushing headlong into using AI in some shape or form. We're doing this in ways where we've created the same kind of disconnects as we've seen in the past, where, you know, the business users are ahead of the security teams who are kind of like running to catch up with them and get visibility into what's going on. And I always tell our team, as you're thinking about designing the product, try to have some empathy for that user who is now told like, "hey, Nick, there are three thousand users of AI within our company today. We just don't know who they are or what they're using or what the risks of that might be. Go solve that." You know, that is very often kind of the context that is given to security teams. When you think about kind of, let's say like a net new thing from a design perspective. You know, I know Loggly, when you worked there, I think like a kind of log aggregation and the SIEM category was already kind of established. But imagine that you're thinking about like building something net new today. Where do you start the thinking? Do you start the thinking from what I just described as like the—the perceived customer problem? Or do you start the thinking from like, okay, here are general best practices and user experience today? Or what's the right way to think about it for somebody who's like trying to build something net new?  

Yeah, I'm going through that right now. Um, I'm mentoring a group of data scientists over at UC Berkeley, and they have never used generative tools before. And their institution is telling them, "sorry, it's not our academic policy to allow you to use these, even though you're data scientists and wow, there's this great calculator that you should really try out." And so what they're doing for—for us is off the record. It's not part of the university curriculum. It's a project base and we're the opposite. We're like, "move fast and use everything you possibly can do." But the challenge is, is as an instructor or as a mentor, I want to be able to see the work. I want to be able to see what you're doing. I want to have a collaborative environment for which we can learn from one another, and that doesn't exist in these prompt environments. You're very much like you are in the terminal, you're in alone, staring at a blinking cursor. Yeah. And I wonder why that doesn't exist, I wonder that. Well, it was the first movers—the same thing with Datadog and Facebook. It was the first mover of there was an interface. And then that company was worth X billion dollars. And then every company to—to follow it copied that interface. Nobody thought about what—what does it mean to be collaborative in a prompt based workspace? What does it mean to be able to see each other's and—and be able to branch each other's prompts? I don't think that's been solved yet. And so I start thinking about the UX. I try to think about blocking and patterns and workflows and where—where these points of information need to be displayed so that it does feel intuitive. And your—your question, it just invoked a scenario that I'm going through in my head now. Yeah. Is that the next multi-billion dollar platform? Will that be a collaborative environment or will it still be an isolating environment? And if it were to be a collaborative one, how do we start to go about thinking, what do we need to see from one another? And so that would be where I would start. I would start with—with teams that are on projects together, each in their own isolation. They're alone together. And then figure out what would you want to see from this person? Just the output, the activity, the branching along the way? I mean, you've got these GitHub commits that give you some indication of when, yeah, they found something that worked. Um, and that, uh, you know, that leads me to blocks. Um, that's the step that, uh, from a UX perspective, what these—these coding platforms or some of the, the tools that are of the day really skip over is to try to allow yourself blocking out. Think of like an architect who has a plot of land to think, "all right, well, okay, the garden will go here and then the house will go here." Or designing just—just on a basic level, blocking out the prioritization in the hierarchy of a screen. Uh, so that we kind of understand and know this is how it might think and feel. And so rough prototypes, rough sort of mapping and then from there. And then once you get an idea or a sense of what you want, then the technology is really good at sort of easing you along to, to some form of production. So it was a long winded way of answering a question that was fairly direct of how do you go about thinking, but I'm trying to give you a scenario that—that is top of mind for me of like, why? Why isn't there a collaborative environment? So you're not just sharing the history of a chat, but you're able to create together, uh, in a, in an IDE or something similar.  

Yeah. I mean, it's such a good point. And I totally relate to what you said is that, that it is an isolating experience. And, you know, for us, for instance, we are, you know, like I said, an AI security company. And so we're trying as hard as we can to be experts in using AI in different forms. And so we're constantly experimenting with these tools in various forms, whether that is desktop, etc. But exactly to your point, I'm experimenting, my coworker is experimenting, my next coworker is experimenting and so on. But we jointly are not experimenting. We get together on Friday mornings. We do a little show and tell of here's what I learned this week about, "oh, I started trying this new tool X, here's what I learned, etc." but it is not a collaborative thing other than in that kind of show and tell session.  

So it's a really interesting point. It feels like a race. Very much feels everybody's in—everybody's in their own sort of fiefdom. It feels like you're all racing one another.  

Yeah, for sure, for sure. That's hard on teams. Yeah yeah.  

Nick I want to kind of wind—wind down today's conversation with something that I think is, you know, probably a great place to end, which is all right. We've talked about net new. We've talked about the psychological impact. We've talked about nudge theory. We've talked about presenting data in the right kind of display and getting people to focus on it. What would be some of your top design tips for companies that are building cybersecurity tools? Uh, is there, are there best practices in user experience? Is that different if it's a SOC analyst who's using a Loggly versus a developer who's using a static code analysis tool? What can you share as somebody who's got a ton of experience in this space?  

Yeah, take it slow. Do it in person and take it slow. Um, one of the things that I would do, uh, you've got—you said you have RSA coming up , um, OSCON, PyCon, um, in its early days would go to a lot of these open source conferences and set up a booth. Uh, and it was hard. I mentioned sort of the demographic profile of—of who it is that we work with. And it is very isolated and it's only around conferences. Um, do we come out in groups, we—we tend to really be heads down, but when conferences roll around, it's an opportunity to loosen up and to, to let go. And so one of the things I found really helpful is to leverage those conferences as an excuse to have, um, generative thought to—to find people. Oftentimes they tweet or post on LinkedIn, "hey, I'm going to this. Um, does anybody want to meet up?" And to find a—a perfect stranger to say, "hey, I'd love to give you fifteen, twenty minutes of your time." Uh, I was so successful at really leveraging those events to say, "hey, I'm going to be at this booth in between section two and session three. Come find me. There's an interface I want to walk you through, or there's a concept I want to talk with you about" and was setting up a practice—a practice of finding what is a demographic that is immune to recruitment. You can't get SOC analysts or sysadmins to click on a link to take a survey. The—the penetration wall is too thick, so high. But yeah, you—you—you can get in in dozens in repetitions, people at a conference to come spend some time with you if you reach out to them with a genuine need and vulnerability to say, "I'm trying to figure out this workflow, could you give me some feedback or some insights on how you like to do it?" And that goes with the networking events. And to make those relationships at the O'Houlihan's bar in the Circus Circus Hotel. You know, these really horrible ways that we try to engage with one another, but to be present and to be open and to use these kinds of gatherings as a great way to start to do research. I found that was—was the most effective path when I worked with npm. That was different. Everybody wanted to help and it was—it was a different set to those were all front-end developers and they were—um, they were much more forward facing. Um, but those who are behind the scenes in the infrastructure side, they're much more reclusive and hard to—to reach. And so that again, coming at them from a point of vulnerability and a point of need of like, "really, I'm trying to figure out this workflow. I would love to hear what you say about it." Um, is—is something that —and by the way, here's an Amazon gift card for your time. Go—sure, go, go find something that you like. Um, yeah, I think that—that is, is a great way to do it. And we can't just assume that because we've typed in a prompt that we've gotten the right answer. That's—that's not the path to success. It's a—it's a start. Um, but to also allow yourself to have a couple different directions, even if they're paper prototypes and low fidelity and to say, "okay, well, where does this feel right? And where would you go from here?" to be —um, in the case of FireTail, you know, to be humble enough to say, "this is a tool that's amongst many tools and I need to understand where you're coming from and where you're going to," uh, so it's not just this—this brand that—that I'm trying to, um, you know, I'm trying to massage. It's really, how can we be utilitarian for you?  

I think that's great advice. And I certainly know what I will be nudging my team towards trying to get out of the visitors.  

Yes, yes. Strong wink on that. Uh, hope you don't mind the pun as we, uh, as we wrap up and, and hope you take away from this episode the concept of woodpecker data on your screen. But please, if you are the similar vintage to me, I, uh, I hope you can get the idea of Woody Woodpecker's laugh out of your head from those Saturday morning cartoons. It was one of the most annoying sounds in all of cartoon history. But with all of that said, I will say thank you so much, Nick, for taking the time to join us and to talk about, like I said, an area that we all live with literally every minute of every working hour of the day and so often gets overlooked and is kind of an afterthought in the products that we use. We always focus on the data, we always focus on the data, but that user experience and getting the right interface and the right displays is so, so important in these tools. Nick, thanks again for taking the time to join us and for sharing your expertise. Thank you.  

Jeremy, awesome. I'll see you—I'll see you at RSA.  

Sounds great. And we will talk to you next time on another episode of the Modern Cyber Podcast. Bye for now.  

Bye bye bye.  

‍