Talking about how he wants to describe himself after redesigning his personal site, Morgan resists the popular 'design engineer' label even though he now builds most of his prototypes directly in code with AI agents.
In terms of where to start, I want to just say that there's so many different ways to get value from prototyping. I think when people hear prototyping, they jump immediately to high-fidelity prototyping. And that's definitely not the way that I think about it or approach it. In my earliest days as a designer and front-end dev, like it was the responsive web days. And so we actually had this like library of phones that we needed to test against, test the designs against. And before we would even test or do anything in like actual design fidelity, we had this little wooden phone that you could slot like a piece of paper into. So you could sketch on paper in the form factor that we expected the phone to be. And that was a really good prototype because it would like just contextualize it just enough that people could understand what we were going for. With this project, for months, the prototypes were low fidelity only, like only sketch looking. And it still added a ton of value. So I would like, I think for a lot of teams, even just starting there or just getting your... sort of centralizing your prototyping efforts so that you can start to build on your team's work like as a collective is a huge benefit. So I would probably start there. What's cool about it is that it is 100% custom to your team and your workflow. This is what works for me and collectively, like my team here at Sublime, but your team might look very different. And like your process, as you sort of discover your little tensions, you just work through them. It's a product design problem to solve, you know? So that's been great. I think that's probably how I'd go about it. Yeah,
like you said, it's a product design problem to solve. Like I feel like there's so much weight placed on internal tools as of late, where it kind of felt like a thing that you could, you could punt a little bit, but now it's like, no, no, no. As designers, we kind of are the best equipped people to go find the problems, find the inefficiencies in how we are building and then just figure out, okay, given the fact that I can build almost anything, what would we create here? And it's really interesting to see where you landed. I feel like this in many ways is the blueprint for the types of systems that more teams are going to be using. Let's talk about you then for a second. So one of the other things that you've done in the midst of this window is redesign your personal site too, which I always find is a fun opportunity to kind of reflect on, you know, how do you want to position yourself? Who am I kind of thing? And you had this line earlier about how your day-to-day has changed as much this year as it has in like the last 10 years combined. And so what did that exercise teach you about how you want to position yourself in the years ahead, especially as somebody who you're doing this amazing thing that's creating so much value internally, but it doesn't show up in, you know, the sexy little portfolio or the neat templated case study that you'd expect of different types of work?
It's a good question and one I continue to wrangle with. My own career has been pretty multidisciplinary. I started in tech, as I mentioned, as a front end developer and then I shifted into product design. I sort of fell into this niche of cybersecurity. From then on, for whatever reason, the jobs that kept connecting with me happened to be in that space and I continue to work in that space today. And these days, I think I still want to put the emphasis on like, if we look at my new site, like my headline is Patrick is a designer who builds. That's pretty much it. Like, I don't want to overstate my engineering skill at this point. I'm not trying to reposition myself as an engineer. I don't even want to call myself a design engineer necessarily. I just think that code is the medium that I've been designing for all these years, regardless of how I've been doing it, whether I'm the one writing the code or if I'm designing the mocks in Figma and then someone else is coding it, or if now I'm in some sort of messy middle where I'm just still using code as the medium more than ever. That's kind of how I'm trying to think about it in terms of like designer, engineer, design engineer. I think I'm just a designer, but my medium is code and I want to put it that way. And I just like to build.
As evidenced by all your experiments and everything that I was, I was poking around. It's cool. You know, you have a nice balance between the exactly like this kind of stuff. It's like, that's a fun detail, you know, and it would have been something I'm sure you probably never would have taken the time to work on if you couldn't only rely on like the creativity scaled with Claude or Sol.
I mostly used Claude code on the first iteration of this site. And then as I've continued to work on it, I've mostly been using codecs. But there are things that emerged as a result of this way of working that just would not have happened any other way. So for instance, I do a lot of writing, as you are aware, and I wanted to be able to bring over my articles to my website, but I also didn't really want to have to manage like bringing over feature images for all of them because that's just kind of a pain in the butt. And so in this process of building out the way that I can, you know, show my writing on my website, I ended up just building a tool to do this generative art that would automatically create some kind of feature image for my article. In the past, like there's no way I would have been able to do this or even thought to do it. And you can actually just, because of the way that this is built, like the tool is a part of the code base of my website. And then I built this so that I could get a sense of like what the tool was capable of doing. And then because it's in the site, I can just expose it. So others can try it if they want and, you know, kind of go from there. And that's just kind of like a really interesting workflow where it's like, in order to design. The end thing that I'm aiming at, I needed to design this tool. And then that tool facilitated the work. And I'm noticing that more and more with more designers' workflow.
Yeah. And that being the knee-jerk reaction is becoming so important, right? It's like, I want to get to this end state. What tool? What tool can I build to just accelerate that process or get me further than I would have been able to do otherwise? Like that's kind of the TLDR of this entire episode in a way, which is fun.
