Redesign of a B2B/SaaS Software for DevOps

Category: Product Design, UX Design, UI Design

#elasticsearch #kibana #grafana #datavisualization #ux #ui


The automated reporting and alerting software has the cluttered interface and suboptimal workflows, which prevents users from creating and scheduling reports and alerts easily.



By redesigning the product that will provide intuitive processes to set up reports and alerts, users will be able to monitor changes in database easily.


Project Background

The client saw an opportunity in the marketplace when they realized data visualization tools, such as Kibana and Grafana, didn’t provide an easy way to automate the delivery of reports. They created the reporting and alerting automation tool as a simple and affordable solution for DevOps engineers to monitor changes in database.

When I started the redesign process, the first thing I wanted to do was to understand what it does and how it works very thoroughly as it was a technical product to grasp without prior knowledge in database or visualization tools.

To do so, I conducted interviews with the internal team members to capture business goals and functional requirements. This was done in multiple sessions through in-person meetings and online product walkthroughs. By talking to the stakeholders at the company, I was able to review the status of the product in details and also how it compares to other products in the market.

Key findings after the initial consultation sessions:

  • The product consists of two distinctive sub-products: Reporting and Alerting

  • Reporting brings a big competitive advantage over similar products in the market

  • The company wants to combine Reporting and Alerting into one product

  • The company wants to minimize the setup time for users to be up and running

  • Main target audience is DevOps engineers


Success Metrics

I wanted to establish goals and objectives, along with key performance indicators (KPIs) to measure periodically. Without a surprise, the stakeholders shared that their number one goal was to increase sales. There were also other aspects they wanted to improve, such as making the installation process simpler as the existing process required users to study extensive getting started documents, which led many of them contacting the support team. Based on these facts, I identified the following:


  • Increase sales


  • Increase the conversion from trial to paid users from 10% to 33% over the next 12 months

Key Performance Indicators

  • A percentage of trials users converting to paid users compared to last month

  • A percentage of downloads to installations compared to last month

  • A number of support tickets related to installations related issues

  • A number of cancellations by existing customers


Target Audience

Primary: DevOps engineers

One of DevOps engineers tasks is to automate the delivery of notifications that can impact business outcomes. They install and configure software for the company or for their clients to monitor key performance indicators, which is mostly on a server, cloud, or data center. They help product managers and business analysts to generate reports and monitor anomalies. They regularly read articles to inform their software purchasing decisions.

Secondary: Product managers and business analysts

Product managers and internal business users use a reporting automation tool to monitor various activities. To use software like our product, they most likely need the assistance from a DevOps engineer to install and configure it. Because of this difference in roles and technical abilities, they may not need the full admin capabilities and act as a report creator or a simple viewer. They may influence the purchasing decision.


User-centered Design Approach

One thing I wanted to do differently was applying design thinking to the process. With limited knowledge and resources, the company hasn’t made a big effort to understand customers’ needs and pain points in depth. Before I delved into the redesign process, I suggested conducting interview sessions with customers to listen to how they use the product on a daily basis.

Before I talk to customers, I wrote some guiding questions to frame my research activities.

Research questions:

  • What are biggest challenges in installing the product?

  • What are biggest challenges in creating and scheduling a report?

  • What are main reasons for trial users decide not to purchase the product?

  • What are biggest challenges outside of using the product? (ex, customer support)

After talking to customers, I gathered the following insights:

Interview summary:

  • There is a learning curve in getting started and creating a report

  • It’s not intuitive to see how to use templates, which is a must

  • When creating a report, can’t see how the graphs will be turned out

  • Standard functions are missing (ex, drag-n-drop to move pages, auto-saving)

  • The website’s product pages don’t communicate features clearly


Usability Reviews

To understand the current status of the product, I conducted usability reviews to identify areas of improvements. I also evaluated competitive and related products in data visualization space, including the Elastic Stack, Grafana, and other open source software, to see how our product measured up against them. Here is the summary of usability reviews:

Product evaluation key findings:

  • The interface should accommodate selecting from multiple data sources

  • Designing a report process should be more visual by previewing changes

  • Templates should be easy to apply and easy to edit

  • Filters should be integrated into the burst reporting feature, which isn’t clearly defined

  • Users should be able to add multiple notification channels

Competitive analysis key findings:

  • Premium products offer comparable features but it’s an overkill if a customer is looking for a simple automation tool

  • The features may not cover important user needs, such as burst reporting

  • There are open source projects that offer more complete functionality but they usually only work with a specific product or don’t support adding multiple data sources

  • For open source products, there is no option for enterprise customers to get support

  • Many of them work with Kibana and follow its typical dashboard interface conventions


Synthesizing Insights

At this point, we had a lot of information gathered through different research activities. I also wanted to have an opportunity to capture any unspoken insights that individual team members had because the project has begun a while before I joined.

I chose the affinity mapping as a method to synthesize findings into actionable insights. We wrote all our findings and personal insights on sticky notes and grouped them based on similarities. Another important step was to determine which features to include in the next update as not all of them were critical for the immediate release.

Affinity Map.png

Based on this exercise, we categorized features into four groups:

Must have

  • Simplify installation and configuration processes

  • Combine Reporting and Alerting as one product

  • Eliminate having to obtain a trial license and offer as freemium

  • Make report creation and usage of template more visual and intuitive

  • Clearly define the burst reporting feature

  • Auto-saving while creating a report

  • Automatic time zone setting

Should have

  • Real-time preview when the user makes changes

  • Drag-n-drop between pages

Could have

  • Automatic sizing of graphs to the template

  • Support more file formats for download options

Won’t have

  • Support different levels of access based on user roles

  • Offer our product as a Kibana plugin

  • More report templates for better design choices


Use Cases

Before I could design actual screens, I needed to understand the product on a micro level. I wrote use cases for all main tasks to describe steps to accomplish them. It also allowed us to exchange feedback on how the product should work before creating any visuals. As we discussed use cases, I was able to gradually refined them until everyone felt like we had the intended experiences for all major tasks. Because of the time constraint, I focused on the main flows and left out alternative or fringe case scenarios.

Example Use Case: Creating a report

Preconditions: A user configures the product

Triggers: A user selects to create a report

Main Flow

  1. The system sets the default name ‘Untitled Report’

  2. A user enters the name and saves

  3. A user selects Data Source > Dashboard

  4. The system automatically displays a preview of the report from the selected data source              

  5. The system auto saves the changes

  6. The system provides an option to further customize the report

  7. The system provides an option to apply a time filter (default, bring Kibana time filter)

  8. The system provides an option to change the location of the generated report

  9. A user has an option to:

    • Download

    • Send a test report

    • Schedule a report

    • Save and exit

  10. A user exits to a list of reports


App Structure

Based on user needs and our goals, I identified the app structure as a diagram:

App Structure 1.png


While I was writing the use cases, I naturally started visualizing screens. Here are some of the exploration that I did for different parts of the app.


Create a report screen with the big portion of the screen dedicated to previewing changes. I also separated steps for the user to build a report in sequence instead of displaying all input fields at once.


Optimizing the offline license activation process was a tricky one. I tried to differentiate steps that happen online vs offline machine as it alternates.


An attempt to visualize the burst reporting feature within the reporting creating process: Create, customize, and send to multiple groups of multiple users


The team settled on giving users 2 free reports and 2 free alerts as a freemium product. After that, it’ll ask the user to upgrade to a paid version.




Visual Design