Continuous Delivery And Continuous Design

Miriam Soesan, Guillermo Martinez at UXDX Europe. Video: https://youtu.be/KRTmPhyTkiM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

DevOps and UX share the same principles

[00:00:00] Guillermo: Hello, everyone. Welcome to the talk about Continuous Delivery and Continuous Design with Miriam Soesan and myself, Guillermo Martinez. I'm leading DevOps in Accenture, and in Accenture Liquid Studio we always work in a DevOps manner, and we always find quite a lot of similarities between DevOps and UX. The talk today is about how these two worlds relate to each other, and how collaboration between DevOps and UX can really make things work.

[00:00:35] First of all, I would like to explain a little bit what DevOps is, what UX is, and how they are combined. Probably you've heard about DevOps, you've heard about Agile, you've heard about customer-centric. You've heard about all these companies in Silicon Valley that are always focused on customer value. The similarity between DevOps and UX is that we want to bring value to the customers. That's the most important thing: we want to bring customers what they want. However, when we work in a DevOps manner, it means we have to do it as soon as possible.

[00:01:12] There are three principles in the world of DevOps: speed, response to change, and innovation. If we think about them, they are quite in line with the customer experience. Speed, because of course we have to be the first, or one of the first, to deliver new value to the customers. Response to change, because we need to understand and bring new functionality to the customers; therefore we should be open to change and to delivering different functionalities, features or any other improvement. And innovation, that's also a clear point. We like to see things moving. It's important to innovate, it's important to be creative and to be able to deliver new value to customers in that manner. Therefore these three principles are quite aligned between DevOps and UX.

[00:02:06] We can use a couple of references from famous companies like Netflix, Fidelity, Google or Amazon, which are the top practitioners in the world of DevOps and customer experience. They work with a focus on customer experience, because of course the customer comes first for them. It's very important to bring the customers what they need, but they want to do it in a manner that is quite cost-effective, so it's cheap, they can do it fast, and they can innovate without big issues. They can continuously bring new value.

What customer value is

[00:02:40] And now that I mentioned value: what's customer value? Customer value is basically experiences. That's what we want to bring to the customers. They can be functional, like features or the voice of the customer, or they can be technical. If we think about an experience in front of the customer, we can think about the functionality that they are looking for, an improvement, or something experimental where we want to see if it makes sense and if it's good for the customer. Then, using the voice of the customer through analytics or research, we can see if these changes are good enough and in line with our expectations.

[00:03:24] Or they can be technical. Think as well about when you have a solution which contains all the functionality a customer might expect, but it's too slow. That's also an experience. The technical experience is also part of the customer value. What we basically do in a DevOps and UX situation is try to bring this experience to the customer as soon as possible. But to get there, we should first understand how we work, how we make things happen. What's the flow for designing the experiences?

Our double diamond, practiced by designers and developers together

[00:03:56] Miriam: Yes. Our interaction design model is based on the well-known Double Diamond model, which I am sure most of you are already familiar with and probably practicing in your own work as well. So I'm not going to walk you through the Double Diamond model. I'm just going to explain how we practice it in Liquid Studio, and the way that we practice it together with the designers and developers.

[00:04:23] The discovery phase is where we start to understand what the problem is. What is the challenge that we're facing? What is our scope, and who is our audience? Now, this is something that not only designers should answer. It's also very important for the developers to understand, because it might affect the backend development. It might affect the language that they decide to code in. It might affect different technical aspects of the product. This is why, from the beginning, we have designers and developers working together.

[00:05:00] Next, of course, we have define: the definition of what it is that we're going to do, from all the information that we've gathered in the discovery phase. This is when we define our requirements and what we expect. Of course, as you probably know, these two parts can be iterated within themselves. That would be the first diamond. Moving on to the second diamond, we start with design, or for the developers, the development part, where we encourage our colleagues to think out of the box, give different answers and try to find creative solutions before we start the delivery phase, which also includes testing.

[00:06:01] And of course, we also do iterations on the entire process. We can iterate within each diamond, but more importantly, we keep iterating the entire process. After the delivery, we continue testing, and in an ever-continuing design and delivery world, we believe that no product is ever really finished. We are constantly gathering feedback, and we are continuously researching and testing how our products and services are working, to iteratively improve them. This explains the structure of the process that designers are usually more familiar with, but also how developers can use the same process, and how we are actually working together.

The problem with traditional delivery

[00:07:01] Guillermo: Sometimes we can find issues in that domain when we are delivering these experiences to the customer. What you see right now on the screen is a regular waterfall, sometimes not that waterfall, sometimes a little bit more agile, but those are the steps of delivery: from identification of functionality, followed by design, implementation, testing, release and so on, to the research, where we find new functionality by performing experiments [?]. In traditional delivery, we have an issue: it doesn't go directly in line with the customer experience and with DevOps. We of course perform all the actions. We can perform the actions of research and experience design. But everything is organized based on functional [?] management. We like to categorize the teams, and we tend to put different teams, or different accountability, on each of the steps. That way we are reducing the collaboration between each of the blocks that you can see on the screen, and therefore it makes the delivery process, or the implementation process, a little bit hard.

