Apurv Ray

Introduction
[24]7 is one of the largest customer experience companies in the world with expertise in chat, voice and IVR based systems. I joined the company when the design studio was just being set up and there were plenty of areas which needed design intervention. I started with the reporting suite. 

It was in dire need of a holistic redesign and a tech stack overhaul as well. The PM assigned and I, together started looking into the who , what and why of the reporting system in place. The old reporting was in fact just a bunch of tables thrown onto a webpage without any kind of visualisation or even active filters to play around with the data. 

Personas and Stakeholders
The current system was virtually impossible to use on the web platform and all the different stakeholders actually downloaded the raw data and just play around with it using other software available. We had to find out exactly how the product is being used and then what should the new product be like. The first step was to identify the primary users and how do they use it right now. The three key stakeholders I identified were Business Analysts, Sr. Business Analysts and the Client (representative). We also followed this up with some gorilla user research and in situ observation for the internal stakeholders. The personas below might give some info about the things we uncovered at this stage.

The personas below are not the finals ones but a mid stage snapshot (IP issues)that were made after the first round of interviews and research. These were circulated throughout the company and were appreciated by every group that got a copy as it put several assumptions and myths to test about their product. You can click on the images to enlarge them. 

Wireframes and Initial Prototypes
The initial research enabled us to start creating a rough outline on what should the product be, we wanted to test early so that the once the basic outline is decided the tech team can start working the stack while the design work and refinement can go on in parallel. Also the leadership was yet to approve the team formation and budget. So to demonstrate what we were planning to build I decided on making a axure prototype that people can play around with instead of just static wireframe images. The wireframe prototype were a big hit with the leadership and the programmers as well as they could get a much better understanding of what they were supposed to build. You can see the prototype by clicking on the button below. 

Visual Design And Themes
The wireframes were eventually polished along with inputs from the Product Management and the Engineering teams and the visual design system was started. I decided to stick with the official colors of the company along with a highlight color. After a couple of iteration the design below was finalised. When I showed this to the leadership at 24/7 this was decided to be applied across the entire 247 Central suite and I needed to make a visual design guideline for the whole system. Some of the reports with the visual design applied can be seen below.

Customisation and Self Serve
One of the most problematic areas in the old system was the inability to edit and customise reports. As a result the clients requested entirely new custom reports which had just one or two additions and rest of it will be a complete duplicate of the standard report. This led to a lot of unwanted repetition and extra server load. So customisation was a very important requirement from the beginning. Also the ability to define your own reports was a long running request from the clients. So I made a system where the same UI can be used to create new reports or edit existing ones. They are available below.

Visual Design and Grid System
Designing the system is easy, but enforcing it across a huge system can be very difficult. Especially if the engineering teams are separate for each part of the suite and sometimes even are spread across different geos. A design system / guideline/ library was the only way to ensure that the components are executed in the same manner everywhere. Below are some of the samples from the design system specs.

The grid system was an important feature that helped get our app use different screens optimally using a fluid layout method. Becoming responsive was not a high priority for version 1 but we tried to get as close as possible. We made the entire app a 5 column layout with 1st column being the left sidebar and the rest 4 columns become the active area. You can see both the design patterns below. In the active area the widgets were either 1 column or 2 columns and they arranged themselves using a "masonry" plugin to fit best in the available screen size.

The project is still under development at the company and these are the screens that were finished around the time I left 24/7. It was supposed to go live by March 2016.