 Welcome everyone for our talk. First of all, I would like to say sorry. We like these colors better That's why we wanted to use these layouts so we're gonna talk about some UX practices and how we blend this with GitOps and how we can achieve great DevX together But first let's get to know each other. So welcome everyone. My name is Anja Dimitri I'm based in Barcelona and I work as a UX designer in the Open Innovation Labs in Red Hat My name is Jonsu. I'm a site liability engineer in Open Innovation Labs team in Red Hat and today I'm sorry I've seen really great some techie talks before us like bunch of YAML files and bunch of Tech tools, but this is not a techie talk. So I wanted to give a disclaimer. Maybe I can show you one YAML file I'm not sure. I don't exactly remember, but just wanted to set the scene and this is what we're gonna actually talk for the Next 20-ish minutes. So we want to talk about how UX and GitOps can actually work together by some myths that we've been observing with our customers and We have this thing called Sho Natta. We're gonna also share a customer experience and a Recent engagement that we've completed with this topic and also we wanted to touch a little bit of platform as a product concept that we really seen is it's getting really increased interest in the In this ecosystem. So let's debunk some myths before Let's start. Yeah So UX is only about pretty things. How many times we've heard this sentence next slide, please But first of all, I want you to ask raise your hand if you know what the UX designer does Okay, give your hand raise if you work once with UX Okay, a few hands on and also keep or raise your hand if you know how to explain what the UX designer does Thank you, then it will ask you later on Next slide, please So I like to explain this kind of a story to understand what's more about the user experience design So think about the worst thing of staying in a hotel I have a friend of mine who used to travel a lot because of work and he was staying at the hotels and every time He came back. He was complaining about I don't know the bed the breakfast the service Whatever it was and one day it was very funny because he came to us and he said you won't believe what happened Someone brought him a pillow menu It was in front of him with the receptionist and he was like, okay What's this and the receptionist I said, okay, you can choose with whatever pillow you want to try We would just bring it to the hotel room You can try them and then you can bring the rest to us if you don't want them So at the end he had such a nice experience that he also he always remembered that hotel He always will explain that the story. Yeah, no You can continue so at the end. This is a kind of the linear X loop that we use It's about the thing make check and also in here you can see it's a kind of a but this is a statement that I did for this So at the end they started to see that it was a bad reviews about the hotel They were not happy so maybe because of that they started to do a kind of research with qualitative and quantitative data They proposed the solution and then proposed it to the business. It was good. It was great They had the budget at the end. They check it with with the user They tested and they saw it was better. Maybe for the next time they will have the pillows in the room So at the end now UX designer helps to make the best decisions for the users for the team and also for the product So meet number two creating an amazing developer experience requires all these fancy UI and a big team that needs to support them like this kind of consoles that you've been all seen in I Don't know AWS Google Cloud think about it when we work with our customers when we talk about developer portal or developer experience They all think about these examples these hyper scalar examples and they think that like They need a lot of time to build something like this But actually the reality is that what is important is that you need to this first of all Who has ever seen a Mobius look before in here? Perfect if you want to know more just come and find us that's a this is our navigator in all our engagements And the whole point is that it helps you to balance the discovery and the delivery work and it's the it's important that what you You need to discover just enough to identify your developers pain point Identify what they can help you and then deliver it and then go over the loop to test with them to see what you Discovered what you delivered is really addressing their problem And that's really important to balance work You don't really go to a big bang build in a cathedral while you need a home like a simple house And it's really important to balance this work with the right foundation like cultural foundation and the right engineering practices such as giraffes and meet number three So when building the platform we know our users needs and we don't need to talk to them So most of the time we see the next slide So we think if we build it they will come We will wait that they will put their applications on and they will deploy everything in the platform But the reality is that's not what happens like it's two weeks ago I was in Brussels talking with a customer and there was this platform engineer was saying that oh We've been focusing on this field in this great platform for developers But they're just not coming and just like deploying their application and then I was talking with developers and they were saying oh Yeah, we are waiting for the platform to be ready for us so that I can deploy it But they were not talking each other It's just because they don't know what they are what they expect from each other So it's when you have such sort of like not talking with your anti-users even though they are internal users You got this empty cluster plus empty cluster problem. What we call they just don't come They don't come So you might think that yeah, yeah, that sounds familiar this kind of thing. So what you guys are suggesting So what we suggest is welcome to the club angels. Thank you Me what we suggest is we say plant your UX UX designer with your developers and treat your platforms as a product So what we mean in that actually so if you think about these classical cloud native Organizations we have these classical three layers infrastructure layers platform layer and application layer and what we seen in our customers generally is that they've been In platform engineering layers. We've seen these like a keep increasing Cognitive law because previously if you think that like you write your Java code Pack it up and throw over some wall and then someone else is tested someone else is run it operate it In the different environments, but now we have these With the cloud native approach we say this like engineers should be like t-shaped It's having some sort of depth knowledge of some topic and a breath of the knowledge a couple of knowledge so that they can Build their thing they can own their thing they can run their thing But what we seen in the reality actually we sort of created this rectangular shape engineers like What we call these like mythical mystical unicorn type of engineers We expect them to do everything at that moment in the in the enough depth of knowledge to run their thing test their things Create like build their thing in the production and etc. And that's created a huge cognitive load for them That's created eventually it's some sort of burnout type of fielding. So What we are seriously is that when it comes to platform is that like creating some Services to take those kind of load from developers but not taking the responsibilities But delivering some sort of capabilities delivering some sort of services for them to help they have to do their work And the way that we actually address this Has anyone read team topologies in here or DevOps topologies, which is the old word That's that's a great book that we highly suggested between totally advocate about this book. So this book is talking about the Separation of concerns and how you can organize your teams for this cloud native of development methodology and It says some sort of great team types and as read that we usually work like an enabling teams for the customer So we help them to enable Enable they are customers with our technology with our UX practices and all and the problem We are trying to solve in here actually Create in the right platform to fit for purpose So that it can be like it can be a great platform for developers that they can't resist and they just Come and use it. So we are we are trying to focus is building the capabilities like let's say cycle liability engineering or helping them to practice their own Github's way there because you've been seen bunch of different github's tools during the day You've seen bunch of different different way to apply these different tools like customized health etc What we want developers to they want we want them to enable with this Approach and we want them to practice this approach and while doing it We don't want them to recover rediscover the world again So if you can provide those services like let's say observability as a service logging as a service Data as a service you take that load from them and you help them to actually focus on what is important Which is the business Business business problem what they try to solve So what we are trying to do actually in here is to apply a product mindset and this Might sound quite fluffy and it can be confusing But there's the next slide about the this bend diagram that we use while describing what's a product and which Phases or which things it has to have in balance. So here you can see that it has to be desirable It has to build the product that customers want it has to be viable It has to be build the right thing and at the end it has to be feasible It has to be the thing right so at the end if you mix all of these three aspects together at the very Middle of it you can find this a sweet pot, which is the Tines viable product I platform Tines viable platform. That's the most important thing in here because Your platform doesn't have to be all these fancy UI or anything It just can be a YAML file which we've been delivering this It's which we've been using this as a starting point for our customers for two for last year And we also actually delivered a talk technical talk how we apply implement this with a Leading airline company and let's say this like that. So we always use we start with get ops I'm put a github approach to how to onboard the applications How to onboard the teams and have some sort of scaffolding in the behind? So it doesn't have to be a fancy UI because your developers already interact with kids You already interact with it. So why not start from there? Why not leverage the github practices? Why not leverage the benefit of github's in order to onboard your applications or up? onboard the new people So you might think okay. I don't believe you but continue. This is what we call show not tell so Last winter actually we were in up up north right below the Arctic Circle in a Norwegian You are working with this Norwegian company It's a highly regulated company and they wanted to build a state of the art platform in order to In order to have improved their developer experience improve their time to market So they engage with us and they have different type of developers So there are not that not all the developers are the same So they have these developers that are looking for just take the problem away from me Just give me the bitch so that I can do my job But they have also some sort of creative developers, but that's what we call them They want to innovate. They want to experiment with the new tools. They want some space. They want some more responsibility so company was looking to address a platform to work with both of them, so Just to set the scene. This is their let's say the old CI CD pipeline. So It was like a black box for the developers. They were just I'm pushing their cause and hoping that it would Deploy somewhere actually their UX designer did a great analogy for this while they were introducing us on their current state The X designer said that it is like a water slide in the pool like the developers put in their child I'm hoping that they would come out but they they don't know if it's gonna come out or not And when it does not come out, they have no idea why because they don't have any visibility They didn't have any transparency for the platform I wonder when they would ask for help in a sense. How many ties they will throw maybe 16 17 There's no one coming out Yeah, so What we did is we also did the platform as a product workshop Which is a workshop that we developed it's a half day and in here we set the scene because it's a quite new concept So we were discussing together with the customer. What's a platform? What's a product for them? How all of these can get together and also actually here You can see the Venn diagram that I just show and it was very important for us to get data like them before starting to build the platform And this is one of the practices that we use it is called event storming coming from domain driven design So the company's ambition was to create such platform like have a high trust in the platform that Even the one person that it starts in them like it first day in the in their company. They can deploy to the production So this is you always set a scenario in event storming again That was our scenario like the one where Mary deploys the production on her first day So what we did in here? We identify what sort of pain points what sort of things that developers needs in order to achieve this And how we envision for developers to interact with the platform So there are a couple of questions that we identify while discussing with developers and the platform people and the business people in the same room And one of the points was like, okay developers needs a sandbox on it The that moment they didn't have any sandbox environment So they were working locally and the cluster was some other story completely or like How can and what sort of branching strategy they should have or every developer says their own way of doing things Which is fine. What should we address in the platform? So here you can see what we did a spring by spring in a kind of research perspective As chance was saying previously They wanted this kind of sandbox or dev environment But we didn't know what it was about what it has to have inside how it was developed Why do they want it or how would they use it? So it was quite interesting because after that I think we just point down the project and the whole journey of it After that we also took in consideration about the onboarding research How it has to be all the stuff provided to the developer, which is the best experience for them Things like that Then we also simplified the like the visualization of the overall process I mean in a sense that we saw the architecture It was very complex with a lot of technologies, but we also needed from the business perspective to be consumable So we also simplified that and by the end we organized the documentation in a sense How it has to be organized which kind of information the devs expect out of it also in sections maybe in kind of in a architectural information I would see and this is what we did and Just to give you a kind of value x toolkit. I won't talk about any of these practices I just want to point them out and to Highlight again the thing face which is about the research in where we really talk with the user We empathize with them and really we really see the pain points in there Then we move into the make face in where we synthesize all the information that we have from the previous phase And we also prototype or make some kind of process or something that we really need We really can't put the hands to the to the user and at the end of course We we check and we test it at the end what we want to all of these processes bring developers to the platform team room Together, so they work together and really really gather the feedback that really needed for the platform Also, this is a final life document. It's a kind of a user journey service blueprint but in where we mapped all the pain points all the documentation tasks all the touch points and also the users in here and You can see here the metrics it's empty because as I said, it's something that it's live and afterwards the customer and together with the platform the users and Developers they define So it's something that it helps us to visualize all together in which steps We are in where we can work and so we can we don't mix things All these work that and our UX designers angels and the company's own UX designers did we always were like feeding the platform back look with their feedback It will basically what we're doing is actually we were keeps watching them in action Like angels did this great focus group discussion for the sandbox to identify how they would like to access a sandbox How they what sort of things that they need in a sandbox how they would like to achieve this information to get that sandbox So we were just building these things and I'm going to the developers building these things and going to the developers and testing testing with them and like That's me creeping over the shoulder of a developer to see how he's really using it It's like it's the same as we discussed as we envisioned and getting their feedback If they are like looking for something like stakes time for them to find something that we were taking most okay We need to simplify this we were looking some stuff and going back to them So that's that's the most important thing you need to bring the users during the development phase You don't have to really build a fancy UI or anything Or you don't have to like like dictate a github's way of working or a tool for them They are good enough to work this. It's just you need to simplify the process for them So for the for that what we were doing as platform team. We were providing some Lego bricks to them We created a home chart library within the company for example We were developing some mostly most used home chart Let's say but put it out there and they were automatically I'm thinking to the cluster because of the Argotops controller. Let's say and we were we were using tecton If you are familiar with tecton has this notion of cluster tests, which is cluster Cluster white available tasks. So we were creating some cluster white test that we know that every developer would need like let's say clone in the Git or container containerization or I don't know like running some sort of Hand package handling test. So we were putting creating this kind of tasks openly in a git repository And we were syncing those kind of changes Whatever is the new task is coming through it up on the cluster and developers were looking at this open like they can see it Easily they can come okay. I need this so they were getting this from library But they can also bring their own tasks in their own namespaces Whatever they need because they are the one who knows how to have to build their application if they need a secret or like if they want to mount a secret as an environment variable or if they need to mount and Config map as an as a personal volume type of thing. It's totally up to them It's just you give them some Lego bricks some sort of leading Like starting point and they can easily see this and the good point is they are Contribute back like if they create a new task and they see that it works for them They will bring it back to the library for the wider user So this is an example of these cluster tasks that we created we were annotating them and we were have some sort of versioning system Just a secret shot from a cluster so we were creating this for them and if this is not working for them They don't they just don't wait for anyone. They create their own tasks So as the as an example for the final results, it was transparent for them. They ever empowered How to onboard their applications how to run their pipelines how to what sort of stages they should have in their pipeline It was obvious to them. So it was they were easily see if there is a problem they were easily know what should improve or Because of these kind of interviews or the feedback loops, they were more confident to come to the platform team like they were easily to They know how to communicate with the platform team. So they were speaking the same language So at the end some key takes a ways after this It's all about feedback loops as a chance. So was saying it's very important to keep all of this process all together And also what I want to point out of this is that we also need to keep them short So it's it doesn't make sense for example if you have an idea now today And you want to make it really, I don't know in one year and a half to after the business plan after you took an MBA After all of the stuff because maybe then it will be late So also what we recommend is to give this feedback loop short and also fail fast and really learn from the overall process And I said share tools really help them to share Speak the same language like git is the biggest shared tool in the moment in the ecosystem between them and ops when they were both interacting with kids when they were identifying their own things own tools or the objects as YAML files or Some sort of plain text files. It's really helped them to Facilitate the conversation easily like gits get ops itself really helped us a lot in this kind of in this In so because before that a couple of years ago I didn't even see the usage of gits in the ops teams There is just some sort of ansible files sitting in some sort of folders inside a may come in Common server like of developers use so it's the same for good like going going the same for observability tools or the logging tools When their tools are becoming more common and common it's really helped them to speak the same language and They create that feedback loops easily and Again, it's all about empowering devs to own their thing and it's all about bringing their knowledge bringing their Newly, let's say the new created things new experiencing to the platform. So platform is not something that now a Platform team or a couple of people building on the side. It is something that is Evolving constantly with the developers feedback with their input with we say hashtag never done Because it's a product. It needs to get evolved over time. It needs to it can't keep the same because if you think about the products Products Like if you think about a product it needs to be like it needs to solve a problem And it needs to evolve over time Otherwise, you will stop using it if it doesn't really address your problems anymore because your problems also change So it's all about a problem. It's all about encouraging devs to bring these knowledge back It's all about keeping that feedback loop all the time alive. So thank you so much for listening to us and We are around if you would like to talk about this or the Moriax practices how we did this in tech in the tech side or I Don't know mobius loop team topologies anything if you would like to talk. We are here that we are here Or you can meet us. You can see us around. Yes. Thank you so much Any questions Yeah, we've got For the next talk, so we've left some room for questions. I'll pass one out Okay So thank you for the talk I was going to ask do you think that it's different to work with UX when you're building platforms for Productivity or do you think it's very similar to building any software product in general? What do you think? Oh, yeah, because I'm a UX designer there for it It was honestly the same it's for me because it's all about what the end user thinks what the end user feels What they're paying points what sort of improvement points that we can get from the users It was the same honestly like engines for the engines was doing the interviews with the users And we were on the site taking this kind of notes It was just like the same that a user using the app. It's just the different like if you don't see it User using it was a pawn to interact with it was using the keyboard and interacting with your Documentation that you create the git the git repos that you created so it's clearly the same the outcome It's just the tools are different, but the way that we were doing it was I think it was the same Yeah, anything you want to add Okay Sorry a few more questions. I see two folks on the queue So let's say I have a slight empty cluster problem What's like the best first feedback step that I can do to get started on the whole feedback cycle Do I can see that light and think the first You're the first first feedback look yeah, I remember that a couple of years ago when I was working in the bank It was the same. I just took my laptop and went to the developers like just show me how you do it show me why you don't do this Like we started to I started to talk with devs But later on I started to do some sort of brown back sessions within the company like open open and like Come and talk with us. Ask us any questions Here is the new capability of the platform that I want to display and they started to join it Regularly and then they were bringing their questions and you see actually when the questions are actually coming from some sort of problems Difficulties they are having while interacting with the Platform so you start to actually think about how to things get better But honestly what I did was just starting the conversation with them There are a couple of practice help you to facilitate these conversations either virtually or or face-to-face that we can maybe Point point out to we have we have a website called open practice library dot com by v. I mean It's the community website is it has all these kind of practices about discovering the work you need to do In some sort of delivery practices and some good Foundational practices there are a couple of UX practices as well there that might be help you to have this kind of conversation Open practice library dot com. Awesome. Thank you What was the Number one thing that you went into it thinking that would happen that was different when you came out There's the biggest misconception From which perspective You can say again from which perspective just when you had the idea of what you were going to build And then hearing the feedback and seeing people using iterating that came out that was completely different than what you thought Let's see what I Think it was like We had some we always start with some sort of opinionated approach when to want to do get off So we started putting it in like with platform developers. We sort of come up with a good way of A good way of practice get off for us And it was just like the talk that before us showing that like you have this Application repository and you have a github's repository for like the overwrite values for the different values per environment And one of the developers just say that I keep forgetting about this repository Like can I have these different values in my own repose? Is that possible or or just or it's that's all and we were like Okay, that's another maybe think that we can provide but it needs to some discussion before Platform teams like we want do we want to really? Cover this edge case or it is something that we can say okay You can do it this way, but we don't really provide it out of the box in here So we started the discussion and we realized actually what this developer suggested was really a bit of commenting before between all the developers So we sort of Created another approach for github's by supporting the different values file in how inside the application repository So that was something I'm Interested in you kind of mentioned that you expose like a Various infrastructure tools as Lego box the Lego blocks that engineers can sort of plug together how they want Quite a lot of these tools are quite sort of low level and very like highly the kind of configuration over convention And I'm kind of interested in what your sort of philosophy is around Creating more opinionated higher level tools on top of those lower level components to expose to users of the platform Because yeah, I just I just worry that like exposing all of those things puts a lot of Responsibility on developers to like understand them deeply and use them correctly What we started to do is like we give some like ready to use Templates, let's say like you don't have to understand how more you don't have to understand github's all you just need to clone these templates Just chase the name. Let's put your application name Just it would just work. But if you want to know more here are the dip here are all the Explanations of these here are the documentation and here are the sessions that we are always doing we have an Enabling team concept in companies when we interact with companies we always look for build an enabling team So that that team goes and work with these teams to enable them to have them understand more but not like like you said like in not in the deep deep level, but Just understand that so that they can consume these templates and if they want to learn more it's out there and Some someone eventually comes and learn more and even starts contributing So we look for like easy to easy to use blogs like just copy this one It will work it will just build big deploy your application But if you want to get to know like get to know or just come to us Here is our room or join our brown back sessions right a slack. We always get to give this kind of Guidance to developers too so that they can learn more if they want to learn Thank you. Thank you. Any more questions? Although those were great questions Right