LongCut logo

When Designers Start Shipping Real Code: Emmet Connolly from Intercom

By Hatch Conference

Summary

## Key takeaways - **AI Hype Overwhelms Signal**: AI is this amazing swirl of new technology, but it's also a swirl of a huge amount of hype, making it hard to separate the signal from the noise, especially from outside like Twitter threads. [01:37], [02:17] - **Pivoted to AI Agent Finn**: Intercom changed from a traditional SaaS business to an AI agent first business with Finn, tearing up a decade's worth of process, launching on GPT-4 date, boosting resolution rate from 23% to 70s%. [02:45], [06:29] - **100% Designers Shipped Code**: Set goal for all 30 product designers to ship a code change to production in Q2 using Cursor workshops and rules file; 100% succeeded, with reactions like 'Wow, that was a lot easier than I thought. I have superpowers now.' [12:59], [14:52] - **Vibecoded Production Frontends**: Designer Daria built entire frontend for guidance page using design system components in production-ready code; engineers hooked it to backend, enabling self-determination over quality. [15:59], [16:55] - **Rapid Prototype Iteration Wins**: James vibecoded interactive prototype, ran 30-minute user studies, updated prototype between sessions for tight feedback loops, making incredible progress toward a real feature. [17:01], [17:45] - **Designers Own Full Frontend**: AI tools enable designers to build from vibecoded prototypes to production fixes, converging to own entire frontend while backend stays with engineers, blurring role boundaries. [27:35], [28:06]

Topics Covered

  • AI Demands Existential Pivots
  • S-Curves Reward Early Creativity
  • Designers Ship Production Code
  • Designers Own Full Front Ends

Full Transcript

Hi folks, how you doing? Good to be here. Thank you. Uh I am also going to

here. Thank you. Uh I am also going to start with like a movie reference. Um

working in tech for the last couple of years or at least a couple of years ago reminded me of this like opening scene.

If you haven't seen this movie, you've seen a scene just like it, right? And

maybe it was how you felt yourself a couple of years ago. you were working remotely, you know, doing your normal job, maybe taking it easy, and then

suddenly, uh, a warning signal seemed to flash, like alerting us all to something important and new that was coming. We

weren't sure what it was, but it seemed like it was going to be a big deal, right? Um, and since then, uh, we have

right? Um, and since then, uh, we have spent a lot of time trying to monitor the situation and keep track of what has actually happened since this original

kind of moment of warning. Um, and at times that process over the last couple of years has felt to me like another amazing moment from the history of cinema that I'm going to play for you now.

>> If we have sound.

>> Oh, we need sound.

>> My god. A dozen more of them.

>> Okay, I'm going to play it again. Here

we go.

>> Sir, there are six of them. Bearing 215

range 150.

>> Oh my god. about a dozen more of them.

And a a blip, a big shiny blimp, and it's slowly moving south.

>> Okay, this is the lowbrow version of of Blair's talk from this morning. Um, at

risk of explaining the joke, right? This

is this guy is me and the radar with the snot is like Twitter threads about AI and what's actually happening and what's going to happen next. It has been pretty hard for any of us, I think, to separate

the the signal from the noise. um

especially if you're just kind of trying to observe it from the outside.

AI is this amazing, you know, swirl of new technology, but it's also a swirl of a huge amount of hype. So, in the past couple of years, then I think we've moved out of this opening scene of the

AI movie. Maybe we're into we were

AI movie. Maybe we're into we were talking about threeact structures and stuff like that earlier, right? Um and

getting to the point where perhaps we can try and make some sense of what's actually going on or figure out what the rest of the story might look like. So,

that is what I'm going to try and talk about. Some of the other speakers were

about. Some of the other speakers were like, I'm only going to mention AI. I'm

going to run headlong into the brick wall that is trying to make my whole talk be about AI and try and figure out what we're going to do with it. Um, so I run the design team at Intercom. Uh, and

we really have been speedrunning this whole story of uh of trying to figure a lot of this stuff out. Over the last two years, we have changed our company, changed intercom from like a traditional

SAS business to an AI agent first business with a a brand new product, Finn. To do that, we've had to tear up

Finn. To do that, we've had to tear up kind of a decade's worth of process and ways of working and structure and really start all over again. Take a mature

company and try and really reinvent it.

