# Breaking Silos (and Metaphors): A 'Roving Engineer' on Design & Engineering Collaboration

## Метаданные

- **Канал:** Google Design
- **YouTube:** https://www.youtube.com/watch?v=hd2muBRsy-c
- **Дата:** 09.12.2024
- **Длительность:** 53:43
- **Просмотры:** 1,071
- **Источник:** https://ekstraktznaniy.ru/video/47578

## Описание

Find new episodes on your favorite platform: https://design-notes.show

This season's special series celebrating ten years since the launch of Material Design (https://design.google/m10)  continues with  Adrian Secord, who describes himself as a “roving engineer.” Adrian has over a decade of experience building systems and tools that transform design into robust product engineering at scale. Plus, a PhD in Computer Graphics.
 

 Here, he reflects on the evolution of Material Design and the (potentially) exciting possibilities for AI-driven UI. He shares insights on the complexities of large-scale design systems and highlights the need for designers and engineers to find common ground.

## Транскрипт

### Segment 1 (00:00 - 05:00) []

design notes is a show about creative work and what it teaches us I'm your host Liam spron each episode I speak with folks from unique creative fields to discover what inspires and unites us in our work this episode I'm continuing with our special series celebrating 10 years since the launch of material design which explores the Inception Evolution and future of Google's design system this time I sat down with Adrien Secord who describes himself as a roving engineer Adrien has more than a decade of experience Building Systems and tools that transform design into robust product engineering at Google scale and a PhD in computer Graphics too in the interview we dug into the perceptual qualities of design why every engineer should experience a design crit and why yeah designers probably should code too let's get started Adrien welcome to design notes hey Liam it's so nice to you thank you so much for having me yeah I'm really excited to have you on I want to start the episode the same way that we always do which is to talk a little bit about who you are what you're working on and the kind of Journey that led you there yeah for sure so I'm an engineer uh unlike a lot of people I'm working with who are you know designers and design oriented um been hanging out on material design for about 10 years now um in fact it was really fun listening to you talk to will larsh uh in the other episode because uh he and I overlapped heavily for a long time so it was sort of fun to hear him talk about the past um before I came to Google I uh was doing a lot of grad school I have a PhD in computer Graphics so algorithms for um movies and video games and that kind of stuff never used any of that information uh knowledge uh instead joined a startup like many people did and then like many startups uh it fell apart and was sort of purchased quickly by Microsoft and I didn't want to go to Microsoft leave New York uh so ended up jumping over to Google and joined Google wallet and I was an iOS engineer on Google Wallet for a few years um and during that time I started teaching an intro to iOS course at Google and so during that point I met some people who are working on material design from the engineering side of things and as I'm sure you know the original material didn't really have a lot of engineering um or it was sort of a group effort across the company to build components and patterns and things um as sort of needed ad hoc um a lot of people working on Google Maps we building stuff Google search all those kinds of things um but material design had just started a nent engineering effort to centralize a lot of that work and one of the people who I often co-taught the intro to iOS class aliser SE um he was uh working on material design and pulled me in and uh Alistair is fantastic but I miss him a lot even though it's been eight or nine years now but uh he pulled me in and started working on iOS components for material design and that was kind of the very beginning um and then over time I ended up um actually taking over that team uh as Tech Le and then his manager managed that team for a little while um and then jumped to be a sort of overall Tech lead of all the different platform teams so at that point material had invested in engineering across web and IOS and Android and flutter even um so I was sort of an overall Tech lead for all those teams trying to coordinate things and make sure that we did the same things at the same time maybe we release the same kind of components at the same time um that kind of work and uh eventually moved into a different piece of material where we were building out design tokens so design tokens are you know not invented at Google but very common across uh the design world but at Google as you well know uh it's its own giant ecosystem internally and we needed to build some infrastructure um some you know database some servers some services apis to store and serve design tokens across all the different teams who need to use them uh so I got to build that backend out which was super fun and I basically kind of went from more or less front end and front-end thinking to more or less backend thinking which I really appreciated it was a great opportunity at Google um to be able to do that and so built at the back end for design tokens and things um still pretty involved in that world I know a lot of the people working on it and occasionally get pulled in to help out with things um and more recently I

### Segment 2 (05:00 - 10:00) [5:00]