[00:08:17] During the last years, Scrum practices have really been popping up, and we are combining design, implementation, even testing, altogether. But most of the time it's still different departments running activities. They have close collaboration, but they are still not really working together. Therefore this end-to-end process contains a couple of doors here and there, from one block to the other, that make things a little bit slower. Imagine the case where a design is done, then implementation, then it goes to test, and when there is an issue in testing, the testers will go back to the development team, and it may be a problem that should be solved by design. However, when we work in this situation, this is not applicable.

[00:09:14] Then something else that happens here is that we might implement one functionality and then leave it hanging there until a large set of functionality is available, to bring what we call a release. That's a situation where we sometimes consider it an Agile way of working, but to be honest, it's not very Agile. We work continuously on bringing functionality. However, this functionality doesn't reach the customer for one to six months. I'm talking about some research, the Puppet research, where they establish the frequency as between one and six months in general. So the situation where we think we are working in an Agile manner is not very agile. We just bring functionality, but it doesn't reach the customer until X amount of time.

[00:10:13] And we tend to deliver a lot of functionality altogether as a release. That makes it hard to test, to validate the whole thing, because there are just a lot of things to validate. It makes it hard to release, because there are a lot of things to be released. And if we take the customer-centric approach into the UX domain, it makes it hard to research the added value of what should come next, because the researchers will have to find what makes sense from a large set of functionality delivered, lots of experiences delivered, and there are a lot of changes [?] at the same time. So the research cannot be performed in an efficient manner.

[00:10:59] After release one, we'll have another release, which is 1.1, and between them the time spent on research is not enough. Also, the new changes that are proposed by the UX domain most of the time won't see the light in the next release, but will be postponed by a couple of releases. Therefore the customer won't see changes as soon as possible; they will see them in the long term.

UXDX delivery: product teams and continuous features

[00:11:34] What DevOps informs here is how we can make these deliveries a little bit more efficient. I'm going to talk now about what I just mentioned here, UXDX delivery. It's in general DevOps delivery, but since we want to focus a little bit more on the customer experience, I just put the brand of UXDX on it. The cycle is the same. We go from research to research, but in this case we are not going to deliver long releases with a lot of functionality.

[00:12:11] We set up a structure, and of course it's quite supported by technology, that's another point. We start with a structure and organization where the team is accountable for doing everything. Probably you've heard about product teams. That's a product team. The product team is where they have ownership, they have motivation, and they have responsibility for defining, researching and designing the functionality, but also implementing it, validating it and releasing it. That's a big change, because it changes the process, the organization and the capabilities a little bit. I'm not talking about everyone doing everything. That's not the case. I'm talking about a team that has all the skills. There might be people who are specialized in one area and people who are specialized in another area. So that's basically a product team.

[00:13:05] The way we work, again, is quite different. It's not focused on releases. It's focused on continuous feature delivery. Therefore what we can do here is ideate a feature, research it, implement a solution and deliver it. From the delivery of that, we go again into research mode, and we might identify new functionality, new features to deliver. It might be an improvement on the feature, like feature 1.1, or we can have a feature 2.0 or feature 3.0. We can have multiple of them. That way we can see how research goes ahead and brings new ones.

[00:13:46] If you can go to the next animation part, we can see here how the research can lead to feature 1.1 or to another type of feature. Also, another principle from DevOps could be multi-version, A/B testing. We can have multiple versions at the same time, and then we can perform continuous or evolutionary research just to identify what makes sense. The point of these feature releases is that we don't take one month to six months to deliver any functionality. We can do it in one day. We can deliver any functionality at any moment, because the team that is accountable and responsible for that research is smaller. So we can make fast decisions and do fast research, deliver a functionality, and then the same day or the day after, we can even improve this functionality or bring a new one.

[00:14:36] We'll have multiple teams, smaller teams in this case, that are accountable for some set of features. That differs a lot from traditional delivery, because, for instance, in the research process, the researchers will have to validate something that has been delivered recently, and only one single functionality or a couple of them, not hundreds at a time. When you have to research, or make an analysis of efficiency and value over time, across a lot of different functionality, it can take a lot of time, and you will see that a lot of it didn't make sense but is still there. Here, the activity is going to be performed in an efficient manner, because in this scenario everything is a little bit smaller and more continuous. Therefore there is no end and no stop. Everything just continues with the flow of delivery.

