Maria leads the Continuous Design practice at Bekk Consulting, where she works with clients to deliver great experiences for end users. She was kind enough to sit down with us to discuss her passion for continuous design, and how she believes the future of UX will be impacted by the need to continuously iterate digital products.
Sofia: Let’s start with some background on you. What do you do at your company?
Maria: My name is Maria, and I've been working as an interaction designer for six years and now I'm the design lead on a big team here in Oslo. I work with a consultancy and we're currently working with the National Railway Company. The National Railway are changing their whole technology platform because of privatization.
We're a team of six designers, and I needed to figure out how we were going to help the National Railway solve these challenges that come with privatization; and the switch to a new technology platform and design. We had to keep the existing channels up and running (to sell tickets), and at the same time build new features, that we would continuously implement. So the old and new design needed to live side-by-side. We also needed to do research and learn how users actually experience and use our channels. To design so continuously has been a very new challenge for me as a designer, and also to be a design lead. I haven't done a project like this before, so I needed to figure out how to make a new design system and decide how we do research.
We actually tested a couple of products like NomNom just to see if these tools can be useful for us. But the challenge right now is that this is not a completely privatized business, so acquiring new software is a very bureaucratic process.
At the same time, I'm also leading a group in the consultancy that looks at the changing environment. Business is changing, digitalization is changing, DevOps, agile, all of this is changing how we do design. And we have to ask ourselves, “how do we adapt as designers?” and also as a team, “how do we design a process that accommodates design?” A lot of designers feel like they're running in this hamster wheel to just push things out.
Some designers feel like they don’t have time to do qualitative research anymore, and there's a big disconnect between quantitative data that we get from analytics, and qualitative data that we get when we talk to users or customer service.
Sofia: You’ve written about continuous design before most notably in this blog post - can you tell us more about the concept?
Maria: Absolutely. I started out as a product designer, working with physical products. And the design process I learned in school is a linear process - you do research, you do prototyping, you do user testing, and then it's done. You do user testing to reduce risk and to figure out if it works, and if it meets the user’s needs. But after the prototyping is done and the tooling is ordered from the factory, you're done, so you need to get it right the first time.
But when you do digital product design, it's never done. So continuous design is the perspective that design is never done. It's a continuous, circular process of designing, implementing, people using it in the real world, and the team learning about the user’s experiences. So you don't just make things and then produce them. It's designing and learning, and I think we've spent too little time learning because it’s often not a priority. You need to deliver the features that the users want in a good way at a very rapid speed. If you're Spotify or if you're NomNom, the users don't care - it needs to be fast. How competitive you are as a business depends on your ability to engage in continuous conversation with your customers through digital products. You can think of research tools as a way to be able to have that conversation with the users, to document it and be able to share the learning in the organization. You are giving the employees access to very valuable research, and at the same time, making the business able to check if it actually delivers value to your customers.
I think that was the starting point for me - the traditional design process doesn't work in a digital environment, because with digital products it’s not about reducing risk before you produce. It's about being able to have that conversation with the customers. I first read about continuous design from Jeff Sussna. He has a book that's called "Designing Delivery." It's really good, and I think he's the first one to actually frame the term “continuous design”.
Sofia: Can you give us a couple of examples of feedback loops a continuous designer can build today to help her team?
Maria: We made a button in our solution that says, "Give us feedback." It opens the email client and then you can email us feedback. So we get raw text from the users, and we get around 30 emails each day. Since we turned on that button, we've gotten approximately 2,300 emails. And they all come into us as Trello cards, forwarded from an email address. When they come into Trello, we sort and prioritize them. Some people want the same feature and then we bundle that up.
The whole team has access to the Trello board - all of the developers and the product owner. The developers are also sorting cards, and they're going into the Trello board to check new emails coming in. So I think when you start to put the responsibility of the solution and the unfiltered feedback to the team and to the product owner, I think everybody feels they have a responsibility towards the users.
Sofia: Do you have any examples of how NOT having a continuous design process made your job more difficult?
Maria: Here’s one failure that I’ll share relating to the National Railway project. When the train isn't running, you need to show people different options, right? So we sometimes setup buses instead. We hire buses, and people can take the bus the same distance as they would take the train. In those cases we also need to communicate that there is a walking distance, because you have to walk from the station to the bus stop. But for longer walking distances in the travel app we hadn’t defined which icon would show up. Suddenly, a lot of users got a lot of UFO icons, because it turned out when the system didn't know the method of transport the user was taking it would just show a UFO, because some clever developer used UFOs in the test-system to identify “unknown” transportation. We would get screenshots from people saying, "There are UFOs in app?”
Sofia: In instances like the ones you just described, how do you manage the situation so that it doesn’t make the whole team fearful of trying to iterate?
Maria: I think it's a complex answer - we're going from a state where we used to have a monopoly, to a state where we're competing, so if we're not able to deliver fast enough then it's over and out. I think the whole privatization happening on top of making new things, you need to take more risk because you need to move faster. I think a lot of businesses are in that position of being disrupted. You can see it in banking, insurance, transport, and a lot of other solutions as well. So how do you move fast enough? With good feedback loops that can help uncover bugs and critical mistakes and a team that is able to respond fast, it’s not that risky to make mistakes. The whole team is responsible for what is put in production - and for listening when we start learning how it is perceived/experienced by our users.