Um, we've altered how the design team works quite dramatically. So, I'll talk about that. And you know, we've made

about that. And you know, we've made mistakes along the way, but I think uh if I look back, we've gotten a lot right as well. So, this is what I'm going to

as well. So, this is what I'm going to talk about. I'm going to talk about how

talk about. I'm going to talk about how we pivoted from Intercom, this like legacy SAS business to Finn, an AI agent that is now the future of the business, growing incredibly fast for us. Um what

we actually did within the design team in order to try and get ahead of a bunch of the changes and then just some broad thoughts on where I think the big shifts might be going next.

Okay. Yeah, this kind of pivot or journey. It has been a a journey of

journey. It has been a a journey of journeys to be honest with you. It's

been a wild ride and a lot of time. I'm

not going to spend loads of time on the backstory here. If you don't know

backstory here. If you don't know intercom, we were building like a traditional customer support help desk for people to provide customer support.

Um the company is like 14 years old now, about a thousand employees. We have

about 60 people on the design team. Um

but uh then this happened, right? uh

things were going fine, but it quickly became apparent in whenever it was November 2022, that um this was going to be a a key inflection point for the

industry, but certainly for us. And the

reason it was obvious that it was going to be a big deal for us was if we just kind of mapped out the things that our tool is intended to do and compare it with the things that an LLM is really good at, there's like a hell of a lot of

overlap. And some of the things are

overlap. And some of the things are solutions to long-standing product problems that we have uh been battling against for a long time. Right? So I

guess my first observation here is that it makes sense to think about the level of like product market fit or technology product fit um that you might be experiencing and it was high for us you

know so this was not a surface level change. This was like an existential

change. This was like an existential change for our product space. We could

see that so we tried to react really fast to that. um and seize the opportunity. By the way, this is a blog

opportunity. By the way, this is a blog post sent from March, which is about I guess four months after that. Um where

we officially launched Finn, we launched it on the on the same uh part partnered with OpenAI on the GP4 launch date because we had even shipped a couple of small features with their support before

that. Um and it's interesting to see how

that. Um and it's interesting to see how we described it at the time. It was kind of a seems a bit like um naive or whatever like a natural language AI bot, but we were just figuring out what the

first iteration of this was. Kind of a a simple Q&A delivery thing. Um and this is kind of how we were, you know, a map of our mental space at the time. I think

it's fair to say that we were still thinking of intercom as the main thing and Finn as some kind of important thing that was creeping into the picture as a a feature or something like that. Um but

then we just kept going.

So this is kind of hard to see actually now that I see it here, but this is a list of all the features we shipped. And

as we shipped those features gradually over the course of the year after we launched Finn, we increased our key thing which is our resolution rate, the rate at which Finn can actually provide the correct answer to a question. And it

kept creeping up and up from 23 to 51 and this is last year. So this is in the 70s for us now. This is the average resolution rate across all our customers that are using Finn. Um,

we launched the next version of it. We

kind of updated and got a clearer picture and a more modern picture along with the industry of what this was going to be. So now you see us talking about

to be. So now you see us talking about an AI agent. Uh, it's putting its hand up for a lot more tasks. It's um, not just answering questions, but it's actually completing tasks like issuing refunds and updating your backend and so

on. And so we're just getting more and

on. And so we're just getting more and more of a sense of what it is that the product is going to be. And we're

developing more and more a sense that, oh man, this is kind of a big deal. and

it's really taking over more and more of our focus. Um, and still we kept going.

our focus. Um, and still we kept going.

So this is a shot of the year after that and uh each of these is like a screenshot of our change it our change log page you know. So we shipped a huge amount of features in order to continue

to build out Finn and the capabilities of it. Now I show this because this also

of it. Now I show this because this also represented a huge challenge for us.

It's really hard, really hard to maintain quality when you're shipping at a pace like this. And people talked about this earlier as well. You've got

to make a certain amount of tradeoffs.

And I'll return to how to address that uh a little bit later.

But it's gotten us to this point today where uh I think we have a very good foothold in the market. Um we're very competitive. Uh clearly our our kind of

competitive. Uh clearly our our kind of intuition that we had um a couple of years ago that this was going to be a big deal for for our industry has played out and yes this is where this is going.

Finn is it is now the Finn show. It's