described myself as a roving engineer I am still within material design or our greater org um but uh I essentially get occasionally grabbed and thrown into a problem area and help out for six months or 12 months and then go and do some more troubleshooting somewhere else so I'm kind of I kind of bounce around from hot spot to hot spot as required okay I know that near the beginning of the journey you said that you uh did a PhD in computer Graphics yeah and then you said that you didn't really do anything with that information true one of the things that I'm really interested in on this show is like the ways that the different parts of the journey that like brings us all into the design World um ends up showing up in our work so when you say that you didn't use the information my first instinct was like are you sure you no I'm lying it's not true uh I mean everyone brings with them their background and their experiences so I mean there are technical things um for example uh I think uh will lar was talking about um color spaces a little bit the HCT color space and um uh how we had to sort of invent a new color space to better represent what we were trying to do with um personalization uh and those sort of related Technologies and it was actually really fun watching that develop I was chatting with some of the engineers at some point but uh I did not personally work on that work but it was really great to see a new color space come to be born you know in the world there are many color spaces you know everything from like spectral stuff that uh you know astronomers would use all the way down to some very simple things like RGB um and everything in between you know and it's been sort of slowly developing for I don't know 50 or 70 years by this point um but it's always exciting to sort of see new one get born I think the other thing that a PhD teaches you is um perseverance no one survives the PHD program without a lot of just uh you know get put your head down and kind of crank out a bunch of work and um keep it going year over year um so that's something I feel like I did learn and um I have been very lucky to be on material uh working here for over 10 years now um but there's an element of that of trying not to bounce off of problems you know when you find a problem dig in and kind of sit with it and you know maybe sit on it uh and not just sort of like oh this is getting too hard I gotta I got to go do something else um because you know we all have our various uh demands on our time and uh sometimes it's easy to go pay attention to the other things instead of tackling that really thorny problem I mean so yeah yes I mean although I I'm not generating algorithms for you know XYZ or anything like that it's uh the kind of technical content of the PHD is now out of date and uh I didn't actually use it in the sort of um academic sense which is what most PhD training really is right I know if um colleague Friend and Friend of the show Yasmine is listening she will know what you're talking about when you talk about committing to the problem over time especially at Google it's very like our plans are measured in centuries kind of Vib 100% also hias yeah shout out to Yas exactly when you mentioned the color space specifically and like seeing a new color space get born I think this is something we've had a few like really interesting articles that go into how the color space works and like what it allows us to do and things like that but I'm interested in like why it's so exciting to see something like that come into the world um that's a good question I mean from a design point of view all of these color spaces and all of these abstractions uh change how you can look at things like uh you know uh color comes from physics and you know all the light that's shining down on us right now has all these wavelengths and all this sort of stuff but that's almost like that's way too complex um to handle in any kind of realistic sense I mean like I said like if you're doing astronomy sure if you're doing you know chemistry sure but um for people that are responsible for doing things like either color on screens which is already a sort of limited slice of the universe uh or color in printing so that's another huge traditional place where color spaces um Thrive um or color matching or looking at a table right now

### Segment 3 (10:00 - 15:00) [10:00]

