Overview

Enterprise focused re-design

Completed: 2019

My Role: Design Lead

Collaborators: Co-founders, Product Lead, Dev, Account Reps, Marketing

TLDR —

As a small startup's first designer, I re-designed their legacy platform to add enterprise functionality, enable new sales, and create cohesive design patterns. In the process, we landed our largest account to date and were acquired by Fortinet soon after.

Objective

Address known gaps in the product, define a structure for the platform, and enable sales in the process.

Process & Deliverables

Wireframing, Iterative Design, Intercept Surveys, Product Validation, Clickable prototypes, Creating a storyline for sales & feedback, topic research, and auditing public DevOps slack teams

About the Product

Panopta is a B2B monitoring platform used by DevOps teams to create custom metrics, alerting, and communications around server infrastructure. It delivers a complete picture of services, network devices, and applications in any deployment — in containers, on-prem, and hybrid. This makes trouble-shooting quicker for IT professionals and allows them to detect incidents earlier.

The Problem

Strategic definition

When I started, the company consisted of 7 people including the two co-founders, head of product, head of sales, and a dev team. As part of a growth strategy, I was hired to add a coherent design structure and enable sales — with the end goal of being acquired.

As the team and platform grew, people within the industry began to notice our hard work. We got a call from a major global financial services firm — they were leaving their industry-leading vendor and wanted to see if we'd be a better fit. The account would be a huge turning point for our startup,  but the enterprise features they needed were another year out in the roadmap. 

My role was to quickly show the direction of our product and where/how/ if we should address their core needs. We needed to stay true to our existing customers and roadmap in the process. Working with the co-founders and head of product, I worked to find efficient solutions to enterprise needs, minimizing cruft and working in parallel to our existing product.

Redesign #1

Creating an actionable dashboard for server instances

When something goes wrong — DevOps teams want context so they can solve the problem quickly and avoid larger problems downstream. Within larger teams, the mapping of infrastructure becomes increasingly complex and less holistically knowable. 

The instance details page provides an overview of server activity, performance, updates, human interaction, and general context. For anyone that jumps into an incident, this page helps users understand what they're looking at and what role, if any, the instance plays in the problem.

A re-design for this product feature was already on the roadmap, and through discussions with current clients, we'd established criteria for updating. However, any new structure or patterns needed to also be extensible to the rest of the platform and solve common problems as we looked at the enterprise market. 

Through discussion with existing clients, we'd arrived at a set of goals: 

• Surface the most relevant information to the default state
• Make changes actionable within the context of this page
• Get more utility out of visualizations
• Create extensible structure & patterns(internal)

Before

After

Process

Iteration, wireframing, & feedback

After a few collaborative meetings with the co-founders and the head of product, I had the context to move forward with wireframing. I spent time doing basic competitive research and trying to look through adjacent examples for insight.

Throughout the design process, iterations were reviewed as part of syncs between the founders and select customers. The feedback from these sessions would then be communicated to me through recordings, notes, and syncs with the head of product.   

As the work became a little higher fidelity, I began meeting with developers to understand what trade-offs were being made and how best to make the designs performant. Their input saved me a ton of time and opened new options as we moved forward. This also helped me to avoid over-promising any functionality that would be de-scoped. 

Separating signal from noise is complex in an environment like infrastructure monitoring.  It took me a while to get used to the density. I relied heavily on customer insights into what information should be surfaced and the appropriate density/layout of that information.

Production

Going into production

After a lot of iteration and feedback from stakeholders and customers, we arrived at an MVP that we were proud of. As things were built, I did design reviews in a testing environment and used developer tools to capture potential updates to the presentation layer.  Some portions of the project were completed in phases and direct editing was used to later phases as an enhancement. Throughout this process, I'm meeting regularly with developers and the head of product to determine the best path forward.

Getting more out of visualizations

From an analytic perspective, we knew a lot of customers visited the instance details page specifically to see the performance metrics. Removing them from secondary navigation and displaying them at the primary level made more sense.

The previous grid was mostly static. Expanding the view of a chart would create a modal that covered valuable information. It was hard to compare charts that weren't close to each other. So, we added the ability to move visualizations within the grid and expand charts to full width. Charts could be temporarily hidden and comparative charts from related instances could be temporarily added.

Direct Editing

As a second phase in the re-design, we added the ability to directly edit the instance's configuration within the experience, rather than entering a separate workflow or feature. One of the biggest problems our users have is “Tool Soup” — working between too many disconnected tools. So, bringing functionality together under a single pane is a huge win for them. The editing occurred in flyouts or in a side pane, depending on the complexity of the requirements. 

Secondary information

We made some adjustments to what was available at the top level but kept the IA similar. UI for the secondary information was cleaned up to match.

