MY ROLE
I was the sole designer initially. I worked on 
both interaction and visual. Later a 
interaction designer helped conduct 
usability testing.  

PLATFORM
Web - Desktop, tablet and mobile
​​​​
TEAM
1 Product manager
1 Lead developer
4 Developers(co-ops)
1 Content designer​​​​​​​
Background 
I previously worked for Quickbase, a no code / low code, PaaS platform. With Quickbase you can build apps through which you can store, track, report data. During my time at Quickbase, I was involved in a project called Platform insights. Through this project, administrators were able to collect insights on the usage of their applications. 
Problem
Administrators of apps built through Quickbase often felt lost and confused when it came to dealing with information about app users. Administrators could not easily identify inactive users. Nor could they identify when they needed to upgrade their platform because of an increase in active users. The end result was that these administrators were stuck with expensive plans that they did not understand, and were consequently frustrated.
Goal
App administrators wanted increased visibility and transparency. They wanted insights regarding their app usage. This would help them minimize their costs.
_____________
Initial draft
During an initial brainstorming session with a product manager and a lead developer, we came up with a two page rough sketch.
The first page is the dashboard that shows overall usage in a gauge chat and the second page is the drilldown to get more information.
Challenges
I made a list of all the challenges as questions, and started answering each of them through in-depth research and surveys.​​​​​​​
Page one 
1. What is the primary information the user wants to see?
We(The project manager and I) did a survey through Pendo to understand what customers want to see in the tool. (Pendo is a third-party analytics tool through which you can display a survey to desired user groups). We received a wide range of feedback. But for the initial MVP, we picked four and began expanding from there:
  -
App users (Number of users that access each app each day)
  -
Read request (Total number of user reads and integration reads since the start of the latest contract)
  -
Attach space (Amount of file attachment space that your apps currently use, compared to the amount purchased)
  -
Days since the contract started (Number of days elapsed since your current contract period began, compared to the total number of days in this period)

2. Which type of chart is best to display the data?
I looked into several types of charts that display a progress bar. I narrowed it down to two chart types. Gauge and bullet chart. They can both track the progress of data usage and also show the projected budget. But the gauge chart was chosen as it is simpler looking and easy to implement. 
3. What colors are best for the charts?
Brand colors were used for the gauge charts. The colors were also grouped based on information. For example, app-based information was displayed in one color while user-based information was displayed in another. These were chosen to avoid overwhelming the dashboard with multiple colors. These colors were also checked to make sure they passed the color contrast ratio with the background for accessibility.
4. How does page one navigate to page two?
Initially, I did not want to overwhelm with multiple buttons in a dashboard. So the primary button appears only when hovering on the widget. The users can also navigate to the page two just by clicking on the chart. (This interaction was later changed after usability testing)
Here's the final design of Page one
Page two
5. How do we show all the data together in one single page? 
A competitor analysis was done to see what other products in the market use the drill-down page in their platform.
6. The timeline graph can show only three apps or usage at a time to improve page performance. How do we let the users know that they can check only three at a time?
Radio buttons: The common pattern for the radio button is to allow the user to choose only one of a predefined set of mutually exclusive options. So we do not want to differ from the already established pattern.
Toggle: According to the Quickbase design system, the toggle should be used only for on and off states. For example, switching between two different views. So we ruled out toggle as well as it doesn't follow our design system.
Checkbox: The checkbox works best for this scenario as the user can select multiple options. But we also want to let the user know that only three are allowed at one time. So once the user selects three options ,we disable the others. The user can select another option only if they uncheck a box.
7. Which layout is best to display both graph and table report in a simple, organized way?
Three different layouts were designed and presented to fellow designers to get their feedback. The Design where both table and graph have equal emphasis was selected.
8. There are a large number of users and apps for an administrator. So space was a biggest concern. How to minimize the space?
The first page has a top bar and a side bar. We decided to remove the side bar and kept a breadcrumb in the top as it is a drill down page. Additionally, we also introduced a collapsable panel so that the graph and table gets more space to view.
Here is the final design for the page two:
Design handoffs
The final designs were handed off to the developers through Zeplin (a tool through which the developer can view code snippets. The designs were also inspected with the developer to ensure that interaction and visuals are presented as required.