you know matching a color to the tone of this table or something um the color space that you work in is kind of like the language that shapes uh your thinking you know about the problem so it's exciting to see a new color space come out of uh a new set of requirements really it's a really interesting design problem not because it's not software I mean I know there's software supporting it but it's really a mathematical model you know of what are the important parts of this giant uh you know nearly Infinite Space of things what is the most important parts of them and how can we collapse those important parts down into like a set of numbers or you know set of smaller Concepts or something like that um that make it useful and fruitful and convenient to use so to see a new one pop up first off I mean there are a lot of color spaces and I would probably say 90% of them have you know gone by the wayside I mean they just didn't survive the uh in the landscape of competition of ideas uh and so to see a new baby one come out and uh and see where it's coming from like why you know why did we make the choices we did why did we need something new you know which is always a great question um uh that's an exciting moment and I think it's probably too early to tell but maybe you know in five or 10 years time we be looking back and maybe you're on the Wikipedia page for color spaces or something and I really hope that you know that one pops up it'd be nice yeah we can talk about it again uh during the M20 campaign exactly 20 it's going to be great um that uh is really interesting to me because it has so much to do with perception and you know you're saying like color is based in physics and stuff we know that people perceive colors differently it brought to mind how uh working in engineering on a system at the scale of something like material you are probably dealing a lot with finding ways to abstract perception to essentially like bring this subjective experience down into something more apprehendable which is code or a mathematical model or something like that yeah and I think um a lot of my work involves Design Systems you know uh material design being the sort of Parental design system at Google but um I don't know if everyone listening knows this but there are many Design Systems at Google and uh they're children of material design uh in a very literal sense uh but like um Maps will have their own design system and search has their own and they're all born from Material design but they have their own local work to specialize to their domain like a map or something um and Design Systems in themselves are an interesting abstraction of all the possible things we could do on a computer screen or on a you know a phone uh it's a really interesting and almost brutally hard problem to sort of think about like really when I'm looking at a laptop like I am right now there's you know so many pixels by so many pixels in a grid they all can take on so many different colors it could display pure static we could display you know rendered 3D shapes we could do all sorts of stuff but it's too complex to think about it that way and um not only for the designer and the person building uh The Experience on the screen but also for anyone trying to understand it and use it to get you know real things done um so we boil things down you know we create these abstractions we create these systems and in part of creating those abstractions and systems we have to explain them to people right so I think this is where the storytelling and the um visualization maybe part of abstractions like Design Systems come in which is very interesting so how do you explain like I sat down for six months I figured out this great system of boxes and things on the screen that I you know I think I can make word processors and podcast apps and whatever with and it's great but then how do you get that out of your head um that 6 months of hard work and into the heads of people have to build stuff on it people have to use it all that kind of stuff and for me that's one of the difficult and interesting problems of building these big abstractions um and uh there's a shout out to the original material actually um they had a beautiful just this beautiful um way of describing it that everything was supposed to be essentially cut out from pieces of paper they were literal pieces of material right I don't know if you ever saw this but the original material design uh they

### Segment 4 (15:00 - 20:00) [15:00]

actually took real paper cut things out and saw how the light and the Shadows worked and they have these we have these great photographs and some of the historical stuff of them like setting up lamps on a table and casting shadows and that's how they built the original um interface components um by analogy but sometimes almost just by copying uh these physical things and the wonderful thing about that is that it's pretty easy to explain to people you know like we're all used to picking up pieces of paper and working with things and Shadows and Light and all that kind of stuff uh of course it can go too far you can go into the skorm you know which is you know I don't know maybe entertaining but not the most useful thing um and I think further iterations of material M2 and M3 and everything that's you know to come uh have definitely wandered away from any kind of physical metaphor but explaining that um gez we just spent so much time trying to figure out this system explaining to other people via a physical metaphor uh that was brilliant I thought that was it was really great and uh um I got to join the team actually just it was just like a year after the original release of material and I remember being so impressed with this sort of like oh this is a very clear system you know it was also very small and maybe uh not so tested at that time you know and not hit up against the harsh bumps of reality as much but um it really was a very nice uh clean system um so there's something in there about having an abstraction not only having abstraction that is useful um and uh fits the problem space that you're trying to solve but also is you can explain it to other humans if you can't explain your distraction to other humans it's you know it's going to be really tough yeah it's interesting this point of like consolidating all of these ideas and then needing to turn them so that they come back out and kind of like spark the same imagination in other people a previous guest on the show Judith donath um who's done a lot of work on um sociable Computing and topics of the interface and things like that um it said that metaphor has kind of always been one of the fundamental ways that we explain things that people have not encountered before that makes sense obviously we see that reflected like in the original version of material it had like an extremely wrong metaphorical basis to the point that yeah you're right like there's videos of like Christian in his garage with flood lights and these paper rigs um but the system has really evolved since then and I think that like onetoone metaphorical basis is no longer there and I wonder One how important you think that metaphorical basis is to in today's context and two if you think that the software interface is something that has become so established that we don't need to rely as much on metaphor to explain the fundamentals as we might have 10 years ago yeah 100% the um the initial problem of explaining how to use something to people who did not grow up with it or are not familiar with it is like real and probably something that happens all the time I don't know like maybe self-driving cars are having this problem today or something um certainly anything do with AI we're having that problem today no one has any clue of how to like hold or handle an AI thing right now it's you know all over the place um and I think with uh original um you know metaphors like the desktop metaphor I think you've talked about before um uh the sort of paper material type thing for original material all these things are familiar uh make things comfortable um hopefully make it understandable enough that people can make leaps based on what they know about things and have it apply to the actual digital imaginary interface um so they're very useful that way but I think as people get more and more used to this and are like literally borne into you know uh like the cell phone era and things like that uh we are given the freedom to wander away and it's okay people don't get mad they you know um I think the schorm thing is really interesting I'm sure there's people who studied that uh you know academically and uh in interesting ways but we just don't design things with faux wood grain and things that look like you know podcasting app with a little microphone and stuff like that uh because partially I think we don't need to anymore you know uh we don't really need to spoon feed um users on these Concepts at least because they grew up with them they know how to use them they're pretty familiar with them um we no longer have uh you know no longer have High School courses that teach people about how to use a mouse