[00:15:26] That approach, the structure of the team and the structure of delivery, which is a continuous way of working, we applied to our Liquid Studio portal, because that's our way of working. We were developing our portal with some students, with some interns. Miriam, I think you can bring some information about it.

417 small changes to the Liquid Studio portal

[00:15:48] Miriam: Yes. As we just mentioned, we took this practice and applied it to our own portal, our own website. What we did, as you can see on the screen, is that from July 2019 until December 2019 we did 417 small changes, or 417 pushes to production, which is quite a lot even per week, if you divide it. So even though the two examples that you currently see on the screen seem like two very different products, they are actually the outcome of a lot of small changes that we implemented.

[00:16:38] Now let me walk you through this process step by step. The screen that you see on the left was based on the preliminary research that we did, when we asked ourselves: who is our audience? What is the purpose of the portal? What colors should we use? Et cetera, et cetera. The color we based very vaguely on the green that you can see in the Liquid Studio logo up here, but we also wanted to have some blue in it, and some more relaxing colors. We also took the theme of Liquid Studio and applied it to the design of the wave here.

[00:17:18] I'm just going to show you a sneak peek of this first design of the website. Then, step by step, and after testing it, we decided to move to a darker color. You can also see here that the logo changed, and the menu up here changed from the original version. We also decided to change the wavelength to make it a bit more relaxed, and we animated it as well, to give it a bit more of a lively feeling, a bit more of an interactive feeling to the product.

A design that went too far

[00:18:01] Now, saying that, it might sound like everything we did on the way was correct, but that is hardly the case, as we also tested a few designs that just did not work. One really good example is the design that I'm about to show you, where we tried to further explore the theme of being liquid, the watery theme. Testing showed that most testers, most users, actually felt that Liquid Studio had something to do with either the sea or marine activities, which is hardly the case, as we are a part of Accenture Technology. We are a tech company, as we see ourselves. So I'm just going to show you this demo and explain why it didn't work.

[00:18:59] We also did this scrolling sideways, instead of the normal up and down. We tried to play a bit with the layout as well. And of course, showing our work at the end. Now, as I said, one of the reasons this design did not work was that we took the liquid theme a step too far. So what we did, as you can see here in the Double Diamond model, is we went back to the research phase. It's not that we decided to scrap everything. We actually kept some of the design. The scrolling sideways, for example, we thought was really successful. But we went back to different colors and a different setting.

[00:19:54] So now the design still involves a more creative way of scrolling through the information, and a different way of showing the information. But from a visual design perspective, we went back to our branding, back to our original colors, and you can see here that we decided to focus on a few areas, as well as keeping the design language and the visual design much more similar to the original brand of Liquid Studio and of Accenture.

[00:20:35] Now, this is our current website. The previous screen showed you the design, which was more our vision, and this screen shows how the website currently looks. We have this black theme, as you can see; our slides are black too. We took it a bit further with the wavelength as well; we changed it a bit. This was done after almost 110 small releases from, not the original, but from the dark blue design. We added some more animations as well to make it a bit more lively, and a bit more about our projects, ourselves and some of our partners.

[00:21:20] That is basically how we implemented the design step by step and continued to test it, continuing not only to ask ourselves what is next, but also to ask our customers, our audience, which consists of potential employees as well as potential interns, and also our colleagues across Accenture in the Netherlands and globally. This is how we did it: step by step, with continuous research, and developers and designers continuing to work together, bringing ideas to the table. And I think now is the time to also show them the pipeline behind all this.

Pipeline demo: changing the partner logos live

[00:22:08] Guillermo: Yes. We're going to run a pipeline demo, just to show the technical aspect of the delivery. We mentioned, first of all, that we want to deliver value as soon as possible. We said that this value is experiences, and we want to do it right now. From the video that we just played, we identified that the logos of the partners are quite big and unaligned. So we are going to change them right now. We don't have to go through the process of change management. We don't have to go through the process of approval, validation and testing, and then see the change in one month or even more. We're going to do it right now.

[00:22:56] In the previous video, we could see that the logos we had at the end, in the partner section, were quite big. So we just want to change them, and we don't want to go through the regular process of making a request, an approval, then a change, then a whole validation, and so on and so on and so on, and at the end the customer sees it in one month. What we do is do it right now. Miriam and I decided that we wanted to change these logos. So what we basically do is change the code in a moment and then push the change. That way we run the pipeline, where all the delivery steps are handled automatically, and we can see the change.

[00:23:39] First of all, I saw that there was some issue there, and then there are a couple of other things to change, like the align items and similar things. So let's align items to the center. I've already validated that these are the good values, so I'm just doing it a bit faster than usual. It's important to put a margin there, because I also saw that the margin wasn't good enough. So basically we are going to make a change to the solution. We don't embed it in a release. We just make a fast change, like any other change we can do, and then we'll see it here in a moment.

