Why getting together matters in design
I was in Barcelona recently with a colleague, running a story mapping workshop. We’d been asked to help design and build a brand new product, and flew out to spend three days with our target users and stakeholders- a team of engineers who help design solar farms for clients. Imagine a huge collection of solar arrays in the desert, row after row of them stretching on for miles, and you begin to get a sense of the scale of these enormous projects. Our job? Build software to help make this work easier and more accurate.
I was amused at the reaction when we arrived, armed with post-it notes, sharpies and rolls of paper. Some of the team couldn’t believe we were really ‘software guys,’ partly because there wasn’t a computer in sight, and partly because we had insisted on meeting face to face to figure out what to make rather than using IM, email and video conferencing.
Working for a global firm, many of my projects require collaborating with colleagues in the US, Australia, Spain, China and Denmark, to name a few. By necessity I’ve had to get better at conducting effective research and design despite distance and time between collaborators. With screen sharing and recording tools, research works well, and our team’s scrum meetings can still work with remote participants. That said, there are often times when getting on a plane is by far the cheapest and quickest way to make real progress. I’ve become a real fan lately of dropping the documentation and meeting requests, and just getting together to really focus and nail the problem together.
For our solar farm project, despite everyone’s best efforts it was clear that figuring out the product requirements was a slow process over phone or video. In the waterfall world, bullet point specifications can still be the norm and this project began with a fine example. Whilst the budget and project plan was set, the software team immediately knew we had a thousand questions to ask and a concept UX phase to do before we would have a clear enough picture to start coding anything. Our team has become adept at story mapping in the past couple of years and we tend to work from a story map coupled with a conceptual Axure wireframe that evolve together over the course of development.
We persuaded our Spanish colleagues it was well worth us getting on a plane, and over three days in the Barca office we rolled up our sleeves and together story mapped the entire user experience for our first few releases. There was confusion, there were disagreements, there was exhuastion, but in three days we did more to de-risk the project and ensure a solid first release than we had done in several months previously. By the end it was satisfying to sit in a room, and look around at the post-its covering all four walls, knowing that everything was recorded and understandable. Workshop environments require people to switch off laptops, stand up, focus and engage, and that never fails to pay off.
This same point occured to me a couple of weeks ago when I was asked to help set out a product roadmap for another DNV GL product – one that forecasts wind several days ahead for clients’ wind farms. Despite this being a long-standing service with a resonably large user base, the team’s development process was unfortunately rather reactionary. Feature requests were sent via client liaisons and the software team built them one by one, the product growing organically without much idea how well it was serving user needs. It worked ok, but with little knowledge of how the product is used and what for, the team were unfortunately unable to satisfy their customers well.
I conducted a short research phase, task-mapping the work performed both by DNV GL engineers who maintained the forecast service, and external customers who used it every day to predict the wind. By spending a single day with a customer in Copenhagen, shadowing energy traders as they compared forecasts and sold production energy on the open market, I was able to learn an enormous amount in just a few hours. As with Barcelona, being there in person demonstrated real engagement and commitment on our part to build software that delivers. I think its fair to say that our customer relished the opportunity to have their voices heard by the team that will actually build their product.
The result? A solid understanding of user needs and the learning that with a series of minor UI and usability improvements, we can make a big difference to our customers daily work for relatively little effort. These insights could not have come from a waterfall spec document or even a conference call, it required a designer /researcher to meet users face to face, see them work and be able to quickly discern what matters, spotting opportunities the client themselves may not have realised.
Over my time as a UX designer I’ve grown more and more convinced of the value of getting away from the screen, meeting colleagues and customers face to face and really doing things the agile way. Stories, real life observations and quick and dirty whiteboard sketches can have huge impact for little investment. As I work in a global team there will always be a balance to strike, but our determination to always deliver means we’re getting pretty good at knowing how to get the most out of our time.