taking over the majority of what we're focused on uh and the majority of how we think about the future.

I've left out a whole bunch of changes other changes here because I just simply don't have time for it. But in this time we also like centralized our design team. We changed our whole planning

team. We changed our whole planning cadence from like two two quarters to about two weeks. Um, we got rid of our road map and we switched everything over from pre-planned like feature oriented

road mapaps to work streams which are small working groups who are just working on a kind of thematic thing like a lot of difficult change a lot of it was hard that's like part of the message that I want to go give here but I

suppose as the saying goes if you don't like change you will like irrelevance even less and we were both running away from that irrelevance I think as well as as chasing the vision for what we had uh

uh next so kind of the lesson I take from this company level and product level experience is that like if you're willing to make a decisive strategic call as a company, you can get the whole

company behind it and just really go for it. It's possible to build something

it. It's possible to build something like surprisingly amazing and new and successful in a relatively short amount of time.

Um, so that's kind of the company level story. Uh, what about design? because

story. Uh, what about design? because

we were not just you know we've kind of had many changes to navigate at once. AI

meant a big change for our product and what our product needed to be, but it also for like all teams, right? Uh

represented a pretty big opportunity for how design was going to work. And so we really sat down and tried to think about how we would and you know we were facing a lot of challenges. Uh we needed to

work as efficiently and effectively as we could. Um so that's what I'll talk

we could. Um so that's what I'll talk about next. How we actually evolved and

about next. How we actually evolved and changed how we worked. Okay, before I get into the nitty-gritty details and I really I'm really keen to show practical examples here. I just want to talk about

examples here. I just want to talk about some of the like more theoretical stuff about it. So this this whole um academic

about it. So this this whole um academic kind of area about researching how technology uh evolves over time and technology often uh follows these kind of scurves they're called where at the

start there's a early period and then an explosive kind of growth period and then a tapering off as everything becomes normal. So if you take take smartphones,

normal. So if you take take smartphones, right, they were super exciting. Like

every new iPhone every year was like really a breakthrough thing. It was and now we're at this we're definitely at this tapering off stage, I think, in in phones where each year is some kind of incremental improvement, but like I

don't really I don't even know what version phone I have if I'm honest anymore. Right. And I think this also

anymore. Right. And I think this also highlights some of the stuff that's come up throughout the day here by the way about you know by the time you get to

phase four here. um your the work has to become highly processified and this is where I think a lot of our process work has come from as these markets scale

like tech has scaled over the last 20 or 40 pick your time period uh over the last several decades um you have to build massive teams and many of them who

can do things reliably and repeatedly and that's where the requirement for increasing specialization and increasing like process which is just follow this guide book and these steps and yeah, like Jenny said, you're not going to

invent anything incredible, but you probably won't screw up. You won't go completely off the rails either, right?

Um, the point I want to make here really is we're obviously some I mean, you never know, by the way, when you're on an exponential curve where you are on the exponential curve, but we're somewhere

closer to the start here. And I think that the start of an S-curve is an incredible time to be a designer. an

incredible time to be a designer because there is so much to be figured out.

We're not just trying to put everything through this conveyor belt like process, but we're having to draw on our creativity and our intuition and our taste and all this other good stuff that

everyone else has been talking about up in this stage today. Um, so it's a good time to be a designer, but it's also scary. That's why we're all here trying

scary. That's why we're all here trying to figure it out together. And I think that the very best way to force yourself to do that is to get like closer to the actual technology, closer to the making

of the thing. Here's like one one more analogy before before we get into it.

Um, couple years ago, I wanted to build a playhouse for my kids. I knew nothing about woodwork, but like every like middle-aged um tech uh uh stereotype, I decided, "Yeah, I should get into woodworking. That would be cool." And I

woodworking. That would be cool." And I watched loads of YouTube videos, right?

And it felt like I was learning stuff.

It felt like I was until I got out there and started to like hammer stuff together. I was like, "Oh, my thing

together. I was like, "Oh, my thing looks like a piece of shit." But when I got when I forgot about that and actually enjoyed the process of learning

through doing, I learned a ton more. Um,

and it was fun. It was fun. Uh, and so the first step to becoming like a decent carpenter, which I would not claim to be, is to like learn the grain of your wood or learn the texture of your material. And I think it's exactly the