[00:24:50] What happens in the meantime? Basically, when we push code, the pipeline runs. What's a pipeline? In any delivery process, there are multiple steps to be covered: unit testing, functional testing, code validation or code checks, security validation, building the solution. In our case, we also deliver with containers, to make multi-cloud [?] possible and to make everything a bit more flexible and scalable. A lot of different steps happen that, traditionally, were each executed manually by one team or multiple teams, and it usually took multiple days.

[00:25:38] When we work in a DevOps situation, the designer might define, together with the developers, what functionality is to be executed, what we want to change, what type of experience we want to deliver, and therefore we can implement it together in a moment. We just push it and go through the whole automated delivery, and that way we don't have to wait a lot of time. We don't have to move from design, to develop, to test, to deploy, to any other step. We just do it all together at once, and the whole chain is executed in an automated manner.

[00:26:19] If you're interested in the technical domain, what happens in the pipeline is basically a set of commands. We programmed the delivery. What happens is basically a lot of commands and a lot of technicalities in the background that will inform us whether what we are doing is good or not, whether it makes sense or whether it's failing. So it really informs us about the status and how everything is going. At the moment we've just passed the first validation, which was fine. Here, this one is where it reports failed or successful information for us. Then we build, then we put it in a container, and so on until it gets pushed directly to production.

[00:27:08] We don't have to make any type of request to push to production, because, as we've been mentioning all the time, it's not a release. It's just a feature. It's just continuously delivering features. So now the container image, the solution, has been pushed to production, so that new experience has been delivered, which will allow the team to add new things based on this change without having to wait one month for the next release. Right now, if we go and refresh the page of the studio, we can see that we've reduced the size. It looks a little bit better.

[00:28:12] Right now, every time the designers are watching the solution, they might already start thinking in their brains about the next improvement. And again, this is a visible change, but think about all the backend, all the things that happen in the background that can be improved. That's the demo that we wanted to do of the pipeline, which is how to program the end-to-end delivery process. On top of working together in a collaborative manner, in a product team, in DevOps delivery, UXDX delivery, everything is supported by technology, so the experience can be delivered in a fast manner without big challenges.

Conclusion: speed, response to change and innovation

[00:29:02] Okay, I hope you liked the demo of the pipeline, which is basically the delivery part in the technology domain. As a conclusion, we were looking for the points of speed, response to change and innovation. We gain speed because the organization that DevOps proposes is much less political than the previous one. Every time we want to do something, we don't need to go through a big process of approvals, rejections, testing and so on. We of course do that, but we do it in a more efficient manner, keeping the team accountable for end-to-end delivery and end-to-end maintenance. We deliver the experiences not on a one-month timeline but on our own timeline. We can perform research over the functionality on the same day, so we don't need to wait a long time for releases to perform our research on them. So we gain speed. New ideas are flowing constantly; we don't have to wait that much. That's thanks to continuous delivery and continuous research, continuous design.

[00:30:12] And response to change, a fast reaction. That's obviously one of the big wins. Every time we deliver a functionality, thanks to technology as well, we are able to measure the value in terms of data and analytics, but we can also perform research all the time. Every time we deliver more functionality, more change, one of these hundreds or even more small changes that we were delivering through our portal, we can perform continuous research, and that research will evolve into new functionality or an improved functionality. Again, we don't have to wait a long month just to perform research on some experience. We can just do it at the moment and take a fast decision, and an experience can evolve into three, four or five versions in the same week, which in traditional delivery is not really possible. And then, of course, practices like hearing the customer are very important to do.

[00:31:09] And the last part is innovation. Initially it's hard. It's something that we always want, but because it's supposedly not that cheap, or because we never know if it's going to bring value, we don't do it. This way of working allows you to innovate way more, because any small change, basically done in minutes, can be delivered in hours, even less. You have fast feedback. You can have multiple versions for testing different versions, or perform research over multiple versions at the same time, and therefore the cost of innovation is greatly reduced. You can try out new things, you can analyze these new things, and then you can take decisions based on that. You don't have to wait a lot of time, and you don't have to create large business cases and meetings and so on in order to drive innovation. And I'm talking not only about what you see on the screen, because we focused a little bit more on what you were seeing on the screen before, but also about backend functionality, new functionality like the chatbot we implemented.

[00:32:18] So in this way of working, we combine customer-centricity, which is the value, with DevOps, which is the fast delivery, and also have a really efficient way of working, where the whole team is more satisfied and motivated, and able to take more decisions and make things happen. With that, I would just like to close. If you have any questions, if you want to know more, send a mail or post a question in the channels. We are always open to hearing from you. I hope you liked it. I hope you were able to learn a couple of new things here and there. Thanks a lot for your time. I hope to see you soon. Thanks a lot, Miriam, as well.

[00:33:03] Miriam: Thank you.