Aligning Patterns Across Design and Development

♪♪ ♪♪ I'm Jake. I'm a developer advocate at Figma. For those that don't know, Figma is a platform for teams to design and build products together, built on the web. Pretty dope product if I say so myself. Before this, I was a software engineer for 12 years. I most recently was working on a React and TypeScript component library for a restaurant reservation platform. But enough of that. We only have so much time. So I'm going to talk about aligning patterns between design and development.

So this cube here represents a pattern. This might be a token, a component, a page. It's a concept that is shared across both design and development as we think about how we're going to build this thing together and make it a reality. Design is often looking at the desired effect of this pattern. How can this be presented in a way that's effective and compelling? And of course, as we know, as engineers, right, we're thinking about that surface, but we're also thinking about the implied kind of inferred construction, the stuff underneath the hood, behind the scenes. And so as collaborators look to build this pattern together, we're coming from different points of origin. And it's important to recognize that when we think about how we collaborate together.

As we travel towards this shared destination, right, it's often thought that the goal is to work side by side. But as most of you know, there's always this perceived space between us. A little Flexbox reference. We often call that space the gap, right? And this is the gap between design and development, and we see the goal as closing that gap. But this is often very hard and feels aspirational more than it does realistic. So bear with me for a second. We're going to talk about Pierre Dufourmat's principle of least time. So for those that don't know, Pierre Dufourmat, a product of the 17th century, a bit of a polymath, genius, thought about a lot of things. One of the things he did was observe the behavior of light. And if you aren't familiar with this concept, it's fairly kind of, it's a thing in math, but in physics, but building on prior observation, he realized that light passes between two points in the least possible time as it travels through different mediums, and it has to do with refraction, right? And that path is the optimal path. The way that I needed to hear this, we're going to actually do right now. So this is us. We're in the ocean, right? And there's been a bit of emergency, and we need a lifeguard to come and save us. Well, the shortest distance between us and the lifeguard is equidistant running and swimming, but as we know, running is often a lot faster than swimming.

So what you can do, option B here, is reduce the amount of swimming as much as you can, but in order to do that, you have to add distance, overall distance. And so what Fermat observed is that the optimal path is somewhere in between, and it depends on factors like friction or waves or sand or the fitness of the lifeguard. And these factors, understanding what these factors are, tell you how much distance you need to add in order to hit the optimal path.

So let's come back to this. Here we are. What forces are at work in this scenario? Well, I think the best way to think about it is almost like gravitational pull back to our points of origin, right? Developers coming down, design going up. The key to collaboration is understanding when the people you are collaborating with are going into their areas of most resistance, when you are adding the most distance for your teammates, and the reality is that oftentimes a little bit of give can go a long way. An addition for you might be a reduction for your team. So we need to understand those forces in order to make Pierre a happy guy.

All right, let's talk about this in practice. So here's everyone's favorite UI element, the button. Boring but does a great job of kind of explaining this stuff simply. So classically, if we want to have an icon in this button, in Figma the way we think about it is a Boolean visibility toggle because that node needs to exist, and so we need to toggle that visibility off with a Boolean toggle. But in code we're thinking of this as an optional property. As soon as that becomes true, we get a second property in Figma. It's an instance swap is the property type. And this is like designer ergonomics wise is an awesome kind of reality for designers. It helps them adopt the design system, understand what's going on. It's core to kind of the structure of how this design file is created. But in code we're just adding the icon, right? And so the way that we think about this thing is similar but a little bit different. Another example of this is the state variant. Designers need to give the hover, the focus, right? The default state that needs to be designed and exist in the component. But that's like CSS for us on the engineering side until we get to disabled. And in this case, it's a Boolean property in code, but it's a variant, an enumerated value inside of the design. And so while we're talking about the same thing, the reality is that there are these differences, right? And so in a sense when we come back to this, we're thinking similarly. We name things the right way. We're calling it an icon and not something else. We're thinking of it as disabled, not something else. We've optimized those paths. We've given a little, received a little.

But it's still got gaps, and that's where tooling comes into play. So quickly, at Figma, we have something called Code Connect that essentially is one of those tools that can fill that gap, that inevitable gap. And the way that it works is it allows teams to publish code-based informed component code snippets to Figma that translate between Figma component logic and the logic in our code.

The way that it looks, just like a storybook story or any sort of thing you would co-locate with your components and your code base, you have a Figma file for the component, and then that gets published up to Figma with our APIs. Then any full-stack engineer, backend engineer, whoever's implementing frontend gets to reap the benefits of not having to think about the presentation layer while they're frontloading all the functional stuff that they're trying to consume when they look at the design. The API is pretty straightforward. Figma stuff, code stuff, right? And it allows us to kind of bridge these gaps, right, and transform, you know, primitive values of variants into Booleans and that sort of a thing. And then you spit out the dynamic snippet that you want to see on the other end.

Now, buttons are super simple. You can do kind of, like, recursive templating, all sorts of stuff. We don't have enough time to get into it. Swing by the booth, look stuff up online if you're online right now. Figma slash CodeConnect on GitHub, ask us questions. But then also, so we currently support HTML, Web Components, Angular, Vue, React, obviously, SwiftUI and Jetpack Compose. But if you're, like, a Svelte fan or an Ember fan, whatever, like, let us know, give us feedback, because we'd love to support more languages with CodeConnect.

Really quick before I go, Simple Design System is a React component library that I created with a designer advocate at Figma. It basically shows how all of Figma's design systems features can be used alongside a React code base together to form a complete picture of a responsive design system. It includes a Figma file with a bunch of stuff, a working React app, storybook, self-hosted storybook instance, Figma integrations that do things like grab Figma variables, transform them to W3C, design, token, draft, spec, JSON, and then convert that over to CSS. So it has examples of that sort of a thing. And, of course, every component in the system is backed with CodeConnect. So you get, like, you know, your React definition, your CSS with easy custom property stuff, and then you get the CodeConnect on there as well. So if you're interested in that, that's figma.sds on GitHub. We'd love to get your feedback on that. And with that, thank you. If you have questions, LinkedIn, jake.fun, hit me up. Love you. We'll see you soon. ♪♪♪