This is a continuation for developing the user interface for my fourth year design project Inara. Part 1 can be found here.
Controlling the User Interface
As part of our project, my team has been working with an industry partner who focuses on security software. During discussions with our industry partner, we found out that it was essential to provide the user a large amount of control over the data being presented. Since our users are already network security experts we needed the ability for them to filter the UI in order to find what they were searching for. As an ideal case, we should build the entire user interface to be customizable according to the information the user requires. Due to the time constraints the team could not achieve the goal while also building the machine learning algorithm. Instead the team decided to use visualizations and make them intractable in order to filter the data being shown. The ability to filter would hopefully alleviate the issue of cognitive overload with the amount of data being displayed.
In order to prototype and test potential UI layouts in a functional manner the team used a subset of our data along with an online tool called Microsoft Power BI. A screenshot of the prototype is shown below but an interactive version can be found here.
This prototype was built using a subset of the same data that would be available to the final user interface. The interface was laid out in order to provide the majority of the data visually. Based on literature research and conversations with our industry partner, we believed that representing the state of the network (good traffic vs bad etc) would reduce the cognitive load required to perceive the state or any threat. Clicking on either of the pie charts (Normal vs Attack Traffic or Traffic by App Name) would filter the entire view in order to only show the desired type of events. The aim behind this is to give the user some level of control over the UI until the point a fully customizable UI is possible.
User Testing
Note: This user testing was done as part of my FYDP so I do not take individual credit regarding the interviews. Any conclusions drawn here are entirely mine and separate from my contributions to my FYDP group.
In order to get user feedback the team did a user testing session with a handful of users followed by an extensive interviews. One of the things we found that is that most people did not attempt to click on any of the interface elements. This went against what we expected since we believed that most users would indeed attempt and click on the UI. During the interview portions we found that most people did not even realize that the UI was indeed interactive which came as a surprise. In order to fully utilize the potential of the UI, we need the users to be able to control it and mold it into something they are comfortable with it. The two potential reasons I think that most people did not click on the UI are as follows:
I believe that the first one is unlikely due to the line graph at the bottom having an overlay when the users hover. I believe that the second one is the potential culprit. In most software (especially websites) a clickable element is often followed by a trigger when the user hovers over it. This trigger is usually in the form of a hand with a finger prompting the user to click on the element. Due to the functionality of Power BI, this did not exist on any of the clickable elements the group created and thus lacked triggers. I believe that adding these triggers to all elements that can be interacted with would help immensely with this issue.
Following this set of user testing the group is moving to build a fully functional prototype that would work with our machine learning model and we hope to run another round of testing once the UI is complete.
