5 Critical Components of Product Design for Cybersecurity
A Pre-RSA Virtual Fireside Chat
In this webinar, Todd Marks, CEO, Ben Slavin, SVP of Strategy and Design, and Brian Thompson, AVP of Engineering, share principles and best practices for creating exceptional user experiences and improving the success of your cybersecurity product.
You'll learn about core fundamentals of product design that are often overlooked in the cybersecurity space, leaving great opportunities to grab more market share for those who embrace them.
Watch the recording or check out the transcript below!
We're talking about the five critical components of product design that cyber companies should embrace. We're going to get into the pain points for cyber companies and product design solutions, and we're going to talk about some case studies throughout.
And therefore, one of the top industries that we work in is cyber. We're happy to share a lot of the experiences that we've had making and marketing software for that industry. Let me first introduce our esteemed panelists. I'm joined by two colleagues.
We have Brian Thompson. He's our Assistant Vice President of Engineering. Brian will give his perspective as a user of security software. We also happen to have a site license, and Brian is actively taking over being our Security Officer, which is super exciting there, too. We also are joined by our SVP of Strategy & Design. Ben Slavin. He is going to discuss some important things to consider from a UX and design perspective.
And last but not least, I want to thank Kim Paradise. Kim is the Engagement Director for our Cybersecurity vertical. We know there's an issue in cyber security, not an issue in cybersecurity itself, but an issue in creating software for cyber security. So Brian, as a cyber security professional, I know you work with a lot of different software products. Why would you say that there is a challenge with the user experience of those software products?
As we look at the cybersecurity industry and what I am responsible for and protecting both Mindgrub and all of our clients, we've got a number of different tools and pieces of software out there–but inherently, we're in an industry that is tough to find talent in.
You and I know have gone back and forth quite a bit about how difficult it is to find talented people who can respond. Because of that, we spend a lot of time training our new people and bringing them up to speed. And because of that, the interface that our teams work with and that cybersecurity software has to fill needs to appeal to a really wide audience. You've got those who have been doing it for a while and who need the nitty-gritty. But you also have to deal with those people who need to get things done quickly, and it's easy for them to pick up if they're not familiar with that software. Generally, cybersecurity software is very utilitarian, and it's not just cyber. It's across the board in many cases. But cyber security is one of those industries where the attackers never stop, and in some cases, if we get it wrong, there are lives or people's livelihoods on the line.
I also think it's got to have something to do with the composition of talent, too, right? Like most of the people that I know who geek out about cyber–they’re the engineers. Speaking to Ben's kind of creative team, user experience, and design professionals–they want to design the next Nike shoe. So do you think there's also a little bit of a shortage of users or experienced professionals in that industry?
Most definitely. Cybersecurity departments are normally not just understaffed but also under budgeted. Therefore, they're trying to bring in people who are focused on the more technical side of things and less on the user experience side. We’re a department that lives in the background if we do our jobs well. The customers of Nike have no idea that there's a cyber security department there, keeping them safe on the back end.
As soon as there is a software interface, Brian. You had mentioned that there's a lot of engineers at play. They're just trying to work fast and try to get the, you know, quickest-to-market interface that pulls the data because they're very used to looking at data, right? This comes down to logs of firewalls–they're just looking at data. But what we've experienced is that that speed in which you can act on the data absolutely needs solid interface design. We talked about the 5 biggest things to consider. Why is it so important? Why is UX–particularly in cyber–so important?
First, I want to start with the foundational concept that design is about more than just how something looks. It's about how it works. When people talk about user experience, they're talking about how it works. They're talking about things like attention to detail, and a number of the different points that Brian was talking about. What is the fit and finish of the product?
When somebody thinks about your product, the design really enables all of the interactions that take place. Whether it's a good design or a bad design, your system is designed–whether it's an engineer who did it, or whether it was someone who is a UX professional–and that's actually one of the things that I love about the team that we've built. I'm a computer engineer by trade and work very closely with our design team to make sure that we're thinking about these core elements which we'll get into a little bit more in just a couple of minutes. But if your software is complex, it's complicated–if it's inconsistent, if it's confusing, that's what people are going to remember. If even the pros can't figure out your product, it doesn't matter how smart or sophisticated the algorithm behind it is, because humans can't use it. The experience matters, the user experience matters. It is what makes it possible for people to use the software. As I said, it's what they'll remember.
But more than that, there are business implications here, too. A strong user experience is why they'll choose your software over the software offered by a competitor.
It's why they'll continue to use your product and it's why they'll refer you to other customers. So it's easy to talk about design and user experience as a nice to have, but they are the difference maker and a fundamental part of competitive business strategy when you're looking at a cyber security platform or piece of software.
Everyone's a consumer, too, and consumers are so fickle about that design. Look at the difference between Tik Tok and Vine. Vine was Tik Tok years ago, but they didn't have a great AI algorithm and hadn't progressed as much, and now Tik Tok is the number one app in the world.
You're exactly right. The customer expectations are set by experiences they have as consumers themselves, and the value that you can derive from user experience. For example, Uber prioritizes the driver experience. They prioritize the user experience of their drivers, and if they were down and out in 2017, they are back now because they prioritized it in a way that Lift didn't. Those consumer companies are leading the way and setting expectations that carry through to business software. Cyber software
How many of you feel that you know your user experience could improve on your software? And maybe your software is difficult to use?
We do sometimes hear, “No, [the software is] great,” and occasionally it's true, but usually it's just because you're not talking to your users, and I think that that's one of the first recommendations that we have. Talking to the humans who will use your software is incredibly important because they will find ways to use, break, and misunderstand your software in ways that you didn't consider. So if you talk to users, if you talk to humans and do the research, it makes a huge difference in terms of setting the direction.
When we build software, or when most people build software, it's easy to imagine that everyone thinks like you do. And it's easy to imagine that you understand the problem space, and it is hugely important to have a vision for what your product should be, and what difference you can bring in what problem you can solve. But people are creative, you know. They will find new ways to use your product. They will find new problems to use your algorithm to solve. And so it's important to talk to those customers. We really prioritize sitting down doing stakeholder interviews with our customers, but their customers as well.
What does the business enable? What does the technology enable? What does the business need to succeed, but also what do users desire? What do they want? What are the problems that they're trying to solve? And what are the other products that they're using?
This might sound like business strategy, but it's a fundamental underpinning of design strategy as well. Customize and tailor that user experience by understanding the users who will use the software. User research is a fundamental process–a fundamental step in the process.
People will skip it because they think they know their customer where they've been the customer before, but it only takes a few interviews to really radically change your understanding of the problem space and the people who will be using your software. So it's something that we always recommend to be included in a product design process.
They think they know exactly what the feature set should be, and I remember a past client, Wendy's. We built their mobile app, they came to us, and they heard that we were the best in making mobile apps. So they wanted to work with us. They're based out of Columbus, Ohio. The first thing that they did was tell us all the functionality that should go into the application.
And we said, “You have a wide demographic of users. You have a high net worth. You have lower socioeconomic, you have urban, you have rural. Are you really sure they all want this feature?” And at the time they thought they were going to go after corporate America himself.
You could go to all your colleagues, take their orders under one account, pay for it, and then have different bags, and tray totals. That’s what their system did.
We said, “Listen, let's test everybody.” So we tested urban, rural, lower, and upper socioeconomic. We actually sat in Wendy's as customers came up. We asked them if we could talk to them. We showed them some different functionality for applications. We basically pulled their users, and across the board they wanted the same 3 things.
They didn't want to have to pay in cash or credit card right? They wanted to have digital means of paying. Obviously, you see that all over the place. Now, this was a handful of years ago.
Now, there's been a huge resurgence, and they're one of the most popular fast food chains. But the brand was kind of dying out a little bit until they really analyzed their users and figured out what they wanted, what the market wanted. They went through and redesigned all their stories, their kiosks, their websites, their mobile applications with our help. That’s definitely a great example of doing user research.
Brian, what do you think on the user experience side as a cyber security professional? Do you wish that people were asking you about features?
I always take the time to fill out feedback forms. I think a great example is going through the airport after you go through TSA. They always have those little kiosks where you can push a button for a smiley face or a frowny face. Even something simple like that in your software can give you ideas as to where to focus. Your software might be pretty large, and you sit down and try to talk to me about what you can improve. You can't ask broad questions like that when your software is enormous, especially to somebody like myself, who is a fairly busy security professional. We need to stay focused on figuring out what the key areas of value are to do that user research.
You don't have to do the whole thing at once. Focus on a core area, get feedback, iterate on it, and move on from there. I think the other side that I always tell my engineers when they're working on things is, “Close your eyes and try to use your application. If you can navigate through the forms without looking at them, that's a clear sign that you know too much about your application, and you're not taking into account the fresh user perspective of trying to figure out what fields are required.” Where do I go for this? If it's muscle memory for you to fill out you're never going to catch the fact that the user experience is wrong.
You made a really good point about learning things that aren't needed. User research can prevent you from wasting money developing features that users don't want.
There was a company that we were looking at, and they thought that the cinder block is the most important piece of information that our users will want, and they had to figure out how to get it from over here to over there, so they could present it to the customer.
Customers didn't care, the users didn't care, and they almost wasted 2 sprints worth of effort
going down the wrong path for a feature that wasn't valuable. Again, we're talking about design and user experience. These things solve business problems, and they actually impact the success of the business. I think that's really important to remember.
We'll have to do a follow up on the whole agile software process, too, which allows for consistent testing and changes every sprint, which is generally every 2 weeks. You can keep pivoting the direction of the software. I think the Government is still doing a lot of waterfall processes where they are building a Bohem over months or a year, and then finally, just putting in a production, starting, using, giving that feedback, and it's feedback loop is still once a year is not week. We could definitely talk about that feedback loop and getting that research not just upfront, but throughout the application for a while.
Originally, years ago, you couldn't shop as readily as a disabled user, so they need to make sure they have screen reader access, right? How is accessibility from a software perspective?
I think what's important to keep in mind is that in the United States one in 4 people have some form of disability, just over roughly 26%. If your security team has 4 people on it that means statistically, at least one of them has some sort of potential issue using your software.
We think about the stereotypical hacker scenes or the cyber security scenes where it's just logs flowing across the page, and you don't consider that could have impacts on people with disabilities who need accommodations to be able to read that. Maybe because it needs to be slower or the colors don't match, because we are lacking contrast.
The software that we build in my room for a Cybersecurity company is to do all of the world out there for our customers. Making sure that it's accessible to everybody is something that is critical, that we build into the experience, and it's not something that can come after the fact. It starts at square one because of the large majority of people out there who have some form of disability, and we do that with our dedicated testing team who are experts in that field who know how to use that software. It's not just, “Can I adjust color contrast, or is the font size right?” It's about motion on the screen. It's about being able to interact. If you can only interact one-handed, take the accessibility sign out of it. Cybersecurity is an industry that never sleeps. If you get an alert in the middle of the night when you're woken up, do you want something complicated where you have to push a bunch of buttons and respond quickly? Or do you need an interface that requires minimal interaction? One that presents content easily in a way that's very readable that is accessible to everybody.
I think the cybersecurity industry is responsible for dark mode. You see that there are a lot of applications with the light mode and dark mode. I was amazed to learn how many people have color blindness. So accessibility can be as simple as just the colors used, and the contrast between one color and the other, like text and background. Then, when your team designs the application, how do they really consider accessibility?
We have a number of different tests that we do. We all perceive the world differently. I think Brian made a great point about some of the specific cases, but these issues that we talk about when we're talking about accessibility–they range from cognition and understanding to interaction, and there is a tremendous amount of scientific research behind these things. So it's not just a designer saying, “These colors look good together.” We have contrast ratios that we are checking in the field of human computer interaction as a target size that is easy for humans to touch. We’re checking distances between buttons to ensure that you don't accidentally quick delete, when you meant to click save. ADA has a number of guidelines as well, and depending on the specific platform that we're on, there are a number of human interface guidelines as well. We make sure that we're thinking about all of those things. And I really think that these decisions about accessibility make it easier for all humans to use the software because we're thinking about things like, “What are the ways in which things might go wrong? What are the ways in which this might be difficult for someone to use or understand what we're trying to communicate, and is there a lot of information overload here? We need to be thoughtful about it. How do we provide clarity? How do we provide clear boundaries between things? That benefits users who need those accommodations, but it also benefits the software product as a whole. So, as I said, we have a number of checklists that we use. We have a number of organizations that have done actual scientific research that we then incorporate into the design of applications.
How would you say that intentionality is important?
I think that this is one that is often overlooked. Intentionality is about making sure you understand the problem space that you're trying to solve. How can you be intentional about enabling your users to solve the problems that your software is designed for? We know navigation is a critical element. How do I get to the place that I need to be from where I am now? I understand what your software does, but I don't have it memorized. Maybe I don't use it every day. So how do I achieve my goal? We can enable that by thinking about navigation design. Those paths, those journeys. It's not just the primary navigation. It's things like secondary navigation or courtesy navigation.
So you might have the header or the bar along the side. But when I'm looking at a record, sometimes there is tangential information that I want to look at. Sometimes it makes sense to add a path to navigate, and we were talking about network analysis previously. We want to think about how people will use the software and make sure that we are doing that.
Software is about meeting the needs of your users. One of our clients is Dragos, and we've worked with them and built their marketing website. We did a lot to understand the personas, the users of that software, the site and the sort of the arguments we needed to make to help someone understand. And thinking about the mental model where someone was as they went through made a huge difference in the decisions that we made.I would encourage you to check their website and look at that navigation at the top. We were really intentional about how we segmented, how we spoke to the different audiences; how there are a couple of different ways to get to the useful information and intentionality is also about simplicity. Sometimes the right answer is about doing a lot of applications. As I said at the beginning, I'm a computer engineer. A lot of applications end up being designed by engineers who throw in all the functionality and don't necessarily think about the end user. So how do you simplify that? How do you make it easy to understand, “What am I looking at, and what can I do with that screen?”
Some of you may be familiar with the nuclear attack alert that went out in Hawaii a number of years ago, and there were images of that that went around social media. It wasn't clear what you were doing or why, and if you were running a test and simulating versus sending a real warning to everyone's cell phone about an imminent nuclear attack. It looked the same. So thinking about simplicity and intentionality, making it very clear what's happening, and what you're doing is incredibly important.
The last thing I want to talk about here is just a sense of customization. This is something that we sometimes recommend, and sometimes don't recommend. It really depends on your specific scenario. Sometimes it's valuable for someone to be able to customize their own dashboard, collect the things that matter to them, or to enable or disable certain features within the platform based on their own specific network, configuration or software configuration. And so I just want to include an intentionality.
Sometimes it is about giving people options to customize, but usually that's 3, 4 or 5 things they can customize–not a 500 check box list of different options you can turn on and off, which becomes so overwhelming that nobody uses it–or people use it, and they don't remember why it's behaving that way because 500 check boxes is too many. Encourage intentionality in the design of your software so that you can understand it, and your users can understand it and what they're doing with it.
I like that–customization versus personalization. Customization is allowing the end user the control, right? For example, users want to tell you what their best communication channel is. They don't want you pinging all of them, or they might block them all, and then you can't get them on any channel. Personalization is where you use algorithms and you use data to know who the user is so you can then send them information you think is most important, which is very helpful from a marketing perspective and for websites. But why wouldn't you want to do that from a software perspective?
I think Brian made a great point about it earlier. You might wake up in the middle of the night and have to deal with a situation. The last thing you want to do is find the next button, and personalization changes the interface when you're not asking for it. Sometimes we will recommend some sort of adaptive or recommendation, adaptive algorithms or recommendation systems as part of an interface. But you put them in a consistent place, and you label them appropriately, so that a user knows what they're expecting. We don't want to try to predict and change something on you at a critical moment by trying to personalize and be smart or too clever about the interface.
For example, in one situation we did force storm surge mode on a mobile app. Brian, can you tell us a bit about the storm surge mode?
When you think about having a natural disaster hit a particular area, everybody's checking to see when their power is going to be back on, or people are just looking at the outage maps, and you have in many cases national media attention. So you have a lot more traffic hitting your systems than normal. There is an aspect to overriding that and kind of protecting your critical systems by forcing people into the workflows that you need. In a security and cyber security focus system we have to strike the fine line between getting people the information as they need it and elevating what is personalized to them in that moment versus also giving them the customizability to see what they want when they want. So I think the worst thing would be to have something that personalizes in the wrong way.
For example, if an alert that is actually critical gets missed or fires incorrectly. I'm sure plenty of people have had false positive alerts go off, and if you have too many false positive alerts, then you no longer pay attention to them. You just ignore them. You have to be really, really smart with personalization, and consider all the different aspects of it.
Can we talk about the difference between the needs of federal users versus commercial ones?
The persona tends to be different. If you've got ideas for how to make one design work for both, I'd love to know–maybe a product from threat connect.
I think the first thing is to realize how broad those 2 audiences are, right. There are lots of different federal users and lots of different commercial users. I think one interface that serves everybody is absolutely possible. But I think it will definitely depend on the specific niche that you're in. It's hard to give a one size fits all answer to that. That's why I would say user research is really important. However, there are fundamentals of user design and interface design that will apply to both. Those rules of accessibility that we talked about in the last 2 recommendations that we have as well things like visualization and scalability also sort of tie into this, so we can speak a little bit more to that. The one difference is that sometimes the federal users have stat users, for instance.
I see the Federal Government as a captive audience. Maybe you think you don't have to try as hard because you're not going to lose users. But I'm telling you–you are. You really do need to try hard. because there is disruption in every market all the time. The Federal Government might be a little slower than others as far as that disruption cycle. Ben, you had mentioned 2 other areas of smart use of visualization. I know from experience how powerful this is with our client, Dark Web and Id Agent. They came to us when they were drinking from the fire hose.
Usernames and passwords had been compromised, and they were found on the dark web. And they had a list–a lot of cyber software starts out with a search and results that is the MVP of both cyber software. But then, from those results, we added so much functionality. So what we ended up doing was adding a whole dashboard on top of it, and seeing one of the most powerful things change over time. That list is just a snapshot. But if you can see one of those or multiple those data points over time that all of a sudden adds a whole nother dimension to your software that, I think, is really powerful. What else is around? Visualization can just add another dimension to how you interact with that software.
I love that perspective dimensionality due to the data. There is a tremendous amount of data that flows through these systems and cybersecurity software in general, and finding the needle in the haystack is important. Also, identifying the areas that are worth investigating. Even if you don't know where the specific action took place. Even if you need to know generally where to look. A visual is a very quick way to get there. We talk about visualizing ways to bring meeting to data.
We're all familiar with one or one or 2 levels of data visualization. If you've ever built a pie chart in excel, that's the first level of a database–but they're much more sophisticated techniques depending on the problem that you're trying to solve, sometimes it's just color or size or bold text that will help something stand out. We also have probably about a 1,000 different visualization techniques that we use depending on what you're trying to pull out of the data, what's important to highlight or understand, whether they're things like pre maps or psyche diagrams or or other types of visualizations, and I also think one of the coolest things that that we get to do is sometimes over time, we get to see how things progress. So for those visualizations, if you can explore one of the dimensions, and you can sort of move through time and see how things change–if you can plot that in a space it makes it very easy for an operator to be able to figure out where they should put attention.
I'll also say one of the products that we've worked on in the greater cyber security space is the tech platform from the Army Futures command, and it's an open source product that many of you are probably familiar with. It's used all over the world, and we've built a number of modules there that help visualization, and visualization can sometimes mean putting things on a map as well. So how do you see things in physical space? How do you understand where activity is? Sometimes it means sorting data points, making larger points on a map, and helping to see over time how things are moving or or unfolding in the physical world. Visualization can take a number of different forms. But we are humans who are hardwired to explore the world around us through visual means, and visualizations are a great way to do that. We talked about accessibility earlier. I will say that there are lots of accessible ways to do this as well. We talk about visualization, but even for non cited users there are ways that we can sort of condense information or surface it in a way that is accessible to those users as well.
How important is scalability in software design, and how is it done?
One of the most important pieces to me, as we bridge the gap between the user experience and design side of things and the technical side of things–cybersecurity is everyone's problem. Yes, it's Nike's problem. We talked about that at the start, and how they're indirectly a cybersecurity company. But so is the farmers market lemonade stand that's happening under the Jones Falls during the summer in Baltimore, where somebody is there, taking payments and selling lemonade. Having your software be able to accommodate both the few users and the large users is critical, and being able to scale that. It's not just an engineering challenge.
Certainly more data means more computation, which means more interesting ways to display. We get into visualizations a lot more. It's. It's easy to read a log file with 10 log entries in it for the day. It's a lot harder to read a log file and pull out what's needed with 10,000 log entries in it for the day, or 100,000 or 10 million log entries or more. And so, having your software be able to present what's needed to the users who are on the smaller side is great. Having it also be able to scale with them and grow–to have it be something that keeps up with them is a way to keep a customer happy and keep them familiar with what you're using.
This, in some ways, could apply to the question about federal versus commercial customers as well in terms of scalability. It's clients of different sizes. It's different technology stacks and platforms that you're running on or operating with. But it's also different types of users.
They're larger institutional buyers that will have certain needs and expectations of your product. And there are smaller, more individual market buyers who may be purchasing your software, and especially for those larger institutional or government buyers. What is the reporting that a CEO needs versus an operator? What are the interfaces that they need to be able to see through your software? That scalability is also the multiple ways that your product will be used and thinking about those different personas within the single virus environment–who needs to use it? How do you scale to the needs of someone who uses it occasionally or on a daily basis? And this is something we have thought about. We have a customer in emergency response 911 call handling space, working on next generation 911. How do you design an interface for someone who's a call taker on a daily basis? How do you serve the needs of the mayor during an emergency? Answering calls? There is additional support. And how do you make sure that it scales to someone who doesn't have training, but needs to use the system on a regular basis, and it is absolutely possible–it just takes work and, as we said earlier, intentionality to achieve.
You think about the smaller smaller users or people who aren't as large. They might not have a security operation center running that they need to feed your software into the report. Your software might be the only thing that they have, but as it grows, and as it scales, they're going to want to integrate it with something else to to do that reporting, and so it’s about not just pigeonholing yourself into the larger size or the smaller size, but really scaling with your customers as they grow with the different user types is critical.
The first question coming from our audience, “Is there anything that we didn't have on the list, right? We talked about user research, intentionality, our use of visualization, scalability and acceptability. If you could add one thing to that, what would it be?” The user question that they asked was a good one: “How would you know if your software includes all 5 parts?”
I think developing a comprehensive product strategy is actually fundamental to design as well. You can't design for a system that you don't understand and so think about the long-term roadmap, and make sure that you're thinking about informed user research, informed by intentionality and all of that. Make sure that you understand your user needs, but also the functional requirements. That's the underpinning of a strategy. And it really is the thing on which all design is going to rest. I could list 10 more things about the visual aesthetic, the structure, and the function of the application. Those are things that designers will know to focus on. But I'm trying to think about the things that are often overlooked, and the things that we really encourage our team to focus on, and that foundational strategy–the partnership between a UX designer and a product manager or a product owner really is, I think, foundational and fundamental to building quality experience.
It actually might go back to the first thing. So first of all, you will know if you've done the user research. Have you talked to users? Get out there. I encourage you to do it or to hire someone who can conduct that user research. You don't need to survey 5,000 people, but talk to some people who are actually using your software, and they will let you know if it's confusing or hard to navigate. And then you can decide, “Is that a design problem? Or is it a training problem?” Because there are some problems that are just hard to solve?
Are you using visualization? You can take a look at your application. And are you visualizing now? Are you doing it in a smart way, or the best way? I think I would recommend talking to someone who's an expert in it to understand that. Check the box of whether you're doing it or not. That's something you can answer for yourself in terms of scalability. Again, this comes back to user research. Are you able to serve the needs? You know the executive sponsor who needs the dashboard reporting and the operator. You know those are things that you can take a look at. You'll learn from user feedback, and you can also look at your sales sheet to tell you. Is it scalable? Are you able to serve all the clients that you're targeting and your sales team is targeting?
Accessibility is a little bit harder to self-assess. It's something that we actually offer an assessment service for where we can take a look and provide some recommendations, even though there's a lot of scientific research and a lot of guidance in the accessibility space, and there are formal guidelines. There's still a lot of subjectivity in terms of assessing that, so I wouldn't. I wouldn't recommend just downloading the list and checking for yourself because there are things that you've learned as standard patterns for enabling this accessible design. So the number one answer comes back to talking to your users. If you are doing the user research, if you are listening to your users, that is giving you a huge leg up on product design. However, you gotta do something with it once you ask them. But if you are doing that the rest can fall in place if you're a responsive organization.
Brian. If you could add a 6th and final thing to the hit list of what's really important, what would you add?
My 6th kind of falls under the same product strategy umbrella. Think back. 10 years ago everybody wanted to be Facebook in a different way. And out of all those companies, very few of them actually succeeded. We look at the security and cybersecurity industry. We have a lot of long standing pieces of software in there. Some of them do great things. I remember my early days of working with Nagios for monitoring and alerting, and I think the UX interface is still very similar to what it was back then. Talk to your users. Figure out what they're using. Now understand why they're using it. But don't just copy what their software does, because you think that's what the market is following. Just because somebody's a market leader today doesn't mean they're going to be a market leader tomorrow, and doesn't mean that their implementation is any good. You'll find this out as you talk to people as well, and you compare your software to others, or even just talk to them about what they're using.
It doesn't have to be very formal. We have RSA coming up. There are plenty of other industry events that are much smaller and much more local, where find a person or 2 chat with them, and just get their take and have a down to Earth conversation about what's working and what's not working, and make sure you have reason and intentionality for why you're copying something from another piece of software, if you believe it's important for your software.
I want us to go back to the point that I made at the beginning, which is that design is more than just how something looks, and that that's a big part of it. It's about how it works. And so design is something that solves business problems. Having an engineering team, having a product team that appreciates and incorporates designs is a huge difference-maker. It's why people will choose your software, it's why they’ll recommend it to their colleagues. It's why they'll stick with it when they're using it. If you're pursuing a piece of software that has real business value, you owe it to yourself to invest in the design because it's going to be a force multiplier.
Yeah, I agree. I think engineers will be your best friends in developing software in terms of telling you what they need. They'll be your worst enemy in telling you how it should work.
Todd made a great point earlier. Cybersecurity professionals are the reason dark mode exists. And that might not be great from an accessibility standpoint for some people, so talk to your designers. It's not just colors. It's about how software works, and it will make everybody's lives better.
Ready to improve the success of your cybersecurity product? Drop us a line to get started!