Plant Optimizer

A digital power plant “twin” that gives recommendations to make a physical plant more efficient, reliable, and cost effective.

Problem

A research team was rapidly approaching their due date for a demo. Due to the need for a quick turn around, the team reached out to my company to help complete the demo for their client. The demo was for a product that would give recommendations based on data from power plants.

Users & Audience

The client had already identified the users and audience for this project. The personas that we were concentrating on were:

• Plant Manager:
  In charge of every day operations of their plant.
• Asset Manager:
  In charge of watching over a fleet of plants.
• Executive:
  Interested in how well all of the fleets in their company are doing.
• Trader:
  Concerned with the market trends for selling power and deciding when the plants should power down due to decreased demand.

These personas made it obvious that there needed to be multiple views in the system.

Product Team

My role throughout this project was as a UX Designer and Developer. With the first half of the funding, the team consisted of myself and a second UX Designer. With the second half of the funding, the team consisted of the original team plus two developers. During the second half, everyone was involved in coding the application. Throughout the project, we created two clickable demos for Subject Matter Experts to be able to present to the client.

Constraints

• Axure RP’s Memory Leaks
  At the time we were creating the clickable demos, Axure RP had a known memory leak issue that limited how complex the prototypes could become before the application would crash. We dealt with many lost files and updates. With the later update from Axure RP, the application ran smoother, but I had definitely found the breaking point of the application and learned not to push clickable prototypes too far without going to code.
• Working Within Predefined Design Structure
  Throughout this project, we had to work within the interaction design and high fidelity the research team had already created. This and the short timeline led to feeling limited in the ability to improve the overall UX of the product. The research team did find some smaller changes to add into the designs from our insight.

Design Process

Due to the situation the client was in, they approached us with the problems already defined for the project they were working on. We immediately delved into a discussion regarding what they had already completed and what their goals were. The research team provided us with high resolution assets for the application and some wireframes with notes about the interactions.

We had two weeks to work with their team to turn their ideas into a clickable demo. During this time the research team was still coming up with new ideas that they would pass to us every morning. We worked with the client to make realistic estimations of which interactions we could legitimately complete with the time constraint. We decided to only create happy paths through the application, made the interactive charts static, and ended up not making every link function. We were using Highcharts to create the images for the charts, but due to the tight deadline and limitations of Axure RP, we couldn’t take full advantage of what Highcharts gave us. During the two weeks, we worked 16 hour days and weekends to finish the demo. We were able to export a full clickable demo out of Axure RP into HTML, making changes right up to an hour before the presentation.

Results

The first demo went off without a hitch and it got the stakeholders very excited for what was to come. After the first demo we knew that to continue with more ideas to get ready for a second demo that we would have to transition the prototype into actual code. Changing to code would give us more flexibility and the ability for the rigged demo to work better.

Shortly after the demo was complete, the price of oil dropped and they couldn’t continue to fund the project past the point of a rigged demo, so the work we had started to move the project into actual code came to a halt after we had completed recreating in code what we originally did for the first demo in Axure.

Retrospective

Limitations of Clickable Prototypes
During this project we truly learned when wireframes and prototypes have hit their limit. You can do and show a lot through wireframes and prototypes to gain early and often feedback, but at some point they become too cumbersome and a waste of time and budget when you could be developing the product instead of trying to fit more functionality into something that will ultimately be thrown out. It is truly a delicate thing to balance.