### Segment 5 (20:00 - 25:00) [20:00]

you know although I'm sure maybe they're still typing I don't know but uh there we don't really need it anymore so it allows for more freedom of expression which to me is exciting but also you could wander too far a field you could you know your your uh design UI elements or whatever could get too abstract or too maybe too inconsistent um so like I think as you know working on a design system uh one of the important things is to make it as consistent as possible to have some principles whatever they are and have those shine through everywhere in the design system in the UI elements and how they interact um so I think there's you sort of run the risk of like it gets too floofy it gets too abstract it's no longer holding together and then you know what do we got uh I don't know sort of falls apart yeah that's an interesting point that actually so many possibilities are opened up that you need to create kind of a your own pocket world that holds some internal consistency so that people can build a model of how this works yeah I love that one of my friends is um a faculty at of um of game design actually his name is Andy nean and uh we talk about you know we play games together we've been playing games together for a long time uh before he was a professor of games but uh we play games together and we often talk about um sort of video games are really interesting because people aren't surprised that they have to learn the interface every time they sit down with a new game right you and honestly if it's a console game you probably know how all the buttons work if it's you know a pointand click thing you probably know how most this works but there's always this tutorial phase this opening phase where you're like learning oh that's where the jump button is or I don't know there's no jumping in this game fine I have to figure other things out um and people aren't like surprised or shocked or bothered by that um so it's a really interesting sort of uh you said Pocket World I think um every game is a little pocket world for UI design um but also you know physics and you know because in games they can do whatever they want so physics and interactions and um how characters interact uh do you speak to people do you not um who are the bad guys who are not the bad guys all that kind of stuff um I find that really interesting cuz it feels like sometimes it almost feels like I can see the original like game designer sitting there and going like trying to talk to me telepathically through the design of the game right they're not there in the room to say anything and sometimes you get frustrated with it you're like why did you put this thing that looks like I can jump on it but I can't jump on it you know like what are you doing uh and I sometimes wish I could have that conversation with you know theal game designer but um yeah I love that idea of a little pocket world of um of interface or um something that can explain how to interact with things that's great so in like in recognition of that kind of possibility does that then make the task of kind of engineering or engineering leadership even more difficult when you have like such a broad range because I know on material I've seen folks draw things or animate things that um you know are brilliantly far away from anything that we know to be possible in the physical world yeah so I can imagine that looking at something like that and bringing it back down into the system can be uh intimidating is one word for it yeah um uh there is forever a tension between design and engineering and um ideally it's a creative tension that great things come out of but sometimes it's a little tricky and motion I think actually it's a good example is one of those places where we have not done well enough in the world of uh UI design uh there have been so many um great like sort of I'd say Micro Design Systems of motion about oh like well when you interact with this it does a certain thing or um or maybe tunable so we could have something that's more hyperactive we calm and enterpris uh and they rarely get kind of well translated when you get down into the code and the implementations and things um and it's uh it's a really tricky uh kind of balance to make because uh the designer is designing um in well ideally not in a vacuum no I mean a designer's job is to not you know necessarily be in a vacuum they're bringing all their experience and all their you know uh

### Segment 6 (25:00 - 30:00) [25:00]

