The Digital Workflow is Obsolete: How to Survive the End of the Canvas - Robin Cannon

In this talk, the speaker Robin, who has extensive experience in design systems, discusses the transformative impact of AI on digital delivery workflows, particularly in front-end development. He highlights the traditional loop of design file to code and back, which is becoming obsolete due to AI's capability to generate vast quantities of components. Robin emphasizes the need for teams to document their unique knowledge and rules surrounding component design, as much of this valuable context often resides only in individual team members' heads. He argues for the importance of creating a unified design system contract that integrates multiple sources, allowing AI to generate correct outputs rather than plausible but incorrect ones. By establishing stronger context validation systems within CI/CD pipelines, teams can enhance product quality in the AI era.

[music] >> I'm Robin, uh VP of product at a company called Knapsack. My background is in the design system space for about the last 10 or 12 years. I started and led the Carbon Design System at IBM and then moved over to JP Morgan and built out the Salt Design System, which is the design system for the corporate investment bank. What I'm really looking at now is

how in particular AI is changing the whole kind of digital delivery workflow, particularly with the focus to front-end delivery and presentation layer delivery. Because I think that that whole workflow that really has been 30 or 40 years is becoming obsolete. And I think that any developer is probably fairly used to this kind of loop that we've seen before. You know, a design file lands. Most of the

time now it's a Figma design file. Um and you build to that specification. Um and then you have a review. You have code review, you have a design review. And then you deliver it. And then somebody files some bugs. And then you go back and you see the updated design file and then you fix it again. And that loop continues. But I think that loop is ending.

Um and really because that loop is ending, it's going to change what we mean when we talk about the idea of your code. So, I know as a IBM Carbon, uh we were based in Austin, Texas and the main IBM design studio. And the Carbon team was 22 people. And all of the walls in the Carbon Design System studio were a And we had right next to

our team space this that was up days since the last nested component incident. and it was almost always sitting at zero. Someone at some point had drawn a little accordion icon in the corner because one of the most common things that was asked is, "Hey, how does the accordion nest inside a button?" Um but we also had, "How do we put this form inside a table cell?"

Uh or how do we wrap this drop down in a tooltip? Um and they're all whole taxonomy of different crimes against components and against component architecture. But here's the thing, all of those components could pass tests. You know, they could pass automated tests and fail every single human test. Um and there were constraints that made this not happen. But where did they live? Cuz they didn't live

in a readme Um and they didn't necessarily even live in the component documentation because we never thought to write down, "Don't put an accordion inside a button." And if we try to write that down in the design system documentation site, that was never going to work. So if it's not there, where is it? It's probably somewhere in a Slack thread from 2018 or it's inside uh senior

engineer's head or it's an email. And honestly, this whiteboard is kind of the reason why I'm standing here and why I've kind of crafted this this talk. The way things are changing, I think it's not about us writing more code. In fact, I think a lot of us are worried about being able to write any code because AI is going to be writing it all. But I

think what's going to be valuable and what's incredibly valuable for us is differently written code. Um we know the QA pipeline. You know, the QA pipeline was built really to be focused on a world where humans were reviewing stuff that other humans had made. added some automation pieces to try and assist with that and we have linting and we have type checking and we have tests and

we had checked the renders. We have visual review. And those are things that we can do and which work when the work is finite. When someone sits down to write it and when another person sits down to look at but we're talking about now an era of AI generation. And when we get to the point of AI generation, then it's not as finite as it was before.

Um you can look at an AI and produce, you know, a thousand components or 150-page layouts before lunchtime. All of them which pass lint tests and all of them which pass the type checks and all of them that render correctly and don't pass the tests because even if they're wrong, that wrongness isn't in the syntax. It's in the intent. Um and this is even more dangerous than

them just being wrong because AI is very good at making things plausible. And the problem with something that's plausible but wrong, that passes tests is that it gets shipped. So, how are we going to QA that? We know that an architectural drawing, a blueprint, is not the same as the actual building. Uh and we know, or hopefully most people know, except people who live primarily in Figma,

