Utilities Client

1. Background Information

Overview of Applications

Over the course of this project, I managed design work on two applications simultaneously: the Call Center Analytics Dashboard and the Form Processing Application.

Call Center Analytics Dashboard

The Call Center Analytics application leveraged an intricate Natural Language Assessment (NLA) pipeline to transcribe customer service calls to text and analyze call meta-data. Then, using AI machine learning models, our data scientists classified and categorized the call transcription data, generating relevant 'topic tags' for each call.

I was responsible for designing and managing the implementation of four filterable “dashboard” screens that enabled stakeholders to view this data in a meaningful way, gaining invaluable insights into customer intent and sentiment:

• Aggregated Analytics: A filterable, high level overview of key metrics across all calls; includes visualizations of call volume over time, call sentiment broken down by duration, and ‘topic tag’ frequency.

• Call List: A filterable listing of all customer service calls, displaying key details at a high level, and allowing users to select a call for further information.

• Call Details: When a user selects a call, this screen displays all relevant metadata, a call summary, and a full call transcript with audio. Additionally, data visualizations display the length of each call “segment”, as well as customer and agent sentiment for each line of dialogue.

• Keyword Search: This view allows power users to enter in key phrases and obtain high level metrics/analytics for calls containing these wordstrings

Form Processing Application

The Form Processing product leveraged Optical Character Recognition (OCR) to read scanned PDFs of paper forms, process the handwritten information, and standardize the data.

I designed and helped implement a custom UI that enabled users to configure batch jobs for processing, search for forms containing errors, and display form data for quick and efficient review. This expedited the processing of thousands of forms a month and saved significant employee labor. The experience consisted of the following screens:

• Define Forms: Users may upload and define a new form template, configuring it to a file containing the corresponding forms; or, they may modify a pre-defined sample template.

• Flow Tasks: This screen enables users to configure a batch job that will run all the forms through the defined form template and output them to SAP.

• Find Scans: Once scans have been processed, the ones that fail to process will be found here. Users can easily find scans, identify errors, and manually review them.

Proof of Concept (POC) Designs

At project inception, I was provided with high level proof of concept designs for 2 screens of each application—exact requirements had yet to be confirmed with consumer group stakeholders and backend teams. As such, it was my responsibility to quickly collaborate with business stakeholders and developers to re-imagine and scale these designs, ensuring they met business objectives and were technically feasible.

Call Center Analytics Dashboard

I was provided with proof of concept designs for 2 screens: Call List and Call Details.

Form Processing Application

I was provided with proof of concept designs for 2 screens: Define Forms and Find Scans.

3. Form Processing Application

Updating Requirements

Proof of Concept Requirements

Before I joined the project, the POC requirements for the Form Processing Application had been outlined and approved; however, designs had been limited to just two static screens: Define Forms and Find Scans. Therefore, I did not need to explicitly define requirements; rather, it was my responsibility to prototype all the interactions for those two screens, as well as design one additional screen with full interactivity: Flow Tasks.

Collaborating with Consumer Group Stakeholders

The POC requirements were relatively high level, and there were still many scoping and business process intricacies that had yet to be identified and accounted for to make the product truly functional. Due to this, I worked closely with our consumer group stakeholders to discuss business process details and flexibly explore design solutions. I kept detailed logs of each change in order to pass the information along to the product manager for enhancement stories.

Understanding the Flow of Data

Additionally, the POC requirements were defined prior to the completion of the backend infrastructure and needed to be updated accordingly. As I began my designs, I engaged with developers to gain insights into the flow of data on the backend and frontend:

1. A form template is uploaded through the UI and processed through the optical character recognition (OCR) application to identify response fields. Then, the user configures the form template to a file in the scanning software via the UI.

2. On the UI, the user then configures a flow task for the form template, uploading an output schema file and matching the schema fields to the textract response fields to properly format the data for SAP processing.