material. And I think it's exactly the same for us. You got to figure out you got to learn through doing what these systems are capable of.

Okay. So in that spirit in intercom uh we set a goal for ourselves for the product design team. There's about 30 designers in this group. Um and I asked all the product designers to ship a code

change in Q2 to ship a pull request like ship code to production. Um a change to the intercom app or Finn. Um and in fact the goal to be a bit more nuanced was simply that everybody tries to ship

code. Everyone makes the attempt. Uh I

code. Everyone makes the attempt. Uh I

had no idea if it was a realistic goal to achieve or not. But in attempting to do it, we would figure out the boundaries, the new boundaries, the much broader boundaries of our roles much

faster, right? And if we fig find out

faster, right? And if we fig find out that it's super tight and close to what we're doing, that's okay. Really far

away, that's okay, too. And once you have a clear picture of that boundary, you can start to like make little incursions across it as well. Um so I was thinking maybe two or three people will manage it, but we'll learn a lot

along the way. How do we do it? I get

this question a lot. We just set up some simple workshops. We helped everyone get

simple workshops. We helped everyone get like it took about two hours uh for everyone to get their dev environment set up. I'm looking super puzzled here

set up. I'm looking super puzzled here about mine. Josh is a bit depressed, but

about mine. Josh is a bit depressed, but we got them working in the end. Um we uh we also did some vibe coding stuff workshops together or hackathons just to kind of like get everyone on the same

page and feeling like it was okay to just just make stuff and share it. Um,

and then we pushed deeper into code and actually trying to ship stuff. Um, this

was another thing that helped a lot.

Ellie, one of our designers, put together a cursor rules file which basically because we were using cursor to to um, help us ship this code. Um,

and it kind of built these non-destructive guardrails. It told

non-destructive guardrails. It told Cursor to not wander off into the back end and do stuff uh, there. So that gave us a lot more confidence of just um, making changes. And lo and behold, 100%

making changes. And lo and behold, 100% of the designers on the team with very little like pushing or or anything from me shipped code to production in Q2. And

by far I think that the most um common reaction was like, "Wow, that was a lot easier than I thought." And I kind of feel like I have superpowers now.

Um what kind of stuff do people ship? Some

of it was super basic. Fix a typo or a little CSS change. Most of them were stuff like this. Right. On the left, we had this kind of like janky reordering thing where they overlapped and so on.

And on the right, like a designer just went in and talked to cursor and fixed the thing and eyeballed the code and sent it for a code review. And this is like the better version that's in production now. And so, in a way, this

production now. And so, in a way, this is like part of a big part of our answer to the quality issue that I alluded to earlier. When you're moving really fast,

earlier. When you're moving really fast, you get get caught in this really frustrating cycle of like we're shipping fast, corners get cut, you log a bug, you redline everything, you try and get it fixed, it doesn't get fixed the right

way, you're begging, it's a P4, blah blah blah. And so this is simple enough,

blah blah. And so this is simple enough, I suppose, but it represents for me a pretty big deal because it's a path to self-determination over quality for designers. It means

that we can take matters into our own hands and have actual much greater control over the um over the quality of the product. Um

the product. Um the other thing that surprised me was uh a few designers actually went much further. So this is something that one

further. So this is something that one of our designers Daria built and Daria didn't like you can see there's like an old guidance page and she didn't like the design of it and she had kind of tried to advocate for changing it and

just had never gotten it um uh prioritized. she had shown mock-ups of a

prioritized. she had shown mock-ups of a nicer version that she thought we should have and then she said I'm just going to try and build it and she did and uh she you know Dario will be more on the

technical side I suppose for our designers but I'm just showing this as a like real life example I don't think this is an in super incredible example of design but more what it represents

which is a designer designed and built this entire front end using our design system in real like real components and real productionready code and got to this stage and then she went to the

engineering team and they're like, "Oh yeah, we can hook that into the back end. We can make that work." Right? So

end. We can make that work." Right? So

this is a pretty big leap forward for what designers are capable of actually um pushing for themselves. I think here is another just real life example. This

is James, one of our designers. This is

not a a this was not something that shipped to code. This was actually a vibecoded prototype that made to look like the real product. But James' uh approach here was really interesting as well. So he vibecoded this like pretty

