Device Control - VMware Carbon Black
The Project & My Role
Device Control is a standard feature for cybersecurity products, and one that has been very heavily requested from our cloud customers. It gives customers insight into external devices in their environments, and gives them the ability to manage access to the devices. This was a new feature we were bringing to the platform, which was an exciting challenge for me as a designer - I got to build the whole experience from the ground up. I led the UX effort on the cross-functional team from start to finish — doing initial research to understand the problem space, several iterations of research and prototyping, facilitating conversations about scope and tradeoffs, and working side-by-side with the UI engineers to bring the final designs to life.
Initial Research & Requirements Gathering
Several other development teams and UX designers had worked on device control previously, so most of my initial research was going through their old designs and research to see what I could use. There were several moderated studies that had been done previously, which was incredibly helpful for learning the things the customers really cared about. I also looked at our competitors to see how they were handling device control, especially to get a sense of how best to make sure this feature would be scalable for the future. Our initial requirements included blocking USB storage devices and providing customers with the ability to create rules to allow access to devices individually or in groups (allowing an entire vendor, etc). Our limited scope for our initial GA release meant that we were first handling USB storage devices (thumbdrives, USB sticks, insert-your-colloquial-term-here), with other types of “devices” — printers, cameras, cellphones — coming later.
User Flows
User Goals
Prototyping
I started with designs from the designer that had worked on Device Control before me and reworked them to meet the new scope of the project. I also worked with the sensor team to figure out exactly what information we were getting from each USB device so I could figure out what information would be helpful for customers to have. We initially designed a small set of features for a closed beta, and then expanded the features (like creating rules to allow groups of USB devices) for the general release. We went through a few versions, and after doing initial user research and lots of discussions with engineering, we ran into a few problems that we had to solve in further versions.
An early concept wireframe showing blocking & approving actions and statuses
Validation Research
Luckily, because we had previous research and a lot of market research from the Product team, the only research we really had to do was to validate the current designs and make sure they made sense to our users. We also wanted to know, though, if we were delivering enough value. We did two rounds of research for the general release.
The takeaways from the first round of research were fairly consistent - users were excited about the initial set of features, but there were a few things they found confusing. There was confusion about the security posture and if the USB devices were being blocked by default. There was also a lack of understanding of the approval process and how creating approval rules worked. I addressed these concerns in multiple ways, adding an “approved status” column and a section at the top of the page with the policies where blocking was on listed, as well as clarifying the approval process. The second round of research showed that we had improved the understanding of the problems, which was great. The users rated the ease of use at a 7.5/10 (average) and how closely it matched their initial requirements as an 8/10 (average).
Device Control inventory page - final
View of a device control blocking event alert - final
Development
Overall, development for the beta and for GA went well. We had to make a few tradeoffs when engineering discovered a few problems building the GA release. One of the biggest was the feature that allowed customers to create approval rules for groups of devices. The problem was that there wasn’t a clear cut way to pair vendor IDs (a hex ID that the USB vendor assigns to their USB devices) with their assigned vendors, because sometimes vendors had multiple IDs (Sandisk has two and Kingston has 3, for example). I had initially designed an interaction where users could search for a vendor name and it would automatically fill in the vendor ID, but unfortunately that wasn’t possible. I presented a number of options to the team and we decided on a middle ground that was still a usable experience but able to be developed in the timeframe.
Takeaways
This project was a great example of communication and cross-functional work. We had multiple engineering teams working on this feature and keeping everyone coordinated was a lot of work. It was also my largest project to date being the UX lead on, which was exciting. There were some tough conversations with Product and Engineering advocating for the users and the best experience, which was a great learning experience for me.
There is a lot that we can build on for Device Control in the future. Bringing in other types of devices means we will have to create classes of devices and rules based around that. Adding granular control capabilities (being able to allow storage devices read-only, for example) will be another task. However, getting the first version of the feature released was a great accomplishment for the team and company, and I was thrilled to be able to lead the charge from the UX side!
“We received the USB device announcement and have implemented the blocks and approvals. Very slick and intuitive how this features just kind of crept in. The best part is that it just works out of the gate.”