World Knowledge in with them but in the end they're not designing typically by writing code on an Android device you know that's just not kind of how the process works so uh they designed some motions some awesome whatever bouncy thing uh sometimes an element in isolation you know will have motion but maybe we're not thinking about okay that's one button on a crowded screen of all sorts of stuff how does that you know maybe that makes the button I don't know overlap of the things and that's tricky um I think one thing that's interesting about being an engineer is in the end your job is to make it all work um and so they're often engineering is often left um figuring out uh a lot of the little details and the little problems that either were not thought of or maybe they were thought of but not documented so we're not dead sure of what we're supposed to do um so it it's the transition from design to engineering is um a really interesting one and uh ideally it's working very well you know so you've got a designer and they sit next to your engine you know the dream you've got a great designer sitting next to a great engineer at the literal table and they you know they're bouncing ideas back and forth oh this doesn't work oh this does work great let's do this but in reality uh in these large company settings you know uh design is designing a thing kind of packaging up and maybe putting a bow on it and then handing it off to engineering for feedback or maybe even just final implementation and then the feedback starts coming oh this doesn't work and that doesn't work and uh you know if there's enough time that actually rounds off the sharp edges of the whole thing and we end up with something that's better um but I don't know if that's always the case yeah we talked earlier about how like our entire team basically is collectively uh speaking to the outside world and perhaps many teams within it's our job to kind of consolidate all of these ideas into some form of communication that then comes back out and helps everyone understand what it is that they're using that we've produced and I'm kind of seeing like a smaller version of that playing out like um among teams who might have to do certain parts of the work asynchronously from design to engineering how do you uh convey the rationale in a way that Sparks the same understanding in other people that you had when you made the thing I think it's the same also like when I work with another designer an engineer editor it's like not only you know here's the thing that I want to do but also you know they might say here's how it breaks and then I have to say okay here was my intention like what might we do yeah in order to resolve that and I think that well I mean uh the hard problems are always the human problems and I think one of the hardest things is communicating intent like you said um and I think one of the good things I mean we're talking about material 10 here coming back to the either the original material design or its current incarnations I think one of the greatest things about it was that we had all this WR written guidance about how it's intended to be used it's not just a sticker sheet of all the button variations and slider variations or something it's trying to explain this is what we were thinking this is sort of how we think these things go together um all the way down to like dos and don'ts for using a button you know that kind of stuff um but communicating that intent especially when you're not there or can't be there because of geography because of time um because of time and the way that maybe you you did all this work and designing all this stuff but we decided not to build it just yet and then 18 months later we're like cool now we have time to build it and you know that was 18 months ago so there's you know there's barriers to communication sort of everywhere uh and I think it's really tough because the it it's hard because your intention and I mean maybe you had a beautifully fleshed out model in your head of how all this hangs together and stuff um and that's great but if it didn't get kind of like written down and recorded and um in some form that say an engineer can understand um it's not I don't want to say it's lost but it's going to make the job way harder um it's a really interesting and I'd say permanent problem like I don't think AI is going to solve it for us I don't think anything's going to solve that for us as long as there's people um collaborating on something especially people with different backgrounds so um I would in an Ideal World I would love every single like UI designer to

### Segment 7 (30:00 - 35:00) [30:00]

have engineering experience and I would love every single engineer out there to have to go through a design Sprint and a design crit and all that kind of stuff in reality we know that's not really the case so without that shared background and experience um I mean you are an exception sir uh but without that kind of shared background and experience for both sides of the the process it it's really tough like the language is different the metaphors are different your training was different you know all that um it's a hard problem yeah so design notes is going on record us saying designers should code designer should code and I mean Engineers should design that's I would be super excited to see that yeah totally yeah I think there was a really interesting point you made about the um again about the original material design spec which was uh that there was so much of the intent behind the system embedded in the way that it was described there and that resonates with me because I feel like over the years I've heard over and over again at IO or just online or wherever that those specs were a lot of people's including Engineers first introduction to design period 100% yep um and I wonder like the system has made some major shifts over the past 10 years with personalization tokens like new technical complexities more components um we're at a point now where I feel the system is actually quite powerful in the way that it abstracts things and I think we also face a challenge in conveying that same level of intent in a way that comes out to the overall audience out there and I'm curious what you think about that as we grow in complexity how do we keep explaining or keep uh embedding that knowledge or building that model yeah that's a great question um I know for instance material design the sort of the public spec that we have up on the web is used um in a lot of uh design curriculum you know which is great you know it's such an amazing thing that someone's like teaching off of this or using this as a resource in the teaching I think it's super cool shout out to Austin and Barbara and Megan and eup Fates and the whole team 100% wonder I am extremely lucky to sit with some of those folks uh my desk uh is right next to all of them or a bunch of them and uh I yeah I'm a lucky guy I'm a lucky engineer um uh the complexity question is really interesting and really hard uh so like in software there's a very I mean well understood not solved but well understood problem of systems that grow over time right so if I'm creating um let's say I'm creating a 1. 0 of um uh a map API so I can you know you can hit this API and ask for I don't know um the coordinates of the closest uh coffee shop and it will you know spit back something whatever you can imagine some kind of API and at the beginning it starts small it starts tight um every different API entry point every different call you can make follows the same patterns and the same like error responses and all this kind of stuff um and that's about as tight as it's going to stay at the beginning right because over time say your API gets very popular maybe it's a product maybe it's being sold um you get these feature requests uh certainly bugs will show up you miss something we're all human um uh but you get feature requests to build on it you start adding more things and we all try to stay consistent as much as possible uh but uh again Being Human we're going to fail um and sometimes there's serious business concerns you know like if you're at a startup and if you don't add this the next three days we might all go down you know um so over time the it of the interface grows even if it's um with the best of intentions the more and more we add to this thing they get sort of it gets heavier and kind of creakier and harder to understand and I think this is a very natural result of successful systems any kind of system um and uh a lot of the time at least in software they you know you can see this in open source projects actually you know you you've got some this is I mean so common you've got some very well-known Library say it's a mapping library or something and it's had a 1. 0 now it's up to 1. 7 whatever it's had many iterations but it's getting creaky creaky and somewhere at some point someone is going to say you know what I'm going to rewrite it like we're going to start the 2. 0 project and it you know open source it causes the Schism in the community and there's people that no no keep the original no no I want to build this new thing uh and they try to start again because basically the complexity gets too high to make progress um uh

