Spikes and sprints
Happy new year! I’m now two months into my time as the first UX design professional for renewable energy gurus, DNV GL. I’ve joined a large and well established software group who usually work in separate teams, each focusing on one of DNV GL’s dozen or so software products. For the last few years, each of these teams have been tackling UX design in their own way, with a mixed bag of successes and failures that unfortunately become apparent in the products as they get used in the real world.
Everyone involved in software development here seem to agree that someone needs to tackle this problem, implementing a reliable and repeatable process for good design. This person also needs to be the catalyst for a touch of culture change at DNV GL, making the software teams better informed about their customers, and the user experiences better across the board. Challenge accepted.
Without much more to go than that, I was thrown into a world of industry-specific jargon, deeply technical software products and developers working at impressive pace to meet their bi-weekly sprint deadlines. Getting familiar with what’s going on, and making myself of value to the team has been a little like running to catch a moving train.
At first I went with the flow, so to speak, and joined many of the teams for their daily scrum meetings – or at least those in Bristol. There are others in both Oslo and Glasgow – I began by responding to their UI design requests by laying out new screens or building icon libraries. It became apparent very quickly that designing in this way, following an agile process, was reactionary and for the most part, too late for the UX designer to have significant impact on the experience. By the time the designs are being coded in a sprint, they are already well defined and the deadline is looming, so any changes to the established norms have to be minimal by necessity. I was going to have to get further upstream if I was to make a real difference.
The sprint work deliverables, I found out, are determined by the product owner, who’s role is to look further ahead and plan what should go into the software, juggling the needs of both users and the business. Offering my help, I found a couple of owners in particular were eager to recruit me as their busy schedules afforded them frustratingly little time for long term design and planning. My UX role meant I could put more time and effort into mapping out future development, and afford the time to develop totally new concepts outside of the sprint cycle.
I now have two long-term projects in this manner, which are referred to as design ‘spikes’ in the agile process, happening some weeks or months before the related sprints begin and developers begin coding. I am working on Bladed – the industry standard for wind turbine design, and also DNV GL Energy’s flagship product – and WindFarmer, the leading tool for wind farm layout and planning. The design spikes free me up from the constraints of the sprint cycle, and allow me to do the required research and design work for big changes in the products, which the teams unanimously agree are long overdue.
My first and most important task for both of these projects has been user research and persona creation, as before we can design effectively we must first put ourselves in the shoes of those that we design for. Whilst the organisation have some of the required knowledge about their customers, it does not reliably make its way through the design process to inform sprint work, often leaving developers to make well-intended guesses about user needs and expectations. I’m currently spending much of my time face to face with the people who use our software, gathering the information we need and building us a more solid foundation for our design work. More on user research next time.
My weeks are currently balanced between short bursts of agile development work with the developers, and ongoing projects with the product owners to design future software releases. As the sole ‘UX guy’ I find myself in huge demand as every project could potentially benefit from my attention, so meticulous planning, multi-tasking and shrewd prioritisation have become critical. Above all else, it’s encouraging to have a great amount of interest and support from all over DNV GL, and such a positive response so far to my work together with the teams. If the last two months are anything to go by, the year ahead should be an exciting and dynamic time for software at DNV GL.