that a Figma file is not the entirety of a design system. But neither is a Storybook file. That's not the entirety of the design system. Um but you're carrying a lot of that. You're carrying a lot of that additional knowledge in your head, but that's not a contract. And I think every team, every team certainly that I've ever worked on, I'm assuming I'm assuming the same for

most of us, every team has these things like the senior engineer knows that why that modal pattern is never used anymore. Um again, there's that email from a few years ago that talks about the exception for what we do in that particular case. And we get a pull request that if the right person is around, that pull request gets approved in 10 minutes. And if that person

is on vacation, then that pull request has 3 days of discussion before it gets in. And as a team, we have things where as a team, there's stuff we just know. And the only time we don't realize that not everybody knows that is if somebody new joins the team, and we have to tell them. But now, AI doesn't know that. And AI is going to go much,

much faster at generating a component, and suddenly nobody knows. So you've been carrying the spec, the additional pieces of spec, this context, and that's a bug. But it's also a bug that we can solve, because we just haven't written this down yet. And I know what you're going to say. Okay, we have Everybody's tried writing everything down. We've always written everything down. We've We've wikis that are

huge. We built a wiki, we wrote ADRs, we wrote um product documents. There's a million Confluence pages. We've written everything down, and it all rotted. Uh and that's very true. It did. And what we were writing there, I've seen happen at IBM, at JP Morgan. You can imagine at companies that size, the thousands and thousands of Confluence about how to use things, about component guidelines, about implementation.

15, 20 different versions, nobody knows which one's the right one. And then, a year later, 25% of those things match reality. They still exist as artifacts. And if you don't have the broader context, then you don't know which artifact is the right one to reference. And the other ones are ghosts. They're confidently incorrect. They're never updated. They're misleading. So, the specifics drift, and the edge cases drift.

And the moment that somebody ships something without updating your documentation, then you're out of date. But, the principles that you have, the principles how you design and build, those do persist. Those are things that persist. So, that's things like a broader stance on accessibility, how we strive for universal design, what our principles are about how we architect schemas, why are there constraints about never nesting modals. And

those are the kind of thing that AI does need to be able to generate something that's correct instead of something that's just plausible. And we know now, we've got all these fun MCPs, and we start to plug these things in. And with Here's what happens if you point AI at some individual sources. You start to point it to the figure you've got a Figma MCP hooked up

and you've got the Storybook MCP hooked up and they don't necessarily agree all the Um and both are partially right probably and neither of them is authoritative. An AI doesn't know. But those single sources are genuinely useful. But because it only knows what it knows, they're not going to flag conflicts. They're always going to have some sense of disagreement. And because AI doesn't know how to resolve

that disagreement, it's just going to pick one and it's going to pick one at random and at speed and then it's going to do that 100 times before anybody has time to notice it. And that's with two sources and we're all really working with four, six, eight, 10, 12 sources that go into these things. Your Figma, your Storybook, your GitHub, your docs, your brand guidelines, your existing

site, your tokens file. And they're all in there and the AI's letting them all fight out like Thunderdome. And when it makes decisions, it's not making decisions for the broad product. It's making decisions for this little bit and this little bit and this little bit and they aren't necessarily the same. It's picking a winner every time it generates. So if we keep pointing at AI at all

these individual sources, that's not going to resolve our problem. That's not going to resolve our conflict. That's going to compound our conflict. And we know what the kind of contract we're looking for is. You know, it's the same as the promise of an API. And the idea there is that an API is genuinely a promise, a contract. And it's something that you don't ship a breaking change

to without some kind of migration path. And you version it and you document it and it's a boundary that everybody else is relying on as well. And a design system contract is that same idea, but it's applied to the presentation layer. And like I said, I've been in design systems for a very long time. When I talk about design systems, I'm talking about something much broader than

just a component library. I'm talking really about this sense of a broader context of how you apply product, how you want to deliver your brand to the world. And yes, that includes component libraries and pattern libraries and tokens and layout principles, but it's accessibility stance, the actual marketing brand guidelines that they give you, how you approach authentication both from an experiential perspective and from an implementation perspective.