well. So he vibecoded this like pretty robust interactive prototype of a new idea he had, right? And then he went and he user tested it. I believe using user testing.com. But his approach was do a

testing.com. But his approach was do a 30-inut user study, talk to them about observe what he observed, right? Hang

up, go update his prototype, 30 minutes later go with an updated prototype into the next session, test that, rinse and repeat. Like super short, tight feedback

repeat. Like super short, tight feedback loops there. You could you could

loops there. You could you could possibly criticize that and say like, "Oh, it's not statistically valid and so on." It doesn't matter. James like made

on." It doesn't matter. James like made incredible progress towards an actual um feature that's now, I think, going to work really well. Um, and I think we have to allow ourselves that permission.

Again, it's the process thing to throw out some of our old ways of working or disregard them as we as we figure out these new ones. Um, it's not just product design, by the way. This is from our creative studio, which is our brand

design team. They're starting to like

design team. They're starting to like build tools. This was built with Claude

build tools. This was built with Claude um uh Claude desktop. Um and he just said, "Hey, I'd like you to build me a tool that allows me to, you know, uh uh play with all the parameters of stuff

like this." And they're using this to

like this." And they're using this to create like assets for a website. Um

another brand designer built this cool interactive logo for Pioneer, which is our upcoming like summit event. Um and I think this is so again same way, right?

Built a tool to do it. And this is cool because we would never have created design output like that had we been restricted to the previous tools that we had. So I just look at this and I'm like

had. So I just look at this and I'm like the pallet that we have available to us is getting bigger. Um and even the creative possibilities of what we can create are getting broader and that's

cool to see. I think this is one last example. This is intercom.design, our

example. This is intercom.design, our

website that a couple of our designers just decided to create and we put it online just to feature some of the stuff that we've done. um they just vibecoded it and we put it online. And I the thing

that I really like about this is there's a playfulness to it and a playfulness to um the experimentation that the designers were working on here as well, you know. Um there there's a whole bunch

you know. Um there there's a whole bunch of things I find actually kind of non-intuitive about like the code generation stuff. I think uh you think

generation stuff. I think uh you think it's for engineers and it might be but I think the jury is still out as to precisely how much more efficient the code generation tools make engineers. I

think it does but we'll see. I think it undoubtedly changes the landscape for designers who can now like express themselves in a ton of new ways that were just not available to us before. As

I said, the pallet has just gotten like a lot bigger of of what we can do. So

none of these on their own are like particularly mindblowing, but I think if you take them together, you can squint and you can see, oh wow, yeah, the traditional product design role can

really expand quite rapidly if we if we push it out here. Um, and at least that's what we've been seeing on the team at at Intercom.

Okay, so to kind of finish up, uh, let me talk about what I think this might all mean for design more generally.

Okay, I think we're at the beginning of a whole new era of interface design. I I

kind of feel like there's a remarkable parallel between these two interfaces.

Not only because they're like, you know, ostensibly very simple input boxes that hide this whole new thing, but I think they both represent kind of a jumping off point or where we can go from here.

I actually worked at Google when Google uh looked like this and and the amount of um interface innovation that happened in the period of time after this was

amazing and part of it was designled but part of it was like design and technology. Things like Ajax allowed new

technology. Things like Ajax allowed new experiences to emerge and if you understood that you could design those new experiences and so there's this interplay between the technology and the

design that I think is important. Um, I

think it's funny and interesting and kind of cool to look at what are to me the most like uh exciting and interesting products and interfaces actually of the last uh year or so,

which are these like command line tools.

It's kind of cool to compare. I I agree with what someone said earlier by the way. You should play with a few of these

way. You should play with a few of these and figure out what their personality is. Like I've played with all of these

is. Like I've played with all of these and they also have like even slightly different takes on this terminal like UI. um uh which I think is fun to see.

UI. um uh which I think is fun to see.

Um but what's most interesting is to play with them and realize how cool and fun and nerdy they are, but also how limited they are and start to just allow your mind to drift a little bit and try

and imagine where they might go from here. Um, and to me, I don't know if

here. Um, and to me, I don't know if this is controversial to say, like this as a user interface, uh, Launchpad is a lot more interesting than like liquid

glass or the conversations around corner radiuses and things like that. Um,

okay. I'm trying to heed my own advice and um, learn the grain of the material myself. This is a game I made uh called

