Markus Edgar Hormess 'Prototyping : Why you should burn requirements documents'

Please note this is an auto-generated transcript and may contain minor-spelling errors.

See a mistake? Help us by letting us know.

‍

00:00:25

S1: Hello and welcome to bring in design closer are the podcast focused and discussing Design's role in toppling complex societal issues, and our goal is to have conversations that inspire and help move the dial forward for organizations to become more human centered in their approach to solving complex business and societal problems. Look, it's the start of 2022. I can't believe it. And I want to ask a favor before we jump into this episode. Now, if you haven't already done it, sign up to our newsletter and this is eight CD dot com where you get fortnightly content about all that is going on in the world. And this is a city such as the Doing Design Festival, which is happening very, very soon. And also, if you love what we do, please leave a rating for the podcast on Apple or Spotify or Google or any other platform that you use to listen to the podcast on. This helps us out enormously. It may seem something so simple, but it really helps that enormously and helps others find the podcast too. So that really helps us and goes a long way. So my name is Gerry Scullion. As you probably know, at this stage, I'm a service designer and the founder. This is HCD, and the CEO of This is Doing, where we provide live online design and innovation classes, transformational design and innovation training for teams and organizations, for people within the design and that change making space. Now in this episode, I speak with one of my colleagues of this is to become one of the co-authors of this. It serves design doing book, Marcus, Edgar, Hormones and Marcus. His name is one that will probably be synonymous with the word service design and be very familiar to people within the services like community. But nevertheless, let me tell you a little bit about Marcus today. He's my guest. Marcus is based in Germany. He's a trained physicist and he's a partner at work life experience. And I look to Marcus for many things, not only just technical advice and actually how to set up a podcast. He's put into that, but I also align with his deep rooted passion with prototyping of services and just prototyping in general. The bits that can so easily be trivialized or just assumed are those moments that are missed within teams and organizations. And we chat at length about how to encourage prototyping generally within your organization. So it's a really good episode and we speak more around play and what this means. And we're like many, what's the opposite of playfulness look like within organizations? And again, how can we move the dial to become more likely to lean into the prototyping mindset anyway? It's a great one. I know you're going to enjoy my as my conversation. So let's jump straight into it. Marcus, I'd go home as a very warm welcome to bringing design closer. How are you?

00:02:48

S2: Oh, I'm fine. Thank you for having me. Hey.

00:02:50

S1: Hi, Gerry.

Marcus. We've known each other for a number of years and we've got the pleasure of working together, obviously with what this is doing. But for our listeners who maybe aren't familiar with Marcus, I'd go hormones. How would you describe yourself and tell us what you do? Well, that's about 50 words or less, 50

00:03:11

S2: years or less. That's one thing I can't do. You know, I'm famous for talking too much. Possibly know 50 words or less. Let's try this. I'm. Physicist by training turn turned to the dark side consults and swapped into service design early on at the intersection of business design and technology really like to integrate that stuff and prototyping is the thing that I like to talk about. Most welding things, using technology to build things, using people, not using people, but working with people to make things happen or almost anything.

00:03:52

S1: Yeah, using people as props.

00:03:55

S2: No, not so much. This is the interesting thing. I just noticed this the other day. Sometimes we say, you know, what's the medium of a service designer? And it's the organization. So organization are people are people the medium because, you know, we should work with them and not change them anyway. This is what we do. You know, most of the time, yeah, the semantics.

00:04:21

S1: So absolutely. And you are one of the authors of this, a service design doing so for people out there who haven't heard of the there's a service design doing book. It's sort of many years old. We're 2022. It's published in eighteen. Is four years old, is it? It's it's for the toddler. It's hopefully it's been toilet trained.

00:04:45

S2: Yeah, it's it's not. It's not the age where they lie on the floor. It's totally resist everything that you try them to

00:04:55

S1: kick and stomp, develop personalities of their own. Yeah, but look, you know, we were chatting and we've been chatting about doing this podcast for for Daphne a couple of years. And it's great that I've completed the sort of the core tasks I've got jack up for Mark. But Adam on the podcast, of course, and now we've got you. So that says we can. We can close. This is 18 and we are always been chatting about prototyping, especially what this is doing to work together, different training and stuff. Plus, playfulness off the back of that is something that I know I've encountered quite a lot over the last number of years. And one of the sort of the side benefits of prototyping. So you mentioned there that your interest in service design prototyping comes from within service design. How did that happen? Walk me through your background on what was brought you to the world of prototype interest. So much about this.

