← Dive Club 🤿
Dive Club 🤿
Stephen Haney - The 2026 AI Design Field Report (tools, process, and what's working)
00:48:29
Loading summary
Transcript71 lines
- [00:00]
Rid
There's been a heck of a debate around the future of coding and design tools lately, but what's actually happening inside of today's top teams?
- [00:08]
Stephen Haney
I've been talking to designers at Atlassian, at Shopify, Vercel Notion. Like all these companies, what I see these companies actually doing is not necessarily matching up to the. To what you'll read on Twitter.
- [00:19]
Rid
Where's all this headed? And how does the future of our tools shape the role of a designer?
- [00:24]
Stephen Haney
What I saw was actually companies are all pretty much doing the same thing. If you're looking to work at a top company, you should probably start scaling up in a way fits into this world.
- [00:33]
Rid
Welcome to Dive Club. My name is Rid, and this is where designers never stop learning. Today's episode is with Stephen Haney, who's the founder of a new design tool called Paper. And for the last few months, he's done a heck of a lot of research into how today's top teams are actually using AI, everything from tooling to process to prototyping. So he's going to share his findings with us today and how that's impacting his product strategy. For Paper.
- [01:03]
Stephen Haney
It's pretty fun. Have, like, a new version of should designers code? And it's like the AI era version of it. It's a little bit more like should designers ship or should designers, like, build? And as always, the answer is like, yes, if you want to. And the more skills you have, you know, the more powerful you can be. Of course, I really enjoyed it. I thought, you know, a lot of great points on both sides. I think when we started paper. Paper is a design tool. We love design. We started Paper because we love design and it's what we want to work on. So we're maybe a little bit biased towards the craft side of things, you know, and, you know, a lot of things that Kari was saying are very much the same way that I think about how design works and how building things works. But I think that clearly AI is like an amazing tool for especially, like, stateful prototyping, interactive prototyping. I don't know if you've noticed this, but prototyping in Figma is not the best experience in the world. You know, like drawing noodles and, you know, when you have multiple versions of things, it takes a really long time. It's kind of limited in what you can do. And so I think very clearly, to me, like, prompting the explosion of cloud code over the holidays was really cool to see, like, everyone was trying it. So I think, like, lean into that stuff. Especially if you need to make stateful things, you know, things that have state, like when you click something, something else happens and then you, you want to show where the focus goes or, or what pops up or how the data loading state should work. It's amazing, amazing for that stuff. I think very clearly to me also, design and engineering are not the same thing. That was like one of the claims I saw on Twitter and I think I, you know, I posted, I should get. Let me pull up this tweet. This is actually the same thing. So Rayo at one point said it's the same thing. So we put them back together in cursor and I think like a core philosophy that we have is sure, we should all be building, of course, and if you want to do both design and engineering, great, you should. It's great to do both and a lot of the highest performing people do both. But I think that fundamentally the reason design exists as a, as a specialty and the reason engineering exists as a specialty are different and specific. You know, specialization is good. I think design is very much an expansion of problem space. It's exploring the problem space. I think K posted Design as a search and I hadn't thought about it that way, but I think I agree it's what should we do? You got to study prior art, you need to experiment visually. You got to try 10 versions right next to each other. You need to communicate. A big reason that Figma won was how much they helped us show collaboration being important and not sharing. Final, final. Underscore, V2 and Dropbox. An interesting thing is we've actually lost that when you go to local dev and you're using cloud code or using cursor, we're actually now back in local space. It's actually a little more friction to share things again and so talk a little bit more later. So I kind of always have this thought of building projects as kind of a continuum. And so I made this real quick little continuum chart in paper and on one side of this is kind of like a very low fidelity, like we should do something. We have this idea how to make a better product, how to help people more. Here's an idea that we should do and it's going to work. And that's oftentimes a visionary role like a founder, CEO, pm. And then as you proceed through the project through time, you know, you have to answer all these questions of like, how are we going to do this? Why are we doing it? How should it work? You know, what's the flow? And that's traditionally been like more of a product design role. As you define some of those things, then typically you do start getting into building and then you start thinking about, you know, like there's pixel precision and hover animations and that's kind of like, you know, we've seen design engineering become more of a role. As you go through the project, you actually get like more information and more fidelity. So you might start with wireframes and then you have stateless design in Figma and then you start building it and you know, you have an actual prototype you can play with and that has more information about how things click through and flows. And then you really start getting very specific. You're like, the backend is going to use redis instead of the database for these scalability reasons. And in mobile safari at 368 pixels, it's going to work this way. And so it's like really dialed in now. And then of course at the far end you got to keep it up. And then you see you start wearing pagers and stuff. This is a continuum. I think design and engineering are obviously there's lots of mix in the middle and handoff is still a thing that we're dealing with. But when you start to see what is AI helping designers with, designers are going to start wearing pagers, right? I don't think they should. I think it's a different job.
- [05:04]
Rid
Real quick message and then we can jump back into it. Don't be the person with the portfolio that doesn't have a custom domain. With Framer's latest release, you don't have that excuse anymore because they partnered with Hover to provide a seamless flow where you can select free or discounted domains that will automatically be connected to your Framer site after purchase. You heard me right. Framer is offering free custom domains for the first year when you upgrade your site to a yearly plan. So definitely don't miss out on this offer. You can head to Dive Club Framer to claim your domain today. There legitimately might not be a tool that the design industry agrees on more than Mobin. Over 1 million designers from companies like Airbnb, Uber, Headspace all use Maubin for design inspiration. And it makes sense. It's one of the highest ROI investments that you can possibly make as a designer. I use Mobin almost every single day to look at real world examples of how different products handle specific UI patterns and flows. And it's invaluable to my practice and I can't recommend the product enough. So head to Dive Club slash Mobin to check it out today. That's Mobbin. Okay, now onto the episode. I read the designer search and Kari's articles, and I guess I kind of agreed with both sides in different ways. And here's my lens. And you can kind of tell me how you think about it, because I look at this full spectrum that you have up here going all the way from, like, the visionary to the reliability. And sometimes I am operating on that entire spectrum as a designer, and when I do 100%, you better believe I'm not jumping into code. Sometimes I'm just sketching in my book, you know, or a lot of times it's just me typing on a canvas. I really like words as a way to think, so most of my early stage exploration is words and then arrows to connect words. And I create these little word maps and that's my favorite way to work. But a decent percentage, dare I say, like, at least half of the design work I do actually does have a pretty clearly defined problem because it's not Greenfield. In fact, it might just be me operating on top of something that is already shipped. And it's like, hey, we shipped this thing, we learned this thing, let's make it better, or we need to add this thing. I do find myself skipping some of the vector tools and exploration processes because I'm already kind of narrowed in. And I never talk about double diamonds, ever. Kari did. So I feel permission to talk about the double diamond, but I kind of, in reflecting on it was like, you know, I think I actually do a decent amount of my work in the second diamond. Only, like, it's not uncommon for me to jump to the second diamond. And when I do, I don't mind just opening up cloud code, but if I am operating in that first diamond, there is no way that I'm going to start in cloud code. It doesn't make sense, at least for my practice. I'm kind of curious how that resonates and maybe how it meshes up with what you're seeing.
- [07:56]
Stephen Haney
It's funny when. When Kari dropped the double diamond, the paper slack actually lit up. People were, he did the double diamond, it says come out?
- [08:04]
Rid
I did not think it was going to show its face, but it made sense.
- [08:07]
Stephen Haney
You know, I think there's, you know, obviously there's problems with any visual depiction of how projects work. I'm kind of partial to hill charts from, you know, the basecamp group.
- [08:15]
Rid
Basically, they're pretty useful. Basecamp hill chart.
- [08:18]
Stephen Haney
We don't actually use basecamp, but I find shapeup is like, such a great project management tool if you haven't checked it out. It's their. Their book, I guess. It's. It's online. You can check it out, how they do project management, and it's terrific. I kind of agree, and that was almost part of my point in my initial post was AI and Cursor and Cloud code are giving us these new tools for a specific part of design. Basically, my take is any tool that removes constraints, that lets you be more free and explore more rapidly and explore the problem space is good for design. And I think AI is good for interactive prototyping. It's easier to do interactive prototyping, clearly, it's easier to start from your production app, where your production app is, and just ask for a change. That's so much better than drawing pictures of it. I see people taking screenshots of their production app all the time and pasting them in Figma and drawing on top. Clearly, prompting is, like, nicer than that. I was talking to a designer at Shopify who's using cursor quite a bit, and he was saying, like, gosh, I didn't realize, like, when you open new modals, the focus is always going to the wrong place in our app. And now I can show the engineers, like, where it should go, like, very easily. I think stuff like that is great. Like, that's really cool because the designer is the person who cares and can see it and can understand it.
- [09:26]
Rid
What you're describing is ux, but historically, as a product of our tools and capabilities, we haven't included it in the set of deliverables, even though it's so clearly key to the user experience.
- [09:37]
Stephen Haney
Oh, 100% agree. 100% agree. And that's been a tooling limitation, right? Like, the designers always cared and has always probably seen it in prod and tried to, like, write a note or something. So I'm really excited about that, that particular area of AI. At the same time, the hype and the FOMO of the Twitter and the, you know, doing podcasts, like we're doing here, is to say things like, you know, visual tools are dead, we don't need them anymore. Canvas tools are gone. Or engineering and designer did the same thing and so just use cursor. I don't think that's true at all. I think that's, like, excitement about the current moment and the new capabilities we have, which is. Which maybe is fair. We can get into this more later, but our vision for the future is basically, agents are going to be Doing a lot of the work, especially on building. And you're going to have different tools that are kind of like different input methods to the coding agents. So if you want to prompt the agent, use text. If you want to fine tune edit the code, use an ide. If you want to draw a picture for the agent to look at, use a canvas tool. And so I think that you're going to have these different input tools to. It's kind of like a centralized agent probably which is going to look like cloud code at least, you know, next few years, who knows after that. And so that's kind of how we're going to start moving Paper is we're going to build a desktop app so that has local file system access and it'll still have real time multiplayer layer all synced to the cloud.
- [10:49]
Rid
Very cool.
- [10:50]
Stephen Haney
You can do offline files if you want, but then that's a different thing. It'll have built in mcp and the reason for this is imagine you have cursor open, you have paper open, you have a terminal with cloud code, whatever you want to do. And they can all talk to each other and they can all see what's in the other screen. And so you can, if you need to draw something, you can do it in paper and then just tell cloud, hey, can you look at what I just did in paper and do that? I think it's a really powerful workflow. And then if you need to edit the code, you can use your IDE to edit the code that it did, review the code. So I think increasingly IDEs development environments are going to become for code review and in reviewing what the agent did, they're really good at that. But I think we need this tool, this free form expressive drawing tool that has just the right amount of structure, you know, like, like a Figma sketch amount of structure is really good for, for this type of stuff that the agent can talk to and the agent can see. And then it still needs to be able to do multiplayer real time collaboration. All these things that we learned from the Figma era that are really good. So I'm excited about this. This is like what we're building. I think it's become like very clear in the last few weeks even how these workflows are going to work in the future and kind of the battlegrounds between different and you know, everyone's kind of posturing now because I think we can all start to see how it's going to benefit people who are building software. One of the cool things about, you know, Making a tool like paper is. Everyone will talk to me. Everyone wants to get on a call and tell me about what they're doing or to see if paper can help them. And so I've been talking to designers at Atlassian, at Shopify, Vercel Notion, like all these companies, and I kind of like, I've come to you to share what I've learned. It's kind of like a field report because I think there's a ton of hype and FOMO and people saying things on Twitter. And what I see these companies actually doing is not necessarily matching up to what you'll read on Twitter. Right. And I think as a designer, as you think about what should you scale up and how should you invest your skill points and your time? You know, optimizing for the things that these companies are actually finding useful is probably a good idea.
- [12:31]
Rid
Okay, so I want to dig into some of your research then. What are some of the main signals that you've noticed that you've latched onto that have kind of informed some of this strategy that you're talking about?
- [12:41]
Stephen Haney
Again, there's so much stuff happening on Twitter and the hype and the FOMO that I would just wanted to get ground truth. As a product maker, I can't make decisions based off the hype on Twitter because I'll make the wrong thing. It's not real, it's not true. And so I just wanted to talk to, like, these executives at these companies, these designers at these companies that are actually using AI and getting benefit from it. And this is all anonymous. So I'm not going to say any specific company is doing any specific thing. Of course I don't want to do that. But this is kind of my takeaway. And what I saw was actually companies are all pretty much doing the same thing. So I think this is like, if you're looking to work at a top company, you should probably start scaling up in a way that fits into this world. The first big takeaway is that AI usage is being mandated in performance reviews for designers, full stop. 100% of designers need to use a Claude code, a cursor in their work. And I think this is because companies want to encourage exploration. You're used to how you do things and how you've gotten things done in the past. And learning a new tool takes time. And maybe you have to ship something next week and you don't have time to learn something new. And so I think companies are mandating it because they want to remove that friction. That's a Very real thing. That's like brand new. That wasn't happening a year ago at all. And so, you know, that's, that's, that's a world we're in. We talked about this a bit like stateful and interactive prototyping. That's the big unlock that companies are getting. And it's because it hasn't been great in Figma in the past. Figma Sketch are great at design that doesn't have any state. They're not so great for explaining state or focus, you know, or things like this. Hover states. You got to draw three copies of something to explain and then you can't really show animation or transitions. Right. So prompting is great for this. And it's how these companies are using it is they're taking their production app, they're actually forking it pretty universally. What I'm seeing is nobody is pring to prod. Designers at these kind of companies are not pring to prod AI is not. Suddenly people are like coding and building and shipping at these kind of companies. It's no, it's, it's that they've actually created designer copies of their repos for designers to. It's like a designer playground. The reason for that is that there's a lot of problems if you're actually just like trying to design in a code base. There's like, like have this frame about new friction like environment variables and local databases and linting and deploys and they. Sometimes the build fails and like none of that is useful for design. So that's why they're creating these designer playgrounds and these, these forks of the code base.
- [14:50]
Rid
Can I ask a clarifying question here? Because you talked about the AI mandate and you talked about tools like cursor, Claude code, the forks of the code base. When I read forks of the code base, I basically do just tie that to like cursor cloud code. How much are you seeing more of these, like, isol prototyping tools, like make lovable, that kind of a thing? Like, is there a trend that you're noticing between the types of AI exploration? Because, like, it's very different which path you take, but a lot of times they just kind of get looped together in the same conversation.
- [15:22]
Stephen Haney
I'm seeing a lot more cloud code and cursor than lovable Replit V0. I think that the one company I talked to is using Replit. And it was, when I heard it, I was like, oh, wow. Like, that's the first time I've heard that actually replit I think is maybe trying a little bit harder than some of the others to court enterprise and to court bringing your existing design system in. The big difference though, really the big difference between clerks or cloud code, local development, local prompting versus these cloud hosted solutions is when you're local, you're using your actual code base or you're using a fork of your code base. And so that, that starting place that you get, and I keep hearing everyone's using the word starting place when I talk to them, that starting place that you get is your real app. It's your real. It's like you don't have to recreate the screen that you had before because it's already there in your app and you can just ask to change it. Whereas if you use a lovable V0 Replit, whatever, Replit's doing a nice job of like cloning your design into replit components. But you still need to like, it doesn't have your real app in there. So you still need to rebuild screens from scratch. You're kind of, you're starting more from scratch on those flows. And that's not a knock at replit. That's just kind of like what I, how I see it, working people are working on things with like GitHub integrations. We're working on something like this to kind of like pull your design into the tool, which is great too. But that's the big difference of local dev. It's one of the reasons we're making a desktop app is to have, just have access to your repo because I think it just empowers like all new types of flows. So at these kind of style companies. So here's the big disclaimer, right? At startups, designers probably are already coding like already shipping startups or like, you know, seed stage startups are a whole different ballgame at these kind of companies where you get this kind of specialization because the jobs are so big that you need to have, you know, multiple people working on it. They are using local cloud code cursor much more than the cloud hosted stuff. Another big thing is like, it's still handoff. I've seen some claims like handoff is dead, you know, designers can code now. I'm not seeing that at all. These are still specs. They are specs with a lot more information inside of them. And that's a good thing, you know, but, but designers are still sitting down with developers and they're still, here's, here's how it should work. And I, I drew this prototype for you. There's some exceptions to this, of course, but I'm really not seeing much PR into production and I'm not even seeing designers wanting to PR to production. Like when I asked, like, you do you want to? And they're like, yeah, like, maybe it'd be nice to like change a color or change some copy, you know, like minor tweaks. But. But again, as a designer, do you want to start wearing a pager? Like, of course not. Like, that's not your job and you need to be thinking about all the things that are your job. And so PR into production comes with maintenance burdens. It comes with a different type of accountability for making sure that you didn't break something else, you know, And I think maybe over time we'll see that break down, you know, as AI empowers people to do more and more. But this isn't a tooling problem. Once you're deploying something live and you're wearing the pager and you're making sure it stays up, it's just a different job. There's a job friction or specialization there that had nothing to do with tooling. And so I don't think tooling is going to change it. What do you think about that? Does that make sense to you?
- [18:06]
Rid
I mean, I'm biased. I'm biased. I'm literally like the seed stage startup and I'm my own boss, so I can do whatever the hell I want. And I want to build and own a lot of the things. And so like a flow that is typical for me is I will do more of the greenfield exploration on a canvas. It's very traditional handoff with annotations and like engineer will wire something up and it'll look pretty good. But in the past where I would then have, you know, maybe a bunch of GitHub comments or linear tickets of all the little things that like, are not quite right. I don't make any of those anymore. I just make a PR and I fix all of them and then like tighten up whatever we just shipped. And then what it ends up in, like the final state is what I made in code with the disclaimer being like, small team.
- [18:53]
Stephen Haney
Yeah, 100%. I mean, and again, this is like big companies with teams that are specialized. I think.
- [18:57]
Rid
Yeah, Shopify, Atlassian are working differently.
- [19:00]
Stephen Haney
Yeah. I mean, and a paper like, everyone codes, everyone ships people whose title is Designer, they're opening PRs. But they would have done that before AI too. Right. So, like there's.
- [19:10]
Rid
Yeah, I think.
- [19:10]
Stephen Haney
And probably same for you. Right? Like you Were probably already wanting to own that stuff. Pre AI.
- [19:13]
Rid
Right.
- [19:14]
Stephen Haney
That might make some people mad. I think working at a startup is harder than working at a big company. They're harder in different ways, of course. Yeah, yeah, yeah.
- [19:20]
Rid
But like, hot take indeed.
- [19:22]
Stephen Haney
You have to do a lot more, you have to do it a lot more quickly and you, you have to wear more hats and you have to be like more horizontal. And that's a good thing, I think. I. If you like it, I like the challenge of it. And so I encourage people to like lean in and do multiple things. Like. Yeah, do the engineering. Yeah. Do design. You know, like, go ahead, do the reliability. If you, if you want to get into databases, you know, I think the most fun people to follow on Twitter are they blog about stuff. They'll blog about a shader and then they'll blog about like how databases work the next day. You know, don't, don't get locked into thinking you can only do one part of this.
- [19:50]
Rid
This, this piece really granular Question is, I'm interested in this trend that you're seeing where designers have their own forks of the code base to play around with and make a mess with because there's. I find so much value in being able to just start on top of whatever is in production because I have been that person that's been taking screenshots and then whiting things out and making. It's just horrible.
- [20:12]
Stephen Haney
Right?
- [20:12]
Rid
As code has kind of run away with AI, the amount of time that I've spent trying to just like catch up and work with something that feels at least close enough to a source of truth is incredibly annoying. That being said, I'm somewhat technical and the idea of figuring out how to like fork a code base and make my own sandbox, like that kind of goes.
- [20:32]
Stephen Haney
Oh, yeah, yeah.
- [20:33]
Rid
Beyond me. So is it, are you seeing teams that are empowering designers and setting this up for them? Like, is this an intentional top down investment that companies have to make?
- [20:43]
Stephen Haney
Yes, 100%. And it reminds me of how we've all been maintaining two copies of our design system, like one in Figma and one code for many years. And now it's like, well, now we're going to maintain two copies of our app, like the real copy and then the designer copy, and that one might fall out of date. Or like we got to. Somebody's got to maintain it. So 100%. So one of the things I, I was looking at is like, what are the new problems? Because we've solved some stuff for prototyping. But we've also given up some things from the, from the previous era. We moved away from local design for a reason. Right? Like the, the benefits of sharing for design are so huge Collaboration, part of your job is making sure stakeholders are signed off or you know, engineers know what to do. And so having your file in the cloud is really helpful for that and having real time cursors is really helpful for that. When you're prototyping with like a cloud code, if you're forking your, your repo, like you have to set up your local environment, right? And like that's not helpful. We talked about this. Linting is something I keep hearing about. Like people are like, oh I just don't care. It's got a squiggly but like it works like why do I have to fix this thing? And that's like an engineering problem, right? It's for long term maintainability of the code base. It's not useful for prototyping. Sharing is really painful. There's no real time collaboration and companies are building. I don't know if they've talked about this publicly, so I won't say who, but like one of the companies has built this entire like vibe code sharing platform where designers can literally, it's like an FTP server. Like they drag and drop their files from the GitHub repo into this FTP server and then like it deploys a preview for them. So 100% companies are building, tooling around these flows but somebody has to build that, right? Like that's a cost that they're, they're investing in and maintaining.
- [22:07]
Rid
Hey, really quickly let me tell you about the all new Dive Talent network. I've hand assembled over a hundred of the most talented designers and builders that I know so I can recommend them to my favorite companies. So if you're listening to this and you're open to new opportunities, the Talent network is anonymous and super low pressure. It's just an easy way to see what's out there without having to post on social media. So if you're interested in joining or maybe you're looking for your next hire, head to dive club slash talent. The last few design deliverables that I've had have been more in this iteration. Second Diamond. I don't actually really know how to share them. It seems so silly but it's like do I really gotta sit here and wait for this like vercel deployment link and then which of the links in that modal do I actually share? You know, it's like it's just. It's not built for me, you know, it's like, not a flow that is built for me. And I've definitely been feeling that frustration lately.
- [22:59]
Stephen Haney
Exactly. Like, that flow is built for, like, engineering. Right. And so there's just parts of it that are not helpful for design that I think will shave off over time. Then Vercel preview links, by the way, are like the class of engineering preview sharing. Like, that's the best it gets for sharing repo previews, but it just doesn't compare to being in a canvas. Like, I can send you this URL right now. You can hop in here and edit it. Right? Like, it's just a different modality of sharing. So we, we need to find a way to bring this back. Is kind of my takeaway to prototyping flows. One of the things we didn't talk about is people are prompting their own tools in real time, which is really cool. So, like, they will prompt a version picker into the lower left hand corner, like, Claude, please make me a ver because I have two different versions I want my stakeholder to see, and I can make a little control, like live. One person I talked to, they prompted, can you make a markdown file that just lists all the permutations of my state of this dialog as a handoff? So they're like prompting a handoff tool then. So smart. He was like, can you make this markdown file control the state of my app, of my prototype? And so that now he's editing the markdown file to actually change the. Which is funny because at some point you start reinventing your own design tool in the prototype. But it's really cool. You can kind of like real time, load these tools. Whatever you need, need. The flip side of that is everyone's, like, prompting the same tools over and over. And prompting takes time and money. And so people are spending a lot of time making these version pickers, making these. These ways to, like, share that are more inherent to the way we've been doing design in the past. And then we talked about the, you know, maintaining a designer fork of the code base is somebody's got to do it and again, take time away from somebody else. I think there's one more thing here too, which nobody's talking about this. This is kind of my takeaway where a designer at one of these big companies might have just spent four weeks building a prototype that's like, really dialed in and has a lot of information about it. Was that actually faster than the old way? Not sure not sure. And I think there's a lot of excitement and people are able to do these new capabilities and executives are getting rewarded if they get their teams to use AI and so they're forcing their teams to use AI and then everyone's really excited if it's kind of, if it looks like it's working, which is good. And I think because we have all this exploration, we will find new flows that work and are actually advantageous. And something I've noticed and something a couple people have mentioned to me is like, is the software that's being produced actually better, like higher quality, and is it actually being produced quicker? And I don't think that anyone is sure about that yet. I haven't seen that. And I feel that myself too. Like, I use Opus, I use cloud all the time. I'm not sure that I'm actually faster. It's certainly easier. But in an app like Paper, there's so much complexity that you get into that you have to review all the code. You can't just trust it. Right. We're not vibe coding Paper. And so is it actually faster? I don't know. We're not 100% sure about that yet. So these are kind of like, like the new problems. I mean, what's your take on that? Have you sped up, you know, doing these, the new ways that you're working?
- [25:38]
Rid
I have so many takes, I'll give two of them that are parallel to each other. One is, I have definitely fallen into the trap of chasing the shiny thing for the sake of tinkering and exploration, which I do think is a good thing in general. If you figure out the way that you shouldn't do it again, great, you learn something. But I have spent two full days, like full working days on a fully interactive prototype, like in Lovable, when this was like before, I was even using Claude code, for instance, and it was amazing. And it felt like I was shooting electricity out of my fingertips. And when I zoom out to like a two month time span, I wasn't even solving the right problem. So there's like, I feel a lot of Kari's pushback, for instance, was, you know, we're just compressing the process, but we don't want to compress the thinking part just because we can jump right to execution. That type of logic makes a heck of a lot of sense to me and I'm trying to be a little bit more sensitive to it.
- [26:41]
Stephen Haney
I think Tommy yesterday tweeted, I forget I'm going to botch it a little bit, but hold on.
- [26:47]
Rid
Pause. I'm going to get this tweet because I think it's so funny.
- [26:50]
Stephen Haney
I think it's so funny.
- [26:51]
Rid
And we're going to read it. Exactly. He says working with designers is way more fun than working with AI to design, but working with AI to code is way more fun than working with engineers.
- [27:04]
Stephen Haney
I love it. It's just like. Yeah. And you know I'm an engineer, right? I do both, but, like, most of my background's in engineering. So as an engineer, I fully agree. That's probably not going to change. We're working really hard to make it more fun to work with AI and design. You know, that's kind of what paper's working on. But there's something inherent there that's not about tooling, that's more about solving the right problems and how you solve the right problems. The philosophy of building things. That I think is really interesting. Sorry. Point two.
- [27:31]
Rid
Okay. Yeah. This is my second take. That is kind of a little bit separate, but it's something I'm thinking a lot about. And we have so many different tech stacks. Me working On a new B2B startup, my experience is so different than somebody working on like, legacy banking infrastructure. We're both writing a lot of code and solving interface level problems. But, like, it's pretty different, right? That gap is about to increase by an order of magnitude where it will almost feel like a different profession. And I think we're already seeing that just a little bit. My engineer said something to me last night that kind of shook me a little bit. He's like, your last pr. I just played with it. Like I knew there weren't going to be any massive infrastructure level changes. All I did was play with it. It felt good. And then I approved it it and that was it. And it's solely because he trusts Opus way more than the last models. Like that feels like a step change. And it really is only possible because we're doing the typical TypeScript tailwind Supabase next like that kind of thing. And there's such a network effect happening right now around that modern web stack because the models are so good at it, which makes more people want to go to it, which makes the models better at it. I think that Flywheel is about to spin out of control where if you're building in that bubble, the way teams operate, the way software is built will look so incredibly different than what we're used to, because I think it's on its own kind of trajectory. Curious if you have a take on There, that's something I've been thinking a lot about.
- [29:09]
Stephen Haney
I don't remember who tweeted this yesterday too. They were talking about, is this peak library. You know, are we never going to make more libraries? Because the libraries that exist right now are kind of like the network effects are just like locking them in, right? Tailwinds, Radix, maybe Base UI will be able to get in with Radix. I don't know. These libraries are just going to like, lock in. Everyone's building with them. And because everyone's building with them, the AI trains on them more. It gets better at them. It'll be really interesting. I don't know how that's going to shake out. My take is like, yeah, it looks like they're going to lock in and we're not going to probably get new primitives. Some of that is that the primitives are good enough now that they actually are letting AI do this. And so what's really, if you really want to think about it, is like, why did the primitives get good enough just in time for AI to arrive too? It's kind of this, like, convergence of like, you know, tailwind and the, these, these unstyled component libraries. And it worked out pretty well, right? So I do think that's true. And then I think the teams that are working this way are going to look. The tooling is going to look different. The, the job titles, that's really interesting. The job titles are going to look a lot different than if you're working on some legacy app where you can't use these, these tools. I kind of get excited about what, what can we do that's new? And, and, and so I, I like leaning into the new world. I also think that as a tool builder, a lot of people are like, you can't build stuff for old flows because people have solved them. Even if there's like pain in those flows, they feel like they're solved. Enough jobs have been created, people have been hired to do certain jobs and so in a way they're solved. An example of this is maintaining design systems in figma. A big thing that I think is really cool in paper is that we can render real REACT components and so you don't have to like, maintain two copies of your design system. I thought this was going to be like, I thought I'd be in sales calls and people would be like, no way, that's amazing. And everyone's just kind of like, yeah, cool. We got a team that does that though, you know, like, we already have a team that does that. So it's like not really a problem. That's an example of like, you can't fix old flows necessarily. You need to like lean in and build new stuff that is just like a totally new flow that works better. So that's why I kind of spend more of my time thinking about what can we do in this new world.
- [30:54]
Rid
I guess let's talk a little bit about that then. Like where do you point given? Because I can't remember how long it's been since we talked. It's like under a year and yet it feels like a lifetime given how much has changed. And so I'm really interested in hearing how your views on your own product strategy have evolved just based off of the rate of change and these things that you're learning from research.
- [31:14]
Stephen Haney
We started paper, it's only been about 14, 15 months now. And when we did it like what I could see was everyone's in figma. Figma's the dominant player. Some of their technical choices they had to make eight years ago with like using a WebGL canvas are going to start looking constraining in the age of AI because AI is really good at code. It's not really good at like drawings that are a proprietary Figma API. And so I think, you know, you see people struggling a bit with the Figma MCP server and it's like, why isn't it working better? And I think part of that is that the data in Figma just isn't code. It's like they're, you know, it's a made up data format. And at the time they had to do that for performance. And I mean, God, I'm glad they did because they've done so much for the design community. But we saw like, wow, they're going to have some technical constraints. I think they're going, they went public, you know, pretty recently. So they're getting a lot more corporate themselves and a little more enterprise focused. And so we just wanted to come in as like a tool for designers. That's just, we all love design, we're super focused on design. We want to make the tool that we want. I didn't know exactly how, you know, I was like, I know we want to do this. I know figma's going to start looking a little old soon and I don't know exactly how or what or is the next thing yet. And so let's, let's get in the game, let's start building a great tool and like, I'm going to Be talking to people every day. I'm going to learn from it. And yeah, like I said, over the last few months and even the last few weeks, it's really crystallized, like this new flow. I was very anti MCP at first. Yeah, I was like, this is such a hype thing. Like, no one's using it. But I actually think the need for MCP is real. Whether it's MCP or something else. The idea that your tools can see each other, see into each other, you know, Figma is a walled garden. Very much like they lean into that. We want to make paper very open and very like programmable. And everything's an API. Like a frame can be an API if you want to script against it. A frame can be an API if you want your coding agent to script against it, which is going to happen. That's actually what's going to happen. So we're going to build this desktop app and it'll sync to the cloud just like any of our files do. So you'll have the real time multiplayer. Your coding agent, you'll be able to prompt to CLAUDE in the terminal and be like, you know, if I have this selected and I go to Claude in terminal and I'm like, hey, can you just grab this text that I have selected? Like, that's all you're gonna have to say. And it's gonna be able to go into paper and pull it out and use it in your design. And so I see in the future, again I see, like, maybe it's a terminal, maybe it's not, whatever. But that coding agent is gonna kind of be this central orchestration and then you're gonna have these tools that are different input methods to talk to it. And building a canvas is really hard. It's like very hard to make this canvas that does all these things in a, in a great way. And so I think that this is something that's like, like one of the input methods we will have to these AI agents and another one will be an ide and maybe the terminal is currently the other input method to them. I think this is going to be really fun. I think it's going to be so cool to just have your drawing tool to have your IDE to have your agent, and they can all talk to each other and they can all see each other. And if you need to talk to your agent in a drawing where you can alt, drag to clone, you can do that. And if you want to talk to your agent in code, if you want to write it a quick Example, you can do that in your ide. So it's like whatever you need to do in that moment, you'll have the right tool to like talk to your coding agent.
- [34:04]
Rid
And the coding agent in this situation, just so I can be super clear, is that. Are you talking about cloud code or whatever that becomes?
- [34:13]
Stephen Haney
Yeah. So I think right now we're going to use mcp because that lets us kind of whatever agent you're using that can use MCP will be able to talk to Paper. We're also building an agent in Paper. So I'm just going to like, you know, so it'll be like the. Probably replacing the layer tree. If you want to go into agent mode, it'll replace the layer tree because you're not, probably not going to be using your layers as much.
- [34:32]
Rid
Sure.
- [34:32]
Stephen Haney
And then you can prompt a canvas aware agent so that agent's going to be able to see all of the things on your canvas, your colors, any you could paste in a reference design. You'll be able to get context into the agent, like super easily. One of the things that canvas tools are so great for is having a bunch of context in one place. And so I think Paper will also become this context management tool. Maybe you're pasting in videos and GIFs and text and colors and design system stuff. The agent you're prompting can just like reference all of it really easily. So it'll be this communication method for you to get information into the agent. You know, a terminal is not so great for that. Like, I don't know how agents are going to look in terms of like, is it going to be in the terminal for a long time? I'm not sure. But I think making a tool that's like programmable and open and like what however agents themselves shake out, and whichever agent you prefer, you will have this canvas input method to it this way to draw pictures for your. For your agent. Whichever agent you want to use is kind of the vision there. And then I think there's this other layer too of this starting place and that's we're going to add stateful prototyping so into Paper. And because you can bring in your actual repo and your actual code components, you can get that starting place and then do stateful interactive prototyping in an environment that's like multiplayer and like collaborative. And automatically, if you want to just send it to your pm, you can just send them a link and they can come in and look at your prototype. Right. I think that's like trying to combine the Best parts of the new world. And like that previous world, which is.
- [35:52]
Rid
A shift, it's a shift from the last time that we talked because I remember that was like an answer to what you were specifically deprioritizing.
- [35:59]
Stephen Haney
A large part of it is like the core engine is much further along now. Like we have all of these things, editing tools that we didn't have before. You know, you can do like text wrap pretty and if you're using a variable font, we support variable fonts now. There's a bunch of design tool table stakes that we needed to build to make a really great design tool. And this is by the way, stuff that will never exist in a terminal or will never exist in an ide. Right? They're not going to build a variable font. It's very complicated. You need to be a designer to even know how to build this. So we post this build log, you can check it out. Paper dot design buildlog. A big part of it is just like the core engine of Paper is like getting more mature now and so we have less work on the core engine and we have more ability now to start working on AI flows. And part of our strategy was like when we get there it'll be more obvious what to do with AI. And I think that's like, yeah, that's now that worked, that's happening. It's like, oh, don't go too late. We know like we need to move on it now.
- [36:50]
Rid
I guess a part of this that's still a little bit hazy in my mind and I know you don't have all the answers, but I'm kind of just curious to hear you talk about it is if at least for some subset of users or use cases, Paper is this kind of context layer that is powering maybe a separate coding agent. Are we in all worlds racing towards this existence where design kind of does lag behind code as a source of truth? And maybe it's actually less of a prioritization to have this one to one match of what is in production on a canvas. Is that something that we're just going to let go of? Is it solved in other ways? Are you going to be like pulling stuff down from GitHub or are you still you envisioning a world where like, yeah, actually you know, most people aren't going to be just pulling context out and it is going to be more like, you know, quote unquote polished designs that someone else would inherit. Like talk to me a little bit about that relationship because that's like one of the Big question marks. I have, you know, for years I put so much emphasis on keeping Figma up to date and now I'm like, I just gave up, you know, I just gave up.
- [37:53]
Stephen Haney
I don't.
- [37:53]
Rid
It's not even a thing I think about anymore.
- [37:54]
Stephen Haney
Totally, totally. When we were building modules at my previous company, designers really felt, everyone felt like the source of truth of design was in Figma. And I just feel like no one thinks that anymore. Maybe there's still some teams that maintain design systems or whatever but like designs being disposable is like a good thing, you know. My paper, my notes from today's conversation. I'm going to throw this in the trash after, right? I don't need it anymore. But I think also that LLMs, they break down the differences between formats too. And so the ability to bring stuff back where it is, like which tool it's in or what format it's in is going to matter less, less in the future because the AI can translate between them really well, which I think is really good. So it'll allow you to be disposable if you want to be disposable. It'll allow you to bring things back from production and work on them on top of them if you want to work on top of them. I think that like that being really interchangeable like production code versus in your design tool and everything's just like flowing between them is a little bit further out. I think that's on the order of years, you know, where it's like really seamless. Maybe, maybe we can do it faster. I hope so. The coding agent is going to do translation but it's going, you're going to still feel a little bit of like a. There's your canvas with things like colors and then there's your code with things like components that are like stateful. And I think it's that the thing we need to solve is getting the stateful components back into a canvas environment that's like still a little muddy for everybody. So I think we're going to get there though. It's going to feel so much more free flowing to be able to just like take things from prod, get them onto a canvas, edit them, PR them if you want to, get them to an engineer if you want to. Like the breakdown of formats is just going, it's like not going to matter what format you're, your, your thing is in anymore. It's just like what information is contained inside of it and is it useful for the other tool to, to use can you talk to me a little.
- [39:27]
Rid
Bit about the Tailwind partnership? I saw the tweet. I saw what Adam wrote. It was one of those things where it was very clear to me, like, okay, this is a big deal, but I also am not, like, entirely sure what it unlocks. So help designers think a little bit about why that was something that you went after and how it could impact the way that we work.
- [39:45]
Stephen Haney
Well, so LLMs use tailwind like 100% of the time, right back to the network effects, Network effect. Tailwind's great. We use it. There's a lot of advantages to Tailwind. There's a lot of technical benefits to using it too. On top of just like, what it lets you do as a designer or an engineer. We just, I really like them. You know, we're friends, we get along. We have some of the same philosophies. And I think having them involved in paper is going to help make sure that the choices we make are really aligned with how Tailwind works works and how front end engineering works. And the feedback they give us, they get all of our early builds. One thing we're, we're shipping, like this week is SVG editing of colors. Because, like, right now, a big limitation of paper, you can't edit colors in SVGs yet. And so we're going to ship that. They're, they're like, hounding me. Adam's like, where is it? Where is it? Where is it? Right? So, like, just, just having them be a part of, like, our inner circle is really, really helpful. We're discussing various ways of building a Tailwind Aware agent. Like a. Agents that can build using, like, Tailwind as a source of, of design inspiration and kind of like, like an idiomatic, you know, tailwind design agent is one thing we're like, hashing out, but then another big thing is just bringing Tailwind in import and export idiomatic tailwind code. So, like, anything you build in paper is already a react component and you can copy it out as Tailwind and you paste it and get Tailwind classes. This is great. And a lot of times what people are doing with this is they're actually just putting it into an LLM. Like, they take this and then they paste it into Cursor or paste it into Claude. But it's already like in Tailwind and it's. And, you know, so we're going to add like, our theming and our tokens are going to be based on the tailwind ways of doing tokens and theming and things like this, and that's just because, like, why have design and engineering be separate on these things? You know, why have a proprietary Figma token system and then the engineering has like a token system that's just as good. In fact, engineering's token system is better. It's more powerful, probably better. Let's bring that into the design tool, but in a way that's like friendly, you know, for, for everyone to, to work with. That's kind of what we're going after. And I think over time you're just going to see more and more benefits of that, that partnership and just having them in the room with us, helping us do design decisions.
- [41:42]
Rid
What else, what haven't we talked about that's kind of rattling around in your brain based off of you spending probably an inordinate amount of time just dreaming about the future and where this is all going and what your strategy is to navigate these waters.
- [41:55]
Stephen Haney
So we recently had a daughter something like father mode now. So like father Steven's advice to designers, Lean into it, have fun, skill up, like 100% skill up. Find time to go play with these tools, even if you don't need to use them in your job yet they are going to matter. The ability to do interactive prototyping is certainly better than it ever has been before. You need, if the jobs are going to require that, so definitely lean into that. Don't buy into the hype too much. You know, you're probably not left behind. Everyone's exploring. No one has the answers right now. Like I, you know, we're trying to figure this out on the fly for the product we're building. Everyone's trying to figure this out on the fly as a group. Like all of our explorations are going to uncover kind of new ways of working that are really cool. So like just, just be part of that and enjoy it. And then also like, watch out for people selling you stuff. You know, a lot of the fomo, a lot of the people that, that drive the hype cycles, they want you to use their product in particular. I'm sure we probably do some of that too. We want you to use paper, of course, but always keep an eye out on like whenever you do see that FOMO stuff, who's in the replies? Like, are the, are the replies full of high quality craftspeople that have been building great stuff for years? Maybe listen to what that person's saying. Are the replies a bunch of AI bots? And like, you know, people, maybe they're just saying random stuff, you know, maybe you think that one might be more fomo. And so that's kind of how I try to sort of the noise from. From signal. I love the ability to. To do AI prototyping. It's so easy. The powers you get are limited, but what you do get until you hit those limits is just so effortless. And I think that's great for design, that effortlessness to. To produce ideas to explore. That's. That's great for design tooling.
- [43:21]
Rid
So building on top of that, something that I've seen, or at least maybe like a strawman that people create to not play and to not explore with these tools is they point at, like, some of the use cases where it just doesn't make any sense to do AI prototyping. I'm like, you're totally right. Like, we're not taking an old, in my opinion, much more rigid, predictable process and totally replacing it with something new. It's just all of a sudden, a big part of my practice as a designer is kind of at each new release or feature or project, however I'm working, is taking a second to think about what's my process for this initiative, because it might look completely different than the last thing I did versus the last thing I did. And I'm finding so much more diversity in how I'm operating as a designer. And I'm having to put more thought into, like, what's my path for this thing that I'm trying to accomplish, and how is that different than the thing that I did last week and that Delta is much, much, much larger than it was a few years ago, like, night and day. Whereas before, I could have given a very straight answer. When, you know, if you were interviewing me for a role, be like, talk to me a little bit about your design process. I would have had a rehearsed answer that I just kind of run with little deviation. And now you'd ask me that question. I'd be like, shoot, I don't know.
- [44:41]
Stephen Haney
Yeah, well, I think there's two ways to look at that, and one is to see it as a lot of work and kind of like, be a little curmudgeony about it. And like, I know my way and I'm going to do it my way. By the way, there's going to be tons of jobs that do things the way that they've been done forever. There's always those kind of jobs, too. The other way to look at it is like, like, what can we do? Let's explore. Let's have fun. If we find new ways to do Things that are useful, gosh, that's great, you know, and then we can share those with everybody. So I, I, I see it as a very exciting time. And I think where, where people are, you know, where people get into trouble is on either side of the extreme, like, design tools are dead. Everyone's going to be prompting for design. Probably not true. There's a lot we've covered all the reasons why canvas tools are very useful. Paper is still useful, pens are still useful. And then the other side of that is like, AI is very bad at visuals. I, I refuse to use it, you know, for very, whatever reasons you have. And some of those things are true, but, like, this is a new capability that we have. Like, let's explore it. Let's, let's see what works. And very much so, the companies are doing that because I think companies are good at this. They are saying, here's a new tool, let's explore it. And that's where you start to see things like mandated and performance reviews. Just make sure that we're exploring these things fully. And those are the times with the greatest opportunity, times of change. Times where people can make a name for themselves. They can find things that the community really values and they can do new workflows that are really valuable at work too. So, yeah, my advice is more to lean into it, but try not to, like, you know, worry that you're missing out or anything like that. I saw a lot of tweets over the holidays, like, I'm behind somebody. Very not behind was tweeting. I feel more behind than I've ever felt in my life.
- [46:08]
Rid
I know the tweet you're talking about. It was the, it's like the old, like VP of Engineering at Tesla or something.
- [46:16]
Stephen Haney
Oh, Karpathy. Yeah, yeah, exactly. He's like the least behind person in the entire world. His mental models of AI are incredible. He's the only person on Twitter that I have notifications turned on for when he posts.
- [46:29]
Rid
No way. Wow, that's crazy.
- [46:31]
Stephen Haney
Anybody? It's because his understanding, his mental models are just like, incredible for piercing the complexity of AI. And if he's saying he feels behind, everyone feels that. So I think the flip side of that is just to try to find your excitement and your joy in exploration and building stuff. And I loved what I saw over the holidays with people building synthesizers and games. And that's a great way to explore and have fun.
- [46:54]
Rid
I've been sent three different test flights by designers who didn't write, like, handwrite a single line of code. And they built entire mobile apps over the Christmas break. And it's cool, man. You know, it's like, it's cool. Are there all kinds of pros and cons and a lack of nuanced conversation? You bet. But it's undeniably cool. And I'm appreciative of you kind of coming in and honestly, just kind of being an open book. You know, you have a lot of incentives to not share all of this and to come in and say, like, no, no, I did all this research. This is what I learned and this is how I'm acting on. It means a lot.
- [47:28]
Stephen Haney
Yeah, 100%. I mean, we want paper to be, like I said, an open platform, an open tool. And I also want to hear where I'm wrong. So if you, if I said something today that like, you as a listener disagree with, like, shoot me a DM, my DMs are open. I want to hear about how this is evolving too and be a part of it. So, yeah, thanks as always. It's awesome to see you and great to catch up.
- [47:45]
Rid
Before I let you go, I want to take just one minute to 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 my ideas in code. Mobin is how I find design inspiration. Paper is how I design like a creative. And Raycast is my shortcut cut 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 Partners.