Design Engineering with Maggie Appleton

What makes for a great designer or a great design engineer and what can us software engineers learn from them? Maggie Appleton is one of the most thoughtful design engineers I know. She's worked as an illustrator, as a designer at an AI startup, and is currently prototyping at GitHub Next. Today we talk about what is a design engineer and why there's often a tension between engineering and design, the tools she's used before and now, and why pen and pencil is not going away, even with agents. Do you still need a designer when AI can generate 20 high-fidelity prototypes? And is AI design obvious to spot? And many more. If you're an engineer wanting to know where design is important and how to get better at design yourself, this episode is for you. This episode is presented by TurboBuffer, vector and full-text search built on object storage. It's fast, cheap, and extremely scalable. Today's episode will be about design and design engineering, and so I wanted to share something visually interesting about our season sponsor, Antithesis. We already know that Antithesis verifies your system correctness by running your whole system in Hostile Simulation and finding bugs. Here's a UI for casualty analysis. You can open a report for a bug and see the probability of a bug occurring throughout the timeline of the simulation. In this case, we can see that at virtual time 25, something happened that makes this bug close to 100% to occur. So we can jump to this point in virtual time simulation to read the logs. This kind of bug probability visualization is one that I've never seen before. There's also this neat log explorer. You can filter on error messages and then visualize how common or uncommon the error is over time. For example, here's looking for failing linearization failures, the purple line. And you can understand how rare or common a specific failure was. Again, I've yet to see this kind of error visualization, and I really like the innovation on the UI side. And finally, the simplified multiverse debugger. You can go back in time and replay a debug timeline. And you can inject bash commands at any time without affecting the playback of the bug. How cool is that? For example, we're listing files in the current directory, but as you can imagine, you can go debug the whole environment so much easier. I love how the team at Anticitiz are pushing what's possible with both debugging and verifying software. Head to anticitiz.com slash pragmatic to learn more. Maggie, welcome to the podcast. Thanks, I'm thrilled to be here. I've had so many guests on the podcast. No one had quite the introductory story into tech like you. How did you get into tech? And you came from a very different background, right? Yes, yeah. I mean, I came in because it was where the money was, I guess. I mean, not really. But in the sense that, like, in university, I studied cultural anthropology, which is like my one true love. Like, I adore cultural anthropology. I totally fell in love with it in university. What is anthropology? Okay, it's the study of human beings, which sounds impossibly broad, and like, how could that be a discipline? But it does it in a particular way, where you go and you live with people intensely in this thing called participant observation. Usually, it was done kind of when the field was born, of different cultures, of course. It was like anthropologists from the West primarily going to places like Papua New Guinea or Australia, and living among kind of traditional peoples, and then realising how different their cultures were. Not just like, oh, they eat different food, you know, they have different houses, but they have completely different understandings of, like, what colour is. They have completely different understandings of time. It was kind of alongside the birth of psychology. Like, understanding how flexible is the human mind about constructing understandings of the world. And anthropology is really one of these eye-opening subjects when you get into it, because you can kind of get into, like, medical anthropology, or the anthropology of sex and gender, and you just find out how extremely adaptable and fluid human beings are. And I loved it, because I grew up as an expat kid overseas, so I think I was exposed early to lots of different cultures, and so it felt very natural to me to realise, like, oh, the way things, you know, people do things at home, you know, quote-unquote home would be London for me, but I left at age six, is completely different to the way they do it elsewhere, and there's no fixed way for humans to kind of construct a society or live life, and the bounds of what we think is possible is much wider than we originally assume, which is what I loved about it. So I studied it, but of course, come senior year, kind of go, right, what jobs are there available in cultural anthropology? I guess living with natives isn't all that many. It's not very lucrative. So the options were, like, go get a PhD and become a professor. Well, the military hires lots of anthropologists to come up with torture techniques for people in different countries. So when presented with these options by our professors, we were like, okay, okay, we'll go think about that. And I had always loved design growing up. So I had been doing, like, you know, I was a kid of the 90s. I grew up on Neopets with HTML and CSS and MySpace, and I learned HTML and CSS probably around 12 or 13, and knew how to do it, but in the way where, like, there wasn't that much complexity to it in whatever this was, 1999. Did you have a MySpace? I did. Oh, oh, yeah. Oh, and you customized it with all the... Yeah, oh, crazy animations and, like, the little sparkle trail at the end of your cursor. And, like, I think mine was quite goth at the time. Like, but I learned a lot. But of course, at the time, the web was so new. It wasn't like people thought this was a career, or you didn't really think of it that way. But I came out of university with this degree that wasn't necessarily employable, and I just started doing freelance web design work, because that was how I knew how to make money. Like, throughout school, I was doing IT tech work for the university, and just naturally went into this because it was like, well, I need to pay rent somehow. And I gravitated towards illustration originally, because I love drawing. So I was originally an illustrator for the first couple years, and the way that I went more into the tech side, because you can kind of be an illustrator that's, like, you know, editorial, or you could go into branding, or, like, all kinds of types. But I started working for a startup. I guess I wouldn't call it a startup. It was more like a design dev shop in Prague that was making UI-UX apps for, like, SF startups at the time. They were doing work for, like, Tinder and Uber, like, in the early days, like, in their beginnings. So it was there I got exposed to UI-UX design, and I was making the illustrations for these apps, and doing logos and branding. But I, like, that was my first exposure to, like, oh, there are people who design buttons and sidebars, and that's kind of interesting. I didn't end up going into that for a while, but that was my first introduction to, like, what is product design in tech as a field. And eventually, I joined this company called Egghead, which does developer education. So they taught JavaScript. Sure, you've seen them around. And I was their illustrator for four years, and then I became an art director, and, like, art directed other people's illustrations for them. And that was really where I learned JavaScript. Philosophy of product design is like you represent the user, and you represent trying to get the best experience possible for the user. And that means user interviews, caring about flows, like, does this button feel big enough? Does it have the right words? And then they can spend much more energy there if they don't have to care about the technical backend. Like maybe it's actually irrelevant, when really what you need to care about is like, does this flow make sense to people? So that's not necessarily a different kind of designer, but it's, if you kind of think of the whole, the stack, right, but expand it all the way out, not just backend and front end, but the interface and users, and then the product in the context of a business and like the product in the context of an economy. Like there are people who lean way more on this side, and I'm a bit more of the straddling of the product design and the engineering. But you can have valid designers all along this, and some people, again, you know, just visuals or just animation. Like there's lots of niches. I just like a bit more of the half engineering, half design, like slice of it. To help understand a bit more of what you do, can you talk about the tools that you use? Like, you know, as engineers, we're kind of used—our tools used to be the IDE and the code editor and, you know, some of the hardcore people like Vim and some of those things. And these days, of course, it's changing a bit more, but, you know, those are the tools that we use. What are your tools? It changes all the time. I mean, to some degree, like some things stay constant, like you're doing similar tasks. But of course, at the moment, I'm trying to try everything because part of my job is like trying to figure out what GitHub should do next. That's what our team does. That's actually the name, right? GitHub Next, hey? It was well named. So a lot of the time, like we are just, you know, of course I'm trying out Codex and Claude and like dogfooding stuff internally at GitHub. I've tried Conductor. I mean, name any agentic harness like OpenCode, Pi, I try them all. I do love Codex at the moment. Like I do think like OpenAI is onto some really good stuff, at least in their design of their like desktop app is beautiful. They've really thought it through. So I think they're doing some really good stuff. I still use paper and pen for like initial brainstorming. Yeah, you have your notebooks here. Yeah, I brought some along because notebooks aren't dead. I don't think they're going to be dead forever. And I still use Figma because I know how to use it and I can do some brainstorming in it before I pass it off to an agent. But to be honest, there's a point where once you figure out what you need to build, which is actually all the work, once you hand it off to an agent. It’s not that implementation is solved, but we’ve reached a point where implementation is, like, good enough that if I spec it out really well and I list out how the agent should verify for me that it actually did the work, I can hand it to an agent and just, like, be like, Right, let me know when you’ve got a PR up. You know, I don’t really look at code that much anymore. I do look at PR code when I’m reviewing it, but skim, skim, skim, you know, okay, that looks sensible, merge. So most of the work I find is everything leading up to telling the agent to implement something, and then the PR review is kind of a separate piece of work. But, like, the bulk of my tools still in this first section now, versus we used to have the IDE, you know, once it was like, okay, you’ve decided this is the right thing to design, now you actually start the work of, like, implementing it. It’s kind of beautiful that that’s no longer part of it as much. Open VS Code sometimes, but not really. Yeah, but beforehand you would prototype, right? Like, you build prototypes. Yeah, yeah, yeah. As part of the, like, what should we build, I include in this lots of prototyping. And I kind of have the privilege of being on a team where we don’t have to build, like, production-quality software. We are mostly trying to prototype and validate ideas. So we have a lower quality bar than someone shipping to proper GitHub.com. That’s a very high quality bar. Yeah, which makes sense. I mean, that’s kind of, you get the directional things right, and then once it’s great, you might build it or you might decide to build it. Yeah, yeah. But I definitely, I mean, we can hopefully show these later, I do a lot of stuff sketching. I mean, even just interface design, a lot of what you’re doing is just drawing boxes and then being like, Does this slide over from the front, from the bottom? Like, if I click this button. So this is like you kind of drawing up a UI, how an interface you think could look like. So I see a mix of UIs, and we’ll put these onto the screen, but UIs, description of what they do. Can you just talk to one of these, or one that’s interesting or memorable? Yeah, yeah. So this is a new—I should explain the context. I’m prototyping at the moment something where my theory is, like, one of the bottlenecks with agents is planning. is a really bad experience at the moment. Like at the moment, you have a long chat with an agent, sometimes even in a CLI, which is a pretty primitive interface. And then the agent grills you by asking you a set of, like, choice A, B, or C questions, and it does this, like, a hundred times over if you're using Matplotlib, Gradio, or whatever. It was just on a podcast. Yeah, yeah. And by question 20, you're, like, quite tired, and your brain starts shutting down. That was my experience. I went through and I got 36 questions, and I was kind of—they were good, but I was starting to get annoyed around, like, yeah, like 20 or 25. I'm like—and also, I had no idea when it would stop. Right. It's endless. And, like, the human brain, you get tired. You can't make this many decisions in this short a time. And also, you don't have enough information about most of those decisions because it's given you a question and three options, and it's told you number A is recommended, then you just start being like, Yep, A. A. Enter. A. I agree with you. So this is not an ideal experience. This gets into, like, agents love to output reams and reams of text, and that's an ideal output for agents, but it is not an ideal input for humans. So we have a mismatch with, like, what do humans need to be able to digest large amounts of information and truly understand it and be able to make informed decisions? That is not the interface for this. So I'm trying to explore how would we make an interface that got us to do better planning and better decision-making, but in a way that was easier for us to comprehend. So this is what I'm prototyping at the moment. And part of this is like, okay, it's going to be multiplayer because, of course, everything should be with your team planning together. So several people can do it together. Exactly. But also, just like, how do you make it so that you have more space for each decision? So I'm trying to prototype, like, okay, so first of all, this has to definitely happen in a GUI, not in a CLI. So these are just, like, rough ideas of how you can have more space. Exactly. So I'm thinking of it as, like, each decision maybe has its own little mini document or card, and depending on the decision, some of them maybe you can just have three multiple choices. That's fine. It's maybe a simple decision, right? A, B, or C. But sometimes it'll ask me things like, Do you think the border should be, like, gray 10%, 12%, or 15%? And I'm like, Well, show me. This is a visual. Definition. Or like, I think there's a lot of people where—not that, I should call it X, sorry, X, Twitter, X, all the same—on X, I feel like a lot of people who get called design engineers or who present themselves as design engineers actually are, like, very good micro-interaction designers. Like little, like, here's a cool hover effect on a button, and like, here's a cool loading transition state. And those things are definitely cool. I don't consider that design engineering because you could achieve most of those things by just telling an agent to do those without looking at a single piece of code. To me, that's just like very, like, advanced, sophisticated, like motion design and visual design. And that's cool, but I don't consider that design engineering because I don't think that's, like, a full job for you to do that as a career. But design engineering now, like the people who I think of as good design engineers do the kind of thing I was talking about before, where you step much more into the engineering side of work. So you're still a designer, you're still caring about, like, product, nouns and verbs, and, like, the visual design, but then you really work with engineers closely and/or are, like, directly involved in implementing and writing code yourself. And you fully understand—well, you know, not fully, you don't have to be, like, full full stack—but, like, you have a deep understanding of the technical architecture of the product you're building. You really are like, okay, given the shape of the backend data, what is possible in the interface? Like that sort of design work. You know, given what models are capable of and what kind of skill—like custom skills—we're building into this product, like how do I explain to users what the capabilities of this product are? Like truly digging into the technicals and not living in the world of, like, just user interviews and the market and, like, what color is the sidebar, but caring much more and working much more closely with the engineers and almost always, I feel like, implementing a lot of it yourself. Like I've always done my own front-end work just because it's easier. And then the engineers I work with are usually thrilled because they hate CSS. And then they get to go work on, like, the more interesting difficult stuff, I'd say. It's like the syncing or, like, the, like, back-of-the-front-end work, you know, like the more logic stuff. They really get to engage in that and they don't have to worry about, like, is this the right border radius on something? Like, I don't think they very rarely care, and I do care, so it's always worked out well to kind of do that. So I just define it as someone who's, like— Deeply into the engineering side of the design. What's, in your past positions, current positions, through friends who are also designers, what have you seen great engineering and design collaboration look like? Made that be with designers or design engineers? I mean, I do find being a design engineer, I've always had amazing collaborations with engineers because, again, you do the bit they didn't ever want to do, and you take away what I assume is most of the tension between designers and engineers that I've never experienced because I've always been a front-end person. But I've heard of people, you know, there being the tension where you have, like, someone's made some perfect Figma file and the engineer hasn't implemented it exactly to spec. Yes, I've been there. Yeah. And obviously there's a tension there because someone made something in a medium— Or there's a nice gradient and it's mobile, and doing gradients would absolutely wreck the scroll performance. And again, these are like, we're talking about years back when this was a thing. Yeah. And now you're going back, like, can I just do a single color? Or you try to explain, like, what you can do with your either performance limitations or think about low-end devices on Android or iOS versus Android, where the designer might be more into the iOS world. And again, a good designer would not, but there's oftentimes the engineer would come like, All right, we have constraints here for whatever reason. Yeah. I think this gets into, like, I don't want to blame the designers because I think it's a failure of tools. Because the design tools that everyone used to use, Sketch and Figma, these, like, pixel mockups, they have no relationship to the constraints of the medium, which is, like, whatever you're building for, iOS or desktop or the web. Like, you have to understand, like, the materials you're building with in any design role. Like, a table designer would not, like, be oblivious to, like, how oak performs in certain contexts, right? Or, like, how pine dents in a certain way. And in the same way, I think if you're designing for the web and you don't understand, like, performance or, like, how is your app, like, fetching data and what's the loading time and what if there's race conditions, like, I think if you're oblivious to that, you'll end up with bad design solutions and then with really bad relationships with engineers. Yeah. So I'm hoping agents actually help solve this, right? Because really then designers using agents can step more into the engineering side and also use agents as a coach and, like, a learning tool and say— Say, okay, the engineers come back and told me that we have this, like, error state I've never heard of in my life. Like, explain to me why that error state would occur, you know, and help me build a state machine, right? Like, there's, like, all these new tools available. But those old frictions, I have to assume, were just, like, tool-based things. And I would say designers that are maybe stuck in the past, who don't want to let go of, like, oh, I make pixel mockups. I don't know if anyone's there anymore, but if they still are, I mean, you're just, yeah, I can't imagine that relationship going well in the future. And then you mentioned Figma. Figma was such a popular tool for a while. That was the interface between engineers and designers. How do you use Figma today, or how have you used it in the past? I think I've always used it, like, not to get to high-fidelity mockups at all. I think to get, like, the rough shape of things past a notebook. Like, a notebook, you can be like, okay, the shape of it is like this, but it's such a rough sketch. And Figma is useful, I find, for being like, okay, exactly what color is, like, the right amount of contrast to, like, draw attention to this element on the page, or, like, exactly what size does this text need to be to, like, flow well. But then I would never take it to high fidelity because, of course, everything always looks different. I mean, I primarily design for the web. Everything looks different in the browser, right? Depends on the font rendering and all this stuff, and responsiveness, and then when exactly are your breakpoints. So I would always take it into browsers pretty early on. You get, like, medium fidelity in Figma, like the shape of it, and then you take it into a prototype, and then you can really tweak and refine. And of course, with agents now, it's just like I point an agent at my Figma mockup, and I'm like, just get all of that in there, and then make, you know, what's called a jig, which is where you get, like, little sliders and variables attached to, like, a little— A jig. A jig comes from woodworking, where you make, like, a little device that helps you do one specific job. So with design, when you're working on a live prototype, you say, like, okay, here are the variables I'm not sure about. I'm not sure about, like, my headline size. I'm not sure about these colors. Give me sliders and colors. code, and then you have to go see the effect, and it's not a direct connection. And so his whole thing was like, you need to have instant direct feedback at all times to be able to, like, look at the artifact you're making and directly tweak it. And it's like this kind of stuff come to life. Like now we finally can do it, but before you couldn't do that. There was, like, no programming system in existence that could give you, like, a live preview of every possible variable or thing. Like the closest we have is, like, dev tools in the browser. Well, another topic which is very related to this one, while we're waiting for one thing that with AI, of course, you're saying it's easier to build stuff, but with AI it's also easier to design. When I was asking people, like, how they work with designers, an engineer replied something which I hear a lot more, which is, I'll quote this person on here: As an engineer, I ask Claude Design to generate 20 high-fidelity alternatives, and I keep iterating until I land on the perfect design. It's very enjoyable and feels much faster than interacting with a design team. So it is a thing saying, oh, I have these tools. I don't necessarily need a designer. Like, I can just ask for all these. Like, and in this case, it will just give me 20 alternatives. I'll choose the perfect one, and boom, I'm done. As someone who is a designer, what's your take on this? And by the way, this is not the first time. I think there's always the thing like, do we need designers? As engineers, do we need product managers? And of course, you know, product managers will also ask, do we need engineers, and so on. But what do you think? Where could this be valid? What could people be missing? I think in cases where you don't have a designer to hand and you're trying to, like, validate a product or, like, prove a hypothesis, but you need an interface for it, it's great to just use a model to be like, sure, make me 20 high-fidelity designs. I'm sure I might look at those designs and be like, well, like... It all depends on taste too, right? Like I might look at them and think, okay, well, these look obviously generated by AI to me, and I don't know that they're going to do the job that they need to do. Again, it depends on the context. If it's something simple, needs a button and a sidebar, fine. But if it's like, you know, we have some new primitive, we're trying to figure out the shape of, that's when you really need a designer to come in. And like, really, it's just someone who's assigned to like think through the problem properly, like put in the brain work and be like, okay, do the experiments, like show them to users, like figure out what people actually understand and don't. And that's really like the labor a designer should come in and do. But I think it's completely fine for developers without access to one to like use models as much as they can. But when models do designs for me, I of course just look at them and think that is terrible quality. That is awful. Even to the extent of like, I think they've been prompted with some what we would call like universal design principles, but they sort of don't understand nuance and context, and then I think they'd like stick to them too strictly. So like, I find the agents want to put a label on everything in the interface. Label meaning? Like a small bit of text. Like there might be like a little button that's like to close the sidebar, and we would usually use an icon button for that because most people are trained that this little button, the other sidebar means it'll close it, and they'll experiment with it and they'll click it and they'll figure out that is correctly what it does. But the agent will write close sidebar or close modal in the top right hand of the modal, and you're like, there's now a lot of text on this page. And they'll just like put like four lines of instructional text over a button and just things where you're like, I understand in the model's mind it's thinking, oh, this is how we like make the interface explainable to the human, you know? But actually it's really bad design. Now, talking about the UX and UI for AI, what do you think UX and good UX and UI looks like? And I know this is a bigger question, but so far, what have you learned of what works and what doesn't? I think when it comes to this, like, what is the ideal UI of AI, which is like a big question, I don't know that we'll figure out the answer to for a while, but it's something like, some things haven't changed. Like in terms of what is good interface design for software, there's still a lot of principles here. Like what formats do we have to show users like data? You know, it's like dashboards and sidebars and documents. Like there's a lot of things that haven't changed. We actually had a good story from this, about this from Elicit where— The app was, like, helping scientists, like, extract data from papers. And they were very used to doing this in Excel spreadsheets. They'd get a big Excel spreadsheet, put the papers in, one on each row, and then they'd extract each piece of data into the cells, right? Pretty standard process. But of course, in the beginning of Lissit, we were like, Oh, that's so old school. There must be some, like, much better interface for, like, you know, seeing the data extracted from papers. So we tried all this crazy stuff. There was, like, infinite canvases with, like, cards spread everywhere. There was one that's, like, a bunch of cards that are all, like, linearly stacked. We were like, maybe it's more like Notion with these, like, composable documents with rich interfaces. Like, we tried all this stuff. And every user interview I did, users were just like, This is very confusing. Can I just have a table? Like, every time. And so after a couple months of this, like, Oh, what's the new UI of AI? we were like, Oh, it's a table. Well, at least in our use case, it turned out the interface people were using was the best because it was the most familiar to them, and it caused the least amount of, like, cognitive load for them to use the tool. So we were like, Right, back to tables. That's fine. Like, it was good to go on that journey. But sometimes we have this notion of, like, the UI of AI will be so wildly different from our current imaginings, and sometimes it's really not at all. It's like, you can do more powerful things. I think there's lots of leverage, but I expect it to all be built with documents and sidebars and cards and tables and, like, all the classic things we've worked out do work and people know how to use. Yeah, interesting. Yeah, there's a cognitive load in learning any new UI paradigm. It can be confusing if your existing tools don't work like that because, again, people will still use operating systems and Google Sheets or Excel or Office documents, etc. And even if, like, a small subset of people are, like, I don't know, familiar with this new UI stuff, you remember, like, probably, like, parents or grandparents teaching them how to use the phones, the interfaces, and once they learned it, they're good. But then, do you really want to do that again? Yeah, no. It's interesting. Yeah, so there will probably be something similar-ish. Yeah, it's kind of like how we started with chatbots, right? It's like chatbots were not the final form. Like, if we could look at Codex, like, there's a lot going on here. There's, sure, there's a chat window here, but there's all kinds of things going on with Git worktrees over here, and then we've got this whole interface, and, like, I can do, like, annotations and debug in this. Like, there's a lot of extra stuff where you take the familiar primitive and you expand outwards from it. And. comes after that. So now we're interested in, like, how do you make proactive agents that aren't annoying is one of the things we're trying to explore. Because proactive agents, you think we have this dream of, like, okay, assume intelligence is, like, free or so cheap that, like, it doesn't matter, right? That's a fun assumption to make. If you could have a hundred background agents running, what would be the least overwhelming, least annoying way to consume any of their outputs is, like, an open research question we're trying to figure out. How would you have agents working in a document with humans where it's not, again, overwhelming or annoying for them to be making changes or doing helpful background work in a way that doesn't feel, like, invasive or interruptive? So we try and take these kind of design questions and figure out prototypes that could solve them in the hopes that, like, you know, if one day GitHub wanted to build something in this direction, we can then be like, hey, here's all the research we did. A question I wanted to ask you is, it's coming from a developer angle. It's what happens when, in your experience, observations, when we start to give more and more decisions to the agent? And I'm going to quote a developer, Jorge Manrubia, who wrote an article called Oh My Craft. He wrote, The need to intervene on the small stuff is decaying quickly as models improve. And when models are capable enough to handle those details themselves, spending too much time on these details starts to feel like a poor use of human attention. And he writes about how he rarely opens his code editor anymore. It's been months he wrote a single line itself. But the thing is, he used to live inside and see all the details, and there is a sense that craft has to do with being there with the details. And of course, you're coming from a design perspective, but what have you observed of your own craft changing, decaying, or, you know, what you're seeing? Do you think there's a danger as there's this temptation, as, you know, we talked about, like, just good, good, good, make this decision. We just did this with the slider, which didn't matter. But it can matter. But it can matter. I think it doesn't matter. I mean, it's hard because, because I'm not like, I would say, like, a true engineer in the sense of, like, I don't necessarily care about clean code that much, right? Yeah, but you care about great design. But I do care about design. But the thing is, they can't, they definitely can't do design to my standards yet, or I have to still be really involved to get the design to look and feel the way I would make it. So I'm annoyed almost that I'm always in there being like, No, that is a terrible transition. Here's how we should do it, you know, or like this. So you're into details. You're not letting go of those details. Yeah, because I wish I could. I wish, I mean, I've written— Do you? Design— Well, I don't know. I want to push you on this. Yeah. I keep thinking this, like, if tomorrow, I keep trying to write design skills that tell the agents exactly my design preferences, which won't be universal. Like, I have preferences about how much padding I like between a border and an element, right? And that's not everyone's preference, and it's not right for every product. But for me, I'm like, there are set rules. Is this much padding, is this kind of border shadow, like, it's pretty standard. And I've tried to write these rules, but then they don't universally apply them properly, and it doesn't work. And so I always end up in there changing specific values that you would think by this point in time would have been automated away, the way that we all talk about that agents are, like, taking over stuff, or you would think this would be, like, so trivial to, like, for them to implement, like, a certain kind of whatever it is, opacity level on a border. So I kind of think, like, if I woke up tomorrow and they just—the skill just worked, or, like, the agents just had enough context and they just designed exactly to my specs, I wonder if I would be like, Oh, all the fun bit is gone. Like, is it satisfying to have, like, a gorgeous interface appear in front of me, but I didn't—I didn't do anything to make it? I'm not sure. I also think about this with, like— Interior design stuff. Have you been on Pinterest any time in the last, like, two years? I'm familiar with it, and, you know, my wife is. And when we were decorating a new house, like, I remember collecting these things. Yeah, we worked with an interior designer, and, you know, my wife collected a lot of things, but I also was there, and you have these kind of, like, we're kind of thinking like this, but not quite, but, like, when you mix this, trying to explain, you know, like, we didn't have the tools beyond, like, you just take screenshots. So yes. Yes, yeah. Familiar enough with Pinterest, I guess. You know, you know, you know, yes. A lot of it is AI now if you get on there. Oh, really? There's gorgeous rooms if you search for certain things, but you look and you can kind of start to see, like, oh, that's for sure AI, that's for sure AI, which is definitely problematic when they're images of a physical space, because then you go like, well, the light might not be accurate, or this is all just fake. And they look beautiful, but you kind of think like, well, someone didn't make that room, and that's not a real room that exists, so it's almost irrelevant to my interior design. And I kind of wonder if it's like this with interfaces where, like, it is all objectively, like, looks gorgeous because it's been trained. It's like very much like everything that was on the web that we've, you know, clicked thumbs up on. But with interfaces, if they all become extremely slick, like think you take, you know, what's popular right now, the linear and the Vercel aesthetic, right? Like very minimalist, very clean, very white, very a little bit of rounded corners. If all the agents can implement that, no problem, just like dead on, people will start to design in different ways because that will become a tell that you've just used an agent to do the design. And if you want to look like you're going to stand out, you need to have some human do something new and different. I think it gets into, like, design, although it has universal basics, like, is the text big enough to read? Do you have enough space around things? A lot of it is fashion. Like, it's in fashion right now to look a little bit like Linear. It's not in fashion to look a bit like MySpace, but it was a while ago. And there'll be, in 10 years in the future, if you look like Linear, you're very out of date. You look like some old crafty piece of software, and there'll be some new aesthetic that comes up. So it's like the models can't necessarily understand that design is, like, within a cultural context, and that cultural context is always changing, and it signals different things to people. And if people read it as like, Oh, they didn't care about this site because it's just, like, the bland basic code. Like, Claude has a specific design language. It's very, like, noticeable, right? Cream background, like slightly red text, like this eyebrow text on things. Like, you look at it and you're like, Yeah, Claude generated that. No human was involved in this. Like, I don't know if I'm going to bother looking at it. So it gets into this, like, the aesthetic style you pick communicates to the person viewing the product or page, and things that clearly were made by agents, I think we might start to reject out of hand. Maybe. I have this thing where when it's text, when it's written text, I can immediately tell if it's AI written. Oh, I cannot. But I can never tell. Sure, maybe you're building a database, but you're building it for users in a cultural context, right? Like they have assumptions about how they decide something is trustworthy. They have assumptions about how they decide that something is worth their time or, like, how a flow should go. And it's all culturally contained. Like, it depends also on, like, how international your audience is and who you're designing for. But, like, there are cultures where, like, time flows from right to left, right, or from up to down. But we assume in the West, you know, time flows left to right. But that's not universal everywhere. I think just, like, reading a little bit of cultural anthropology and understanding how varied people's worldviews can be. Like, some cultures see—not see different colors, but categorize colors differently in a way that makes them see them differently. Like, they might see blue and green as actually one unified color. And if you're designing an interface, like, not that that necessarily directly applies, but I think it's understanding there's a broad range of ways humans can interpret something. And, you know, if you're building tools for humans, there might be some way you could, like, teach them to see the world differently through the thing you're building as well, like change their perspective on, like, how they interpret reality. And then in anthropology, you said that, you know, anthropologists would—one thing that would they would do, they would—the traditional anthropologists would live with natives and be embedded in them. Is that something that maybe now that AI is, you know, like it's making code a bit easier, as engineers, I think it's pretty clear that an engineer becomes more valuable the more they take on the other parts of the business, the more empathy, the understanding. Could it be just an idea when you have the opportunity, just embed yourself with customers, become a customer yourself? I mean, this used to be the thing, right? Like Amazon had their customer obsession, which also starts with understanding the customer. But I guess this might be very natural as someone who's an anthropologist, which is like, go talk to people, go and try to be one of them, whoever you're building with. There is a good point that, like— Engineers are about to have more free time in a certain way. I know there's an infinite number of engineering problems to solve, and then it's like maybe we solve them better, you know, by having with that extra time. But a big part of this is, yeah, you could expand into more of the design side, and past the interface is really like the user research side, and that is like go fully understand the domain you're designing or building for, and like what real-world context are people using it in? Like when are they pulling out your app? Like in a factory? Are they on a tube? Like, I don't know, a little bit of like understanding context of use is a big thing that user researchers do. And then understanding the moment when someone reaches for your product versus like reaching for a different product, like when do they decide you're the right solution? That definitely gets into the user research side, but that's a great thing for engineers to expand into if that like appeals. And as closing, what books would you recommend, ones that you enjoyed reading and why? One of my favorites that I give to most people is called Addiction by Design. So it's about people addicted to gambling machines in Las Vegas, but it's an anthropologist doing it, and she talks about both like living among these people and their experiences, but also the machine designers. Like how do you design a machine that is so addictive that someone sits at it for 12 hours straight? It's like a really fascinating thing. And how are like gambling casinos designed to have no windows so there's like no time around you as you like sit at this machine? It's by Natasha Dow Schüll, and I read it in university and I love it. It's a total mix of like cultural anthropology, participant observation, and also machine design and engineering, and like how do you design addictive systems, which of course you read it and then you think about phones and Instagram and you reflect a little bit on like what are these systems we're building for people. Maggie, thanks so much. This was very interesting. Yeah, thanks for having me. Really fun. This was a very visual episode, so I hope you were able to watch it over video, especially the parts where Maggie showed her sketches in the notebook. And this was one of the most interesting parts of this episode for me, even as Maggie spends her days prototyping the In the future of agentic tools, she starts her design process with pen and paper. Her reasoning is that agents cannot see, but us humans can. And I have to wonder, is it only true for visual stuff? I mean, when I think back to my most productive brainstorming sessions with engineers, it was usually in front of a whiteboard drawing stuff, where we drew out our ideas about the system and the components. Another extremely cool trick from Maggie is how she uses AI to generate prototypes with sliders to change parameters and change the design. She calls it a build your own Figma, and we did a live demo with the Constellation animation that she played around with. This was so darn cool. You get Figma-like tools dynamically built for you. It's also pretty incredible that we can do this with agents in a matter of minutes. Just wow. Finally, I appreciated how Maggie was honest about how she feels about the design craft. It's cool that agents make her work faster, but she said she's not sure she'd love if an agent just spit out a perfect design. And yet, agents are getting better at design. It feels to me that this is kind of how I feel about code. It's great that the agent can generate good code, but it was something I liked being good at, and I was good at it. Now, I don't write the code, but it does feel more transactional. I feel a bit less connected to the code and the creation of the code itself. For design, agents are not there yet, but I didn't sense that Maggie wants to let go of that designer in her. I wonder if one thing to learn from her for us devs is that we should also have a notebook to make sketches of ideas, not just UIs, but architectures and systems. I don't know, but I might give it a go. At least it will make me feel less that I'm dependent on agents, and I'll have some AI-free space, if you will. Thanks for listening, and let me know how you liked this less conventional episode. Thanks, and I'll see you in the next one.