Collaborate, get stuff done


Four months ago I joined DNV GL’s software team as the first in-house UX designer. One of our main challenges so far has been figuring out how to get the most out of design practice. How can my design background help make better software from day one, and set up a better way of working together for the future?

Here’s the problem we face. 30 talented software developers sit in one building, making products that are updated every six months. These products are deep engineering tools, which enable those with the right technical knowledge to design wind turbines and wave energy converters, plan wind farms and predict the electricity they’ll produce.

In the other building sit a team of turbine engineers, who use these tools daily to do the designing. Machines such as the enormous Samsung Heavy Industries turbine prototype in Fife, Scotland were designed using our tools. This is the biggest turbine in the world with the potential to power 4800 homes, so the investment is frankly enormous. With that kind of responsibility, the tools need to do their job well, no excuses.

Our products were originally designed by experts for experts. They are powerful but intimidating, and largely incomprehensible to the layperson. You need deep knowledge to really understand what’s going on, and this makes any kind of design appraisal and discussion very difficult because everyone involved will have different experience and understanding. The developers need to know what to make, and the customers (our engineering consultants) need to communicate what they need.. A great design process would have the two groups constantly communicating, working together to create new ideas and iterate good ones. This however, is where things often fell down.

What has been missing has been someone who can get to the bottom of what customers need and envision how the product can be made to better serve that need, thinking outside of the constraints of what already exists. The vision must be communicated to the dev team, and it’s design refined so that it is achievable and realistic. This is where I discovered my job.

I was asked to deliver a new vision for WindFarmer, our leading product for designing wind farm layouts. It’s been in the market for a few years, but is recently being threatened by emerging competition. The product owner knew the key to success was a product tailored for user needs, but wasn’t sure how to identify them or what to do next. Previous attempts had resulted in huge, detailed spec documents that amazingly were never even read. To make matters worse, the mis-fires had sapped motivation and energy, leaving people reluctant to tackle the problem. I was given two weeks to turn this situation around.

I cleared my schedule to focus on only the task at hand. Then I arranged for one of our target users – a wind farm energy analyst – to sit at the next desk for a few days. I had to wrap my head around how he uses WindFarmer in his job, and identify which parts of his process needed our attention. What was important to him, and where could the software add real value by making his life easier? Over the next three days, he walked me through his work, and I asked him to demonstrate as he went. Often, when dissatisfied with WindFarmer he had hacked together his own tools in Excel to do the job he needed. Using research techniques I’d learned through ethnographic work during my time at Kinneir Dufort, I knew how to identify what was significant, when to probe deeper to extract more information and when to shut up and listen. I was also able to process this and begin creating new ideas on the fly as a result of what I was hearing.

As this was a new and unusual sight in DNV GL, I tried to make the design process transparent, printing and sticking everything on the corridor wall by my desk for everyone to see as they walk past to the kitchen. The sketch wall soon became a gathering point for developers and product owners who often stopped by to discuss new additions or show their other colleagues. Visualisation was the key here – sketches and Balsamiq mockups allowed everyone to see the design taking shape in a way a spec document wouldn’t. I encouraged a positive and open environment where everyone could stop me to ask a question or add their own thoughts to the wall.

By the end of the first week, we had a taskflow map up and had agreed precisely what the product had to deliver. Sketches had given way to Balsamiq and eventually more precise Adobe Illustrator screen layouts. A rough product architecture map was also present. It was still a concept, but it was on target and felt real enough that others were taking an interest again.

By the middle of the second week, impromtu gatherings were happening daily around the sketch wall and cross-team communication was happening as a result. It was wonderful to see a resurgence of interest in the project. Though there wasn’t time to tackle every part of the UI, we knew enough to agree an over-arching architecture, general UI layout and rules. Critically, this would be enough for the dev team to begin coding without having to wait for every last detail to agreed.

I would have to handover some kind of document to communicate the concept to them. Having stopped by the sketch wall a few times, many of the team were already familiar with the ideas, but needed something to refer to over the coming months. Learning my lessons from the hefty and ineffective spec documents, I made a design guide that was light, very visual, and which related everything back to user needs, the driving force behind every decision.

The two week ‘design spike’ was a tremendous success, and has set the template for projects to follow. I am already into a similar stint of work for our flagship product Bladed, and am confident for similar results. Some key lessons have really stood out from this:

  • Arrange time with your software’s users, get familiar with them and observe them using the product; this is the quickest way to really understand what they need.

  • Listen to ideas from any corner and collaborate with interested parties to create concepts. The designer is sometimes better as the facilitator, rather than the originator, and ideas will benefit from different points of view.

  • Visualise your ideas, however rough the sketches may be, and display them somewhere where others can see and have space to stay and discuss. You’ll be surprised how important this place will become.

  • Encourage an informal environment of honest and frank discussion, where anyone can contribute. The UX Design department can be the place where things just happen quicker!

Matt Corrall