00:05:59

S2: Oh, that's a very good question. I always think are really interested in in possibility. And, you know, early on, I've got a degree in science, so technology always was something that I was interested in and observing new technologies and what they can do or what they can do was really something I I was fascinated by.

00:06:26

S1: And so I was going to say, does it come from a place defined from the scientific background of thought, how kind of testing and, you know, wanting to make sure that you're not going too far ahead and then have to come back on yourself? Is there something in the scientific mindset that lends itself to the prototyping mindset?

00:06:48

S2: I'm not sure if there is a huge difference. And I think in the community, you see a big difference. They are rarely being able to talk to each other like scientific community or the design community, and these are bridges that we might have to build. But if you look at the scientific method and the design approach, it's not, you know, on on some core values, it's not that different. It's about trying out things, not just thinking about stuff, about doing experiments, doing many experiments, trying to learn how things work and then built something on top of it and so on. On a very simple basis. It's very similar and we can learn a lot from the from the scientific community in terms of, you know, experimentation mindset. And one of the things that I learned already at university was when I was trying to to write my my thesis, you know, I was trying to understand how phase transitions worked at the time. And in the end, you try so many ways to solve that problem that you were given and you learn so much what doesn't work right? And then it's it's like you start with an empty piece of paper that is your map and you walk a couple of steps and then you like cartographer, you map out what works, what doesn't work and what the path is. And then in your thesis, you you just write up that one path that worked, but you learn so much along the way. And I think that. A similar thing in design when you're trying to figure out how to build something that works for our customers, for the stakeholders, for the employees. In the end, we can't just put in a perfect solution. We also need to learn about all these kind of sideways, these little detours that don't work because we need to avoid them and we need to learn when they happen, what to do or how to recover that. So the perfect concept, even if it works, is not worth it. It's not worth a lot unless you kind of also know what kind of terrain you're in. If you want to stay with that metaphor,

00:09:04

S1: just sticking on that for a little bit more like, you know, when we talk about prototyping, I think myself and yourself have a similar kind of understanding of what we mean. But in my experience of speaking to teams and delivering training and stuff, prototypes tend to be compressed into this kind of understanding of it being a other paper prototype or a digital prototype on the screen where they click through things. How do you describe what a prototype is just so you've got that shared long standing in this thing with the listeners?

00:09:40

S2: It's I think it's one of these cases where the language gets in the way. It's a very natural prototyping. It's a very natural concept. It's part of how we learn, especially in the in the field of service design. Is this how do you learn a language, right? You learn a couple of sentences, you try it in front of people. You know how it fails or not. And then you get corrected and then you try again and you try again until it works and you can communicate. And you know, when you learn, when kids learn to ride a bicycle, they write the bicycle. What they don't, they try. They fall, they get up again. And you know, they try again until it works. Every try is kind of a prototype. It's an early version of where you want to go and and we learn along the way because the most important thing about prototyping is you try something out and then you learn from it and then you try to improve. But it's not about thinking about something, not trying it out in your head, but trying it out in the real world. And prototyping historically has the. I think that the terminology comes was used mainly in product design or industrial design when when you built an object. And but, you know, I think looking at the at the world from a service perspective, you know, it's all about the experience. And so how do we prototype these experiences? And that's everything which is out there. So it can be. A consulting experience that needs to be prototyped, you know, the communication needs to be prototyped, all that kind of stuff, a conversation can be prototyped. All these experiences and basically a prototype is trying it out and and see what happens. And learning from it. I think that's the key things. You build a prototype. You set something up. You try it and you observe and learn from it. I think these are the important steps.

00:11:38

S1: I mean, within teams and organizations that have kind of come from this waterfall mindset where they might have had a document created at the start with all the requirements in us and they know exactly what they're doing. And then I'm being kind of facetious there and then they'll have some sort of screen design session and all the requirements in the functional requirements will be thrown against that. And then some of my can say, well, we need to usability test that stuff, and then they start creating a series of interactive wireframes and they're like, OK, cool. Where do you see prototyping certificate? If that's that's a typical scenario for an organization that might be, I don't know, on the journey to becoming more agile in their approaches of ways of working. That, to me, sounds very similar to how organizations wrap for prototyping up into their ways of working. I'm kind of keen to get your understanding of how they should probably explore us.