myself. This is a game I made uh called 2027 Race to AGI. You play the CEO of a frontier lab and your job is to make a series of moral decisions uh on the

journey to trying to achieve uh safe AGI. Spoiler, it's really really hard to

AGI. Spoiler, it's really really hard to beat the game. Um you're going to you're going to fail most of the time. Uh I, by the way, I use Claude code. I'm like

ride or die on Claude Code at this stage. I think I used Claude also to

stage. I think I used Claude also to help me write some code for Strudel, which is a live coding music platform. I

do a bunch of music stuff as well. Um,

and this is just super interesting. If

you keep watching the video, I'll I'll let it play for a while. Um, there's

this real interplay between the code and when when you live coding is you update the code live and it plays music. So, as

you're editing the code, the music that that is being produced changes. Also,

it's got these cool visualizations in the back that I'm really really keen on.

Uh, I tried to build a musical instrument, uh, like a a gestural musical instrument, but then I got totally sidetracked into just the gestural UI and all the different like effects and affordances of that. And so

the lesson there is like just try and build something and it doesn't matter.

Just follow your interests and you might end up somewhere like more interesting than what you originally had in mind.

Um, and with my video game obsessed 11-year-old son, we have been building some like video games, just fun little things to work on together. Um, again,

the code done with Cloud, the backgrounds with Midjourney, sprite packs like this can be DDA was talking about sprites this morning. You could

like Nano Banana, which is the Google thing, can create like really good sprite sheets for for games and stuff like this. So, um, yeah, all along I

like this. So, um, yeah, all along I have been having a lot of fun. This is

fun stuff. It's like cool. And the thing that I would really say is like it's way too early to try and start figuring out how to like apply this to your work. I

mean you can apply it to your work but if you just want to explore like follow your imagination or your curiosity and so on. Um and and what's most important

so on. Um and and what's most important I think is that like I have learned a lot by just fooling around with this stuff and certainly a lot more than

gazing into the snot covered abyss that is Twitter and people telling you what's actually happening. Um it's interesting

actually happening. Um it's interesting if you go to a conference and two people show independently pretty much the exact same slide. I think it means something

same slide. I think it means something folks. Uh Jenny showed this slide,

folks. Uh Jenny showed this slide, right? Uh and uh what does it represent?

right? Uh and uh what does it represent?

Why are we doing because I think uh you know we have a pretty big opportunity as designers. Our roles are quite adjacent

designers. Our roles are quite adjacent probably more adjacent to these other two partner roles I would say um that than they are to each other. And these

tools, as I said, give us like superpowers to move into these other areas and really start to blur the boundaries between the roles. And so,

like, I would even take it further than stepping back from specialists to generalists. I think everyone needs to

generalists. I think everyone needs to be a generalist at the start of an S-curve and even into like generalists beyond design if you can. And um if it makes you feel any better, it's

happening the other direction, right?

Okay. So, this is other disciplines are going to deploy bleed into design as well. This is a job posting for OpenAI

well. This is a job posting for OpenAI for a new role called a forward deployed engineer. Intercom has this as well,

engineer. Intercom has this as well, right? Forward deployed engineers.

right? Forward deployed engineers.

Basically, it's still really hard to get an AI agent working on your own. You

need someone to work with the business, help them get it set up, and not shoot themselves in the foot too bad, right?

Um, but if you look at the bit I've highlighted down here about the role, as a forward deployed engineer, you'll embed with customers, understand their domain, co-develop solutions to tackle real problems in often undefined

evolving problem spaces. I'm like,

that's a pretty good description of a designer, guys. So, the the the the

designer, guys. So, the the the the roles are blurring from the other direction also, right?

What might this mean? This is a bit of a hot take, right? But what might it mean?

Okay, I'm going to try and explain this.

So, we're seeing what designers can do change and evolve in a couple of different ways. First of all, take like

different ways. First of all, take like what you might call solution design, which is how should we solve this problem? What should the product even be

problem? What should the product even be or what should it look like? And we have like now the ability to create these throwaway proof of concept vibecoded prototypes. That's amazing. We designers

prototypes. That's amazing. We designers

in the um intercom team are uh influencing strategy and influencing what we build a lot more now that we

have interactive compelling um uh prototypes that use real or mocked data.