### Segment 8 (35:00 - 40:00) [35:00]

there's something similar in terms of you've probably bumped into this uh in terms of teams who maintain sorry software teams who maintain a product so at the beginning you know I've got my product um maybe I've got 10 Engineers great and we're adding features at like you know I don't know one feature a week or something great but then the size of your project or product is growing um so the number of features requests and bugs and the maintenance involved grows and grows until the point you get to some point where the product is so big that the maintenance cost is 10 engineers and at that point you will never add another feature because it has grown to the size of the team who supports it and you know at then you have you got to do something drastic to to fix that um I've gone far a field of your original question I think no but it's good because I'm also wondering like you know obviously maintenance is one thing that I've bumped into uh over the years but also I'm curious about code as a constraint or like the complexity of the system becoming a constraint in the sense that you know no spoilers but I've proposed features for existing components that you know the components are built in a certain way in a library that people are actively using and uh certain new behaviors would make it really hard to kind of build that component in the way that it currently exists so where design runs up against what is possible with what is built um how do you think about resolving that how do you know when the balance of changes that you would have to make in the way that the code is built uh is worth it it's a good question um so I would say software engineering in general is um a game of tradeoffs right it's always we can do anything almost anything uh software engineering is a kind of wild world these days of like it's a there's a lot of magic it seems like magic probably from the outside but and of course there's a billion constraints on the inside but within those two you know bounds there's a ton of room to build things in many ways so like you said so you're let's say to be concrete you're proposing um a new animation style for an existing button that but that button is used in a couple hundred places in every say let's say it's internal every Google app great how many Google Apps are there I don't even know but there's dozens is too small of a number right so uh that button is being used everywhere and you want to add this new motion constraint to it but the original authors of the button weren't even thinking about motion they were just like oh well we know what the right motion for the button it goes I don't know click or something like that um uh and they have no concept or no ability in there to add anything new in terms of the motion curves or whatever it has to do uh at that point it's a that's a big trade-off right so you have one designer who has worked very hard and has brought all of their knowledge and training to Bear against some problem um and their answer is okay cool what we need to do is add this new motion curve to this button that's like 100% cool and that is exactly why you know designers are awesome and that's why they're there and then we have all these Engineers uh who are responsible for you know shipping this button and getting into the apps and all the bugs that come back and all this kind of stuff who are saying like yeah that's cool but for us to change this say several thousand instances of this button everywhere it would take us I don't know six months of work or something um especially at something the size of Google and then someone has to balance the you know the the tradeoffs between the benefit that new thing would bring against all that engineering time and one thing I will say is a lot of Engineers especially if they're not um haven't been designed adjacent and haven't worked with designers tightly uh I think a lot of Engineers sometimes have the sort of crusty response of like no I don't want to change anything like it's working leave it alone you know why are you changing my buttons basically uh you know we get this all the time in material design and I respect the position but I think it's also a little shortsighted sometimes um and someone needs to you know bridge the gap between those two um and ultimately make a call at least in an organization like Google um in a startup I'm sure you could do something a little bit more agile um the trade-offs are there but you know the scope is smaller um I I don't think there's the tension between those two things is is never really going away um and

