Loading summary
Transcript71 lines
- [00:00]
Rid
A big focus for my year is figuring out what are the next steps that I can take to grow as a new design engineer.
- [00:07]
Karl Koch
Product design ux, design ui. Is it different? Maybe we just spread everyone apart into these super, super specialist roles, which I think were really practical for a time. They actually helped a lot for kind of delivering great products. But with AI kind of being this leveler of giving designers more power and more control over the front end, I feel like we are, we're sort of sweeping back into generalist territory.
- [00:31]
Rid
How do you push past the typical AI output to craft an experience that both looks and feels amazing?
- [00:38]
Karl Koch
The piece that really tells a design engineer from just a front end engineer is creativity and craft. And it's having the mindset of being someone who cares about that final 10% that for me is the design engineer. It's somebody who has a designer's mindset towards shipping product. So you're thinking about how to build it, but you're thinking about how to build it in the most delightful way possible.
- [01:03]
Rid
Welcome to Dive Club. My name is Rid and this is where designers never stop learning. Today's episode is with Karl Koch and he's going to do a deep dive into how you can level up as a new design engineer. He's going to share specific tactics that you can use to get the most out of AI and even walks us through some of the little details that he's sweating. As a Design Engineer at DuckDuckGo, this is a very, very practical episode. So let's dive right in to some of these tactics.
- [01:33]
Karl Koch
One of the big problems that I found with AI generally and the code that it produces is it's very deterministic. So like its whole approach is to look for the next best token and then produce the best output based on those tokens. Right. Sometimes that's super helpful because you're going to get the best outcome, because you're going to get like all of this training data from GitHub and it's going to create the best thing, but sometimes it's learning from stuff that's maybe not optimized. And so what you end up with is stuff that works, but it doesn't necessarily work in the best way. And so what this little demo is that I put together is like trying to visualize what I mean by that. So you've got two, two approaches left and right when I enter something in here. So let's say I'm trying to filter down and I'm interested in getting a mouse pad. So I'll type Mouse. And you can see every time I change a value, something kind of loads and flashes a bit. And you can also see this number is incrementing an insane amount. Important thing to flag is that, like, this is a bit overambitious at the moment because we're running in a dev mode. So strict mode on React is basically causing us problems. It wouldn't render as often, but you would at least render twice for every instance of this right hand example. So what's going on? And the difference here, I guess, is the reactive way is wrapping all of these changes inside of a useeffect. Useeffect is a thing that's very React specific, but it's something that AI just loves to put everything inside if it can find a way to do so.
- [03:00]
Carlos
I have noticed that recently.
- [03:01]
Karl Koch
Recently, yeah. And what we're doing essentially is we're putting the stateful changes inside of UseEffect. So we're basically double doing everything, whereas on the right hand side, we're just directly going to update the state in real time. And you can see there is no Flash and we render still for every change because obviously we're trying to do something each time I type a letter, but we're only doing it once. Whereas on this side, if we ignore the strict mode stuff, we would be rendering twice for each of these. It's a small, simple thing, but you can already see like this huge gap between these two ways of doing something. And in this example, it's like, you know, filtering a list, that's fine, but if we are filtering this list from the network, so we're making network requests, and that list contains images and lots of heavy data, we're essentially really overloading the front end with all of this extra work for absolutely no value. You could AI your way out of it. You could just say, like this keeps happening. But in my experience, you say, like this keeps flashing. If you don't know what's going on, you just say, every time I type it flashes. The AI will go on this huge rampage of trying to solve the Flash but not understand that it created the Flash by just wrapping everything in a way it didn't need to be wrapped.
- [04:17]
Rid
Real quick message, and then we can
- [04:18]
Carlos
jump back into it.
- [04:19]
Rid
You know what I'm excited about? The Granola mcp. It allows you to connect your AI tools directly to your granola meeting notes. And as somebody who's been vibe coding a lot of tools recently, this release is a pretty big deal because my meeting notes are some of the most valuable context that I Have. And now I can find specific topics, pull out action items, and get any question answered based on my meeting history. This is all available today and I'm already building with it like crazy. So if you want to join me, head to Dive Club GranolaMCP. That's Granola MCP. An even smarter version of Lovable just released. It is 71% better at solving complex tasks, which means it can do more work more autonomously. There's more intelligent planning, prompt queuings, you can stack requests while Lovable works. And my favorite part, there's automated testing, which means Lovable now tests your apps like a real user, opens its own browser, navigates flows, investigates edge cases, and catches bugs for you. And the best part is when it finds a problem, it fixes it right on the spot. I genuinely believe Lovable is the easiest way to build software today. So head to Dive Club Lovable to try the new release.
- [05:37]
Carlos
Okay, now onto the episode. And even for people who maybe are quite intimidated by actually looking at the code, just having the tiny piece of knowledge in their brain about, hey, AI has a tendency to overuse use effect, making it easy to just say, hey, like, is this something that's happening? You know, like. Or make sure that we are not doing that kind of thing. I've already tucked that away in my toolkit.
- [05:59]
Karl Koch
Yeah.
- [05:59]
Carlos
So thank you.
- [06:00]
Karl Koch
It's a good one. I think the thing that really caught me onto actually was that React themselves wrote a specific blog post which was titled, I think it was, you might not need an effect. The whole post was basically detailing the fact that everyone seems to overdo use effect because it's like the way to make something reactive. But actually we've got loads of other ways ways now in code to create reactive outcomes and even things like this example where you can just directly update, manipulate state and see a reactive output. That's awesome. And so we don't need the effect in this case. And so I ended up creating a skill. Well, it was before skills, but I created a document that I gave to the AI and just basically put it in there and said, look, here's this article about not using an effect. Follow this. And so then I could just always call upon that and say, like, are you sure we need, like, something's flashing here? Like refer to this document. And oftentimes it would tell me, like, there's an unnecessary effect in here, like, let's get rid of it.
- [06:58]
Carlos
Yeah, that makes a lot of sense to me. And it's even how I'm thinking a lot about my practice now is I don't necessarily have to learn everything. I just have to do a good job of curating the right pieces of knowledge and inspiration and then organizing it in a way where I can very easily point at it to improve my own practice.
- [07:15]
Karl Koch
Yeah, and I think that's the secret is, I mean we touched on it a bit earlier, but the idea of the design engineering mindset is you don't need to be an expert in coding because then I'd just be a front end engineer. And at that point, you know, we don't need the role. It's more about having that kind of combined mindset of being curious enough, craft oriented enough and like interested to try and find like the best possible solutions combined with being logical, being thoughtful and caring about like how do we actually build this and make this work. And combining those two mindsets gets you to this like a different place I think than you get if you're just a designer relying entirely on code or an engineer relying entirely on being given a design or asking AI to come up with a design. Like having that middle ground, it just gives you the kind of best of everything, I think. And there's the whole master of non argument but like that's fine. Like I don't mind being super generalist like across the board with design and engineering, but it's fine.
- [08:13]
Carlos
I think we're in the power to the generalists era and you're hitting on this thing where you know, there's such a big difference between being able to bring your pixels to life in code versus getting them to move and behave in the best possible way. So I'm wondering if you have other examples that we can point to as just little tactics that designers can adopt because already this has been very practical for me.
- [08:38]
Karl Koch
Yeah, so demo number two, I guess that we've got here. So this is another like a really common thing that I find in AI created code, but it's something that's just engineering 101. It kind of baffles me given the amount of data that we have available to these LLMs that like there are still these really common simple things going wrong. But in this example, again, we've got the same thing left and right. So every time you create something in a list for rendering to happen properly, you need to assign it an id. And so you will have probably come across this with like create a list item, you need to add a key and that key needs to be something unique. Otherwise like how do I know that the first one in the List and the third one in the list are different. The kind of very common approach that I see AI take is to just use an index. So index being a number from 0 to whatever. In principle it seems fine. Like if you just think as someone who doesn't understand how all of this is working under the hood, okay, you know, naught and one and two, they're all different numbers. So like that's fine, of course.
- [09:40]
Carlos
And the index is just placement in an array, right?
- [09:42]
Karl Koch
Yeah, exactly. Yeah, yeah. So hence that's why it starts at zero. So arrays as a zero base. So we always start at zero. From a kind of principal standpoint, it makes sense. And you're like, okay, fine, this is unique. The reality is, because of what you said there, the fact that we're assigning it a key based on where it is in the array, that means that it isn't actually unique like we think it is. To prove that, point out, like if I just put hello into this box here and then we'll do like hello in this one here. So on the left we're using index. On the right we've defined like a unique id which we're basing off of a few different parameters. If I add a new entry, my expectation here, add a new entry is going to come in at the top.
- [10:20]
Carlos
Yeah.
- [10:21]
Karl Koch
So I add a new entry. But what? Yeah, it doesn't. And that's because it's an array index, so it's adding it at the end. Now if I want to do the same thing, I can go, cool, all right. On this side we're getting it in the top like we expect. So that's fine, that's good. And that means that our right hand approach is working. On our left hand approach there's another problem which is because of this index based bound, like if I change. I don't know, let's put this one bad, I don't know, put whatever words we want in. If I try and discard the hello, you'll see that. Wait, what? Sure, it didn't work. And it's all because the indexing is incorrect. Whereas in this example where we've got a unique ID that we're defining, I can independently remove the correct things in the correct order. So my expectation is met as it should be. That's so tiny and it's so specific. Like again, I've just been there before where you will put together something, ask AI to like put a list of XYZ together and you're like, what? Every time I hit delete on this thing, it's just like the wrong one's being deleted and it's because it just seems to want to default to using the index.
- [11:30]
Carlos
I know this is not the point of this demo, but, man, I'm paying so much attention to how things move. When you create a new item on the right and delete an item, and there's like a lot of intentionality there where you're creating a new one and it's sliding in from the side, and then when you remove one, it first, I guess maybe decrease the opacity and then slides up. Whereas every time I would build this, I would have that be like one motion. But this feels so good.
- [11:55]
Karl Koch
I guess we talked about it a bit, but, like, the idea of the design engineer mindset of just making like a silly little demo like this right now, it's like I'm going to put that time into what the experience feels like just to delete a thing. Because that little 10% at the end really matters. Even though this is like a, you know, I mean, it's throwaway code, right? I'm just like, doing it to prove a point. But even just picking, like, instrument serif up top, you know, like, unnecessary. I mean, it's not beautiful, the whole thing, right? As this fairly standard, but there's like lots of little pieces like that where I'm like, well, I'm going to put that extra 10% in just because I feel weird if I just. If it was all just, you know, I don't like default browser stuff.
- [12:36]
Carlos
And I think, again, like, speaking as someone who is trying to build more that doesn't necessarily have this level of taste yet, you know, like, I can look at this and be like, wow, that was good. And then I had to train my brain to be like, why do I like that so much? And then I'm really paying attention to, oh, okay, he's thinking about this in two different parts and, oh, new items slide in from the side. That's like something I'm trying to do way more intentionally, is trying to tease apart why really good design engineers are good at what they do and, like, what makes it actually work. And then I can just slowly add 1, 2, 3 little pieces to my toolkit. And already I've now made the mental note, like, okay, next time I have something where I'm going to add an item, I'm going to slide it in, like 8 pixels from the left.
- [13:21]
Karl Koch
I guess the way that I think about it with these things is, like, if you break it down as a design problem and try to understand, like, what. What am I actually doing here? Like, it's digital pixels on a screen. It's not a physical thing. But, like, if I'm saying I want to add a new entry, I'm putting something into an existing set of things. And so that's why there's that kind of slight slide in, because it's like I'm inserting it.
- [13:43]
Carlos
Yeah, you're pushing it in.
- [13:44]
Karl Koch
And like. Yeah, in real life, that's what we would do. We would put it into that. That space. Then when I discard it, it's like I'm less interested by it. Cause I'm getting rid of it, you know, I don't need it. And so it's kind of more of a just poof and go away. And then everything kind of comes back to the kind of starting point. So it gives us that opportunity to, I guess, bring a bit of humanity and, like, reality to something that is inherently just digital pixels on a screen.
- [14:11]
Carlos
I'm smiling because you said the word poof, and that was the exact word that was in my brain when you hit hide.
- [14:16]
Karl Koch
It's the one that lives in my brain forever. Every time I'm trying to think of an animation to get rid of something, just poop it away.
- [14:22]
Carlos
That's good.
- [14:22]
Karl Koch
It's good.
- [14:23]
Carlos
Okay, let's keep going here. I'm enjoying myself.
- [14:25]
Karl Koch
All right, so we've got this Inspector Dao. So this. This is kind of more of. It's less overexciting. Right. This is just a slightly broken UI on purpose. This is more just like reminding ourselves that there's more to the browser that you're using than you realize. And sometimes the best place to debug a problem is just in the browser. Obviously. You know, Cursor recently have shipped the ability to kind of debug in the browser inside of Cursor and do a lot more creative stuff inside of there with the. The side panel and the selection states, etc. Which helps with a lot of this. Let's say if you're using claw code, you're doing something that's maybe more terminal based if you want to play in that area. Or you're using an IDE that isn't Cursor, you won't have that stuff. So you can just leverage what we have here. So, obviously there's a ton of things that are subtle and sweet, but, like, the most immediate problem is the images in this example. So, like, the images are getting squished Now. This one looks fine, actually pretty Much. I don't know what the back looks like in real life, but it looks pretty close. You know, if I don't know what I'm looking for, I might immediately be like, huh, okay, well that one's fine, the others are broken. And so if I'm trying to prompt an LLM to be like, ah, you need to fix these images, like what am I going to say? Or like, well, the images look squashed. You say that to the LLM, it's like, great, okay, cool. And it will resize everything because it's like, well, the images are squashed. Ah, so it's going to change the dimensions to try and solve the problem. And then it's like, okay, that's not solved it. So then you end up fighting with it again, asking it all these questions. But in reality, like all I got to do is just right click inspect element and if I've clicked on the image, I'm going to get taken straight to the image in this little console. I already know what I'm looking for. Obviously it's the sort of thing that you can kind of train yourself to get towards. But I know immediately this object fill is the problem. And just in one change from fill to cover, I can solve the problem and I can get rid of the inspector. Because once you've made a tweak, if you don't refresh the page, the changes you've made in the inspector stay. So you don't have to have it living there, always getting in the way. But then that means I can look at this and go, okay, great, like all of these images now, you know, they're not super nice images, but they all fit and they look right. Those sorts of little things that save you, I guess, a ton of time, but also just a ton of wasted credits and energy. I've been guilty of this and I know a lot of people are. Once you start to play with using AI to help you build stuff, it's very easy to then just always go to the AI to solve a problem. And it's actually like, even for me, as someone who knows how to solve some of these problems quickly, I can get caught in a loop. I'll just fix this thing because I know what the problem is, just fix it. And then it does maybe fix it, but then it creates another problem or it doesn't quite fix it. And I could have solved it a minute ago, but I didn't. Instead I just over prompted and over prompted and ended up fighting against it. And actually I read an interesting article By Andre Karpathy. I think it was just the other day, yesterday, and he was speaking exactly to this, where it's like you can ask AI to produce something, and sometimes you'll get a thousand lines of code, and you look at it and you think, that doesn't seem quite right. And then the immediate answer will be something like, yes, you're right. And then it'll refactor it into something. It's a hundred lines of code, and it works perfectly. You think, why didn't you do that the first time? But it took you to know that it didn't look right to prompt it, to then fix it. And I think that's fine because it's like a, you know, instead of being a one and done, it's a two and done. And you still got there pretty quick. But if you don't know to question it, you can end up with bloated repositories that are like tens of thousands of lines of code to do stuff that you could do in a few thousand.
- [18:04]
Carlos
Can we talk about that for a second? Because I'm sure that there's a good amount of people that are listening that are, like, nodding along because they're understanding conceptually, yes, if you know what to look for, you will get a better output. And yet I spend a lot of time thinking about how can somebody who actually doesn't know what to look for yet they don't even really know that much syntax at all. How can they strategically close that gap in a way that is high roi? Because it's not as simple anymore as, like, well, just, you know, go to a coding bootcamp, go spend eight months learning syntax. You know, there's gotta be a happier path in terms of how to grow that muscle and be able to scout, you know, that doesn't really pass the sniff test. There's gotta be something better there. There's gotta be a way to optimize, there's. Any thoughts for that person who's motivated, wants to think about a learning journey, but, you know, doesn't really just want to start building an HTML CSS website from scratch as step one.
- [19:01]
Karl Koch
Yeah, that's funny you say that. I mentor a lot of people on the side, and there's a lot of people actually just generally, like, anecdotally, there's a lot of people trying to move towards more of a design engineering role, whether that's actually, like, a role that they do as an employed role or whether it's just a mindset shift of, like, being more aware. And I Found myself just saying the same things like over and over again. It's like, oh, well, ideally you need to like understand the terminal and then like, you know, just the basics and then once you know that you can do the basics of HTML and the basics of CSS and you could kind of build a builder, build and build. But then a lot of those people would go off and they'd come back to me and be like, I just did a react bootcamp and I'm like, okay, cool. But also like, you've just, you've just skipped so much important stuff and move straight to a framework. And frameworks are great, but the whole reason they exist is to create a layer of abstraction. So we're trying to take you away from how it's really working, which is great for like practical day to day use, but it's not great for you understanding what's really going wrong or what's really happening. And it spurred me to put together a course and that felt like the best thing that I could try and do to help bridge that gap of knowledge is to take, I guess what I know, everything that I've spent years learning and all of that knowledge, and try and piece it together in a way that will properly take people on a journey from like zero knowledge. Like literally, we're talking, you've never even opened the terminal before, but we start there and then by the end of it, you're building web pages, prototypes, things that are interactive, that have motion, that do clever stuff. Like, it is a full spectrum. I'm hoping, fingers crossed, that it kind of helps to provide a resource that people can come back to as well. Right. It shouldn't be like a course from 0 to 1 and then just like ship it and be done with it. And like, okay, I completed the course and got a certificate. I'll put it on LinkedIn and that's it, I'm done. The idea is that it becomes kind of almost a repository that you can refer back to if you like, you know, want to do a specific animation again, like, oh, I remember learning it in the course. So I can go back to that and find it and reuse it.
- [21:10]
Rid
Hey, quick note. After recording, I asked Carl if he'd be down to offer a special discount for Dive Club listeners and he agreed. So if you head to Dive Club, Carl, that's K A R L. You can get 10% off his become a Design Engineer course and we'll put it
- [21:25]
Carlos
in the show notes too. All right, back to the episode. And I also love that you specifically defined like the front of the front end. Because I think that's an important distinction too. And at least in my own practice, as someone who is, you know, doing the startup design thing where you're wearing all of the hats, the front of the front end is design. Like that is not an engineering thing anymore. Like as a designer I own all of that. And it makes sense too, right? Like that is a core part of
- [21:54]
Rid
what the user experience actually is.
- [21:56]
Carlos
How does it feel and move and behave. And up to this point it's always just been like somebody else's job to kind of land the plane on that. And there was really just a tooling issue. And now that I feel empowered, I'm like, yeah, that's just, that's UX design. I own the experience of this product and that entails nailing every single detail on the front of the front end.
- [22:16]
Karl Koch
Yeah, I totally agree. And, and actually if you step back, like, I don't know, 20 years, like the front of the front end was owned by design because you had the idea of the web designer. The web designer was like the most common like hire in any kind of agency actually in that time. And the expectation was HTML and CSS was your job. Like you design and you build the basics and then someone probably jumps in and does like a bit of php, probably back then to set up the databases and do all the kind of the more interactive and like data related parts. But your web designer was putting the front end together. And it's funny, we like went on this huge journey. We talked about it earlier about being a generalist. Like we went on this huge journey when Facebook defined the product designer and went like, okay, right now we need to split all these things up, like product design, UX design, ui. Is it different? Oh, maybe we just spread everyone apart into these super, super specialist roles, which I think were really practical for a time and they actually helped a lot for kind of delivering great products. But with AI kind of being this leveler of giving designers more power and more control over the front end, I feel like we are, we're sort of swooping back into generalist territory. People are going to want to hire that because, I mean, from a business perspective it makes sense. You get one person who can do two roles, right, great. But also just like from, I guess a more selfish individual perspective. For us as designers working in a company, it's actually just giving us way more control over the thing that people see at the end. And what do we really care most about as designers? We care about what the end customer is going to experience, that end person who uses the product. And, you know, you talked about it, the fact that it's kind of. It encompasses the UX like it really does, and being able to say like, that Radius just looks a bit off and I don't love it. And rather than having to have a conversation about that in like, you know, putting in some linear or whatever people are using, you know, and like raising a ticket and trying to get it prioritized and doing all this stuff, you can just say, actually, I'm just going to jump in the code base quickly, tweak the radius, ship a fix, print, get someone to have a quick look at it done, you know, like five minutes, ten minutes done. Instead of battling for two weeks trying to get someone to prioritize it on a roadmap.
- [24:36]
Rid
I've been designing products every day for the last 15 years, but in the last six months, everything has changed. With AI in the mix, I'm cranking out ideas faster than ever. But none of that matters if I can't get the feedback that I need to get the team aligned. And right now, getting async feedback still kind of sucks. So I'm building the product I've always wanted and it's called Inflight. I use it every day to share ideas and get feedback from the team. It's totally changing the way that I work. So I'm excited to show you. Right now I'm only giving access to Dive Club listeners, so head to Dive Club Inflight to claim your spot.
- [25:18]
Carlos
It's not only just more complicated control, it's more accountability too. Like, you can't point to anybody else. The amount of times I've said like, well, you know, it looks good in figma, it's like, no, that's not an excuse anymore. Like, what is the end product? You are responsible as the designer of that product for every single detail.
- [25:34]
Karl Koch
100%. 100%. And I think a good example of that actually, if we were to touch on it, is what I do for my day job. We talked about it. I work at DuckDuckGo, so we're a private search engine, we're a private browser. We're, you know, fighting against Google, who are huge and they've got thousands, thousands, tens of thousands of engineers and designers and we've got but the limited resources of the size of our team, which is significantly smaller. But, you know, I guess what that gives us is an opportunity to really try and focus in on the little details, the little moments of delight, the Small kind of pieces of craft that we can put into an experience that maybe 99.9% of people won't ever touch or see or do anything with. And so a project that I worked on recently was around what we call Search Assist, which is our AI powered answer that we give you at the top of the search results. And we want to add images in. So, like, I've got an example here of who played Vecna. Very topical. So if I search that I get a response. And we get a little image here in this module and we surface this result from specific sources which we cite the image we have to get from a different place. So we are getting that image directly from Wikipedia. And so we need to source that image and reference the source of that image separately from the answer itself. We ended up settling on this little copyright right button that we show in the bottom right hand corner. I remember when we put the original implementation together, we used some existing componentry and the result was basically you click the button, you see the dialog that shows the information. Cool. Like, it works. It worked great. But the reality for me was this is like a tiny little moment where I could just do something more, even though I know nobody's really going to ever click this, because no one really cares. Like, we're doing it legally because we have to, but, you know, no one really cares. But if they do care, when they click it, they get this very tiny, very tiny morphing effect where the button grows from being the circle to being the dialogue. It's fakery. You know, we're using clip paths and other things to make this work. But there is just something about that experience that makes it feel like I cared because I did care. I cared enough for us to put the time and effort in to make this happen in this particular way. And no one asked me to do that. Even down to the bezier timing on the specific out, like easing out animation, like it's all dialed in.
- [28:01]
Rid
I mean, but that's the type of
- [28:03]
Carlos
bar that I want to have for myself too, you know. And it's interesting that you talk about the morphing effect, because I haven't been able to really pull that off in a way that I've been proud of with AI and it always kind of gets skewed or I never know, like, do I use motion for this or is it just css? Or like you mentioned a clip paths, like, like, not. Maybe we could just get ultra specific here for a second because this is very topical for me. How should designers Think about creating this type of effect, assuming that they're not going to be writing much syntax. And it really is just trying to coach the AI to help.
- [28:37]
Karl Koch
Well, I think here is another example where, like, understanding a little bit about how it works gives you the right vocabulary to talk about it. So just like we would if we had the useeffect error, where it's like, okay, that's not quite right. I've seen it before. It's probably use effect, and I can kind of steer the conversation. You could do the same thing here where you say, like, I want to do a clip path animation. So I've got this circle. I prefer to avoid using a library because, you know, I want to keep it responsive. I want to keep it kind of keep the bundle size down, focus on kind of performance, which is obviously a huge for us building a search engine. So, like, you know, use a clip path and I want the button, it's going to be a circle, and I want it to morph into the shape of the dialog that contains the contents. And you can kind of start from there, like, as simple as that. But already you've kind of given it keywords which are clip path starts as a circle morph dialogue. So it's like, it should know from that and be able to infer enough. And then once you get to that point, it's like, okay, now it's functioning. And it still takes some finessing, but once it's functioning, then you can start to think about, like, okay, how do I dial in this cubic bezier? Like, what do I want this to actually feel like as an animation? And then you can use this. Tons of tools. There's some tools on the design engineering website. There's tools like easing.dev is really good for just getting little snippets you can play with. And then typically I'll just get those and just drop a bunch in and just try, like, what does it feel like if it's really fast out? Does it feel like if it's really slow out and just start to really kind of pick it apart and find the right combination of values that just feel just right. And this took us a little while to tune because originally it was like, too quick or it was too kind of boisterous. Another thing I see a lot with these things, especially if you ask AI to build stuff, is it springs everything. Everything's a spring.
- [30:20]
Carlos
Everything's a spring. Yeah, yeah.
- [30:22]
Karl Koch
So you'd be like, you know, you've got this thing flying about and. Yeah, cool. Sometimes but if you're in this kind of a context and this thing was, like, bouncing around, like, I'm trying to read, you know, I've clicked it for a reason. The goal is to read the copyright information. So the animation needs to not be, like, overly gratuitous and, like, too in your face. So the. The way that we kind of thought about it is how do we make it so that it's more interesting and more kind of thoughtful than just appearing and disappearing, but without going down a path of being, like, gratitious and just, like, over the top. There's other places like this more button as well. When we worked on this, like, this is if you want to expand the answer out, like, there's some subtle animation here where the state changes happen. They just kind of help to tell the story of, like, something's happening and it feels a little bit nicer than just if it suddenly changes, you don't notice the change, and that can be a problem. So you need to, like, try and draw some attention. But we don't draw too much attention. I mean, that's maybe, like I said, it's quite boisterous as an animation. It kind of goes in and out and flipping around, but, you know, it helps to just tell the story. And I think it makes the experience just like 5%, 10% better for people that do click the button and, you know, if it does great, I've done my job.
- [31:36]
Carlos
This kind of stuff might seem obvious to you, but even very practical stuff, like the words like clip, path and morph, like, that's actually really helpful for me as I'm. I'm. I'm just always trying to find the right language to describe what I want. And so I love hearing that. I'm wondering even, like, zooming out for a second. You've talked about this mindset for what it means to be a design engineer. Is there anything else that falls into that category that we haven't talked about that you think someone who does resonate as being, you know, much more of a traditional designer who wants to grow those muscles, anything else that falls into that category that. That we can be thinking about.
- [32:12]
Karl Koch
So for me, the biggest thing is we talked about LLMs and how they're kind of helping to level up designers and turn them into designers who can code to a degree. Right. And that's fantastic because we're able to see designers ship stuff that maybe they wouldn't have ever got to ship or wouldn't have quite turned out the way they wanted to. And I think that the piece that really tells a design engineer from just a front end engineer is creativity and craft. And it's having the mindset of being someone who cares about that final 10%. Like I was talking about less than 1% clicked button doesn't need to animate. It just doesn't. But I want it to animate because I want the that 0.1% or 0.04% or whatever it is that the person who's going to click that to have an experience that feels cared about and, and like has a moment of delight that they can be like that's that person who made that thought about this. Even if they don't consciously think it, they're going to think it subconsciously. That for me is the design engineer. It's somebody who has a designer's mindset towards shipping product. So you're thinking about how to build it, but you're thinking about how to build it in the most delightful way possible.
- [33:21]
Carlos
I love the combination of creativity and craft as a definition. And it then kind of makes me wonder like what are you seeing at the job market level for design engineers? I'm curious. State of the world today. But then also like where's the this kind of heading? As AI continues to make code cheaper
- [33:40]
Karl Koch
and cheaper, I think a lot of the roles still at the moment are sat kind of maybe where we were or where we are kind of in the current state, which is that a design engineer still needs to have fundamental coding knowledge and needs to be able to code and use AI as an accelerator, but not the hundred percent their their way of coding something. Obviously outside of the job market you can can vibe code something into production and be super successful like 100% in the job space. Like that just won't fly. Like you're not going to see an employer being like cool, I'm going to trust 100 vibe coding. Some places are trialing it. I've heard some mutterings around intercom trialing designers vibe coding into production and super interesting to hear that that's the happening because I think there's definitely a value to it when the thing that they're building and shipping and working on is like simple enough that you could trust the machine to do the whole thing. But I think most employers, I think at least in my experience in the conversations I've had, are still going to be nervous about allowing people to just blindly trust an AI and ship to production. In fact, if I think about it, it reminds me very much of the office. And people may remember this, but the moment where Michael Scott blindly trusts the sat nav and then finds his way into a lake. But it's that same kind of mindset of like, you know, you let the machine just tell you everything and you go, okay, I'll do it and I'll do it that way. And that can get you a certain amount of the way through. But it doesn't mean that, you know, suddenly now you can vibe code like a thing that you're, you're 100% now a design engineer. I think you still need to have enough of a mindset. I think that will change though. Like, you know, I'm not, I guess, old man yelling at Clouds about this. Like, I know realist that like, it's not going to be a forever world, that you're going to need 100% knowledge across the board of these things. And I think just as like a design engineer needs to understand design and like the front of the front end, over time that is going to narrow and narrow, narrow to the point that I probably will get good enough that we can say like, you know, I don't need to know about the use effect bug because enough has happened in the training data that it knows to not do that anymore. It's only a matter of time. Like, I'm not gonna deny that, but I still think we're probably like a few years off from that being a thing. So I think it's still a good time now to, to grasp on those fundamentals.
- [36:04]
Carlos
And there's such a gap between making something functional and delightful. Even going back to like those little items that you were adding and hiding. You know, like, there's a lot that goes into that and you feel the difference. I'm not getting anywhere near to that level of quality out of the box. And again, it's like, it's so beyond the conversation that I see a lot today of, you know, we point at the purple gradients and how that's, you know, visual slot for me. I don't even care about the visuals really. I think the bar for visual quality is going to continue to rise really quickly. And I don't really see that as the best way for me to even stand out. As a designer who ships, I want things to, to feel amazing and to be really snappy and fast and optimized. And I'm, I spend so much more of my time wrestling with AI around like, interactions and you very quickly realize what you don't know in that world. The reality is I probably do have to learn a little bit more it reminds me of even, like, one of your quotes that I wrote down. It was something like, build with vibes, but ship with rigor. I'm like, I can feel my gap right now in the ship with with rigor part of the equation. And it's definitely something that I'm trying to grow in.
- [37:16]
Karl Koch
I'd be the first to admit I vibe code a bunch of stuff that I work on. Like, I leverage these tools as much as anyone. You know, there are. There are definitely points in time where I'm like, oh, am I, like, still a design engineer now? Like, am I. Am I moving away from this? Because I'm relying more and more on AI to kind of solve problems for me. But then I just had to keep coming back to the fact that the thing that makes me feel differently about stuff is that I make design decisions that an AI won't make. And there are times when I'll ask it to go off and do a thing, and it's like, I've done it and I look at what it's done and I'm like, yeah, really? But then there's also times where I'm like, I'll have thought of an idea that it wouldn't even think of. That's not complicated. We're talking simple stuff. Like, I mean, I've got my personal website out. Some of the examples of, like, the cards, when you hover over these ones, like, it's just taking the image that you've got here of the particular element and then just placing it in the background, blurring it and enlarging it. Like, that's all I'm doing as a simple, subtle, you know, mostly pointless thing to do, but it just brings a bit of life to this moment. And we do the same thing here on these music cards. Like, it just takes the album artwork, places it above it and then blurs it. And then you've got these little, you know, music bars flying around. Unnecessary little details. They're things that will only show on desktop. You're not going to see this on mobile, which is always a problem with, you know, important interactions, but in this case, it's just delight, so it doesn't really matter. And I like to think of it as this way of just. Just certainly giving people an opportunity to see that little 5, 10% of like, oh, I just cared enough to decide to do that. And I've tried to sprinkle little pieces of this throughout my site, but without trying to draw too much attention away from just the focus of what I have, it there for which is like, here's some stuff I've built that might be interesting and here's like some content that you might want to read that might be interesting to you. And if you want to chat and like we, you know, I can be useful to you, then let's talk. That's the goal of my website. And so as long as you can book some time with me or you can like hire me to do some freelance work and you can see the things I've done, then I've solved my problem. And then if you want to dig into the details, like there's more stuff you can go and find, but it's sort of deliberately not super upfront.
- [39:42]
Carlos
I like the image blur because it's not like that hard to pull off, I think, unless I'm missing something, you know, like, I'm so very confident that I could one shot that in a way that you would approve of in terms of just like the way that the code is written. But I also like that that's how you have that two part definition of creativity and craft. Like what makes that good is not necessarily the craft, the code's pretty easy, but the creativity, it's interesting, right? That subtle little detail that makes it a little bit different than your normal card that you'd interact with on the web. And being able to spike in both of those. I don't know, I'm just like still thinking about that as a definition of a design engineer. And it's really resonant.
- [40:22]
Karl Koch
I mean, there's been examples before on dive, like of people's portfolios that are super, super interesting, where on the face of it, it's like, okay, cool, yeah, some text, a bento grid, like, all right. And then it's that moment when you hover over that the card changes and something exciting happens. And it's that, that little attention to detail of like caring enough that when someone visits that site and has that rollover effect that they're going to be like, okay, why did you put that time in? Like, you did it for a reason. And that makes me interested. And now, now I want to dig in and I want to find out more about you. And I'm not saying I'm doing anything to that level. Like, you know, I think I've tried to keep things, I guess typically more restrained because I'm far more minimal when it comes to design. But I figured it was sort of a good time now to start adding some little touches of like little moments just that feel kind of interesting and a Little bit subtle and that 10% more.
- [41:17]
Carlos
I haven't made this connection before, but I've also felt like I can do that on websites that I own. Maybe it's portfolio. I haven't actually had one of those for a little bit, but like the dive website for instance, you know, like I obsessed over those hover details and framer and all the little things and it was almost like an expression of myself. I haven't yet been able to feel like that about a product that I'm working on as a part of my actual day job.
- [41:43]
Rid
And I think I'm just getting little
- [41:46]
Carlos
pieces of that recently. And it only comes with being able to sweat the details in code like you. I personally don't feel that in Figma.
- [41:56]
Rid
Like I have to be like really
- [41:58]
Carlos
massaging something and playing with the hover states repeatedly. I'm thinking about like the episode cards on the dive website. I spent way too long on those. But I like how it feels, you know, like this is what I wanted it to feel like.
- [42:11]
Rid
And I'm getting to do a little
- [42:12]
Carlos
bit more of that with the inflight product where it's like, no, I can just obsess over how it feels and it can be this like expression of who I am. Not everywhere. Some pieces suck, but some pieces are really good, you know. And I mean, what a fun time to be a designer who was interested in this design engineering path because you can get that feeling outside of your own little corner of the Internet kind of thing.
- [42:35]
Karl Koch
It's interesting when you talk about products like I think, think it's, it's a very different world and that I think for me as someone who is a design engineer at a company, I guess the danger zones of seeing design engineering online is it can be easy to fall into the trap of thinking that being a great design engineer means that you are an excellent animator and you can build these like super beautiful details of like how all these things can join and change and morph. And the reality is that like, like most of the energy we put into stuff in like day to day work as a design engineer is a lot less about those kind of crafty details and kind of more about trying to translate design intent into something that is functional and beautiful and fast and efficient.
- [43:22]
Carlos
Yeah, right.
- [43:23]
Karl Koch
Especially when you work on a search engine, like it's all about like, don't. You can't add all of these extra things that are going to create like any kind of speed blocks. But when you get that time to say, let's add that tiny moment the little morphing button I put in or the changes of state of that more button. It's those little tiny moments where I'm like, I have the, I guess the authority or like, I have like the permission to go all out and just like go for it in those little moments. Because I know that all the things around the edges that I've worked on are sound and like, it's performant, it's going to work. And so I'm going to put that time in to make those things happen because I care and I want them to be there, not because anyone's directing me to do so. So I think, like, for anyone who is aspiring towards design engineering, it's worth knowing that there won't be an expectation that you have to be this master animator, like, and that you need to, to be like, able to put motion into everything you work on, because it can sometimes feel that way.
- [44:23]
Carlos
No, I think that's a great point and I love the word permission. My hope is that more designers are feeling that level of permission. I think with that comes the awareness of the amount that you have to learn. So I appreciate you coming on today and sharing some of the, you know, mental models and tactics that you're thinking about while making this course. We'll put the link in the show notes for anybody who's interested in going deeper. I know for myself, even just from this conversation, I've come away with some super practical takeaways and things that I can start to incorporate in my own practice. So I appreciate you coming on today.
- [44:55]
Karl Koch
Carlos, thanks so much. Yeah, thanks for having me.
- [44:59]
Rid
Before I let you go, I want to take just one minute to run you through my favorite products because I'm constantly asked what's in my stack. Framer is how I build websites. Genway is how I do research. Granola is how I take notes during crit. Jitter is how I animate my designs. Lovable is how I build, build my ideas in code. Marvin is how I find design inspiration. Paper is how I design like a creative. And Raycast is my shortcut every step of the way. Now, I've hand selected these companies so that I can do these episodes full time. So by far the number one way to support the show is to check them out. You can find the full list at Dive Club Slash Partners.