00:12:41

S2: I think the first word I said that where I chomped on was the requirements document. You know, that's that's burn that and replace it with a prototype. I think as simple as that, there's few people that understand requirements documentations. It's the people writing it. I think that's about it in my experience. And there is so much to be there.

00:13:06

S1: And I need to stop here because people, there's probably people in there in flames. They're kind of go and burn the requirements, documents like that and replace it with a prototype or replace a wall with a prototype. How do you know what to prototype? Those requirements are coming from policy and they're coming from regulation and these are mandated and they need to be included in the design. What do you say to people when they kind of, you know, I wouldn't be the first designer just to say, you know, go against the requirements document?

00:13:36

S2: Of course. I mean, you know, the reality is, I mean, I say it in that way because I want the people to listen because the the first thing a lot goes wrong with requirements documents, especially the first is the people that often get asked for requirements are and people that can formulate them very well in this moment and they just give you a list. It's a wish list. Sometimes they they need it. Sometimes they don't really need it and they don't know that. So a lot of things go wrong and we know all this, you know, all these these problems with the requirements, documents and. And the second thing is that someone else reads it and it's kind of a handover. So it takes out a conversation that we in service design and design. She saw it replaced by, you know, going out there and doing contextual research. So we look at what people need. And then, of course, it makes sense to kind of compile all that learning into maybe a document. So we don't forget. However, if we now go on to say now, let's move to the developers and have this thing done. If we are talking about a digital product or service, then there is this document. Why not flank it with a first prototype to say this is what we mean by all these requirements? And you know, this is our first vision, how this could feel like, how this could work. This actually solve our problem before they go into the details and solve all these deep technical problems that might be associated with it. So it it it helps people to understand what's in this other document.

00:15:18

S1: OK, so is there a way that we can rather burn the requirements documents because that could be seen as a free antagonizing approach to trying to working with with part of the business? But is there a way to have you seen ways where they can take that requirements document and maybe explore its re-evaluation?

00:15:41

S2: I think in in the end, maybe the document is maybe the document isn't the source of the problem, it's the it's how how the work is stacked up in a project with the handovers. Yeah, because often that document is there because, you know, we get the requirements from one part of the organization and some other part has to do it and they don't necessarily talk to each other. They just hand over that, you know, it's everything in this document. And so and then they walk away and people are OK. You can't document everything that you learned. And when you do research. So and suddenly, even if you you capture all the technical details, all the empathy, the why this is important is lost when you hand over a document. So can we please have some of the developers, maybe or someone from the development community also join the research so they know what the insights mean, that they know why it's such a problem for the users, for the people in the context, you know, being out there in the in-home interviews, whatever it is. So we so there is at least a piece of MPAC and they can raise their hands, say, OK, the this is the requirement, but this is how you need to read it. Because I've been here, I've been out there, man.

00:17:03

S1: Yeah, shared ownership and also research to swim a little bit further upstream to help co-create and those requirements. If if this is like this, we're not saying this is the best case scenario, OK? We're just saying if you're in a scenario like that, that would be one way to potentially look at approaching us and trying to sort of permeate us. You know that that's sort of skin of the organization where it's very protective of these kind of rituals that tends to persist. So just going back to the prototyping thing over, imagine like the they're doing that and they've got these digital prototype. Let's just be clear, like, you know, when we worked together before we tried to explore and conversational prototyping and stuff that comes from that. What why would somebody approach prototyping from a conversation with respect to what are the benefits of of working in this way? And I mean, again, I'm playing devil's advocate about this

00:18:08

