Apollo Studios

Design + Full Stack Development

Simplifying RPA Data with a Custom Analytics Dashboard

Designing, building, and shipping a software enabling more comprehensive, accessible, and customizable data analysis into the company’s database.

Process Highlights

Overview

During my internship at Apollo Studios, another intern and I were tasked with analyzing a database containing over 4 million entries to generate insights for both internal use and client purposes.

Our initial challenge was to develop a script capable of analyzing the data, followed by producing analytics based on specific requirements set by the company and, in some cases, the client.

We built a data analytics dashboard, that provided insights to both clients and internal stakeholders. I also had to build the product.

Timeline

Summer 2024

Team

Product Manger, Data Science Intern, Product Design Engineer Intern

Robotic Process Automation

Solutions Architecture

Custom Software Development

Apollo Studios

Apollo Studios is a startup that builds primary robotic process automation solutions for businesses. They also do solutions architecture and develop custom software for clients. I also had to build the product

Research

Where Are We Currently?

The Audit of the Process

We spoke to clients and internal stakeholders about how they felt about the process. We then measured how long it took them to accomplish certain data goals.

“How long does it take you to get data on a specific company’s RPA bots ?”

36±12s when timing their average workflow

Using MongoDB tools, executives overestimated RPA performance by

12±7% compared to actual data performance

Executives underestimated the failure rate from business exceptions by

30±8% compared to actual data performance

Low accuracy

MongoDB was hiding the true data and performance of the company.

Long waiting times

Everything took too long, and for a fast pace startup, this would affect their performance.

Unfeasible long term solution

Apollo needed something that could accomplish their business goals and get better knowledge of their data.

Research

Analysis

The Current Situation

Apollo Studios operated on a MongoDB database that was accessed through MongoDB Compass. This software was beneficial in searching for client names, bot names, and a time period, although it was very inaccessible to understand. The software also did not provide easy, comprehensive analysis that one could just glance at and understand the data

Our Audience: Client and Company

Both the client and executives at the company wanted a solution to this problem, whereupon customers could easily understand how their RPAs were performing, and the executives could isolate which areas they would like to work on.

Overall, the main problem was accessible understanding of the database. It needed a clean, frontend interface. We were designing for two different audiences - with two different needs.

Low accessibility of the data

Clients could not view the data on their own time

No comprehensive insights

Data was visually incomprehensible

Slow customization of data searching

Lack of aggregate performance data

For Apollo, they struggled to get aggregate data comprehension without long MongoDB searches.

Clients simply could not know how their RPA bots were doing.

The current process of understanding RPA data for Apollo

Step 0: Open MongoDB Compass.

Step 1: Connect to the database and navigate to correct folder.

Step 2: Understand correct naming conventions and statuses.

This was completely unfeasible for clients and the process took too long for internal stakeholders

Step 3: Understand how to generate queries and extract insights - without other Mongo software

Step 4: Visualize that data, or email it, or anything at all

What were the problems?

We conducted some user research and wrote our findings

Insights needed to be fast

People wanted aggregate data insights

Data needed to be customizable

Overall Success Metric

Both clients and executives must be able to see an overall success metric for all bots, filtered by company and date.

Bot Status Break Down

The statuses of each bot should have been able to be categorized into three specific labels. Success and failure for clients, all for executives.

Overall Activity

CTO wanted to see overall activity to understand how many bots are running each day.

Activity Based on Date

CEO wanted to see bot activity across specific date ranges to measure performance and understand bot usage.

Performance D2D

Easy comparisons of bot performance and activity across a selective date range.

Easily Send Data

There is no way to send data and its analysis by either clients or executives.

Naming Conventions

Currently Apollo must change their data labels in order for clients to understand the bots.

Specific Bot Activity

Activity should be broken down by bot to understand their data specifically and in comparison to other bots.

Visualization

Emphasis on visual data representation for clients as it aids in understanding the data at a glance.

Searchable

The data is too difficult to parse through as you must use naming conventions. Search bar should allow for plain text search.

Final Data Spreadsheet

Currently you have to download a csv in order to see individual company bot performance.

Easily See Bots by Company

CEO, CTO and clients want to be able to see all of their bots and their names in one place.

“How long does it take you to get data on a specific company’s RPA bots ?”

36±12s when timing their average workflow

Using MongoDB tools, executives overestimated RPA performance by

12±7% compared to actual data performance

Executives underestimated the failure rate from business exceptions by

30±8% compared to actual data performance

Research

What data do we currently need?

Format

We started by focusing on simple data elements, metric cards, a data table and visual elements for more detailed information.

The three main data visualizations

Bot names for specific companies

Status organization of bot transactions (success, failure, business exception)

