IIQ Studio

AUTOMATED SOLAR SYSTEM DESIGN

When I joined Sungevity in 2015, each solar system design was manually created by engineering experts. The process was time consuming, expensive, and the software was slow and complex to use.

I was part of a project to update Sungevity's solar design tool. This is the story of creating 'IIQ Studio' – a webapp that enables solar sales professionals to provide accurate, automated solar designs for their customers.

OVERVIEW

Since 2007, Sungevity has become one of the largest providers of residential solar in the world. The company first achieved success through its revolutionary Remote Solar Design (RSD) Tool. The RSD Tool enabled the company to design accurate solar systems on rooftops using publicly available satellite imagery, and providing potential customers with accurate quotes for installation. By the time I joined the organization in 2015, the RSD Tool had become outdated. The software wasn’t scaling with the business, and the programming language used no longer fit into the technology stack adopted by the rest of the organization.

MY ROLE

I led the design of IIQ Studio for Sungevity across desktop and tablet platforms. I presented works and research to executive leadership to gain buy-in and align with defined business goals. In addition, worked closely with a project manager to plan and scope designs, and collaborated with a small development team on frameworks, prototypes, and styleguides. Example responsibilities and artifacts include:

User journeys, task flows, wireframes

UI mockups, prototypes, and design specs

Usability testing

Product and user research

Persona development

Design facilitation and workshops

SETTING THE STAGE

The Challenge

We were challenged to replace the Remote Solar Design Tool with an updated product leveraging new, bleeding edge technology. The new tool was to provide more accurate system designs to a larger market, and adhere to the technology framework the company had established since its inception. Our success depended on a few important factors:

Learnability - the existing tool was difficult to learn. New employees took upwards of three months to get up to speed, with intense training for the first month, and still required quality assurance checks and regular design revisions.

Audience – the existing tool was built with solar engineers in mind. The company wanted to scale the tool to meet the needs of three user profiles: Solar Engineers, Solar Sales Consultants, and (eventually) Solar Customers.

Devices – the existing tool was built exclusively for desktop users. The goals defined by Sungevity leadership centered around a responsive design that would meet users in their specific context.

Product Vision

Our vision for IIQ Studio was to be the fastest, most accurate resource for potential customers to explore going solar. We wanted to provide customers with a simple interface to locate their property, review and customize a potential system design, and understand the impact it would have on their monthly energy bills. As a final step, customers could initiate their purchase, all without the current intermediary step of talking on the phone. We called this process Solar Online.

We knew this was a lofty goal that would take some time and a number of strides from our starting point, but we worked with the business to build a strategic path. When we started, all system designs were completed by a team of Solar Engineers. Our first step was to bring system designs one step closer to the customer by enabling our Sales Consultants to co-design with customers. We defined success as Sales Consultants using IIQ Studio to design sellable systems.

PROCESS

Discovery

In order to drive product planning, I conducted user research. Our goal was to learn more about our initial target user, Solar Sales Consultants, and collect insights to test some of our key assumptions. We wanted to learn about their sales process, and more importantly, their existing knowledge about designing rooftop solar systems. Our key insights:

Sales Consultant suffering interface overload.

Promote the Conversation

Sales Consultants were expected to complete a system design while having a conversation with the customer. They wanted to make sure the tool wouldn’t distract them from keeping the customer engaged and discussing their solar goals. We had to build elements within the interface that had simple, repeatable steps and promoted the conversation.

Accuracy > Everything Else

We had both quantitative and qualitative data that emphasized the importance of an accurate initial design. Customers were far more likely to cancel their solar purchase if Sales Consultants had to get back in touch for a redesign or change order because of a design mistake – the company lost all credibility. Our tool would have to include features to mitigate error, and coach users toward a sellable system.

Meet Customer Motivations

Our Sales Consultants had robust experience working with customers to understand their solar motivations. They knew different motivations resulted in different design layouts, and therefore a different bottomline for customers. We needed a tool that had the flexibility to meet the various customer goals, and provide real time data for Sales Consultants to communicate over the phone.

Product Research

An important detail in the discovery phase was gaining a better understanding of existing products that were intended to serve the same, or similar purposes. I collected an array of samples from competitors and allies in the space, and analyzed the process they presented to their users. In addition, I conducted heuristic evaluations on the products to learn from existing usability problems, and target some successful features we could build on. By composing a competitive analysis, the team was better equipped to articulate the product strategy, and avoid some of the pitfalls that would put adoption at risk with our user base.

User Flow

I leveraged our learnings from the competitive analysis to help articulate the key phases of the remote system design process. However, most products presented the phases in a different order, and each phases had a number of sub-steps. In addition, I wanted to make sure the process we defined met the cognitive model of our lead persona. I worked directly with subject matter experts and a sample of our target users to separate each step on sticky notes. Each participant moved the steps around until they captured their ideal process, adding feature ideas or suggestions. After working with several users, a clear pattern set in and helped crystallize our users' ideal process and optimal task flow.

Exploration

With our user insights and a strong grasp on the tasks, I set about drafting early explorations of the application framework. We wanted the arrangement and layout of the user interface had to lend itself to the process of the system design experience. Once I had filled a trashcan with sketches of layouts and components, I drafted quick, low fidelity mockups to review high level concepts with the team.

High Fidelity Mockups

Working iteratively in sketches and low fidelity mockups helped quickly eliminate a lot of ideas that simply wouldn't work for our users, and gave the development team a forum for gauging feasibility of features and components. After gaining consensus from the team and approval from stakeholders, I had enough footing to flesh out the designs more concretely.

Validating Designs

Prototyping was the most effective way to get meaningful feedback from both users and developers. Once I had a set of high fidelity mockups built in Sketch, I uploaded my designs to Invision, where I could solicit additional notes from my team, and build a clickable prototype to review with our Sales Consultant users. While Invision had its limitations in relation to our tool, it was important in helping us finalize the system design flow, and it helped us collect more data around the limitations of our sales users.

For more nuanced, microinteractions and important screen transitions, I used Keynote, and worked with a dev to hammer out the details.

PIVOTS AND UPDATES

Progressive Disclosure

The initial phase of IIQ Studio was to build a tool that allowed Sales Consultants to design sellable solar systems. Shortly after our development team had our beta product up and functional, we worked with our target users to collect feedback and make quick adjustments. Before long, our pilot sales team was working one-to-one with customers, selling systems through IIQ Studio. Before our team could celebrate, we had to turn our attention to our next user group – Solar Engineers.

The original Remote Solar Design tool was degrading quicker than expected, and we were under a time crunch to scale the feature set of IIQ Studio. Through research with each of our targeted user groups, we knew that skill level and solar knowledge was going to vary widely. To solve this problem we planned IIQ Studio to be a tool that unveiled more of itself as skill levels progressed, a process known as progressive disclosure.

Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone.

— Jakob Nielsen

Rather than burden all of our users with a complex set of features they would rarely use, we deferred a more technical set of system design features to our solar design experts. Our Sales Consultants could continue to use the simple procedural interface to meet the energy goals of customers, while our Solar Engineers leveraged the additional IIQ Studio features to finalize designs, if necessary.

Detailed Design Specifications

In an effort to build more consistency throughout our software organization, product leadership wanted to work toward implementing Google's Material UI guidelines across new initiatives. This, in conjunction with brand guidelines, largely drove the visual presentation of the interface. I worked closely with a developer from the team to understand the constraints of the system, while still working to meet all the goals defined by our users and the business. To assist in future decision making, and to help the product scale, I created style guide documentation for the product, detailing the components, buttons, and states of the application.