top of page

Admin Suite / Report Builder

General availibility July 2017

Building reports on our legacy application (before Report Builder GA)

Our legacy application was never intended to be used by external users, but by our managed services team, a group of highly trained program administrators. 

Most pages in our legacy application consisted of a list area and configuration area. Each page was like a direct access to our database, there were many settings on each page and  there was no feedback what so ever. That is, there was no way to preview changes before committing the changes, the user would have to save and publish the changes, and look at the published report. Updating a report was a dangerous task that was left to the experts.

There were approximately 140 screens on the report building section of our application. A new hire had to go through two months of intensive training and it took  her six months to feel confident  in configuring the aplication.

The Report Builder

There was a previous iteration of report builder. The first approach was to simplify the report building experience regardless of the existing data structure of the application. ​This approach ended up not working because the data structure couldn't be adapted to the new design, and migration of old programs was not possible. 

In the second iteration, our approach was way more constrained:

  • Main focus go to market

  • Maintain a unified experience through out Amin Suite. That is, allways think on Report Builder as part of a suite

  • No budget to do more research, use the research done during the first iteration

  • Use the layout created for the first iteration and use existing components

  • Keep 100% feature parity with the existing application and data structure

  • Focus on improving the user experience maintaining all the settings and features that were present in the existing application

An iterative Approach

The application part of Admin Suite that would allow our users to build and manage reports.


The Challenge

Manage reporting navigation


  • Use the table component

  • Focus on problems found on usability testing

Original page to configure navigation

User adds tabs and subtabs on the left list. Selecting items on the list, displays configuration on the right


  • Search feature

  • Filter navigation by role

  • View live version of navigation

  • Tab and reports counter

  • Clear hierarchy Tab/sub-tab/report

  • Main call-to-action is Create new Tab​

  • Sub-tabs are added in context of the parent tab

  • Reports are assigned in context of the parent sub-tab

New Design

Create and modify Dshboards, Dashboard modules, and preview as any role

Old Design

Old Design

User creates dashboards and modules on the left list, all dashboards and modules appear on the left list at once; On the right, user configures the settings for the selected list item ​


  • No preview. To view changes, the user has to publish the report and look at the published report.

  • No way to view the report as a specific role

  • Confusing langugae 

New Design


  • No interactions between left panels and preview panel

  • Give priority to existing compnents

  • User have to save to refresh the preview panel


  • Modules are created within the context of it's parent Dashboard

  • Instant preview when saving changes

  • View the report as any role

  • View published version of the report

  • Drag and drop to reorder modules

  • Updated user-friendly languge 

Since our main focus was go to market, we decided to go with an iterative approach. That is, we took a closer look at the usage of the all the features of the existing application, and decided to targeted the most used features first. We were going to release to EAP when we got to 80% feature parity and GA (General Availibility) when we got to 90% feature parity with the current application

The set of features I designed that were part of the EAP release were:

  • Manage reporting navigation

  • Create and modify Dashboards

  • Create and modify Dashboard Modules

  • Preview reporting changes as any role

Admin Suite Persona

The persona we are designing for we call her the Tech Admin


  • Business application manager, Tech admin, Medallia admin, System admin, Business analyst


  • Technical background is not required but may be helpful

  • 2-4 yrs prior experience implementing and maintaining enterprise software systems

  • Previously worked in or closely with IT, Tech, and/or CX (Customer Experience) Strategy


  • 5 years experience with large scale systems

  • Self motivated to troubleshoot

  • Deep analytical skills (excellent with higher-level Excel functions)

  • Technically savvy (but not necessarily a CS major)

Medallia's goal is to create a world in which companies are loved by their customers and employees. We do so by connecting any type of feedback from our client's customers to the relevant person that can take action to make the customer's experience better.

Medallia's clients cover many spaces, hospitality, retail, comunications, fashon, finances, etc. To make customer feedback engaging throuout the organization is not an easy task. Configuring something that is tailored for all these different roles is difficult, our application has to be flexible and customizable in order to adapt to all our different cliets needs.

That's why it takes a team of in-house experts between 3-9 months to do an implementation, from these 3-9 months, 50% of the time is spent in configuring surveys and reports.

This worked great for fortune 500 companies where managed services took care of everything. However,  we wanted to scale and  reach smaller companies, and our current situation didn't  scale.

Medallia Admin Suite

So we start one of the largest projects of Medallia, the self service initiative which we called Admin Suite.

The goals were simple

  • Reach mid size to smaller companies

  • Lower implementation times by Medallias managed services

  • Partner with other companies to implement and mantain our product

  • Allow our clients to do some of the simpler service requests

Admin suite consist of four key elements

  • Survey Builder
    Where the user can create and manage surveys

  • Report Builder
    Users can create and manage reports

  • Power Zone
    A place where experiences users can configure and administrate users, roles, data management, and all the features that have keept Medallia as the leader in the space

  • Packages
    Sets of pre-configured, bet practice oriented solutions designed to reach the smalest client. 

Each of these pillars is it's own team, fully stocked with product managers, front and back end developers, engineering managers, and designers.

Our goal was for our users to have a unified experience throughout Admin Suite.  We knew that having different teams working on different parts of one larger product was challenging so we got together and created a series of principles that were applied thorugh out Admin Suite. These principles are:

bottom of page