Continuous Design

Continuous Design: One eye on the horizon and the other on the next wave
Maria Skaaden, Continuous Design Practice Lead, Bekk Consulting
From the Design Operations Summit website:
How do you create the conditions for delivering a great customer experience on a rapidly changing platform? In 2016, Norway’s national railway company began building a new technology platform. As designers, we yearned to address the customer’s actual needs and desires, not just a fresh look and technical upgrade. But with no process, principles, tools, or internal design resources, where do you start?
She is going to share the journey she has been on with her small team of six designers. Their client – the railway – has gone from being a monopoly, to having to deal with privatization and competition. This work has given her a new perspective on how to organize design in a changing organization.
The railway has been in existence since 1883, and it has been a key part of the country’s history. They are focused on the service of taking the train – from commuters, to people going on vacation with their families. It’s good for the environment, too.
She is going to share some of the challenges they faced. The region has been through a period of privatization, first in Britain, then Sweden, and most recently in Norway. Train transport is heavily subsidized, so the government wanted to see if it can be done more cheaply. In contrast, Amtrak was created by combining 20 companies into one owned by the government. So, it was announced that Britain was the first of many to bring trains into Norway. What does that mean for a company that has been around for 150 years?
It means organizational change – it was a divorce. Trains and ticket machines were handed to the government, because they wanted to handle the main functions. This meant that the railway could no longer control all aspects of their service – they needed a new strategy, new business models. This was further complicated by the fact that the government was creating new ideas the railway was required to use. At the beginning, there were no designers or design processes in place. They knew it would be critical to deliver through digital channels (since they no longer owned the machines).
They had 20 developers working in Agile, but there is the risk of doing many waterfall design processes. The work felt like being a hamster in a hamster wheel – always reacting, not in discovery.
There were many hard technical deadlines. So, where to begin? She is going to share five true short stories of how they changed the work they did together to deliver better outcomes.
#1 Not the typical design challenge … She was discussing the goals with the project manager, and she wasn’t sure how she was going to contribute. They needed to carefully manage the timeline as the APIs were switched over. So, she was told that the design couldn’t change, and the starting point was clearly technical. After three releases in quick success, user feedback from the app store said “might as well stop working on it and go back to the ‘stone age’ at NSB”. There were 2 million people using the app, and they don’t want it to change just because it’s outdated. The design team simplified passenger categories and the checkout process for multiple users. But customers didn’t want to learn something new – they felt like they were living on a construction site, which ultimately damages the brand.
#2 War room meetings and waves ... Users were unhappy, but the designers clashed with the developers early on, too. There are four development teams, with 1-2 designers for each. The designers wanted to zoom out to look for improvements, but time was lacking. The team first started to talk about this approach – balancing the designers in the front, looking at the horizon, while at the same time keeping the engineers steering and focused on Wave 1.
The designers needed to help the engineers understand how the waves were connected. While a Sprint is two weeks, the Wave can be big or small – it’s about the goals and value of the planned release. By creating their own words for this approach, they established some shared ownership over the process. They started the process with a design sprint, which included everyone. This has become really popular – a way of getting familiar with design thinking, without calling it that. In this way, both the developers and designers got buy-in for their ideas. And the team learned Design Thinking. They don’t always have time for a design sprint, but everyone is included in design critique. And the developers understand the process better now, because they have been through it themselves.
#3 Getting in touch with our users … The have 160K users in our digital channels every day. We deliver design decisions, and we need to know if what we’re designing is the right thing.
This model comes from Paul Pangaro. The team could have a business or technical or user goal. And the users have their own goals, too. In order to address uncertainty, they needed feedback loops. It’s not enough to do lab or guerilla testing – ecological validity is important. We have to have the humility to work with customers to identify the most important solution through a co-creation process.
#4 Mending broken promises … On the website, they made a very simple button ‘give us feedback’. The mindset remains of them as a government agency, and it was hard to get buy-in for the tools they were building. So the did a duct tape and rubber band solution – the easiest thing they could make – and they did the same thing in the app. They got 2300 emails in the first year. She was sorting through these herself, and eventually she started to see patterns. Business outcomes and customer value might be different, but in some cases they are the same.
Eventually the developers were engaged, interested, and they wanted to help. One developer saw a simple problem like buying a return ticket, and proposed to fix it in a simple way – they were inspired, and for her that was an emotional moment. When you are receiving 40 complaint emails a day, the user is unavoidable, but now they have a problem of scale.
There are things they can’t control, like train delays. But, what promises can they keep? Buses take few passengers, so it takes more time. What promises can the digital channels help us keep? They started showing delays in the app, and enabled notification for changes to preferred routes.
#5 A new perspective on design. At first she and her team were told to please make the user experience the same, for now. In a year they have made positive changes. But what is more important is they have shifted the mindset of the product team and how they make products together. They now have a common language, they have several feedback loops in place, and better ways of delivering designs to the team in a new way.
How can design fit into agile development? She thinks that is the wrong problem statement. We need to create the conditions that accommodate design, rather than having designers become hamsters. How might that look like?
A wave might look like this – explore, develop, feedback, learning.
That continuous conversation is so important – you build to learn. When the learning goes up again, you might see a new star on the horizon.
That perspective is so critical – both the wave and the horizon. No one process that works for every team, but she hopes it inspires us to create even better conditions for designers in our teams to deliver great experiences.
Pingback: Design Ops 2018 – Recap | Natalie Hanson