REPORTING FEATURE
My Process for Improving Industrial Defender's Reporting Feature
Team
2 Product Managers
1 QA Engineer/Developer
1 Designer (me)
Role
UX Designer
Visual Designer
Design Methods
Interviews
Paper Wireframes
Workflow Diagrams
Wireframes in Adobe XD
Card Sorting
Tools Used
Adobe XD
Adobe Illustrator
Draw.io
Excel
BACKGROUND INFORMATION & CONTEXT:
Industrial Defender ASM:
Before I go into detail about my process of improving the Reporting feature, I think it’s important to give context about the product that this feature lives on. The Reporting feature is a part of the ID ASM, which stands for Industrial Defender Automated Systems Manager. The ASM is an asset management tool that allows users to see all of their assets on a single application, how they change over time, and their risks and vulnerabilities.
Reporting Feature:
Reporting was an existing feature within the ASM and the design of the page hadn’t been updated since 2012. The purpose of the Reporting feature is to present asset data in a condensed format. Additionally, the user is allowed to select which asset they would like in a report. Depending on the type of assets that the user is managing with the ASM, they will have a variety of security standards that they need to comply with. This feature is useful for showing auditors that all of your assets are in compliance with their respective security standards. However, users had a lot of complaints about the menu for this feature so I knew that one of my goals for this project was going to be improving the navigation. Going through an audit is already a stressful experience so I didn’t want this feature to be adding to that stress.
STEP 1: UNDERSTAND
In order to better understand what the reporting feature was, and what it’s used for, I met with the engineer who created it back in 2012 and read Industrial Defender's user guide chapter on it. After gaining a better understanding of the existing feature, I interviewed a product manager to hear more about customer complaints about the feature. Then I interviewed a software engineer to understand some of the technical constraints and also learn things they disliked about this feature. In an ideal situation, I would’ve had the opportunity to conduct first-hand interviews with customers. I also would've liked to observe how customers use the feature with user testing but user testing is not something I have been able to add to the Industrial Defender process yet due to a lack of budget.
Key Takeaways:
After conducting these interviews with Industrial Defender employees, the biggest takeaways were that the menus are too close together so it is easy to accidentally hover over the top menu. The double menu is confusing and sometimes users think that it is a continuation of the main menu. It is difficult to generate a report because the menu has so many nested levels and the button for generating a report is at the lowest level of the nested menu. Additionally, if the user moves their mouse too quickly they will lose their place within the nested menu and have to start their navigation all again. Given all of that information, I was able to identify that the main problem with this feature was that the layout of the page makes the workflow for generating a report difficult and frustrating.
STEP 2: DESIGN PLANNING
Now that I was able to synthesize the main pain points that both users and Industrial Defender employees experienced and knew about regarding the Reporting feature, it was time to start the design planning phase. One of the pain points was that the menu had too many parts. Given that the menu had too many parts because a lot of the categories had repeating report names within them, I knew that I wanted to reorganize the information in the menu first. To start reorganizing the reports, I planned a card sorting workshop activity with one of the product managers that had a better understanding than me of all the available reports. Given that this activity was done remotely, I used excel and listed out all of the available reports, ignoring the duplicates. When I was listing out the reports I grouped them together by type because I knew that there were only 3 report types which would already decrease the size of the menu. I knew that this organizational structure would make sense to the users because when they buy the product they specify which types of reports they want, either Standard & Vulnerability, Compliance, and or Custom. After preparing the document I went through the report titles with the product manager and tagged each report with the type of data that it produces. After this activity, I was able to create new categories for the report menu based on the report types and I created subcategories based on the data produced by the reports.
New Report Categories and Sub-Categories:
Report Name 1
-
Basline Data
Report Name 2
-
Baseline Data
Report Name 3
-
Baseline Data
Standard &
Vulnerability Reports
Compliance Reports
Report Name 1
-
Basline Data
Report Name 2
-
Baseline Data
Report Name 3
-
Baseline Data
Custom Reports
Report Name 1
-
Basline Data
Report Name 2
-
Baseline Data
Report Name 3
-
Baseline Data
Sketching:
After establishing the new categories and sub-categories, I started sketching to quickly work through ideas for a new layout that utilized these new categories. However, after seeing the new layout sketched out (left picture) I was nervous that the page was going to look too different from the original and that it would be a jarring experience for the users. So, I created an additional sketch that didn’t utilize the new categories and looked similar to the original page (right picture) but didn’t have a nested menu. I showed both the sketches to the Product Manager and he preferred the new layout over the similar layout because he wanted to get rid of the duplicate reports. After thinking about the sketches a bit more I picked the new layout sketch because I thought it solved the problem I was working on the best.
New Layout:
Similar Layout:
Workflow Diagram:
I created a workflow diagram and presented it to the team so we could come to a consensus on the workflow before I spent a significant amount of time creating wireframes and mockups. I like to be efficient with my work so agreeing on the new workflow or visual design in the early stages is something that I always like to do. It's helpful because if I get feedback from a product manager or engineer that the new design isn't what they want or that the idea takes too much time to implement, I haven't spent a significant amount of time yet in the later steps of the design process.
STEP 3: High Fidelity Mockups
A Quick Disclaimer: the reason that the style of this page looks very different from the original is that between when I started working at Industrial Defender and when I worked on this project, I created a style guide for the company and these mockups were created based on the new style guide.
So after agreeing with the team about a new workflow, I started bringing the idea to life and this is what the new Reporting page looks like. The problem I was trying to solve was that the layout of the page made the workflow for generating a report difficult and frustrating. I think that the changes I made helped solve that problem because with this reorganization of the categories I was able to make the generate report button readily available to users.
Prototype:
EXPLAINING DESIGN CHOICES & REFLECTING
Eliminating Nested Menus:
I’ve discussed how I worked to reorganize the menu to have less categories because the large menu was a pain point for users. However, even with fewer categories, I felt like based on other complaints about the Reporting feature, that it was best to stop using a nested menu for this feature. The nested menu caused issues for the users because it was easy to move the mouse a bit too far and then lose your place within menu causing them to have to start your navigation all over again. Additionally, with the options being so close together, the user would sometimes click on the wrong action item at the end of the menu which again was frustrating. With the new layout, users have to click on an item first so they don't have to worry about losing their place is they hover their mouse a bit too far. Additionally, the action items for generating a report, and managing a subscription are separated by columns so it less likely for the user to accidentally click on the wrong one.
Make Key Actions/Info More Accessible
With the old layout, some users reported being confusing about being greeted by a blank page with a double menu when they clicked on the reporting button in the main menu. Some users thought that the page was still loading and others thought that the experience was weird. Additionally, if they were using the menu to navigate to the Subscriptions page for a specific report, it was hard to remember if a subscription for that report already existed. So, it was a request to show the subscription count on the Reporting page. With the new layout, the default view shows the report names for Standard reports that produce Actual data in a table format. Additionally, there is a Manage Subscriptions column which shows the number of subscriptions associated with a report and also functions as a button to navigate to the Subscription Management page. I chose to make the numbers blue so it could signal to the user that it is clickable because the color blue is used like that consistently around the rest of the ID ASM.
Reflections:
Overall I really enjoyed working on this project. The biggest thing I learned from working on this project was that it is okay to completely change the layout of a page. Previously, I was hesitant about doing that because I was worried it would be a jarring experience for the user. After seeing how well the changes to the Reporting feature were received by people who have used it in the past, I’ve been able to tap into my creativity, even more, when coming up with design solutions for other problems within the ID ASM.