Season 1
|
Episode 7
Framer, AI, and designing for Jay-Z
Dan Hollick
Product Designer @ Raycast
May 18, 2023
May 18, 2023
|
30:43
30:43
music by Dennis
About this Episode
In this episode, Dan shares his insights on using Framer from his experience as an early adopter. He also discusses his approach to learning to code while building his own product and shares some tips for others looking to do the same. And obviously, we couldn't call it a Deep Dive without chatting a bit about the impact of AI as well as learning how Jay-Z used to influence the product roadmap at TIDAL 👀
Show Notes
Deep Dives
Get our weekly breakdowns
Insights + resources from top designers 👇
Lauren LoPrete
Director of Design Systems @ Cash App
David Hoang
VP of Marketing and Design @ Replit
Adrien Griveau
Founding Designer @ Linear
James McDonald
Designer @ Clerk
Femke
Design Lead @ Gusto
Join 10K+ designers
HC
HC
HC
HC
Deep Dives
Get our weekly breakdowns
Free lessons from 👇
Lauren LoPrete
Lead designer @ Netflix
David Hoang
VP of Marketing and Design @ Replit
Adrien Griveau
Founding Designer @ Linear
Femke
Design Lead @ Gusto
Join 10K+ designers
HC
HC
HC
Deep Dives
Get our weekly breakdowns
Insights + resources from top designers 👇
Lauren LoPrete
Director of Design Systems @ Cash App
David Hoang
VP of Marketing and Design @ Replit
Adrien Griveau
Founding Designer @ Linear
James McDonald
Designer @ Clerk
Femke
Design Lead @ Gusto
Join 10K+ designers
HC
HC
HC
HC
Transcript chapters
A history with Framer
[00:00:00] Dan Hollick: So my journey framer has been a long one, really. I've been using framer through all of their various pivots. You know, I was using framer to do prototyping at multiple different jobs. and then recently I've been way more interested in framer because of their like recent pivot to making sites. as you know, I have a, I have a blog, which I coded myself, but every couple of months I'll get the urge to write a new blog post and I'll go, go to my repo and spin it up and there'll be like five different things I need to update. And I spend two weeks just like updating the site and I never get round to actually publish anything. And so the idea of framer now or framer sites, was really alluring. Like, okay, I can just offload this to something else, but still have all the like technical capability of code. Like framer gives you a lot of tools to hatch out of their UI and like really build stuff out. So, I just jumped in, started learning it.
[00:00:52] It was frustrating in the beginning, like I hit a couple of walls. but then I, I pretty early on saw the value proposition of framer sites. I [00:01:00] think a lot of us have.
[00:01:01] Michael: Can you talk a little bit more about some of the favorite parts of framer sites?
[00:01:04] Dan Hollick: Sure. So, like I said, I think some of my favorite parts about framer are the tools they give you to extend the tool.
[00:01:11] When you sort of hit the limits of what, like the functionality they've built into framework, they give you tools to just like write custom code, custom react, and you can leverage all the hundreds of thousands of React libraries that are out there where people have already done this work, right? You don't have to write it yourself. You can just drop it into framework.
[00:01:29] You need some technical expertise, but I really like that while they're building out the rest of the functionality, you have options to just make it work and like hack something together. It, it does encourage, just hacking stuff together, which kind of gels with the way I like to build stuff.
[00:01:44] Michael: Do you have a favorite thing that you've built in Framer?
[00:01:47] Dan Hollick: Um, it's a good question. I, so, a while ago I've recreated this like tailwind ui, like hover effect, and that was just a bunch of fun. I mean it
[00:01:56] Michael: mm-hmm
[00:01:56] Dan Hollick: it uses almost no framer ui. It's like [00:02:00] all custom code, but it's so much fun that like you can just build that, pop it online, and people are using it like immediately in their sites.
[00:02:07] It's just super cool.
[00:02:08] Michael: I have the remix link for that saved. Like I remember when James tweeted it and I was like, oh, that's so cool. And then your remix link popped up and I was like, yes it is. It is now something that I can use in my own work. I think that's like one of polar coolest parts. I mean, maybe it looks, it looks pretty good and I think that's like the thing that I'm so excited about with Framer is just this remix culture that has already been accelerating and just how quickly it's like catalyzing different design trends even cuz everything is so much more access.
[00:02:36] Dan Hollick: Yeah, it, there was a master stroke on their side, was just like, including that remix functionality. It's like got a viral loop built in where you're like, oh, I have a cool idea. I'm just gonna see if other people like this. And then you can just riff on other people's stuff. it's super cool, and I think it's one of the big things that Framer has going for it outside of something like Weblo. Which it has the same sort of thing, but it, it just lacks that like virality for some reason.
[00:02:58] I dunno.
A history with Framer
[00:00:00] Dan Hollick: So my journey framer has been a long one, really. I've been using framer through all of their various pivots. You know, I was using framer to do prototyping at multiple different jobs. and then recently I've been way more interested in framer because of their like recent pivot to making sites. as you know, I have a, I have a blog, which I coded myself, but every couple of months I'll get the urge to write a new blog post and I'll go, go to my repo and spin it up and there'll be like five different things I need to update. And I spend two weeks just like updating the site and I never get round to actually publish anything. And so the idea of framer now or framer sites, was really alluring. Like, okay, I can just offload this to something else, but still have all the like technical capability of code. Like framer gives you a lot of tools to hatch out of their UI and like really build stuff out. So, I just jumped in, started learning it.
[00:00:52] It was frustrating in the beginning, like I hit a couple of walls. but then I, I pretty early on saw the value proposition of framer sites. I [00:01:00] think a lot of us have.
[00:01:01] Michael: Can you talk a little bit more about some of the favorite parts of framer sites?
[00:01:04] Dan Hollick: Sure. So, like I said, I think some of my favorite parts about framer are the tools they give you to extend the tool.
[00:01:11] When you sort of hit the limits of what, like the functionality they've built into framework, they give you tools to just like write custom code, custom react, and you can leverage all the hundreds of thousands of React libraries that are out there where people have already done this work, right? You don't have to write it yourself. You can just drop it into framework.
[00:01:29] You need some technical expertise, but I really like that while they're building out the rest of the functionality, you have options to just make it work and like hack something together. It, it does encourage, just hacking stuff together, which kind of gels with the way I like to build stuff.
[00:01:44] Michael: Do you have a favorite thing that you've built in Framer?
[00:01:47] Dan Hollick: Um, it's a good question. I, so, a while ago I've recreated this like tailwind ui, like hover effect, and that was just a bunch of fun. I mean it
[00:01:56] Michael: mm-hmm
[00:01:56] Dan Hollick: it uses almost no framer ui. It's like [00:02:00] all custom code, but it's so much fun that like you can just build that, pop it online, and people are using it like immediately in their sites.
[00:02:07] It's just super cool.
[00:02:08] Michael: I have the remix link for that saved. Like I remember when James tweeted it and I was like, oh, that's so cool. And then your remix link popped up and I was like, yes it is. It is now something that I can use in my own work. I think that's like one of polar coolest parts. I mean, maybe it looks, it looks pretty good and I think that's like the thing that I'm so excited about with Framer is just this remix culture that has already been accelerating and just how quickly it's like catalyzing different design trends even cuz everything is so much more access.
[00:02:36] Dan Hollick: Yeah, it, there was a master stroke on their side, was just like, including that remix functionality. It's like got a viral loop built in where you're like, oh, I have a cool idea. I'm just gonna see if other people like this. And then you can just riff on other people's stuff. it's super cool, and I think it's one of the big things that Framer has going for it outside of something like Weblo. Which it has the same sort of thing, but it, it just lacks that like virality for some reason.
[00:02:58] I dunno.
Criteria for picking between Webflow & Framer
[00:02:59] Michael: I'm pretty [00:03:00] interested to hear how you think about the difference between Framer and Webflow. Obviously you are someone that can do it all yourself anyway with code and has experience with different tools, but I'm really interested in, in kind of thinking about it from the lens of someone that's just starting out and maybe they're building out their portfolio for the first time.
[00:03:15] How do you think that someone should evaluate the differences between Webflow and Framer?
[00:03:21] Dan Hollick: Yeah, so when picking between Webflow and Framer, especially as a junior designer, it's probably worth saying like it almost doesn't matter which tool you pick. They're both really good tools and you won't go wrong.
[00:03:32] But the thing, I think makes the choice much easier for a designer is Framer works more like a design tool. you're bound to feel a bit more comfortable in Framer. Webflow is great, but it, it feels a little bit like Web 1.0, whereas Framer is like Very component based. It's all about that sort of architecture.
[00:03:49] So it, it just like matches with the way you already think and work from something like Figma.
[00:03:54] Michael: One of the things that you say is this idea of no code doesn't necessarily mean no [00:04:00] complexity.
[00:04:00] Can you unpack what you mean by that?
[00:04:02] Dan Hollick: Yeah. I think I stole this from someone else, so I'm not gonna take full credit, but no code definitely doesn't mean no complexity. You might not be like programming in the traditional sense, but you are running into all problems that programmers run into, especially at scale.
[00:04:18] So you still have to think about like how you structure something to make it as efficient as possible. Maybe a good example is before Framer recently released like light and dark mode, if you wanted to switch between light and dark mode, you had to have a component for each mode, right? And all of a sudden your components have doubled. So, It's a rabbit hole, and just because you're doing it visually doesn't mean you aren't leveraging programming principles to try and make it as efficient as possible.
Criteria for picking between Webflow & Framer
[00:02:59] Michael: I'm pretty [00:03:00] interested to hear how you think about the difference between Framer and Webflow. Obviously you are someone that can do it all yourself anyway with code and has experience with different tools, but I'm really interested in, in kind of thinking about it from the lens of someone that's just starting out and maybe they're building out their portfolio for the first time.
[00:03:15] How do you think that someone should evaluate the differences between Webflow and Framer?
[00:03:21] Dan Hollick: Yeah, so when picking between Webflow and Framer, especially as a junior designer, it's probably worth saying like it almost doesn't matter which tool you pick. They're both really good tools and you won't go wrong.
[00:03:32] But the thing, I think makes the choice much easier for a designer is Framer works more like a design tool. you're bound to feel a bit more comfortable in Framer. Webflow is great, but it, it feels a little bit like Web 1.0, whereas Framer is like Very component based. It's all about that sort of architecture.
[00:03:49] So it, it just like matches with the way you already think and work from something like Figma.
[00:03:54] Michael: One of the things that you say is this idea of no code doesn't necessarily mean no [00:04:00] complexity.
[00:04:00] Can you unpack what you mean by that?
[00:04:02] Dan Hollick: Yeah. I think I stole this from someone else, so I'm not gonna take full credit, but no code definitely doesn't mean no complexity. You might not be like programming in the traditional sense, but you are running into all problems that programmers run into, especially at scale.
[00:04:18] So you still have to think about like how you structure something to make it as efficient as possible. Maybe a good example is before Framer recently released like light and dark mode, if you wanted to switch between light and dark mode, you had to have a component for each mode, right? And all of a sudden your components have doubled. So, It's a rabbit hole, and just because you're doing it visually doesn't mean you aren't leveraging programming principles to try and make it as efficient as possible.
Framer teaches designers to think like developers
[00:04:45] Michael: Yeah. I love the idea of programming principles. I remember saying, after kind of getting more familiar with Webflow, it, it kind of taught me front end, like that's how I learned css and when I was actually learning to write some of the syntax, I would kind of picture the [00:05:00] Webflow UI or like
[00:05:01] Dan Hollick: yeah
[00:05:01] Michael: I would know that I know this is possible because I can do it in Webflow.
[00:05:05] I just have to figure out what the syntax is. I'm wondering, do you see framer in the same way? Like do you think that this is actually something that can teach a lot of designers to think more like developers?
[00:05:15] Dan Hollick: A hundred percent. I definitely think framer is surreptitiously teaching designers react. They don't know it, but you’re learning react and, and a lot of those principles are familiar to you.
Framer teaches designers to think like developers
[00:04:45] Michael: Yeah. I love the idea of programming principles. I remember saying, after kind of getting more familiar with Webflow, it, it kind of taught me front end, like that's how I learned css and when I was actually learning to write some of the syntax, I would kind of picture the [00:05:00] Webflow UI or like
[00:05:01] Dan Hollick: yeah
[00:05:01] Michael: I would know that I know this is possible because I can do it in Webflow.
[00:05:05] I just have to figure out what the syntax is. I'm wondering, do you see framer in the same way? Like do you think that this is actually something that can teach a lot of designers to think more like developers?
[00:05:15] Dan Hollick: A hundred percent. I definitely think framer is surreptitiously teaching designers react. They don't know it, but you’re learning react and, and a lot of those principles are familiar to you.
Using Twitter to make complex ideas simple
[00:05:25] Michael: So on this topic of complexity, something that I've always admired of you is you really have this knack for taking ideas that are seriously complex and making them simple.
[00:05:34] looking through some of your Twitter threads, I mean, you, you go in depth on things like shaders, chromatic aberration in even how QR codes work. how did that start? Why is that something that you are into and spend so much time?
[00:05:47] Dan Hollick: So I guess I started trying to teach people stuff on Twitter because teaching someone is sort of the best way to understand something.
[00:05:54] So it's selfish in a sense. I think a lot of people assume that I've known [00:06:00] about all of these topics for a really long time, and I'm just choosing to share it now. In reality, I've just learned about it. I thought it was interesting. And to make sure I really understand it, I try explain it to other people.
[00:06:10] and I think as designers, one of the tools we have in our toolbox is we can explain stuff visually. and so I just sort of combined the two. I was like, okay, I've just learned this thing, how can I explain visually? Because it's gonna aid me in teaching the concept. I just, uh, I just kept doing it and, uh, it got easier and easier with each, like, really long tweet thread.
[00:06:29] But it's, uh, it's super satisfying to distill an idea down into its like core visual components. You strip away everything that might confuse someone and you say, okay, this is all you need to care about diagram. it's really satisfying. But yeah, it was a lot of practice too.
Using Twitter to make complex ideas simple
[00:05:25] Michael: So on this topic of complexity, something that I've always admired of you is you really have this knack for taking ideas that are seriously complex and making them simple.
[00:05:34] looking through some of your Twitter threads, I mean, you, you go in depth on things like shaders, chromatic aberration in even how QR codes work. how did that start? Why is that something that you are into and spend so much time?
[00:05:47] Dan Hollick: So I guess I started trying to teach people stuff on Twitter because teaching someone is sort of the best way to understand something.
[00:05:54] So it's selfish in a sense. I think a lot of people assume that I've known [00:06:00] about all of these topics for a really long time, and I'm just choosing to share it now. In reality, I've just learned about it. I thought it was interesting. And to make sure I really understand it, I try explain it to other people.
[00:06:10] and I think as designers, one of the tools we have in our toolbox is we can explain stuff visually. and so I just sort of combined the two. I was like, okay, I've just learned this thing, how can I explain visually? Because it's gonna aid me in teaching the concept. I just, uh, I just kept doing it and, uh, it got easier and easier with each, like, really long tweet thread.
[00:06:29] But it's, uh, it's super satisfying to distill an idea down into its like core visual components. You strip away everything that might confuse someone and you say, okay, this is all you need to care about diagram. it's really satisfying. But yeah, it was a lot of practice too.
How to approach color theory
[00:06:44] Michael: I'm curious to even kind of drill in on the the color theory topic. Just because that is something that, at least from my standpoint, I mean, you understand at a really, really high level. And I'm wondering what are the more common mistakes or shortcomings that you see other designers make as it relates to it?[00:07:00]
[00:07:00] Dan Hollick: Yeah. I think the shortcomings I see in other designers when it comes to color are a misunderstanding of how color works on computers and how that differs from the way we perceive color. so a small example is like if you have your HSL color picker open and you have a blue shade selected and you think, oh, I just want like a complimentary shade of green, and you just slide the hue over, you're like, okay, they're gonna the same. They're gonna be the same sort of intensity. But it doesn't work like that. For us, we perceive green as much brighter than blue. But the, for the computer, they're mathematically like on the same level. so I see a lot of that like creep in. It's just this like fundamental misunderstanding of the medium.
[00:07:40] Color is also one of those things that is endlessly complex. So it's not like I blame anyone. how are you supposed to understand the difference between a color space, a color gamut, a color model? Like they're all subtly different things, but you're just designing something, man, like you...
[00:07:53] if the color looks good, it looks good.
[00:07:55] Michael: Yeah, I, I mean, that is encouraging for me as someone who cannot [00:08:00] explain the difference between those things. I remember not even that long ago, really being a bit confused as it relates to like, how do I even think about X and RGB and hsb and HSL and, and all of this stuff?
[00:08:12] It can be overwhelming, especially earlier in your d journey as a designer. So, can you just give us a little bit of a rundown for how, how do designers approach these different ways of even dealing with color and what's your recomme?
[00:08:23] Dan Hollick: So if I was a junior designer right now and I needed to create like a color palette for a product, I think what I would do would be leverage the stuff that already exists.
[00:08:33] a thing I do with almost every project is I take the tailwind color palette because it's super comprehensive. They have like five or six gray scales. I pick some scales that I think I'll want to use, some like hues I'll want to use, and I just try apply it and see where falls short for my use case.
[00:08:51] So you might find like, okay, I, I might need a color between these two and I don't really ever use grave 500, so maybe I can just like rework the scale so it suits [00:09:00] my use case. because really, I mean, a lot of the work, like hard work has been done by other people.
[00:09:05] These scales are really good. You just need to like adapt them to fit use case. and you'll learn a lot about color in the process of just like playing around.
How to approach color theory
[00:06:44] Michael: I'm curious to even kind of drill in on the the color theory topic. Just because that is something that, at least from my standpoint, I mean, you understand at a really, really high level. And I'm wondering what are the more common mistakes or shortcomings that you see other designers make as it relates to it?[00:07:00]
[00:07:00] Dan Hollick: Yeah. I think the shortcomings I see in other designers when it comes to color are a misunderstanding of how color works on computers and how that differs from the way we perceive color. so a small example is like if you have your HSL color picker open and you have a blue shade selected and you think, oh, I just want like a complimentary shade of green, and you just slide the hue over, you're like, okay, they're gonna the same. They're gonna be the same sort of intensity. But it doesn't work like that. For us, we perceive green as much brighter than blue. But the, for the computer, they're mathematically like on the same level. so I see a lot of that like creep in. It's just this like fundamental misunderstanding of the medium.
[00:07:40] Color is also one of those things that is endlessly complex. So it's not like I blame anyone. how are you supposed to understand the difference between a color space, a color gamut, a color model? Like they're all subtly different things, but you're just designing something, man, like you...
[00:07:53] if the color looks good, it looks good.
[00:07:55] Michael: Yeah, I, I mean, that is encouraging for me as someone who cannot [00:08:00] explain the difference between those things. I remember not even that long ago, really being a bit confused as it relates to like, how do I even think about X and RGB and hsb and HSL and, and all of this stuff?
[00:08:12] It can be overwhelming, especially earlier in your d journey as a designer. So, can you just give us a little bit of a rundown for how, how do designers approach these different ways of even dealing with color and what's your recomme?
[00:08:23] Dan Hollick: So if I was a junior designer right now and I needed to create like a color palette for a product, I think what I would do would be leverage the stuff that already exists.
[00:08:33] a thing I do with almost every project is I take the tailwind color palette because it's super comprehensive. They have like five or six gray scales. I pick some scales that I think I'll want to use, some like hues I'll want to use, and I just try apply it and see where falls short for my use case.
[00:08:51] So you might find like, okay, I, I might need a color between these two and I don't really ever use grave 500, so maybe I can just like rework the scale so it suits [00:09:00] my use case. because really, I mean, a lot of the work, like hard work has been done by other people.
[00:09:05] These scales are really good. You just need to like adapt them to fit use case. and you'll learn a lot about color in the process of just like playing around.
The beauty of compact design systems
[00:09:13] Michael: So the, the first time I came across you was on Twitter, it was August of 2019, and you tweeted this screen grab of a plug-in that you built internally while you were at Tidal. And it was like fetching data from the API is an automatically populating your designs in Figma. And I remember thinking like, I don't know who this dang guy is, but he is an absolute wizard. And so I kind of want to hear a little bit more about that process and, and maybe you can just even share about your time at Tidal and, and kind of what led there, what was that like and what were the different things that you were working on?
[00:09:45] Dan Hollick: Sure. So when I was working at Tidal, my main responsibility was the design system, first of all, and design tool, like, just anything we needed that would like, help make the team more efficient.
[00:09:57] and so one of the things that we had to do quite a [00:10:00] was put together mockups for the marketing team. And of course titles in like a bunch of different countries and a bunch of different languages. So it was always super tedious to like Go through and, okay, what albums are we gonna like show for this image? And go get that information. Manually, like type it out, like copy the image offline somewhere.
[00:10:19] it was, it was just super tedious to populate these marketing marks with actual products like data. and so when Figma opened up their plugin api, I was like, oh, this, we have an api, like an internal API that we have access. and now Figma is like plugin API means that we can just merge those two together and I can sort of hack together, basically a way for us to not have to deal with the marketing team anymore.
[00:10:43] yeah, I just, uh, built this plugin that, uh, you could just drop an artist or an album link in it and it would populate a page.
[00:10:50] It was a time when design systems less mature. They took up like less of the conversation in design. and we had to support Tidal on [00:11:00] every platform. So Tidal’s on like your phone, your computer, your watch, your fridge, your tv. It's on like absolutely everything. we needed to all of those platforms with design systems.
[00:11:11] So it was a really interesting experience trying to build really small, compact little design systems. because again, I'm a fan of like just enough design. We were only three or four designers, so we didn't have time to maintain like massive systems. it, it was a really rewarding experience trying tackle all those platforms at once.
[00:11:30] Michael: Can you unpack a little bit what you mean by these small, compact design systems? How'd you even think about what went into them and how they connected to like the larger product ecosystem that you were working on?
[00:11:41] Dan Hollick: Yeah. so at Tidal we decided to go with the atomic design system principle. what we decided to do was to share just the atoms, right? So that was things like color, iconography, font choices, et cetera. We shared just the atoms between all the systems. And then all the sort of like [00:12:00] molecules and organism, we split out into their own system. So, you could update something in the atomic level and everything would inherit that change.
[00:12:07] it just worked out being much easier for us to have small little systems on top of that. they varied quite a lot between platforms.
The beauty of compact design systems
[00:09:13] Michael: So the, the first time I came across you was on Twitter, it was August of 2019, and you tweeted this screen grab of a plug-in that you built internally while you were at Tidal. And it was like fetching data from the API is an automatically populating your designs in Figma. And I remember thinking like, I don't know who this dang guy is, but he is an absolute wizard. And so I kind of want to hear a little bit more about that process and, and maybe you can just even share about your time at Tidal and, and kind of what led there, what was that like and what were the different things that you were working on?
[00:09:45] Dan Hollick: Sure. So when I was working at Tidal, my main responsibility was the design system, first of all, and design tool, like, just anything we needed that would like, help make the team more efficient.
[00:09:57] and so one of the things that we had to do quite a [00:10:00] was put together mockups for the marketing team. And of course titles in like a bunch of different countries and a bunch of different languages. So it was always super tedious to like Go through and, okay, what albums are we gonna like show for this image? And go get that information. Manually, like type it out, like copy the image offline somewhere.
[00:10:19] it was, it was just super tedious to populate these marketing marks with actual products like data. and so when Figma opened up their plugin api, I was like, oh, this, we have an api, like an internal API that we have access. and now Figma is like plugin API means that we can just merge those two together and I can sort of hack together, basically a way for us to not have to deal with the marketing team anymore.
[00:10:43] yeah, I just, uh, built this plugin that, uh, you could just drop an artist or an album link in it and it would populate a page.
[00:10:50] It was a time when design systems less mature. They took up like less of the conversation in design. and we had to support Tidal on [00:11:00] every platform. So Tidal’s on like your phone, your computer, your watch, your fridge, your tv. It's on like absolutely everything. we needed to all of those platforms with design systems.
[00:11:11] So it was a really interesting experience trying to build really small, compact little design systems. because again, I'm a fan of like just enough design. We were only three or four designers, so we didn't have time to maintain like massive systems. it, it was a really rewarding experience trying tackle all those platforms at once.
[00:11:30] Michael: Can you unpack a little bit what you mean by these small, compact design systems? How'd you even think about what went into them and how they connected to like the larger product ecosystem that you were working on?
[00:11:41] Dan Hollick: Yeah. so at Tidal we decided to go with the atomic design system principle. what we decided to do was to share just the atoms, right? So that was things like color, iconography, font choices, et cetera. We shared just the atoms between all the systems. And then all the sort of like [00:12:00] molecules and organism, we split out into their own system. So, you could update something in the atomic level and everything would inherit that change.
[00:12:07] it just worked out being much easier for us to have small little systems on top of that. they varied quite a lot between platforms.
From Jay-Z to full-time contracting
[00:12:14] Michael: You were at Tidal for I think like two and a half years. So a pretty significant amount of time. What were some of the main ways that you grew as a designer and maybe any specific feedback that you received while you were there that really helped you in your career?
[00:12:28] Dan Hollick: Yeah, so I think the ways in which I, I grew as a designer at Tidal I became pretty adaptable. We were a small team, small design team, like only three or four of us, depending on the year. you know, a Tidal was still owned by Jay-Z at this point, and surprisingly he had like quite a lot of product influence.
[00:12:47] So occasionally he'd set the roadmap like halfway through a year. And so you just have to adapt. Like it doesn't really matter what you were planning on doing. Jay's got an idea and we're just gonna do it.
[00:12:57] Michael: Do you have any specific stories about when Jay [00:13:00] made his presence felt on the product roadmap?
[00:13:02] Dan Hollick: Yeah. I remember once or twice being in a meeting at Ti and the head of product return to you and say, oh, like, uh, Jay loved that thing he worked on, you'd be like, what doesn't he have Jay-Z stuff to do? Why is he looking at my designs ?
[00:13:16] but one of the things I remember Jay, introduced was one of his friends, uh, Nipsey was, I think he was murdered, while we were working there.
[00:13:24] so he really wanted to introduce a system where you could like donate to artists if they had like a cause on their page. So, Yeah, we pivoted to building this like donation system halfway through the year, which, I mean, it was, it was totally like a cool thing to build, but it, it wasn't on our roadmap, put it that way.
[00:13:41] Michael: Yeah, that is, that is a, a category of experiences that you're not many other designers are gonna be able to have. It's pretty cool post Tidal, I mean, you, you eventually made this jump, so you were at Barclays, you're at Tidal, and now you're actually running your own design studio, working on your own, taking on different contract projects.
[00:13:58] What's that jump been [00:14:00] like for?
[00:14:00] Dan Hollick: Yeah, so I mean, I think halfway through the pandemic, I decided I didn't really like the idea of my work being tied to my physical location. At the time I was living in Norway and it constrained the sort of opportunities I had, as a designer.
[00:14:14] I started looking for remote contract positions, in the US specifically. So I indirectly ended up being a contractor. I actually started working with a little company called Tuol as a contractor, and I just sort of fell into the contractor life. since then I've sort of been bouncing around between full-time contractors, well contracting gigs, and, um, freelance, full freelance. And it's been super rewarding, but it's also been, You're, pretty rough at points.
[00:14:44] one of the problems with being a contractor or freelancer is you take on all the risk, right? And I think we all understand that like in the current tech climate, there's a lot of risk, right? People are downsizing a lot, and contractors and freelancers are often the first to go. So it, uh, it is an [00:15:00] inherently risky but rewarding, career path to.
[00:15:02] Michael: do you have a preference between the full-time contractor with one company versus operating a little bit more like a freelancer and dabbling with different projects concurrently?
[00:15:11] Dan Hollick: I think my preference is the full-time contract work.
[00:15:15] Because I think as a product designer, you just get to sort of like ruminate on an idea and on a product for a lot longer. Whereas, doing freelance projects is fun, but you sort of, you just have to get it out the door and move on to something else. And that context switching can be quite exhausting.
[00:15:34] Whereas if you are in-house with someone, even if it is as a contractor, you really get a chance to, um, stew on a problem.
From Jay-Z to full-time contracting
[00:12:14] Michael: You were at Tidal for I think like two and a half years. So a pretty significant amount of time. What were some of the main ways that you grew as a designer and maybe any specific feedback that you received while you were there that really helped you in your career?
[00:12:28] Dan Hollick: Yeah, so I think the ways in which I, I grew as a designer at Tidal I became pretty adaptable. We were a small team, small design team, like only three or four of us, depending on the year. you know, a Tidal was still owned by Jay-Z at this point, and surprisingly he had like quite a lot of product influence.
[00:12:47] So occasionally he'd set the roadmap like halfway through a year. And so you just have to adapt. Like it doesn't really matter what you were planning on doing. Jay's got an idea and we're just gonna do it.
[00:12:57] Michael: Do you have any specific stories about when Jay [00:13:00] made his presence felt on the product roadmap?
[00:13:02] Dan Hollick: Yeah. I remember once or twice being in a meeting at Ti and the head of product return to you and say, oh, like, uh, Jay loved that thing he worked on, you'd be like, what doesn't he have Jay-Z stuff to do? Why is he looking at my designs ?
[00:13:16] but one of the things I remember Jay, introduced was one of his friends, uh, Nipsey was, I think he was murdered, while we were working there.
[00:13:24] so he really wanted to introduce a system where you could like donate to artists if they had like a cause on their page. So, Yeah, we pivoted to building this like donation system halfway through the year, which, I mean, it was, it was totally like a cool thing to build, but it, it wasn't on our roadmap, put it that way.
[00:13:41] Michael: Yeah, that is, that is a, a category of experiences that you're not many other designers are gonna be able to have. It's pretty cool post Tidal, I mean, you, you eventually made this jump, so you were at Barclays, you're at Tidal, and now you're actually running your own design studio, working on your own, taking on different contract projects.
[00:13:58] What's that jump been [00:14:00] like for?
[00:14:00] Dan Hollick: Yeah, so I mean, I think halfway through the pandemic, I decided I didn't really like the idea of my work being tied to my physical location. At the time I was living in Norway and it constrained the sort of opportunities I had, as a designer.
[00:14:14] I started looking for remote contract positions, in the US specifically. So I indirectly ended up being a contractor. I actually started working with a little company called Tuol as a contractor, and I just sort of fell into the contractor life. since then I've sort of been bouncing around between full-time contractors, well contracting gigs, and, um, freelance, full freelance. And it's been super rewarding, but it's also been, You're, pretty rough at points.
[00:14:44] one of the problems with being a contractor or freelancer is you take on all the risk, right? And I think we all understand that like in the current tech climate, there's a lot of risk, right? People are downsizing a lot, and contractors and freelancers are often the first to go. So it, uh, it is an [00:15:00] inherently risky but rewarding, career path to.
[00:15:02] Michael: do you have a preference between the full-time contractor with one company versus operating a little bit more like a freelancer and dabbling with different projects concurrently?
[00:15:11] Dan Hollick: I think my preference is the full-time contract work.
[00:15:15] Because I think as a product designer, you just get to sort of like ruminate on an idea and on a product for a lot longer. Whereas, doing freelance projects is fun, but you sort of, you just have to get it out the door and move on to something else. And that context switching can be quite exhausting.
[00:15:34] Whereas if you are in-house with someone, even if it is as a contractor, you really get a chance to, um, stew on a problem.
Learning to code to solve a problem
[00:15:40] Michael: one of those problems that you worked on was actually something that you created called Juggle, which is a property management app. And I actually remember coming across this out in the wild myself, and I really liked all the design.
[00:15:51] It's still somewhere in my swipe file today. Can you talk a little bit about that experience and what it was like starting from things, from from scratch on your own [00:16:00] and kind of what led to that and how you even went from zero to one and and took it from just an idea to something very.
[00:16:07] Dan Hollick: Sure. So there's an interesting story behind this.
[00:16:10] So in about like 2016, my girlfriend and I moved to Norway cuz I got a tech job in Norway. but we just bought a apartment back in South Africa. So we ended renting it out while we lived in Norway and we had like an estate agent manage the rental. and it was all fine, but it pretty tedious to deal with the estate agent.
[00:16:30] They would just like email us with something, we'd email back, they'd email the tenant, and it was just like this broken telephone game. And I remember thinking, oh man, like we're paying them to do what? and so my girlfriend came up with the idea of like, why don't we make uh, sort of tool that is like GitHub issues, but for landlords and tenants so you can manage like maintenance issues and billing and stuff all in this sort of, GitHub issue like, interface. And so we had that idea in like 2018 and we had no idea how to do anything with [00:17:00] it. Like at the time I couldn't really code. And so we spent the next two years like me learning on the fly, like react and
[00:17:07] Michael: Wow.
[00:17:07] Dan Hollick: And a whole bunch of stuff. and my girlfriend designed it and then we sort of pivoted around where I was designing and building it and she was doing all the like marketing and CEO stuff.
[00:17:16] And it was a, it was a wild ride. We ended up getting a small bit of funding from the nor. like innovation arm, like the Governmental Innovation Institute or something. it was a really cool experience, but it took a really long time because we had so much learning to do on the fly.
[00:17:31] Michael: That's pretty incredible. I knew that you were working on this and I knew that you had technical skills, but I didn't actually know that this was when you learned react to solve this set of problems and all of that.
[00:17:40] can you just tell us a little bit more about like, what was that learning journey like and maybe even helping other designers who are on the fence of like, should I learn to code? Like do you have a recommendation or even just a, set of principles that you've kind of learned over these, these two years of kind of throwing yourself into the deep end?
[00:17:59] Dan Hollick: Yeah, so [00:18:00] if you want to learn to code, I think the most important thing is that you have something you desperately want to exist. Because it's so to learn from scratch that you'll need to motivate yourself through the really tough bits by having like a concrete goal. I think that was really important for me.
[00:18:18] I needed to build this thing that we had this great idea, we thought it was gonna be a big thing. The thing that stood between us and it existing was me figuring this out. there almost needs to be some sort of stake at, at least like a personal stake you have in this. and a little bit about my journey:
[00:18:34] I spent some money buying a bunch of West Bus tutorials. West Bus is like, uh, I don't know, like one of the OG sort of course creators on Twitter. he was like, instrumental. It's really important to find someone who can teach in a way that matches your learning style. And he, just fits for me. Courses are really great because you build an actual production thing from start to finish and he leaves a lot of the mistakes in the video [00:19:00] to be like, okay, well this is what, like, you're gonna run into this problem, so I'm gonna leave it here so you see how I solved it.
[00:19:07] whereas I think a lot of course creators make the mistake of making it too polished, you know, like editing out mistakes. But your students are learning so much in between the stuff you're saying. They're like looking at how you've got everything set up. You know, they're watching your mouse and they're like, oh, what's going on over there?
[00:19:24] So there's a lot that you're not even aware of that is teaching people. I really did benefit a lot from that like style of, it's not perfect, but here is everything, you know?
Learning to code to solve a problem
[00:15:40] Michael: one of those problems that you worked on was actually something that you created called Juggle, which is a property management app. And I actually remember coming across this out in the wild myself, and I really liked all the design.
[00:15:51] It's still somewhere in my swipe file today. Can you talk a little bit about that experience and what it was like starting from things, from from scratch on your own [00:16:00] and kind of what led to that and how you even went from zero to one and and took it from just an idea to something very.
[00:16:07] Dan Hollick: Sure. So there's an interesting story behind this.
[00:16:10] So in about like 2016, my girlfriend and I moved to Norway cuz I got a tech job in Norway. but we just bought a apartment back in South Africa. So we ended renting it out while we lived in Norway and we had like an estate agent manage the rental. and it was all fine, but it pretty tedious to deal with the estate agent.
[00:16:30] They would just like email us with something, we'd email back, they'd email the tenant, and it was just like this broken telephone game. And I remember thinking, oh man, like we're paying them to do what? and so my girlfriend came up with the idea of like, why don't we make uh, sort of tool that is like GitHub issues, but for landlords and tenants so you can manage like maintenance issues and billing and stuff all in this sort of, GitHub issue like, interface. And so we had that idea in like 2018 and we had no idea how to do anything with [00:17:00] it. Like at the time I couldn't really code. And so we spent the next two years like me learning on the fly, like react and
[00:17:07] Michael: Wow.
[00:17:07] Dan Hollick: And a whole bunch of stuff. and my girlfriend designed it and then we sort of pivoted around where I was designing and building it and she was doing all the like marketing and CEO stuff.
[00:17:16] And it was a, it was a wild ride. We ended up getting a small bit of funding from the nor. like innovation arm, like the Governmental Innovation Institute or something. it was a really cool experience, but it took a really long time because we had so much learning to do on the fly.
[00:17:31] Michael: That's pretty incredible. I knew that you were working on this and I knew that you had technical skills, but I didn't actually know that this was when you learned react to solve this set of problems and all of that.
[00:17:40] can you just tell us a little bit more about like, what was that learning journey like and maybe even helping other designers who are on the fence of like, should I learn to code? Like do you have a recommendation or even just a, set of principles that you've kind of learned over these, these two years of kind of throwing yourself into the deep end?
[00:17:59] Dan Hollick: Yeah, so [00:18:00] if you want to learn to code, I think the most important thing is that you have something you desperately want to exist. Because it's so to learn from scratch that you'll need to motivate yourself through the really tough bits by having like a concrete goal. I think that was really important for me.
[00:18:18] I needed to build this thing that we had this great idea, we thought it was gonna be a big thing. The thing that stood between us and it existing was me figuring this out. there almost needs to be some sort of stake at, at least like a personal stake you have in this. and a little bit about my journey:
[00:18:34] I spent some money buying a bunch of West Bus tutorials. West Bus is like, uh, I don't know, like one of the OG sort of course creators on Twitter. he was like, instrumental. It's really important to find someone who can teach in a way that matches your learning style. And he, just fits for me. Courses are really great because you build an actual production thing from start to finish and he leaves a lot of the mistakes in the video [00:19:00] to be like, okay, well this is what, like, you're gonna run into this problem, so I'm gonna leave it here so you see how I solved it.
[00:19:07] whereas I think a lot of course creators make the mistake of making it too polished, you know, like editing out mistakes. But your students are learning so much in between the stuff you're saying. They're like looking at how you've got everything set up. You know, they're watching your mouse and they're like, oh, what's going on over there?
[00:19:24] So there's a lot that you're not even aware of that is teaching people. I really did benefit a lot from that like style of, it's not perfect, but here is everything, you know?
How learning to code impacts being a designer
[00:19:33] Michael: Yeah. That's something that I can store away and use even for my own teaching. It makes a lot of sense. I'm curious now that you have this, this skillset, this understanding of React and you know how to code, how has it impacted you as a designer?
[00:19:44] Dan Hollick: Yeah, I think knowing how to code as a designer, it isn't like an essential skill, but it makes a lot of the hard stuff a little bit easier. So I've been in tons of conversations with developers where they might say, oh yeah, it's really hard to do that, [00:20:00] and I can at least push back if it isn't, or ask more like follow up questions and be like, okay, why?
[00:20:05] Can you just tell me a bit about, you know, what makes it hard? and It gets you into conversations you might not normally be having with developers, and it opens up opportunities to work with them in ways you might not expect.
[00:20:16] You know, they might come to you and say, oh, I've been thinking about this. Like this crazy feature, we could do it, I think we could hack it together like this and it's just like a shared enthusiasm of, uh, like a common language. I think people underestimate that.
[00:20:27] Michael: I think it's even just beneficial to be a sounding board for engineers and just like the, frequency that those one or two questions that you ask as follow ups, that they actually unlock something in their mind where it opens up a different path that maybe they hadn't considered that way or something like that.
[00:20:43] Being able to be like a more technical sparring partner with engineers has...
[00:20:47] I can look back and see a lot of benefits where I'm grateful for even just like the little bit that I know about engineering for that reason.
[00:20:55] Dan Hollick: Yeah.
[00:20:55] I think there's a term in engineering called rubber ducking at a title, a bunch of [00:21:00] developers had little rubber ducks on their monitors, and the idea would be that like you could take a rubber duck to someone and be like, okay, I just need to bounce some ideas off of you. You're not actually expected to have like a full back and forth. It's more just like I'm having a and just the idea of like talking through it with an actual rubber duck will get me through some of the complexities here.
How learning to code impacts being a designer
[00:19:33] Michael: Yeah. That's something that I can store away and use even for my own teaching. It makes a lot of sense. I'm curious now that you have this, this skillset, this understanding of React and you know how to code, how has it impacted you as a designer?
[00:19:44] Dan Hollick: Yeah, I think knowing how to code as a designer, it isn't like an essential skill, but it makes a lot of the hard stuff a little bit easier. So I've been in tons of conversations with developers where they might say, oh yeah, it's really hard to do that, [00:20:00] and I can at least push back if it isn't, or ask more like follow up questions and be like, okay, why?
[00:20:05] Can you just tell me a bit about, you know, what makes it hard? and It gets you into conversations you might not normally be having with developers, and it opens up opportunities to work with them in ways you might not expect.
[00:20:16] You know, they might come to you and say, oh, I've been thinking about this. Like this crazy feature, we could do it, I think we could hack it together like this and it's just like a shared enthusiasm of, uh, like a common language. I think people underestimate that.
[00:20:27] Michael: I think it's even just beneficial to be a sounding board for engineers and just like the, frequency that those one or two questions that you ask as follow ups, that they actually unlock something in their mind where it opens up a different path that maybe they hadn't considered that way or something like that.
[00:20:43] Being able to be like a more technical sparring partner with engineers has...
[00:20:47] I can look back and see a lot of benefits where I'm grateful for even just like the little bit that I know about engineering for that reason.
[00:20:55] Dan Hollick: Yeah.
[00:20:55] I think there's a term in engineering called rubber ducking at a title, a bunch of [00:21:00] developers had little rubber ducks on their monitors, and the idea would be that like you could take a rubber duck to someone and be like, okay, I just need to bounce some ideas off of you. You're not actually expected to have like a full back and forth. It's more just like I'm having a and just the idea of like talking through it with an actual rubber duck will get me through some of the complexities here.
How designers can prep for AI
[00:21:21] Michael: I'm curious, you know, as someone that is a little bit more technically savvy, I'd love for you to kind of weigh in on the current state of things because right now, every time I open up Twitter, there's all kinds of advancements in different tooling and AI and how chat GPT is gonna change the world.
[00:21:36] And I'd love to hear how you think about it. maybe you even have a little bit of like a prediction or, uh, some thinking around how the role of design is gonna change in the next one to two years or so, given all of these advancements.
[00:21:48] Dan Hollick: Yeah, so I think design is gonna change a lot over the next couple of years. And I think we sort of misremember how much design has changed in the last decade.
[00:21:58] I mentioned to you earlier that when I [00:22:00] started, we were using Photoshop. so the tools have advanced, but they haven't advanced at the level I think we're gonna see with ai. I think that progress is just gonna move a lot faster. But the good news is I think for at least in the beginning, The focus will be on automating the stuff that we hate doing.
[00:22:16] not replacing us entirely, but removing parts of the job that are tedious and error prone. And that AI is just like better suited for,. But it will make it harder, especially for people trying to break in to design. I think the, you said the bottom of this pyramid will get a little bit narrower, as we go forward, which is, you know, unfortunate, especially if you're trying to get into design right now, but, uh, I don't think it's all doom and gloom. I, I think it's gonna open opportunities we haven't quite understood yet. so I'm probably 60% existential dread and 40% super stoked. Like, it, it's somewhere there
[00:22:50] Michael: that's a lot better than a lot of people.
[00:22:52] Dan Hollick: Yeah.
[00:22:52] Michael: do you have any advice someone that maybe is a year or two into their career and they kind of see this coming. If you were in that situation, how would you [00:23:00] prepare?
[00:23:00] Dan Hollick: I think the way to prepare for the impending AI revolution as a junior designer anyways, is to get really familiar with the tools.
[00:23:09] I don't think that piece of advice has ever changed. Like if you were trying to get into design four years ago, I probably would've told you be really good at Figma just like practice in Figma. And now that's gonna change a little bit to like be really good in Figma and know how to prompt an AI to generate something.
[00:23:26] just being good the tools will get you in the door. You know, you can't, um, you can't ignore the basics.
[00:23:32] Michael: Yeah, that makes sense. It feels like we're, we're moving towards a world where He's forced to be a little bit more generalist too. Because there are so many new efficiencies coming with design, maybe it's not gonna be enough to just crank out UI all day, you know?
[00:23:47] And, and so like expanding the surface area of what I as a designer, can contribute to the company that I work at. Maybe I'm flexing my product sense and contributing more to strategy and product process at the [00:24:00] company or maybe I am dabbling a little bit more into code and becoming more technical.
[00:24:04] I'm interested to kind of see how the core skill sets that we associate or attribute value to for designers, how those over the next few years, it'll be fun to watch.
[00:24:14] Dan Hollick: Yeah. I think AI is going to push a lot of job roles closer together because it's not just happening to design, you know. It's happening to front end engineering. It's happening to back end engineering.
[00:24:24] It's happening all over the place. So you'll companies will be able to do a lot more with fewer people and they will expect them to have broader ranges of responsibility. Um, so you, you might be sort of forced into learning something that hasn't historically been part of design. and for those of us that have been around for a while, like the role has changed a lot.
[00:24:44] This is just part of what is a really, really young profession. You know, it's still completely in, its nascent. I think that's a word.
[00:24:52] Michael: It is now. it's really. I mean, it it is, it's scary. It's, daunting in many ways, but I also think it is like very exciting. [00:25:00] I'm super stoked too, because it does feel like every time we have these technology cycles that almost kind of reinvent our day to day, it does level the playing field a little bit because there's so much newness that Yeah, on one I could see how it would be intimidating as someone that is like earlier in my career. But at the same time, if I think about, well, maybe I'm gonna be using AI prompts a bunch two years from now in my role. Well the people that have been doing this for 10 years, that's new to them too. And it's new to me.
[00:25:28] And so that is kind of motivating or it's like, yeah, I can figure this out and like if I really put myself to it, In many ways could catch up on the people who have been in this industry for so long because of the amount of change that's taking place.
[00:25:41] Dan Hollick: Yeah. You know, that's actually a great way to think about it.
[00:25:43] I haven't really considered that. Like it is going to the old dogs who can't learn new tricks are probably going to be as affected as the people trying to make it into the industry right there. In some ways, one of them is better crypt than the other. Hadn't thought. .
[00:25:56] Michael: Yeah, I'm wondering how much longer people are gonna be able to say the tools don't matter, basically.[00:26:00]
[00:26:00] Dan Hollick: Yeah. Yeah.
How designers can prep for AI
[00:21:21] Michael: I'm curious, you know, as someone that is a little bit more technically savvy, I'd love for you to kind of weigh in on the current state of things because right now, every time I open up Twitter, there's all kinds of advancements in different tooling and AI and how chat GPT is gonna change the world.
[00:21:36] And I'd love to hear how you think about it. maybe you even have a little bit of like a prediction or, uh, some thinking around how the role of design is gonna change in the next one to two years or so, given all of these advancements.
[00:21:48] Dan Hollick: Yeah, so I think design is gonna change a lot over the next couple of years. And I think we sort of misremember how much design has changed in the last decade.
[00:21:58] I mentioned to you earlier that when I [00:22:00] started, we were using Photoshop. so the tools have advanced, but they haven't advanced at the level I think we're gonna see with ai. I think that progress is just gonna move a lot faster. But the good news is I think for at least in the beginning, The focus will be on automating the stuff that we hate doing.
[00:22:16] not replacing us entirely, but removing parts of the job that are tedious and error prone. And that AI is just like better suited for,. But it will make it harder, especially for people trying to break in to design. I think the, you said the bottom of this pyramid will get a little bit narrower, as we go forward, which is, you know, unfortunate, especially if you're trying to get into design right now, but, uh, I don't think it's all doom and gloom. I, I think it's gonna open opportunities we haven't quite understood yet. so I'm probably 60% existential dread and 40% super stoked. Like, it, it's somewhere there
[00:22:50] Michael: that's a lot better than a lot of people.
[00:22:52] Dan Hollick: Yeah.
[00:22:52] Michael: do you have any advice someone that maybe is a year or two into their career and they kind of see this coming. If you were in that situation, how would you [00:23:00] prepare?
[00:23:00] Dan Hollick: I think the way to prepare for the impending AI revolution as a junior designer anyways, is to get really familiar with the tools.
[00:23:09] I don't think that piece of advice has ever changed. Like if you were trying to get into design four years ago, I probably would've told you be really good at Figma just like practice in Figma. And now that's gonna change a little bit to like be really good in Figma and know how to prompt an AI to generate something.
[00:23:26] just being good the tools will get you in the door. You know, you can't, um, you can't ignore the basics.
[00:23:32] Michael: Yeah, that makes sense. It feels like we're, we're moving towards a world where He's forced to be a little bit more generalist too. Because there are so many new efficiencies coming with design, maybe it's not gonna be enough to just crank out UI all day, you know?
[00:23:47] And, and so like expanding the surface area of what I as a designer, can contribute to the company that I work at. Maybe I'm flexing my product sense and contributing more to strategy and product process at the [00:24:00] company or maybe I am dabbling a little bit more into code and becoming more technical.
[00:24:04] I'm interested to kind of see how the core skill sets that we associate or attribute value to for designers, how those over the next few years, it'll be fun to watch.
[00:24:14] Dan Hollick: Yeah. I think AI is going to push a lot of job roles closer together because it's not just happening to design, you know. It's happening to front end engineering. It's happening to back end engineering.
[00:24:24] It's happening all over the place. So you'll companies will be able to do a lot more with fewer people and they will expect them to have broader ranges of responsibility. Um, so you, you might be sort of forced into learning something that hasn't historically been part of design. and for those of us that have been around for a while, like the role has changed a lot.
[00:24:44] This is just part of what is a really, really young profession. You know, it's still completely in, its nascent. I think that's a word.
[00:24:52] Michael: It is now. it's really. I mean, it it is, it's scary. It's, daunting in many ways, but I also think it is like very exciting. [00:25:00] I'm super stoked too, because it does feel like every time we have these technology cycles that almost kind of reinvent our day to day, it does level the playing field a little bit because there's so much newness that Yeah, on one I could see how it would be intimidating as someone that is like earlier in my career. But at the same time, if I think about, well, maybe I'm gonna be using AI prompts a bunch two years from now in my role. Well the people that have been doing this for 10 years, that's new to them too. And it's new to me.
[00:25:28] And so that is kind of motivating or it's like, yeah, I can figure this out and like if I really put myself to it, In many ways could catch up on the people who have been in this industry for so long because of the amount of change that's taking place.
[00:25:41] Dan Hollick: Yeah. You know, that's actually a great way to think about it.
[00:25:43] I haven't really considered that. Like it is going to the old dogs who can't learn new tricks are probably going to be as affected as the people trying to make it into the industry right there. In some ways, one of them is better crypt than the other. Hadn't thought. .
[00:25:56] Michael: Yeah, I'm wondering how much longer people are gonna be able to say the tools don't matter, basically.[00:26:00]
[00:26:00] Dan Hollick: Yeah. Yeah.
Deep Dives
Get our weekly breakdowns
Insights + resources from top designers 👇
Lauren LoPrete
Director of Design Systems @ Cash App
David Hoang
VP of Marketing and Design @ Replit
Adrien Griveau
Founding Designer @ Linear
James McDonald
Designer @ Clerk
Femke
Design Lead @ Gusto
Join 10K+ designers
HC
HC
HC
HC
hello@dive.club
Ⓒ Dive 2024