What I learned

Getting Feedback

Most of our customer feedback occurred during the design process. But, I also used intercept surveys during the release to capture any bugs or missing information. The bulk of the feedback was positive, but that didn't help us improve. We did however catch several bugs through this and made some minor tweaks to surface information that we had de-prioritized.

Retrospect

• Data density like this was new to me, but it makes a lot of sense in the context of their JTBD. It took a while to get used to, but I started to really enjoy it. 
• I would have liked to be more directly involved in getting feedback from our clients. However, I understand the risk in B2B customer relationships and that this needed to happen quickly in regards to our runway. Everyone played their role.
• As the only designer, there was a lot of pressure to build things quickly. I would have liked to do some remote unmoderated usability testing with dev before and after release— particularly around some of the direct editing and use of visualizations.
• Visually, there's too much reliance on borders and dividing lines. I wish that I would have solved some of those issues with value differences, to keep the overall design more open. But, at the time, I wanted to make the difference between old & new sections of the app seem less jarring.

Redesign #2

Incident Details — Redesign

When a server fails above or below a metric threshold set by the user, it creates an “incident.” It could be a simple warning that an event has been triggered multiple times within the last few minutes or a critical failure that requires immediate attention. These unexpected problems can lead to service level agreements breaches and lost revenue.

The incident details page gives a snapshot of what metrics triggered the incident, what was happening when that occurred, and who knows about it. Teams need to respond to incidents efficiently to determine the cause, response, and level of threat. 

We identified needs to improve:

• Get more information, interaction, and utility out of visualizations
• The ability to communicate observations and actions with others
• Surface the incident's context, history, and connections
  
• Communicate team structure and process

Before

After

Process

Iteration, wireframing, & feedback

The process for this re-design followed the prior work on Instance Details. We re-used the structure and gathered feedback from trusted customers as the process moved forward. I worked closely with the Head of Product and the dev team. As we got closer to production, high-fidelity prototypes, along with a script and story, were made for our Account reps to get feedback on the designs — including relative usefulness, and desirability.

Higher Fidelity

Where we landed

Getting to the root cause of an issue requires context and often the help of multiple team members. One of the needs we uncovered was a lack of communication within context. We added a messaging timeline that integrated with Slack to capture communication where it happened naturally. Important messages in Slack could be pushed to this timeline as a record. Messages within the incident timeline could be set as the “Incident Summary” which provided a record of causation in the timeline history. 

Having this record is a huge win for anyone running an audit.

For large teams, especially international teams, it's important to communicate who has already seen the alert, who's in charge of the alert, and who will be notified. The ability to add and communicate runbooks allows teams to communicate processes as well.

Bubbling up context

Separating signal from noise is difficult in a complex environment like infrastructure monitoring. We did our best to keep this compact yet data-rich. A history of prior incidents could be expanded from the header, and a full history was a click away.

Re-Design #3

Incident Overview

One thing that our current users and potential customers shared in common was a need for a better overview of incidents. The existing page was an MVP response that primarily served as a filterable log, but we needed to focus more on communicating the context of a ticket – Without losing any of the current functionality. Teams at scale would need a more direct picture of the ticket’s status, history, and the individual contributions of team members. 

For anyone working triage or managing levels of people doing triage, we needed a way to get everything under one pane of glass. And, individual users needed a “space” where they could see their queue and a history of their work tickets.

Before

After

Problem & Process

Creating an actionable ticketing feed

The existing Incident Overview provided a filterable history but wasn't very actionable. Key details like who'd seen the ticket, who was leading, and status changes were missing.

Outcome

The outcome & what I learned

We landed a key account, then were acquired

We landed our biggest account to date, and I'm told that the design work played a major role in their decision. The work we did to enable enterprise sales paid off, and not long after the Panopta was acquired by Fortinet. 

This project built on the success of the design structure that I'd helped build alongside the head of product and the front-end team.  And, I'm proud of how efficiently we solved the requests while maintaining our direction.

Integrations and working well with other tools

You don't have to be the place where everything happens. We took a strong opinion to be tool agnostic and give users contextual feedback into whatever external tools they needed. Customers face a real problem of having too many tools. Being able to see everything under a single pane of glass was key to our functionality.

Solving a problem

I derive a lot of satisfaction from helping people do their job more efficiently.

Data Density

I learned a lot about creating an actionable and data rich UI.

Collaborate with Front-End ahead of time

Early collaboration became essential to saving time for everyone, and avoiding over promise.

Visual Design

In terms of visual design, too much reliance on borders and containers. We used the card structure so that it would blend in a little more with the existing app. the plan was to get back to I wouldn't have used containers, was part of a way to make the transition less abrupt.