 Responsibilities, we are always here, everybody's responsible for design, but sometimes it feels like if everybody's responsible for design then nobody is. And it seems like a leader question, but who do you think is responsible for design? Well, I know you don't want me to say this, but everyone kind of is. The idea is that as cheesy as it sounds, you're working together as a team and your goal is as a team at the end of it to produce something good. Now how you go about doing that is a good question. In some cases, you have these very isolated teams, almost like silos, where you have the developers and they prepare a design and, you know, it's this complete thing and now they hand it off to the developers to implement. You don't really want that kind of experience. And I mean, I've had some experience of that in the past. I work on material components for the web. And so by the necessity of that, that's pretty much what happened there because we had the material design spec and then we had to go ahead and we had to implement that as different components for the web. That becomes a very challenging process because I feel that the interaction between a designer and a developer should be a dialogue, not something where there's a prepared design that gets implemented because there's always something missing there. What happens in this particular situation? And you lose context, right? You lose context, yeah. And I think it's important for developers to bring some of that context into this discussion as well. For example, where it comes to platform specifics. Like the behavior of the platform. The behavior of the platform. And you know, all of the caveats that come with the platform and all of the positive aspects of it as well that you can really, you know, seize and put into your design. I think that's an important discussion. For example, where it comes to things like typography. The web is full of problems because fonts are big. And if you're making your end users download them, you're going to have to consider what happens while the fonts are downloading. What happens once the fonts do download? You know, do you swap in a system font by the downloaded font? Do you wait a while before you do that just so you give your user a chance not to see that jarring transition? And these are all learned things that as a developer you can have the designers with, particularly if they're new to the platform. Do you feel that your responsibility is to support the designer as well as being responsible for the experience as well? Or is that just really based on the relationships that you have with the designer that you feel that you may have had to take hold of that responsibility? I don't see it as much of an individual responsibility. Again, it's kind of a shared responsibility where you're only really as good. Both the designer and the developer are only really as good as what comes out at the end of it, right? Because you can have the most amazing design and if it's not realistic to implement it according to the restrictions of the particular platform you're going to implement it in, then it's not going to work, right? So why call yourself a developer anyway? I mean, it almost is like you're one step away if you're taking the responsibilities of behavior from the user perspective rather than from just a purely visual design perspective. But like how are users going to interact with the product or whatever? Why not just be a designer? Well I think it's really a matter of focus. As a designer I wouldn't do as good a job as I do currently as a developer. Whereas for a lot of designers it will probably be the other way around. So I think we can frame the whole thing in a matter of focus. So I know I won't be doing design full-time but I feel like I should know enough about a designer's work process, about a designer's tools, about a designer's language in order to be able to collaborate with them and present problems to them in their language and present solutions to them in their language. The same way I feel that it's useful for a designer to know a little bit about development, not be able to put up a website together and ship it to production, nothing like that. But know a little bit about what it's like to develop a website based on a design so that they can then communicate with me in a similar way. I mean, there's a thing that Nick Butcher, one of the design advocates on our team, he talks about ceilings and floors, especially when it comes to material design. And so some people see designers, developers see material design as a limitation, that it's a ceiling because it makes you design products that look like Google. But his perception, and the way he sees it is, no, it's actually a flaw, is you build up upon that. And I kind of like see the similarities. So in a sense, the design and developer, that's the focus rather than the limitation. Right. Did you say that's true? Yes. I think that's true. That it's important for us to know a little bit beyond our own core jobs, because that's the only way that you're actually going to be able to work as a team together. I mean, if you're living in different worlds, it's going to be very hard to work together. So you have your specialism, but that's the starting point rather than the end point. Yes, exactly. That's what I feel. I think in that case, it is not really limiting. It's more exhausting because you have to have much more feedback loops with the designer into can't do this. What else do you think could work? I can place the underlying in exactly that position because I don't have control over that.