### Segment 9 (40:00 - 45:00) [40:00]

I don't know I mean the answer is always like shove everyone in a room and make them figure it out you know get the humans talking to actually talk about it um but yeah uh making those kinds of changes is very hard yeah I think um definitely at previous jobs I've worked with software Engineers who like the first reaction that I get from a proposed is like that simply isn't possible yes and I think something that we um have mostly gotten the hang of on the design side is answering every question with well it depends yes well it depends I think that's ultimately the answer to everything yeah and to come back to what you were saying before that I know these are imaginary people were making up here but that engineer that says um that simply isn't possible maybe with this kind of like slightly dumbfounded irritated view look on their face like they thinking of the abstraction to go back again the abstraction that has sort of been built into that button say you know it's I can change the well you know font I can change the color but no there is no way for me to change the motion curves or no there's corner radius or something and of course there is in the sense that it's all software I mean we could you can rip down rip things out uh and get pretty low down in the stack if you have to but in their heads their day today conception of that button uh which exists for a very good reason they have that conception that their day-to-day conception of that button doesn't include these affordances the motion and the corner radiuses and stuff so for them in that second like it's a true response you know like it's a real like I don't know what you mean like this brick is a brick I don't know what you want me to do with this brick you know what's going on here but the one thing that's exciting about software um development is that uh you know you could you can disassemble the brick you can bring the brick down to its component atoms and start again to you know to kind of you know bust this analogy badly uh but uh I like that kind of reaction of like oh that's impossible because there you can clearly see at what level does their level of abstraction sort of stop or what's their working concept you know yeah there's a concept um again like I have a background in sociology and art so I approach design from that perspective a lot and I think one of the things that we're talking about here which I think we've been talking about the whole time is the concept of inter subjectivity which is basically like person a has a perception of a phenomenon in this case it's like the button that is their like model and informed the way that they built it I also have my own model of the button but inter subjectivity is like knowing how to have a perception of the other person's perception how to orient yourself towards that person's mental model of the button which I think is what we're talking about when we talk about how Engineers need to have a design perspective and designers need to have an engineering perspective we need to understand how each person is kind of modeling the same concept in their mind because it's not the same going all the way back to the beginning of the discussion with perception and color yeah I it's I honestly think it's like one of well it's one of the biggest challenges in life you know like uh I've got some or it's the biggest source of or a big source of misunderstandings in life you know I've uh I don't know uh I've got a certain sense of like how clean the apartment should be and maybe your partner has a very different sense of how clean the apartment should be based on like how they were raised and like I don't know Stu that they see uh but if you don't ever talk about that uh you know you're going to just be buding heads continually um it's similar I mean luckily for design and Engineering um uh one nice thing I think actually be about this problem in a work context is that um as long as everyone is respectful and cool and trying to you know in general do the right thing um uh the way around this is like I said is we all sit down and ideally in the same room physically but you know in the same virtual room and kind of talk it out and then I learn your model and you learn my model and I love I love being in some of these problem solving sessions where we're like you know no we can't add motion to this button it's impossible I absolutely love you can see the light go off in someone's eyes when they're like oh wait you want to do what and then you can see them finally mapping the two models together yeah and and

### Segment 10 (45:00 - 50:00) [45:00]

