ESG was a client based out of the Gulf Coast, where they provide enterprise software solutions for independent energy retailers in deregulated markets. Unlike PG&E in California or Excel Energy in Colorado, organizations in the Gulf Coast can actually distribute their own energy by leasing energy directly from an energy company, and then selling it to customers like you and me. Rather than the monopoly market that PG&E or Excel exist in, customers based in the Gulf Coast can actually select which energy retailer they'd like to have their energy delivered through. As a result, ESG provides both the consumer & enterprise facing software solutions.
I spent the first few months working on the consumer facing software, starting with the information architecture, wireframing, and moving to hi-fidelity mockups and a comprehensive styleguide. I then spent about 6 months working on the enterprise side alone, rethinking the entire experience of the archaic software. Unfortunately the organization
The scope of the redesign was focused on ensuring that any design decision made should not stray too far from what the existing API supports. With that in mind, my first step was performing an audit on the existing site (below).
It's apparent that the information hierarchy needed some serious work. So that's where we started.
After collaborating with both ESG stakeholders and my project manager, we developed an finalized an Information Architecture that had 5 primary branches: Pay Now, Payment History/Bills, Energy Usage, Messages, and Account Management
We decided that each of these sections were important enough that they should be easy enough to navigate. Based on customer interviews, we learned that the most important functionality for most users were bill payments, viewing bill history, and viewing energy usage (if applicable).
A few key things we solved for:
- Easy autopay setup, easy manage payments and payment methods
- Consolidation of payments and bills under a single view
- Energy usage graph to allow customers to better understand usage patterns
- Allowing retailers to build more constructive relationships with customers
- Easy paperliss billing option to reduce cost for energy retailers
- Batch payment functionality for customers with multiple properties (i.e. landlords)
Following the IA, I designed and iterated on wireframes that covered the core functionality outlined above.
The homepage presents the bill payment option at the very top left, as that's likely the primary action a user takes when visiting the page. We also explored placing the bill trends up top to provide a visual context of their bill.
The payment setup page uses a two column approach: the left for entering payment information, while the right column remains in view as a sticky module. The user also has the option to edit the payment amount--an eduge case that we uncovered for customers that may be splitting a bill, for example.
We tested all of our wireframes above with different groups of users to help confirm or challenge our assumptions.
We performed 11 user tests total, included 7 females/4 males, ages from 26 to 77 years old. More importantly, we accounted for both low and high tech comfort levels. We reviewed and revised the protocol with the ESG product team, and we conducted two separate task analysis flows. We conducted the tests remotely over Zoom. Some of the tasks we asked included:
You have received a new bill and want to review the detailed PDF version. Can you find where to download the PDF version of your current bill?
You are satisfied this recent bill is accurate. Can you find where to set up auto-pay to pay the current and future bills automatically?
You ran your A.C. heavily last month as it was unseasonably warm. Can you find where to see how much electricity you used last month?
You want to understand if you can change your bill due date. Can you find where to review information on this within frequently asked questions?
You have recently changed your primary cell number. Can you find where to update that information?
We had both design successes and failures. Overall, they commented on how easy it was to find items they were looking for. The 'Usage' page and homepage charts tested well as well. The majority of users found the interaction with the chart intuitive (using toggles to switch cost/usage, expanding data table, etc.)
Some failures included that the 'recurring payment' language was confusing for some. Another area for improvement was the organization and display of table based information within the ‘Payments/Bills’ section (e.g. Billing information is likely a higher priority over payments and date ranges in current format are confusing). After a thorough review of these tests, we developed our final solutions in hi-fidelity.
The homepage closely reflects the user testing outcomes. One of the key things ESG stakeholders emphasized was the ability for retailers to customize the homepage layout depending on their needs. Some retailers may want to highlight the usage trends, while others may want to highlight account information. By providing a modular, rearrangable layout, the customer facing platform scales across different retailer needs.
Based on the user testing result, we separated the billing history and payment history into two different tabs. We also incuded a "View as PDF" CTA in each billing row for easy download.
Under the usage page, we highlighted an area for Key Insights so customers can get a high level understanding of their usage at a glance. We also included an area for retailers to provide tips & tricks to customers to help them save energy.
In addition to providing hi-fidelity web solutions, I also designed out the responsive versions as well.
Independent energy retailers also need the ability to customize the visual design to fit their brand. I also designed a few examples for their existing clients to help deonstrate any retailer can apply their branding to the platform.
A few of the challenges of working with ESG was that a) they were a very large, beurocratic organization that was b) very 'waterfall' in their product development process. As a result, I never really interfaced with an engineer on their side during the design process, so I created a comprehensive styleguide that would help assist their developers if they had any questions regarding designs, components, edge cases, etc.
The colors section of the styleguide is especially important. I added a theme for each of ESG's existing clients to match their brands, and I included primary and secondary colors. I ensured that each of the primary colors, when contrasted with white text (i.e. a button) is WCGA 2.0 accessible.
I also outlined type styles to ensure that the hierarchy scales across different retailers. The rest of the styleguide outlines UI elements and different components used throughout.
The ESG Sigma Customer Care & Billing (CC&B) platform is their billing platform where customer care professionals can access customer information, manage billing cycles, drive day-to-day operations and logistics, and more. It's a highly complex information management system that was designed and built with engineers, rather than using a user-centered design process. Over the last 15 years, new features have been added, but old, and unused features remained, resulting in a disorganized and broken user experience. Below are a few screenshots of how it looked before MojoTech stepped in.
It certainly doesn't take a product designer to recognize that there's huge opportunities of improvement here. One of the key points is that because the software isn't intuitive, there's quite a bit of training involved for new hires or new clients, thus resulting in more money spent for ESG. By creating a more intuitive experience, ESG should be able to lower training or onboarding costs associated with this software.
Throughout the 7 months of work, we also met with ESG stakeholders twice a week to get demoes of the existing software and workflows. This was key to gain a firsthand understanding of what could be improved. We used Zoom to record these work sessions.
To kick off the project, we went onsight to their offices in Atlanta for a journeymapping workshop. The goal of this visit was to not only meet with the stakeholders and align our goals, but for us on the MojoTech side to gain a better understanding of the existing functionalities of the software, how different individuals in different roles (personas) use it differently, and what's successful or what can be improved about their current workflows. Below are a few screenshots of the journey map workshop:
We created these categories according to the specific tasks that different personas take on, including Billing Analysts, Customer Support Representatives, and Operations Managers.
Developing personas was certainly an integral part of this project for a few reasons. The software is a centralized platform where individuals with different roles and duties go to accomplish their tasks. As a result, it was imperative to understand what each persona's workflow and goals looked like to help them best accomplish their goals.s>
We ended up deciding to restructure the entire navigation based on these personas.
Restructuring the information architecture was quite an iterative and collaborative process. One of the first things we had to do was to go through the existing site and audit the existing navigation, which was absolutely horrendous. There were so many sub-menus within sub-menus with functionality that hadn't been used in years. Below is a somewhat final draft of the information architecture.
The search branch is where CSRs spend 95% of their time. The typical workflow looks like: customer calls and has a question, CSR searches for profile, CSR answers questions. Billing Analysts spend most of their time under the Billing section, where they review bills to make sure there aren't any conflicts. Their primary goal is to get as many bills out as possible to customers. Enrollment analysts work with customer enrollment applications, premise applications, meter set ups, and more. Finally, administrators can configure settings for the entire platform on both the enterprise and consumer side.
I designed and iterated on over 250 screens throughout this project, so I'm just going to show a few key screens.
The customer search screen is where CSRs begin. Referring back to the journey map, the first thing CSRs do when on the phone with a customer is to gather basic information about them to look up their profile in the system. In the upper nav, there are two tabs--"customers" and "corporate". Customers are individuals like you and I, while the corporate tab is used for commercial or corporate properties. The CSR will use the data found in the table below the search fields to find the profile. The left two columns are fixed.
The customer portfolio view is organized into various modules, with the most important pieces of information at the top. Within each module, we provided additional menu options specific to those buckets. Before, these menu options were only available in the global nav. By eliminating it from the global nav, the CSR experience becomes much more focused.
Another key area of focus was consolidating styles, such as this payments and adjustments table below.
Because this platform is so data heavy, there was much design consideration around these tables. They had to scale well across a variety of different pieces of data, from numerical to long, text strings. Many of the tables have some sort of identifier which we made a link, which would either go to a PDF view or a separate page. We also decided to use a breadcrumb navigation to help keep the CSR's informed of what "layer" of information they're on. They could also quickly navigate back to root level pages with this UI pattern.
We also decided to use modals for many tasks to provide fast, focused, contextual interactions without totally leaving the original experience. A good example is paying a bill, or setting up a recurring payment (above). Once the action is complete, the CSR can revert back to the portfolio view automatically.
Let's move on to some key screens under the "Billing" tab.
The Billing tab is where Billing Analysts go through hundreds, if not thousands of bills that have had "warnings/exceptions", which means that there was some kind of issue around the bill that stopped it from getting sent out to the customer automatically. At the top, there are 3 high level statuses that give the Billing Analyst an overview of how many bills they have to process or have been processed. Below, Billing Analysts can filter by warnings or exceptions. This is especially important for teams with multiple billing analysts so there's no overlap or conflicts between them. The "Assign Exceptions" CTA is present for Lead Billing Analysts to assign exceptions to their team members, essentially filtering bills to clear for them. And below is a table that displays all the necessary information necessary for a Billing Analyst to try and resolve the bill.
A major complaint from Billing Analysts that we solved for was how convoluted resolving a bill could be. There were over 50 different types of exceptions/warnings, each with their own recommended steps of how to resolve them. BA's had to refer to a 75 page PDF to look for this information, and it would take them months if not years to memorize these steps. As a result, I added a "Warnings/Exceptions Details" panels, which is accessible by the "View Details" button under the Warnings/Exceptions column in the table. The exceptions would be listed, with recommended steps of how to resolve them. We also included menu items that would help refer BAs to the pieces of information they'd need to solve it.
Once exceptions have been resolved, a BA then selects the bill and can select from a variety of menu options appropriate for the bill.
These are just a couple of the main workflows that I'm showing in this case study. If you'd like to see a walkthrough of the rest of the problems and workflows we solved for, feel free to reach out!
In addition to delivering over 250 mockups to our client, I also created a comprehensive styleguide.
These are just a few of the 35+ styleguide pages. I heavily document the different UI elements, possible states, components, and even individual page behaviors and descriptions (because I never really interfaced with an engineer). To view the full styleguide, click here.
This was my first time working with such a large piece of enterprise software. On top of that, ESG is an energy company, NOT a tech company. As a result, their product development processes were certainly not 'agile', which made it difficult to move forward at the pace I wanted. Often times, we'd wait for feedback or approval from ALL the stakeholders, which would sometimes take months. Furthermore, the original piece of software they developed was so archaic and so disorganized that often times I felt overwhelmed. Luckily, I worked with a great project manager to get as much done as we could. Unfortunately the contract ended before we could touch every single part of the platform. Overally, it was still a great learning experience!