Right? It's just so much more compelling than a static, you know, let me talk you through my 50 artboard Figma file and try and tell you like what my idea is, right? And similar to the example that I

right? And similar to the example that I showed you where um Daria built like a whole screen herself, we're actually seeing designers who are building UIs with components from our design system

and starting to hand over not like a redline mockup of a picture of what you want and then expecting someone to rebuild it for you, but in fact um the start of the real thing that will

actually get shipped to production. Now

take it from the other side where you've got production code maybe some of it is like buggy and you're looking to fix the quality and we've had ways you know and tools to try and make that better. I

think now using cursor uh to provide that QA and polish and fix what's in production and tweak the finer details is also a new power that designers have.

Now think about what happens the and by the way it's not stopping right so like uh what we can do at each of these sides is is uh increasing and I think if these

things keep moving closer together they'll converge at a point where designers may be or will be responsible for building and owning the entire front

end right so instead of handing specs off to engineers and asking them to build them designers will build the front end I think that

front end backend is a much like more natural line of separation uh between design and engineering than what we have today which is even hard to like summarize it and painful and messy and

and and so on. Um so this is interesting. This is a big opportunity

interesting. This is a big opportunity for design I think if we if we want to take it here are other ways of thinking about it. These are the three main kind

about it. These are the three main kind of pillars that we're thinking about in intercom of how to actually use AI in our work. So the first is that vision

our work. So the first is that vision setting thing like way more compelling prototypes vibecoded ideas that um bring uh uh ideas and allow us to explore them

much more quickly and iterate through those ideas much more quickly. Um, it's

allowed us to be much more efficient and be much more of a shipping machine within the traditional, if you want to call it, design, engineering, collaboration process. And not fully

collaboration process. And not fully there yet, but it it it has us on this path to potentially like owning the front end uh from conception all the way

through to the finest little details.

This is a long quote, so apologies. I

won't I won't read the whole thing, but the gist of it here is to be free to create, you have to let go of the strategies that have worked for you in the past. Um, and and an important thing

the past. Um, and and an important thing is that can be scary, but when you let go, it will still be there for you.

You'll still have all those skills and tools that you had. You just get new ones in addition. Um, but I really think you need to not severize, but allow yourself to leave some of those things

behind. uh if you want to walk into some

behind. uh if you want to walk into some of the new possibilities that are ahead like design has always been about exploring the adjacent possible or at least for me that's what it has always been about. It hasn't been about

been about. It hasn't been about tweaking the finer details or micro optimizing everything. It's pushing the

optimizing everything. It's pushing the boundaries of new things. Um and I think uh AI for that reason can be really really great for design and designers. I

really believe that if we allow it to be. Okay, I'm almost finished. There are

be. Okay, I'm almost finished. There are

lots of ways to think about AI. Maybe

you're like the person on the left here.

You are sitting back thoughtfully pondering the implications of what this all might mean. Maybe you're leaning forward like you're aruck. You're a

gape. You can't believe what you're seeing. You're astonished at what you're

seeing. You're astonished at what you're witnessing. Uh maybe you're like arms

witnessing. Uh maybe you're like arms crossed. You're skeptical. Maybe even a

crossed. You're skeptical. Maybe even a little bit hostile. Or maybe the whole thing just makes you nailbitingly nervous about the future of what's going to come next. I think what you should

not be is the guy with his head in his hands here. This is Gary Kasparov uh

hands here. This is Gary Kasparov uh back in 1997. He was the world chess grandmaster I think they call it. Uh and

he had just been defeated by Deep Blue.

And a lot of people say that this is like the maybe opening scene of the AI story that we're all living through right now. And those opening scenes,

right now. And those opening scenes, they're designed to hook you. They're

designed to create an emotional reaction. And I think a lot of designers

reaction. And I think a lot of designers have been having this emotional reaction or confusion um uh in terms of how to

respond to AI thus far. Um but if we remember that design's function is not to maintain the old, it is to invent something new. I think we're getting

something new. I think we're getting further past this opening scene now. And

we're at the point where you can actually choose your character. You can

decide how you want to exist within this movie and what role you want to play.

Um, and I think there's a a great big opportunity for a lot of us. That is

Yeah, that's it. That's me.

[Applause]

Loading...

Loading video analysis...