figuring out what you wanted and then like and then usually it goes fast and it's like oh cool yeah we can do this yeah goes from there I think it's um I feel like we've had a breakthrough on this episode I feel like designer developer collaboration is unlocked I feel like this makes it like this perspective on things makes it such a more apprehendable problem it's not like it's not something that's unique to our work environment or our roles within that environment it's actually just what we're doing all the time every day yeah 100% it's just been professionalized and um I often think about the training we all got like I didn't I get I didn't get trained as a designer um it sounds intense I've never been through a design crit despite me claiming I should do that uh sounds intense um and uh designers who came up through sort of a traditional training also didn't uh you know did stay up all night in the engineering lab like getting whatever done um and we so we've just there's different cultures you know kind of bumping up against each other and ideally that is Rich and fertile and everyone is excited to learn about their you know uh their co-workers how they're thinking all this kind of stuff sometimes time pressures and Geographic differences and uh time zone differences and stuff leads us to butting heads a little bit more than it should be I I hate the I hate the standard kogin Le engineer thing of like oh well design just designs these wild things and then throws them over the wall and now I got to learn how to build them you know or figure out how to build this thing I really dislike that because uh you know design is amazing they do amazing stuff they're also humans who sometimes mess things up or don't understand say like um you know really common things like uh my phone needs to run at 60 frames per second that is the standard set by the system and if it doesn't run at that like there are severe consequences therefore there are real constraints on your motion curve or whatever uh but designers can grck that and then like you know we can get better together but also like get over here you know the wall is not endless exactly come over to this side and and I'll do the same yeah um I want to wrap up you know um ostensibly we're here to talk about the history of the design system the past 10 years all of that stuff but I also want to take all that information that we've just talked about and get your idea your extrapolation into what's going to happen next what do you want to happen next sure uh so I see a fork in the road I'm sure you see a similar Fork um and the fork in the road is this we have the Juggernaut of AI um bounding towards um obviously Google and many other companies are working very hard to figure out how AI might solve real problems uh but in terms of user interfaces uh one branch of the road is well the sort of I would say I guess now traditional UI design Paradigm right so we work with designers they come up with Design Systems we um uh come up with color systems and motion systems and we um codify them into design tokens which then get shipped to engineering and Engineering uses those things to build experiences that turn into apps that's sort of I actually don't see that changing too much there's a different branch in the road uh that I've heard people talk about which is my phone or my app or something will basically become an empty container um and then AI will on the Fly based on my needs and my preferences and what asking for and stuff ship UI down the wire or down the radio waves into my phone and the phone's UI will you know update spontaneously based on the current task and this kind of stuff um so sort of a fully AI driven real time UI uh I am having a hard time imagining that second branch of the road being sort of practical um but it is totally possible I'm wrong but the future as I'm seeing it right now is uh a little fuzzy uh as is many things with AI uh I have a hard time imagining a fully Aid driven UI but um I would be excited to be wrong um and I think the interesting the more interesting part will be how does um new technologies like AI or whatever is coming next um modify the traditional design and Engineering um uh workflows uh so um so for example one thing right now is designers at least at Google and

### Segment 11 (50:00 - 53:00) [50:00]

in many other places are the ones who have to go through their Design Systems or go through their designs and pull out the design tokens right they need to pull out oh the primary color is FFF the something else is something something and then they kind of either input those into a program or write them down in a spreadsheet or whatever the workflow is and some you know somehow those get transformed to code you know it's all sort of dependent on your environment um maybe that's a place where something like an AI could help extract that step and basically make it transparent like make it to the point where we kind of Engineers consider like a compiler or something it's just like oh yeah I don't even think about all the machinations that are happening to extract that stuff and it works almost perfectly or perfectly enough that I can forget about it um and that would be like if we get those are the interesting bits how do we make these Technologies actually help the sort of human process um I hoping we don't end up in some spot where all these new technologies are like eliminating the human process uh because I think that would be a giant loss and kind of lame and boring um but it's possible I don't know the optimistic perhaps naive part of me thinks that humans are always going to be human processing yeah I don't know how that could be replaced I think if Humanity has no creative motivation then we're like living in a different dimension yeah uh I guess I think some humans will always be doing the creative stuff I worry about um how many of them can pay rent doing so with some of these Technologies coming down the pipe I don't know uh it's uh let's say uncomfortably exciting mhm um we we'll see where it goes yeah for my part I have to say um you know another thing I did when I was in school was glass blowing and my professor was really good friends with an artist um who worked in Venice and he had a big studio and he had many people who came out of that studio uh to start their own Studios and one student in particular um ended up copying one of the teachers most iconic works and kind of selling it and people always ask this guy in interviews they said like aren't you upset that one of your students is like ripping off your coolest piece or whatever and and the guy was like no it doesn't bother me because I think people who uh encounter this work will always know the difference and I do think it's the same for the interface yes we will always feel the difference yes these things that have high touch literal touch but High um we're experiencing them pretty deeply I would say or at least um uniformly through the day and regularly and stuff I agree you definitely feel it it's like um font selection in books or something sometimes you pick up a book and you're just like nope not reading that because I don't know what the heck that font is I don't know if it registers like uh consciously but um yeah I agree we're very sensitive to these things thank you again Adrien for joining me this was a really cool episode yeah thanks so much it was really fun to be here you can subscribe to design notes on Spotify Apple podcasts or wherever you're listening right now if you like this episode leave us five stars and stay tuned for more interviews with the founders and stewards of design of Google as we uncover new histories perspectives and futures for the interface as always thanks for listening and sharing