Activity by bot and company - searchable through date ranges

Important Metrics:

Total transactions for specific company

Overall status comparisons between bots

Aggregate success and error easily compared

Complete bot data with detailed values

Initial Data Sketches

We used these data sketches to ask our PM what data they wanted visualized, and how

Iterating Quickly by Testing a Design Style

Apollo had no clear design system, so we tested this possible design aesthetic with our PM.

We received feedback that it was too playful so we made changes to it.

Overview

Apollo Studios

Details

Bots Data

Errors

Successes

Development

Initial Wireframes and Feedback

We wanted to figure out how the data should be laid out

So we built a small wireframe prototype, using a strong information hierarchy of what was most important to the stakeholders: bot successes, bot transactions, and bot failures.

At a glance, users found it easy to see:

+ Overall bot metrics (success, failure)

+ Transactions by bot

+ Basic detailed information on each bot

Clients would be overwhelmed

However, Apollo Studios felt the clients would be overwhelmed by the amount of data and visualization.

We were building a product for two different audiences, how could we make sure both were satisfied?

A homepage with the basics

By placing these main components on one page, we allowed for basic understanding of performance, with an invitation to delve deeper.

This helped us with our two audience problem.

We decided to build an overview page and an analytics page. If a user wanted more information besides just a general overview they were free to explore this.

The homepage now had all the important info

Development

High Fidelity Designs & More Iterations

Overview and analytics pages

I reworked the dashboard to have Overview and Analytics pages to highlight what mattered most: Success, Errors, and Business Exceptions. The original layout buried these critical metrics under a flood of numbers, so I elevated them visually and reduced the surrounding noise.

UI Changes to the Dashboard

Instead of stacking multiple bar charts, I moved unnecessary bot data -along with its confusing, database-driven labels - to the dedicated Bot Performance page, ensuring clients didn’t have to parse irrelevant information.

A smoother gradient line graph replaced the second bar chart, making it easier to compare trends at a glance. By consolidating essential data in a single view and relocating the rest, I created a more coherent experience that puts the user’s most pressing concerns front and center.

Feedback on the analytics page

After a final design was presented to my product manager

Iteration on the Analytics page

Feedback on the overview page

Mostly based on overwhelming the user

Iteration on the Analytics page

Overwhelming the user

The first two high fidelity iterations had to have improvements because there was just far too much data.

Graphs and data visualization

We had to rethink what type of charts we were using - what leant itself best to transaction periods?

Creating more pages

We needed to make pages for data analytics and error analysis - these provided more detailed information for internal purposes.

Development

Final Designs

An error failure and bot transactions page

The error page would categorize and log major errors, showing how frequently each occurs over the last seven days. It helps users prioritize the most common error types and implement focused resolutions.

The bot transactions page highlights metrics for individual bots, illustrating trends in success, errors, and exceptions at a more granular level. Additionally, it flags significant performance drops, allowing teams to quickly isolate and address potential issues.

Simplification

Although these two pages were useful, we never developed them ourselves. Most of the development of the dashboard was done by me, and I lacked the time to build these last two out. The team is currently working on them now.

React Components

Hover over them!

Graph and Bar Chart

React Components

I used UI library frameworks and learned how to do frontend engineering.

Pie Chart

Overview page - Dummy data for confidentiality

Analytics page

Error Analysis + Bot Performance

Two pages still in development by the end of my internship

Conclusion

Takeaways

Stakeholder Outcomes

Executives at Apollo Studios achieved their goal of being able to access data insights into an otherwise incomprehensible MongoDB database.

RPA engineers were able to understand the reasons why their bots were failing and which bots were underperforming.

Clients were able to quickly access realtime updates about their RPAs at Apollo Studios and their performance.

Collaboration

I worked alongside another intern from UC Berkeley who specialized in the backend data science of the project, and we formed a great team in helping each other build the dashboard.

I realized it is important to understand the process of building a product end-to-end so that it can be as cohesive as possible. This gave me renewed appreciation for CS knowledge.

+91% Faster Access to Client Data

From ~35 seconds using MongoDB to 3 seconds using our Data Analytics dashboard.

Data Cleaned 4 Million Entries

Cleaned all entries with a standardized data naming system.

Increased Transparency to Clients

Developed easier analytics to track performance of the RPAs

Design Takeaways

This was my first industry design experience. I learned what it meant to design in a team, and receive feedback from supervisors and peers.

I also learned how to design with a clear business objective. It was very enjoyable to have a clear problem and goal, and work my way to a solution.

Technical Takeaways

Empathy for your fellow developer. As I had to build anything I dreamt up, I learned what it takes to actually program something - and make sure it works in many edge cases.

See more projects