The role of UX in the renewable energy industry
The renewable energy industry, with its technical focus and high stakes projects, isn’t an industry people usually associate with user experience design.
But over the last few years, our small agile software team at a renewable energy company has managed to make a real impact through our determination to improve UX. Only by delivering good software and by proving design and research make a real, measurable benefit to business have we convinced those around us of the worth of user experience practice.
Our team looks after over a dozen software products for the industry — a range of desktop and web software used by engineers around the world to design wind farms and solar plants, and tinker with emerging technologies like wave and tidal power.
Our users are a relatively small and specialized group, but their use of our products has enormous impact on renewables projects around the world. To ensure we build valuable software, we’re co-designing and testing every week with a network of users worldwide, from solar farm designers in Barcelona to weather modeling experts in Shanghai.
Not long ago, this collaboration wasn’t happening. I’m going to tell you how all of that changed.
When I began at DNV GL as the team’s first designer, the development team and I were asked to redesign a product called WindFarmer, which helps engineers design wind farms and estimate the energy they’ll produce — placing wind turbines on a map in optimal locations to get the most power. It’d been around for over a decade and was respected in the industry for the accuracy of its estimates, but it’d suffered in recent years by a slump in sales and emerging competition.
Recognizing the need for innovation, the developers had already successfully adopted agile practices in order to deliver updates more quickly and flexibly. In a bid to make sense of a sprawling pile of user stories, our scrum master began applying Jeff Patton’s story mapping techniques, a method of mapping out the size, scope, and priority of a product on Post-it notes.
Working with the product owner, he found this to be a brain-melting exercise that took much longer than expected. Enlisting the help of an experienced user accelerated the exercise. It was obvious the team needed to get to know their users better.
“Our users took matters into their own hands because their needs weren’t being met by our products.”
To start filling the gaps in our knowledge, I watched users at work. I was surprised to find many people using spreadsheets alongside the product — helping them organize their projects and get through their work more quickly. Our users love to solve problems, and when their needs weren’t met by the products, they took matters into their own hands.
The product wasn’t bad, it was just off target. We needed to enable better communication between the development team and our users. We needed confidence we were building the right product, and we needed a structured design process to get us there. But we weren’t yet sure what that process was.
So we needed to identify UX design activities that would help us build complex engineering applications — not only what to do, but when to do it. The work had to fit with the agile methods used by our team.
When we began, we had no idea which techniques would stick. It took a year of experimentation to really nail what worked for us, and I’ve outlined them below.
1. Guerrilla personas
Invited to a meeting with Windfarmer salespeople from around the world, I took the opportunity to tap into their direct experience with users. I ran a spontaneous workshop to create personas and user goals. Enthusiastic to contribute to the design process, the sales team made short work of the task I’d set for them.
2. Task mapping
Needing to learn how people used the current product, I observed engineers at work and made visual task maps of their work processes. The maps made it easy to understand task order, priority, and time taken. For the first time the team had a detailed picture of how different people used our product, and we could appraise where we were strong and where we could add value.
3. Sketch sessions
Our product owner had lots of good ideas but was struggling to convey his vision to developers. The breakthrough came when I got paper and Sharpies and sat down to sketch UI designs with him. Noticing the sketches on the walls, people would stop by on their way for coffee and contribute. It was a great way to get the vision our product owner had out of his head and into a format the team could build upon.
4. User testing
It used to be tough for the team to know if we’d really made a new feature intuitive and everyone had their own opinion. Introducing user testing cut those arguments short with hard evidence.
Once we had a functional prototype in real code, we would get users to carry out repeated tasks with old and new products for benchmarking. We studied time taken, where people got stuck, and high and low points of the journey.
For the first time ever we could measure subjective qualities like usability. Quantifying the impact of design began to convince people around us that UX delivers.
5. User advisors
We often needed advice from domain experts to really understand what users were up to with our software. We asked one of our more experienced users to sit with our team part-time. He quickly distilled specialist knowledge for us and ensured we were up to date with the current engineering practice. Today, we’ve built a network of specialist advisors around the company, and we call on them for assistance whenever we start scratching our heads.
6. Teaching others UX skills
Over-worked and wanting to go home at 5pm more often, I began teaching developers how to conduct user research, write user stories, and even design UI layouts with PowerPoint.
We found when team members are empowered to be part-time designers, they’re more flexible. More direct contact with users means more empathy and less time in meetings. An unexpected benefit was the sense of ownership the team felt over designs we’d all contributed to. For us, it was better the designer relinquish some control and instead let the team own the experience.
7. The perfect pairing
Within the first few months of the project we’d made lots of improvements, but the experience was inconsistent. The team needed a clear vision and design patterns to work to.
I tried a design spec document at first, but even though it gave a coherent vision, it wasn’t a good fit with agile practices — it took too long to read and to maintain. We eventually settled on a pairing that works for us: a story map and an interactive prototype.
Story maps tell devs what users need to do and why, and prototypes give them guidance on how they’ll do it. These form a living, visualized spec that’s continually iterated as we discover more. For the first time, the same understanding of the product was possible across the entire team.
When we released a beta version of the new product for trial this year, it was a marked improvement over the old. Though it didn’t yet do everything we wanted, it served as proof that we could deliver and that UX design was of real, measurable benefit.
By tackling this project we’re more confident as a team now and everyone understands how and when to use UX work in the agile process. Managers now come to us earlier for help defining what should be built and how, rather than telling us. Starting with the adoption of agile, the last few years have seen a real culture change in our group, and the transparent and inclusive nature of the design techniques we adopted have only encouraged that positive change.
The challenges around this project were huge, but we can proudly say we’re using design and development knowhow to help the world adopt renewable energy. There can’t be many more worthwhile goals than that.
Below, watch Matt’s talk on how UX is helping shape the renewable energy industry.
Originally published at blog.invisionapp.com on January 4, 2016.