S2: because it's fast, right? There is a huge bias in in design. It's fun, it's fun. It's fun and it's fast. The thing is, you know, try just take a timer and time the the time it takes for you to sketch a certain interface or a certain interaction. And then. Think about, OK, so this is the interaction, if a human now would replace that interaction. You know, if we had a employee doing this instead of an app, right? How would that conversation work? And so if we do that then and you time the conversation and use kind of improv theater techniques, you know, you just, you know, do you play around with this and you say, OK, now I'm I'm the employee doing the service for you. Maybe, you know, travel advice or some, you know, navigational stuff for your for your holiday. Then I can we kind of just have a conversation. Imagine you have to draw all this in a user interface. And how long would it take? And this is this is one of the things prototyping tries to maximize learning, and we can go through so many different variations in a conversation much more quickly than we can, drawing it out at some point. Of course, we need to make a decision. So what is kind of the channel that we that we want to have this in? Will this be an app? Will this be a website? Should this be the call center taking taking that part? But there's this. This is one of the things you don't always have to prototype in the same channel. It depends on what question, what you want to learn. Sometimes you need to build prototypes that actually allow you to make. That decision doesn't need to be an app at all. And this is something that is not happening because we always know we need to build that app. And so these kind of lightweight tools allow us to step back and say, Let's forget that for a moment, yes, we will come back to that, of course, and 90 percent will go into there. But we also might discover some really interesting questions.

00:20:22

S1: So to reframe that a little bit more. And we want to touch a bit touch on this. There's more and around the point you made there that you already know that you were doing an app. So your prototyping an app or as if you prototype much earlier in the process, there's a higher chance that you can have more input into what goes into the app or what maybe could be or the part of the service could be, you know, paper or it could be Wi-Fi and whatever it is. Yeah. And too often prototyping happen happens too late is what we're seeing now. Prototyping is is more and usability testing. But on the point of of, you mentioned about it being fast, I mentioned about it being fun. Is that safe to say that fun makes for a better kind of experience in the in the long run? Why should fun enter in the conversation when we're working?

00:21:21

S2: I think it's about the energy in the room. If you've seen prior to having sessions, we work with a with a huge medical engineering company and you know, it was a three day workshop where they explored new services or so, you know, new service portfolio. What could they do in like two to three years? And I think after six hours, we had, you know, all the PhDs in the room on the floor playing with Lego and setting up basically huge ecosystems that they walked through like and to understand where they stand and where they could make a difference. You know, they were when we introduced it, you could see them kind of looking over to the big boxes of prototyping materials that we brought. And they were just waiting for it to be opened like a box and that you couldn't hold them back. And this is the energy intellectually in that in that field. And this has to do with with the safe space that you create around these things. You know where we are. This was about partially about cancer research and and treatments, and we had people in the room to bring that empathy. So they had a history. And so we had to balance this kind of energy. We need to, to be honest and and careful that we can say, OK, yeah, we do something for a very serious costs and we need to be on eye level with all these people and treat them in the right way. At the same time, we need to create that kind of emotional, safe space for us so that we can come up with ideas and new solutions and have some fun having fun and being playful around these things without forgetting why we're we're doing this, I think, is the trick here. So but it it creates that safe space and we've done a similar project. Like just last year where it was, you know, also again, mental health and with students. And that was one of the topics in the project itself. We use prototyping. We used quite light hearted methodologies to manage kind of the engagement in the room. And I think it's it needs both otherwise, and I'm pretty sure it's not as productive or, you know, we don't get to the solution that we got to.

00:24:05

S1: What's the antithesis of fun in the workplace?

00:24:09

S2: Oh, I don't know. The absence of fun sounds really sad. Sounds sad and so depressing. So I don't.

00:24:19

S1: Yeah, it's it's it's so miserable. But like,

00:24:22

S2: yeah, the thing is fun. I'm not sure if I'm not a big, if I'm a big fan of the word fun because it, you know, I like to have fun, but there it's also something that is maybe meaningful fun. Sometimes, yeah, mindless fun is necessary to kind of get away from something for a moment and

00:24:44

S1: mindful and mind active.

00:24:46

S2: And then but then getting back to that place, you know, it's it's a bit like in a meditation, you know, so you you notice that you're in need of something and you see that in when when I was younger, I was working for a social service and there when, when with being with the nurses, we had a bad day. You know, you wouldn't believe the jokes they cracked. And I was like, Can you do that? It's important. And it was just, you know, why this is. Oh, and it took me a while to understand that this is, you know, they're building themselves that safe space to cope with these things. And then they got very serious again, of course, and they took all the patients very seriously. And I and they they taught me that there is this kind of front stage backstage in this field, but they need to take care of themselves so they can take care of other people.

00:25:52

