Consumers Energy Mobile App

Consumers Energy is a public utility that provides natural gas and electricity to 6.6 million of Michigan's 10 million residents. The Energy Mobile app project was a project to help CE bring their large offering to reach their customers more conveniently, especially when needed, as mentioned in an outage scenario.

Overview

Can you remember the last time your power went out? Or maybe a time you didn't have running gas to your home or apartment? I'm hoping you never have to face that situation for most of you, but for the others, what would you do in that scenario? How would you go upon finding a solution? Maybe the service provider has information on their website.

But wait… there's no way to access your utility companies' website because your power is out. We can use their mobile app, but just your luck, there isn't one existing with your provider. Imagine this situation is potentially a reality for some folks in Michigan. This was an issue for Consumers Energy, which brought their Energy Mobile app project to fruition.

Scope‍

Consumers Energy is a public utility that provides natural gas and electricity to 6.6 million of Michigan's 10 million residents. The Energy Mobile app project was a project to help CE bring their large offering to reach their customers more conveniently, especially when needed, as mentioned in an outage scenario.

Audience

The target audience for the project on residential customers of Consumers Energy. The primary goals of the end-user are:

• to help them understand their electricity and gas consumption to help lower their bills
• to have the ability to customize their communications from the application
understand if there is an outage and what actions are in process to reach a resolution

The business had its goals set on having its customers interact with their utility more to increase satisfaction, ultimately for longer-lasting loyalty. Reaching loyalty with their customers forms the basis for a utility looking to amplify the experience they offer significantly.

Process

The project was broken into two phases, to reach an MVP of their offering created into a native mobile app for both iOS and Android. The first phase focused on designing and developing only the app's core functionality & components and creating and gathering branded content. The second phase was to build out the rest of the screens in terms of features divided into two-week sprints. The full project duration for five months, with the first phase being two months and the second lasting three months. The scope account for the following features:

• account overview
• viewing and paying bills
• understand usage/consumption
• communication on outages
• alerts & notifications
• billing & payments
• customer profile information
• customer support
‍
Design Systems

One of the first activities we completed was to create assets for a design system, which is a collection of UI components, text styles, colors, and images. It helps keep the project aligned across the technical teams and serves as a documented series of rules, principles, and best practices. These assets act as a source of truth for the various functional teams. We had to have a full functioning app by the end of the eight weeks. We started on the design system as soon as possible to give our development team a head start. Usually, these documents are composed of multiple design files of different aspects and features of a product. The assets most widely used across the files get selected as an asset of the document, with edge-case scenarios.

A style guide/design system is complicated when there haven't been any means of design created prior. Although we had a bit of a starting point for the general components, we eventually would customize each subsidiary's needs and their respective target audience. Also, designing UI components without having a clear path of all the different directions a product can go can be extremely challenging. However, based on the scope's overall objectives, our team mapped out the tasks that needed to be complete within each app section. From here, I relied on different sources to help come up with the first pass of the design system, such as on previous usability test insight documents, design patterns (bending when necessary), and the company's current style guide. (The style guide also needed to be tweaked since it was tailored for web-only use). Since we were planning for accessibility testing at the end of the next phase of the project, the company style guide also had to be tweaked as most of the documentation was tailored for web-only use. See below for the first pass of the design system:

Mapping Out the Architecture

To help aid with the understanding the full plan of of how each section of the application would connect together we utilized a high level view of the product.

Understanding the Flow

Utilizing user stories, we broke each section out into more detail to further define the architecture of each feature. User stories act as brief statements that include the role of the user and activity they wish to perform in the context of a constraint. Once we had the design system in place, we focused on utilizing the assets to compile each feature's necessary UI—the first being login and registration.

Helping the Developers Ease into Code

We utilized Zeplin to integrate each of the screens to help having all assets in one location and maintaining consistency along development. Our developers found a lot of the aspects and features of zeplin helpful for any of the front end elements.

Challenges

As we began to design the project's initial screens, we were initially given direction from our product owner to focus only on iOS due to time constraints. We had one sprint for each group of features (around ten days or a week and a half) to complete the designs. The client wasn't interested in seeing wireframes even after showing examples to help demonstrate the value. I began to fear design debt creeping upon the project but had very little time to react aside from completing the current sprint designs. Within each sprint, as with all the designs, I would try to meet different aspects of the app for Android but would often run out of time until the next sprint began. It was a massive lesson for me to emphasize how much of an impact postponing android designs could have on the project's overall progression to the leadership on every project.

Once the fear of design debt began to be overbearing as we completed the second phase, I realized enough was enough. Otherwise, the project wasn't going to be complete in time. I first identified to our project's leadership some of the (rather large) gaps between operating systems that we would have to address sooner or later, which was also going to require a fair amount of time.

After various discussions and ultimately deciding not to push the timeline, we agreed upon adding another designer. The scope of the last phase of the project wasn't as large as the previous phases, which helped tremendously. Luckily we were able to add another junior level designer who initially focused on recreating the already created elements in iOS to Android.

I can't even describe the weight that felt lifted off my shoulders and how helpful having another designer was. Just having the comfort of knowing time could be spent to assure the designs were appropriately created and non-rushed was priceless. The other designer's helped us get the designs done a sprint early.

However, the ultimate goal for this project was to help users pay their bills on time and by adding another way to access their account via their mobile phone, gave the app an increase in account & bill access to users by 62%