Kind of what means correct or right for your And we take multiple sources in, but what we want to have is one contract that comes out. So an aggregation and orchestration where we say, "Okay, here are these conflicts. And here's how we're addressing them." And that might be going through those conflicts one by one. Or it might be saying that Figma is the canonical source rather than

Storybook or Storybook is the canonical source rather than Figma and ranking them so that if they disagree, the AI knows how to pick that and how to validate. So when Figma says 16 pixels and Storybook says 24 pixels, the cont- context layer decides, not the AI. It's validating before things get generated. And this is what I do at Knapsack. You know, we have a design system schema.

And we ingest multiple sources and normalize them into that kind of unified structure so that humans can consume it and AI developers can consume it. And I'm not saying that as a pitch, but it's just that I think that's broadly the kind of architecture that this talk is about and it's running. And teams that own this kind of layer are going to own that presentation layer quality

in the AI era. It's not designers and it's not product managers. It's the people who are closest to the implementation who hold a lot of that context more than anybody else. And so here's a couple of things that we can do about that. Now, you're probably already doing this to some extent. If you're already doing this naming props by intent and documenting your calendar allowed states, then

that's good practice. Um you maybe learned it already building a component library or architecting an It's the same kind of instinct. But if we look at variant equals blue and size is large, that's appearance and the moment your brand changes, then every generated component that AI builds is going to be wrong. But if we look at the other side, intent is primary and emphasis is high. Now

we're talking about meaning. And the brand can change and the contract still holds. But what this does is it changes the way that design works and it certainly changes the way that canvas as an abstraction works. Because now that is not something that you look at and build from. It's an input that AI can use to understand the intent. So the Figma files are source. It's not

the contract itself. And that means that we can change the source really, really easily and the contract remains and the AI generation can remain. And so if the naming doesn't tell a machine what the component's for, then AI is going to guess. And as we mentioned earlier, AI is going to guess very plausibly. This I think is is probably the biggest single thing for me and it's

something that you can do this week. You can something you can do this afternoon. If you just open up a markdown file or notion document or wherever your kind of team lives in its work and start writing down some of the things that your team just knows. And that's going to be things like why don't we use red here? And why do we never use that modal

pattern anymore even though it's written down? And why do authentication flows bypass our usual patterns? Why does that data table never get put in a card? Why, and this is some of these might be documented elsewhere, why you never put a destruction at destructive action behind a single click? Every team has 20, 30, 100 of these And they live in somebody's head. But that means nobody can

find them. And every single one of those invisible rules is exactly where AI is going to generate something plausible and wrong. And it's not because AI is bad at all. It's just because AI is needs to be told what to dish out. And the what's great about this is we can automate it all. We can plug the whole thing into our pipeline. You know, we already run

linters and we already run type checkers. We run the test. So this isn't a new pipeline and we which means that we can integrate this context validation into all our CI/CD processes. Does the generated output honor the contract that we've created? So a component gets generated with an accordion nested inside a button like happened at IBM. And it passes the lint and it passes the type check.

And it passes the test. But now it gets caught. It gets caught by the context validator because the contract says the accordion is a standalone pattern. And it's never nested. And that means that if we go back to that carbon whiteboard, now we've automated some of that implementation. And I think for me, the team that ships this first inside your organization is going to own a big

part of that quality conversation for the next 5 years because you're just going to keep getting better. This actually touches on what Vanya was saying earlier. When you talk about the the failures feed back. And when you fix those failures as tests, you're fixing the contracts. And the contracts get sharper and your loop compounds. And so all of that judgment that used to exist in like in-person

code review, whether it was formal or informal, or in those slack threads, or in emails, or conversations with the senior engineer, all of that judgment now needs to exist and it now needs to travel as infrastructure. And that's what I mean that the code that isn't the code is what matters the most. Because the only people who can write that code are the developers who are in

this room. Thank you. >> [music]