S1: It's funny whenever I've worked with people who who work with vulnerability in the medical space, whenever I introduce to them prototyping or investigative rehearsals, they take what looks like a duck to water. I don't have to sell it to them, OK? And I think it's because of their ability to build a safe space amongst themselves much quicker than a traditional organization and the traditional organizations I refer to as the ones that tend to have somewhat of a closed mind. It's very much control and command kind of a center of how they work and they struggle with the idea. I always feel like I have to sell this to like, you should try this like, well, why? What, why? So most of the questions that I get from from listeners are from that mindset. They're in there in those organizations. They want to change things and they struggle like with stakeholders when they say, we're going to try prototyping earlier in the process. And also we're going to do something that could be seen as having fun or more playful approaches. How have you handled that in the past? Is that something you can you can discuss?

00:27:13

S2: This is a tough one. I'm I just reminded was just reminded of that for workshop. That was years and years ago, and it was the first time I noticed these kind of inner blockades when people stopped working on something. And I think this is this is something that you seen in bigger organizations. It's. I have my idea now. I put it in a PowerPoint deck. And this is what I can do. Yeah, and now someone else needs to do more. And so we did a two day workshop in, I think it was automotive and they were trying to map out a technology roadmap for kind of the next five to 10 years. And they brought together lots of people from all around the world to join in and to kind of align. And we used prototyping for them to actually build that kind of vision of the future. But it was really interesting because there is a certain. So yes, they would be building cardboard prototypes. They would use kind of walk throughs and, you know, do all these simulations. But that was really hard. Then they thought, You know, this is it. This is now. And it was really hard to do the next step to go deeper and actually prototype more. And this barrier is this now it. I think it mirrors maybe all these kind of silos that you have inside organization now. It's someone else's problem that you have or this this tiny prototype, this inkling of a starting point. It stops it because it's then you give it to someone. You explain it and then someone does it. But it's not their thing. So how can we actually help people to learn that they can do more and this is something that I'm I've been pushing for for the last 15 years or so really is trying to say guys in this world with the technology that we have with the communications infrastructure that you can build almost anything, almost anything yourself. If you want to, you know, you find all the instructions on the internet you you hook up to the communities that help you build it. A lot of technology is there that helps you build stuff. You know, if, for example, in if you want to build digital products or the whole no code and low code movement is out there, I mean, you can build things today that you needed engineers for like a whole team of engineers for 10 years ago. I mean, look, you can do A.I. stuff yourself right now. Just putting stuff, you know, building bricks together. It's like Lego. Yes, there is a learning curve. But if you really wanted it, yes, you can. And there's lots of accounts out there, the same in in building building like physical products. There is, you know, I started the fab up here in Nuremberg, which is kind of maker space that allows you to build almost anything, you know? So there's 3D printers, laser cutters, a digital electronic workbench and and you know, there's 10 year olds that just use that stuff every day. Yeah. And hell, why should a 20 not like a 35 year old? Guy, in a company not be able to kind of pull all these things together and make something

00:30:52

S1: mash up, yeah,

00:30:53

S2: yeah. And I think that's the limiting thing we need and this is there's a lot of things you can talk about. And as you notice, I talk a lot about these things, but that doesn't convince people they need to experience that they need to experience that. Wow. I just built something with A.I., right? Wow. I just built an app, and I can't even program. Wow. Boom, right? And you need to experience these things by building and building stuff, building stuff, building stuff, and then you get more proficient in it. And of course, at some point you need to hand it over to someone who takes it further, right? But this point happens later than we often believe, because if if it happens too early and if it's just something in a PowerPoint slide, then you have to do all that convincing. Know all that, oh, we need to build good storyline because that's all. These are all evidences of. I have to sell something. I have to convince somebody a prototype sometimes. Does that chop for you without you having because people can try it and they see who that works? That's amazing. Here's even feedback from real customers using that thing and and and being so you don't need to put together that kind of super flashy storyline anymore.

00:32:23

S1: No. And I typically in businesses, whenever we talk about the value of prototyping and prototyping earlier, you can lean on the fact that you're reducing risk and increasing certainty in what you're building is the right thing. And if they have an argument with that, what's the what's their argument like? What how can they how can they match this? There's very few other things that I've ever heard of none that come to mind, actually, as I'm as I'm saying it like now prototyping can give you so much bang for buck.

00:33:00

