Multiple Dashboards
Role: Lead Product Designer
Summary
Signal Sciences is a web-app security company that protects websites, web apps, and API’s from hackers. Our product allows users to customize rules, monitor traffic, and act on threats across their entire org. The console is organized by corporation (corp) and then by site (workspace). Users can access different workspaces based on their permission level.
Problem
Each workspace has a default overview dashboard that gives our users visibility into how their apps and websites are being attacked. Our users can monitor different types of traffic, flagged/suspicious IPs, and most attacked URLs. A customer might have as many as 5 different devs monitoring different aspects of the same workspace, and allowing them to customize their overview would reduce a lot of friction in their day to day workflow. The number one request we received from support tickets was that customers wanted to customize and save different dashboards so that their dev teams could have a more granular view of the data they were tracking.
Default overview before
Process
I met with my PM and we went through the support tickets and flagged similarities between them. Together we made a list of project requirements and after reviewing them with the engineers I started my wireframes. This was an MVP but I wanted to pump as much value in as I could. I didn’t want the users to create a custom dashboard and just be staring at a blank screen prompting them to add a card. So I started looking at different pages across the console to see what data already existed on other pages that we could surface as part of the custom dashboards project. I wanted to create a library of system cards that the user could choose from to add as well as the option to create a custom card. During my digging, I found a list of attacks from top countries on a page that was being deprecated and was able to create a new card for the library.
Solution
You probably figured out from the title of this project that the solution to the problem statement was to create the ability for users to add custom dashboards.
Users needed to be able to:
Create/edit/delete dashboards
Create/edit/delete custom cards
Add system cards
Copy a dashboard to another workspace
Move cards around
See a monitoring view of the dashboard on a TV
That’s a lot of actions for a user to take in a small amount of space. SigSci customers are not frequent users, normally they log in when something is wrong (aka their site is being attacked) and under a stressful situation. I didn’t want the user to be distracted by a bunch of buttons all over the dashboard calling for their attention.
Final comps - workspace overview
I created a small icon button bar for the header of the top 3 actions a user would take while viewing a specific dashboard (edit, copy, monitor view). I changed the IA of the page so that everything that impacted the dashboard you were looking at was grouped in the header. I also added an icon next to the title to change dashboards. Clicking on that icon opens a modal where the user has the ability to create a new dashboard, set a favorite, or change dashboards.
Final comps - dashboard button bar
Final comps - dashboard switcher
Final comps - add dashboard
When adding a new dashboard the user can set a name and choose from a list of system cards (this is the library I mentioned earlier) to add. Once they click create, they land on their partially constructed dashboard (this was done on purpose to encourage users to add cards after trying the new feature) and are able to add custom cards and set the order of cards to whatever they like. I didn’t include custom cards in the add dashboard flow because they require an extra step from the user to build the card. I didn’t want an endless stream of modals and thought it would be overwhelming (to the user and myself) to add multiple custom cards at once while still in the middle of creating a new dashboard. Having the custom card action on the dashboard itself and not in the modal allowed us to have a more efficient conversion path by keeping the user focused on one step of the flow at a time.
Final comps - custom dashboard
Final comps - add card (step 1)
Final comps - add custom card (step 2)
Learnings
The hardest part of this project was trying to balance the prominence of the controls with the importance of the information. As you can see, there are a lot of interactions in a very small space. To do it all over again, if I had more time I would have liked to make the library of system cards more visual. I think there’s an opportunity there to delight the user, but we didn’t have the time or resources to complete it.