3. Next, the user scans a batch of forms to the scanning software file previously configured in the corresponding form template. The flow task automatically runs, and the forms are processed by SAP.

4. Successfully processed forms go to a designated s3 bucket.

5. Forms with errors go to a different s3 bucket to be displayed on the UI for review.

   
   

Various requirements updates were necessary to ensure the UI properly accommodated this data flow—in particular for the Flow Tasks screen. I advocated for maintaining a usable, simple interface in all feature implementations, consistently iterating on my designs to ensure maximum usability despite complicated logic.

User Flows

After understanding the flow of data on the backend, it was essential to establish the step-by-step flow for users on the front end. To achieve this, I developed a comprehensive task flow diagram that accounted for all possible interactions. This established a clear visual of the user journey for all stakeholders involved.

Prototyping & Testing

Given the highly process-oriented nature of this application, it was imperative to create detailed prototypes featuring individual frames for each microinteraction on every screen: Define Forms, Flow Tasks, and Find Scans. This helped frontend developers further understand the sequential flow of interactions to complete tasks on the UI, enabling them to code with accuracy.

It’s important to note that frontend development work had already been completed on the majority of UI components prior to my involvement on the project. Since the client did not have a sufficient design system and the POC designs were not stylized, the developers built everything with standard AntDesign components. Unfortunately, we determined there was not enough time for developers to restylize them for MVP; therefore, I designed all of my initial prototypes with unstylized AntDesign components for their reference.

User Flows and Interactions

Post MVP Stylization

Though there wasn't time during MVP build out a stylized UI, I nonetheless crafted Custom UI Components and revamped my prototypes, accordingly. I systematically redesigned every screen using the new stylized components, ensuring that developers could vividly visualize and comprehend all the prototyped states of the restyled elements.

Guerrilla User Testing

For this particular product, we were fortunate that our consumer group stakeholders were also the intended users of the application. Throughout the process of refining my prototypes and incorporating updates to align with business processes, I had the opportunity to present my designs to our main consumer group stakeholder/user on three distinct occasions.

During these sessions, she engaged with the prototypes to execute the following tasks, offering immediate feedback on any inaccuracies or pain points she encountered:

1. Upload a new form template and define form fields (draw bounding box, change data format, change confidence level, etc.)

2. Configure a new flow task and match document fields to Output Schema fields.

3. Find a scan with errors from a particular date and manually rectify the error.

Additionally, I was able to send the prototypes to her offline for additional feedback. As a result, I was able to incorporate this feedback in to my designs, as well as in the build via enhancement stories.

Demo of Prototypes

You may view a demo video of the prototype or reference the High Fidelity Mockups above for all screens.

Build & QA

At project inception, only the UI components had been developed, and there was no product in existence. To address this, I collaborated with the product manager to plan several "mini-sprints" of build stories to develop the three prototyped screens along with their respective microinteractions.

Enhancements and Bug Fixes

Throughout development, I navigated ongoing requests and alterations in scope from our consumer group stakeholders and incorporated user feedback obtained through guerrilla user testing, altering my designs accordingly. In turn, I collaborated with the product manager to translate these changes into enhancement stories for the frontend development team. Working closely with the QA tester, I also helped support Bug Fix stories to rectify UI functionality issues.

At this stage of the project, we did not have an active subscription to Zeplin. However, for each story, I provided a link to a Figma frame containing detailed visual annotations. For features that involved particularly complex interactions, I recorded demonstration videos and included links to those, as well.

Ultimately, we conducted 7 “mini-sprints” of stories to complete the build and ensure an optimal user experience. Throughout that time, I personally QA tested each of the completed stories and communicated frequently with the frontend development team to quickly rectify issues.

Error Handling and Alerts

Given the multitude of interactions involved in the application's design, I also collaborated extensively with frontend developers and QA testers to devise comprehensive error handling for all potential scenarios. I established a centralized repository for all error modals, which facilitated easy reference and development.