S2: Absolutely. Absolutely. I mean, this and again, this is not new, right? In the if you look, I worked with the in the automotive industry 20 years ago and the at the time, they were calling this front loading and trying to just iterate earlier, not just just, you know, in the the half year or a couple of months before the launch of a new car, they tried to iterate much earlier. So because there earlier in the design phase in the in the development, it was just cheaper to fix the problems much cheaper because there's so many people having to that need to collaborate to make this thing happen. Now, as soon as you make changes late, of course, you have to tell everybody and you just like the cost of that change. A, you know, becomes massive if you if you're unlucky and obsolete. And the and the I mean, there is heaps of literature on this. This is what like Toyota, the Toyota Way was from the beginning. So they iterated, you know, early, much earlier. So lots of design changes in the in the early stages of development. And then, yes, there was a little bump of design changes just before the start of production. But, you know, and now this was all about the car and the same thing now happens to all the services and experiences. We're just not used to thinking about them in the same way. You know, the the Munich airport did a huge test run for the new terminal where they, you know, they sent thousands or, I don't know, hundreds of customers with carts, you know, little task carts into the new terminal, testing all the services that were there. But this was just, you know, a couple of months before I noticed very shortly before they were opening it just to stress test that and everybody is doing these pilots. Everybody's doing pilots because they don't want to to to have their big service fail when they opened up the doors. So clever people are not doing this early enough. And you know, this is where prototyping again, you know, can be of huge value when you bring together the team. That's interdisciplinary, and you actually you start with a prototyping workshop. You start the project with a prototyping workshop. Mm-Hmm. Why would you do this? Because prototypes don't need language. And if you know we did this with lawyers and desire designers about regulation, and these are two kind of and people from the from the public specs, they know this. This is a hard gap that you need to cross. And it's getting better. And there's more and more people that can, you know, they understand each other. And but at the time, you know, in this project, it was about privacy. So we brought the designers in. We brought the the regulators or regulators and had them build prototypes together. And even though they didn't have that language, the shared language at the beginning was through the prototypes they started to understand each other. And at the end, they understood what what do I mean when I say that, what do I mean when I ask that question? Where the teams together, they were proud of the prototypes. And even if you and this doesn't mean that you solve the issues that you're having in this one prototyping workshop, what you're doing is you build a base for the rest of your project that people actually know, have you know, communication and they know what they're what they mean, what they talk about?

00:36:56

S1: Yeah. Marcus, we're coming towards the end of the episodes. There's lots more than we could have. We could speak about a bit more. But you're also yourself an Adam Run, the global service champ. Is there a service on the horizon?

00:37:13

S2: Oh yes, there is a service charm coming up in almost two months. I think it's a bit less than two months in in March, from the 16th to the 20th of March. So if you're if you're remotely interested in prototyping because you know, the the service actually started because at the time, 10 years ago, prototyping and service design was the final frontier. People knew how to prototype products, but they didn't have such a grasp on on services. So we said we need to build a a sandbox where we can try these things.

00:37:54

S1: Yeah, and that's what it is. I'll throw a link to that went into the show notes. People want to reach out to you. You know, here's mini the prototype of Marcus, the latest prototype for Say, Hello Alexa, hello sir Mark. And I guess it's all Hey, it's the it's the youngest cast on this site today,

00:38:21

S2: and that's my daughter. And I think she wants to to watch, I think, something with unnamed Ellison.

00:38:29

S1: That's what I heard. Elsa, it's the big,

00:38:33

S2: very big thing. Yeah, we're just listening to the music right now, so.

00:38:38

S1: Very good. Well, look, Marcus, I'll let you go back to your day, as always. I love speaking with you. And if people reach out to you for a link to your do your website, work by experience and also you're working on some prototyping courses for this is doing as well. So hopefully have those in some point in the next couple of months. Thanks so much for your time, Marcus.

00:38:59

S2: No thank you. Thank you for having me. That's great. Thank you so much, Terry. Take care.

00:39:05

S1: So there you have it. That's all for this episode of Bringing Design Closer. If you like this episode, feel free to visit. This is 80cm where you can access our back catalog of over 100 episodes, with episodes related to service design, product management, design, research, and much, much more. If you're interested in design and innovation training, feel free to check out our business. This is doing dotcom, where you can join online classrooms and learn from the world's best design and innovation leaders. Join that! This is eight city newsletter where you receive updates from the network and also, if you're interested, apply to join the Slack community. And this is 80cm. Stay safe and until next time, take care.

‍