Video transcript: Imagining a Fluid Future for Design Tools

This is a transcript of a talk given by Jason Grigsby at An Event Apart Spring Summit on April 18, 2022

AEA presenter:
Jason Grigsby is co-founder of Cloud Four, an agency based in Portland, Oregon. He’s also founder and president of Mobile Portland, a local nonprofit dedicated to promoting the mobile community in Portland. He’s the author of the book Progressive Web Apps from A Book Apart. Over the years he’s worked with a lot of design systems and he’s here today to talk about how our tools do or don’t measure up to what we need of them in a responsive design world riddled with design systems. Please welcome Jason Grigsby.

Jason Grigsby:
Hi everybody. Today we’re gonna look at some design tools that I think are doing things a little differently and perhaps a little better for today’s web. But before we get to that, I’d like to share some context for why I think design tools need to change. And really it’s all Ethan Marcott’s fault. I kid, a little bit. But the reality is that 12 years ago this month, Ethan’s responsive design talk at An Event Apart changed the web. And more importantly, for our purposes today, it broke the traditional web design and development process. I mean, this is how we’ve historically built sites. We put together some plans, we create some wire frames, then somebody creates mockups from those wire frames. Eventually those mockups are converted into HTML, CSS, and JavaScript. And at some point in the what we hope is not too distant future, the site launches.

Jason Grigsby:
Now I know that there are many organizations that still use this process, but the truth is that responsive design broke this process in fundamental ways. To prove it, let’s just focus in on two steps in the process, the static wire frames and the static designs. Let’s assume the site we’re working on has five core templates. That means we’ll need five wire frames and we’re gonna need five mockups, but we can’t forget about mobile. So let’s add those wire frames and designs in and we probably need to worry about tablet as well. And there’s no way that we’re gonna be able to publish a website and not have at least one round of revisions. By the time we get here, we’ve got 60 total artifacts for just those five templates. And of course, most organizations have more than five templates. And how often is there just one round of revisions?

Jason Grigsby:
So we’ve created dozens of artifacts, literally dozens of artifacts, and not a single one of them accurately reflects what the experience will like be like in the responsive design. And that’s because these artifacts only show three breakpoints. They don’t even count for device rotation, let alone the numerous resolutions that exist between those breakpoints. And it’s not as if design challenges only happen at the three breakpoints we designed for, in fact, some of the more interesting challenges happen in those gaps. As a small example of this, we were working on a recent project for Cloudinary where we were converting some static designs that they had created into responsive web templates. My colleague, Paul, was leading the efforts and one morning Paul noticed the section displaying top categories looked awkward at a screen size that was between the breakpoints that we had been given mockups for.

Jason Grigsby:
As you can see here, to the right of the photo and the top categories, there’s some white space that’s not being used well. Paul suggested that it might make sense to move the two sections next to each other, but in doing so, it caused the background to break that list of top categories awkwardly. So Paul also suggested a second design change to make the background solid for these screen sizes. The designer at Cloudinary liked the change. Our contact liked it as well. Paul implemented those changes quickly. Seems like a win-win, right? But Paul is the exception, not the rule. Many developers wouldn’t catch these sorts of design issues, but Paul is equally adept at development and design. What happens when your static mockups are in the hands of a developer who doesn’t have Paul’s design skills? And hearing this and thinking about what Paul was doing, resizing the browser and identifying design problems, it reminds me actually of one of the first and best bits of responsive design advice I ever heard, Steven Hay said that the way that he designed responsively was to start from the small screen design and then expand his browser into the page looked like crap. And then boom, that’s when you need a breakpoint. Now, I’m sure that many of you have spent more time than you care to admit resizing your browser. And what Steven described to me seems like a core part of responsive design, that active resizing the browser and looking for problems. But here’s the thing. If the active resizing designs is to see where they break is core to responsive design, then what happens when your design tool only creates fixed width designs? And the other thing about this process that bugs me is that there’s a fundamental assumption that underpins it. And this assumption is that designers will take the webpage so far and then they’ll hand it off and then development will take over.

Jason Grigsby:
And this creates an artificial barrier between the team members. And not only that, but we’ve seen that there are still design decisions that need to be made after the design is converted into HTML, CSS and JavaScript. Just look at what Paul was doing with that Cloudinary design. And there are likely development decisions that are happening before things are handed off. As our industry has started using design systems, the problems with that traditional web design process has become even more apparent. A well -considered design system will address multiple use cases. It’ll have interaction, animation, accessibility, performance. The team that works on the design system has to make sure that they have the best solutions for all of these problems. All of these important considerations are then baked into the components in the design system so that they can be reused by other teams. From a development perspective, the possibilities for reuse are numerous.

Jason Grigsby:
The component will be documented in some system, whether it’s Storybook or Pattern Lab or whatever it is. The component will then might be coded or converted into any number of JavaScript frameworks to make it easier for teams to adopt the component. See all of that good thought put into the component shouldn’t go to waste. On the other hand, designers oftentimes working in apps like Sketch, Adobe XD, Figma, Photoshop, and in those tools they may have the ability to create reusable pieces of a design. Each tool calls them something different, whether they’re symbols, libraries, tokens, templates, what they call them and how they work doesn’t matter. What matters is that we have a divide again, between design and development. The designers cannot use the design system components even though so much time has been put into them. Because of this, designers oftentimes maintaining their own copy of the design system in their design tools.

Jason Grigsby:
They’re attempting to recreate manually the experience of those components in whatever that shared library is that their design tool offers. But keeping these two systems in sync is a big challenge. It requires a lot of work and they’re inevitably going to be differences because you’re taking something that is designed in the web and trying to create a fixed width copy of it. And so at some point these things will have deviations. And what happens when a design created with one of these copies of a component in a design tool is used to create a design, it’s handed to a developer and in some way it’s different than what the component is in the design system. How does a developer know which design deviations were intentional and which were merely mistakes made while trying to replicate something that exists natively in HTML, CSS, and Javascript. My business partner and Cloud Four’s Creative Director, Tyler Sticka, he wrote about how this leads to a broken process in organizations. Say a designer has mocked up a new design element, it seems self-explanatory. So they throw it over the wall to the devs, the developers then go about implementing the design. A few weeks later, the designer notices the design has been implemented and well, they have a few questions. The basic gist of the design is there, but the nuance has all been lost. The full bleed image, the spacing, the buttons, placement, the iconography. For sure, the developer didn’t mean ill, but this isn’t what they designed.

Jason Grigsby:
So they go back to their computer and they start annotating the design extensively. When they’re satisfied, they’ve documented every last detail, they send it over to the developer who looks at the specs and is, well, now they’re equally confused. They’re not sure how they’re gonna implement these specific changes given the rules that they have in the design system. And knowing these measurements is helpful, but what happens at other screen sizes? At some point it seems like there are more questions than there are answers. So maybe on some teams, the designer and the developer have, they have a good working relationship, they sit down together and they, they sort these things out. But in other organizations, the developer might just give up. Maybe they just don’t care enough or maybe they’re on a deadline. So they create a new media query, they throw in a CSS import rule.

Jason Grigsby:
They make sure the webpage matches the mockup at the breakpoints of the design because they know they’ll get feedback about that. And they’ll do that even though it may break the design system rules and it may look odd in other sizes. Now, to me, this is more evidence that the old process is broken, but I don’t think that that’s the conclusion that most design tools have come to. See, they look at all these problems that they handoff and how designers are working on these detailed, detailed specifications and think, aha, I could help with that. And so you see this right? Design tools like Marvel which is design applications actually pretty cool. It’s not the comic book company, but they tout how they generate detailed and extensive documentation for developers. And this is a key selling point. And yet when I look at this video for Marvel’s website, I have more questions. Like, if the design tool is showing me margins like these, are these margins fixed or are they gonna change?

Jason Grigsby:
And should I even care what the measurements say? I mean, I notice that the measurements are the same both vertically and horizontally. Is it possible that what we really want here is for the image to be centered and the actual matter measurements don’t matter because if the margins are different so long as it remains centered, that’s correct. Another part of the video, it shows a color being specified, but it would be better if it just said, what design token I need to use? And if the color is slightly different from the design token, is that an oversight or is it intentional?

Jason Grigsby:
Similarly, later on in the video, it shows an avatar. It shows the code. It’s trying to generate the code for this. It’s 420 pixels square, but at what breakpoints? Does it change? And again, where are the design tokens? And I picked on Marvel cuz it has this nice animation, but I could have picked on nearly any other application, whether it’s Figma or Sketch or Adobe XD, they’re even entire products built around the idea of providing better specs to developers. It seems like every design tool wants to be in the business of generating code for developers. But is this even a good idea? Does it make sense for developers to adopt code from design tools, especially in situations where a design system is being used? Setting aside for a moment, the inevitable worries about AI taking over our jobs. The code generated by design tools is unlikely to be a good fit for companies, particularly for those using design systems.

Jason Grigsby:
Because it’s fixed width, it’s not responsive, it lacks design tokens. It it doesn’t honor the design system’s conventions. It it’s specific to one use case. And despite these issues, it seems like every design tool is keen to prove that it can generate code as if FrontPage and Dreamweaver never existed. But even if the code generated is useful as either a guide or, or much less likely as production code. I’m just as troubled by what the specification and code generation features are saying about the way these tools view their role in relation to the design system code. And seeing these tools often treat the static mockups as a source of truth. And frankly, anything that doesn’t exist in the medium of the web can’t be considered the source of truth for the web. So for these reasons and many others, when we started doing responsive designs over a decade ago, we’re forced to burn down our whole, our old design process and find something else that works for us.

Jason Grigsby:
And it took some time in experimentation, but we eventually settled on a new process that has worked incredibly well. We’ve used it for a wide range of sites, from marketing sites to complex web applications. And there are other pieces to the process, but the core engine is a responsive design sprint. We start with discovery for the patterns we’re gonna design during the sprint. Then we sketch small screens because it’s easier to move from a New York apartment to a big house in the suburbs than to move from house to the suburbs into a New York apartment. And that is why designing for small screens makes sense. It helps you build better designs. Then we move directly into code, call it prototyping in browser mockups, HTML design. It doesn’t really matter. We’ve used all those labels. What matters is that we’re designing responsive from the beginning because we’re designing it in the medium and then the process repeats in the next sprint.

Jason Grigsby:
Once an in browser mock-up has been approved, we determine what portions of that design should be made to components. We codify those components and document them in a design system. And then this becomes sort of a virtuous cycle where every component creates that we’ve created speeds up the design process because it can be used as a building block and subsequent prototypes. Now I’m not saying we found the one true way to design responsive designs and build design systems. I mean every organization is different, but I can’t say confidently that this process is demonstrably better than the traditional web design process because we’ve, we’ve used both of them. When we design this way, the designs have greater integrity because each small component has been thoughtfully designed and fully responsive. And so because the smaller pieces are fully responsive, when you get to building full pages, you find that the pages don’t break down.

Jason Grigsby:
The foundation is solid, so everything is responsive. You can also solve problems that you may not see when you’re looking at static mockups. My favorite example of this is when we were working with Walmart to make their grocery site responsive, they have an interface where you can select a time slot for delivery. We did some design work to make it fit on small screens. We thought we had solved a problem, but actually when we started using it on devices, we noticed that there was this awkward problem where if you got to the bottom of one day’s time slots and then click to go to the next day, it could actually be quite jarring. The places where it felt the worst were actually times when there were a lot of times slots on one day and then on the next day there were none. And so essentially what was happening is you have this really long page that suddenly became really short when you tapped on that button and without providing a way to orient users, they were getting lost, they didn’t know where they were on the page. So we spent a lot of time creating animations to help users understand what was happening. So when the user taps the button, the page slides back up to the top to where the list of days are, and it does that before the next day slides into view. And then at the top of that sort of column, there’s a list of days and that also slides into view. Now we spent a lot of time working on this to get the animation and timing all right and the sequence sorted out the, the end result just feels right, feels intuitive, like this is how it should always work. But it wasn’t intuitive. It took a lot of work and we would’ve never even realized that there was a problem unless we were designing in the browser. And even in this process, we still sometimes hand have handoffs whether it’s to developers who are codifying the components in the design system or people who are implementing it into the end environment.

Jason Grigsby:
But the nice thing about the designs we hand off is that the majority of the responsive problems have already been solved because we’re designing responsively from the beginning. We’re such believers in this process that we spend time teaching it in talks and workshops. And actually one of our favorite things is when client designers embed in our team to learn this process. If they can code, they participate in that process fully. But even if they’re just designers who don’t know how to code, they can still participate by creating screenshots of the HTML mockups, then modifying them in their design tool of choice. We get that sort of quick, quick collaboration to find the best answers. Unfortunately, this process just isn’t a good fit for some organizations. And it works for us, but we have a bit of a secret advantage. See our designers code and our developers went to art school.

Jason Grigsby:
It used to be true that all of our developers had gone to art school. That’s no longer the case. But all of our developers have some design interest. And I realized the subject of designers coding is a bit of a hot topic. There are a lot of people with dogmatic responses and opinions on this. Frankly, I was pleased when building this to find a article or two that put the shoe on the other foot and asked if developers should design. So look, yes, in my ideal world designers code and developers design, but in my ideal world, everyone knows how to code and design, particularly design because honestly, I think I’m most offended by poorly design things. If you’ve ever been irate at a door handle that that is designed to be something that you pull, but the sign says push, well then you are my kindred spirits and I guess we can thank Don Norman and The Design of Everyday Things for making that something that we can never forgive.

Jason Grigsby:
So that’s my ideal world. But I’m also a realist. They’re amazing designers we’ve worked with who cannot code and they’re phenomenal developers who don’t have an eye for design. We just don’t live in that ideal world. So what I’ve been looking for for a few years is some way to help designers get closer to the process similar to ours, I believe that most designers, and I know in particular the talented ones we’ve worked with, they want to craft the entire user experience. They wanna make sure that no matter what device someone uses that they, that when they reach that experience that they have an exceptional one. But the tools they have right now only allow them to see a small portion of that experience. And not only that, when you’re working with design systems, using design tools can be much less efficient. This is something I learned when I met with our design team to ask why they don’t use design tools more often. I know they use them occasionally when exploring ideas, but it’s more an exception than the rule. So Danielle, one of the designers at Cloud Four, she had a very succinct explanation

Danielle Romo:
Because we prototype so much and it’s a lot easier to use the existing components then try and go in and recreate them in Sketch or Figma to use them there just because I’m not using it extensively. When we already have that I that available to us.

Jason Grigsby:
So the point that Danielle’s making here makes a lot of sense and that’s as a design system becomes more mature, the number of components that are available in the design system if you’re able to code with them is much more. It provides a bigger foundation for being able to design things than whatever you have in design tools. So between Cloud Four’s designers and myself, we came up with the wishlist for design tools, starting with some must must haves. First it must have support for responsive design. As I said, I want designers to have the experience of resizing the browsers. So it needs, needs to do that. It must treat the design system as a source of truth. It must be able to import those components so that designers who can’t code have the experience Danielle talked about. But you should be able to design from scratch when you want to and it should feel like a true design tool.

Jason Grigsby:
And I realize that’s completely subjective, but if it doesn’t work well for people, colleagues aren’t gonna use it. Next, we’ve got some things we think should be likely to have. It probably needs to be built on the web. It doesn’t have to. I’m not dogmatic about that, but I just think it’s gonna be pretty hard to recreate the features of the web in a native application when you could just use the web in the first place. It should be easy to update the design system, but frankly, I want better design tools enough that I’d put up with some pain, both in terms of getting the components in and being able to maintain them. You should be able to override components when necessary. This is a, maybe I’ll talk a little bit more about how I’ve been rethinking this and it would be great to be able to prototype interactions and have usability testing, but neither of these, even usability, which is really core to what we do, they’re, they’re not must haves and it doesn’t mean that they don’t matter. It just means that there are other ways we could solve this problem with other tools if the design tool itself doesn’t have them. And then we’ve got some nice to have features like being able to integrate with the design system documentation, being able to collaborate tools for developers to inspect the design and animation support. And you’ll notice that co-generation is not on any of these lists. So Tyler summed up, well, what we’re looking for in a design tool

Tyler Sticka:
But in terms of what I look for on a design tool, it’s something that I can develop muscle memory for and something that allows me to import as much or as little as possible and to break away from it when I don’t need it anymore so that I can, you know, if you’re, if you’re tasked with like doing a new hero area for an existing page, being able to assemble the parts of that existing page but then to be freeform up above it is really, really helpful. Maybe it’s just me, others can say, but I find it really hard to get into a flow with a design tool if I have to treat any freeform exploration as like a separate exercise if I have to like, cuz there are some design tools that are really good at kind of just moving around existing components, but they’re terrible if you just want to play with shapes above that. And I find that it’s makes my brain stutter if I have to jump into something else and then go back.

Jason Grigsby:
So we decided to take that list, grab some design tools and see how close we could get to our ideal. In order to conduct this experiment, we needed a design system built in React and documented in Storybook. Now Storybook is needed because some of the tools that some of the design tools use Storybook’s code to determine what properties of component should be editable. The React requirement actually makes me a little sad. Two years ago I gave a talk at An Event Apart that tested how far we could take web components. Web components are a web standards way of defining custom elements. You can have something like a C4 button as an HTML element and use it on a page instead of writing all the markup by hand. Web components are kind of perfect for design systems and many of our recent design system projects are built using them.

Jason Grigsby:
We’re big fans. Unfortunately every design tool that we looked at that was doing some form of code import was limited to React. So in order to play in this space, we decided to limit ourselves to React as well. And then we needed to look for a React based design system that was using Storybook well. We settled on Storybook’s own design system, the, the design system they use for their marketing sites and stuff because we figured that if any organization was using Storybook and it’s properly used correctly, it would be Storybook’s maintainers. Using this design system, we created a few simple designs that we are gonna try to recreate in the different design tools. And then we took a look at a bunch of different design tools, including ones that aren’t listed here. We crossed off Photoshop cuz it couldn’t import things. Invision used to have ability to do some design stuff, but I think they’re all doing collaboration now.

Jason Grigsby:
And even their import really was more about bringing Storybook into documentation, not actually into design. XD didn’t really have a good way to import stuff. And Sketch, there are a couple of open source libraries that bring HTML and React into Sketch, but it’s React native and HTML has some serious limitations and the libraries haven’t really changed much in two years since my AEA talk. So that left us with three contenders. Let’s take a look at Framer. So importing Storybook React components wasn’t too difficult in Framer. Framer’s actually built on React, so that gave us sort of good foundation. It did require creating a custom wrapper. You can see it’s a pretty short file, but one of the things they notice in this wrapper is that there’s something that we saw in a lot of these tools. The design tools oftentimes need a little more information to know what the parts of the component are that can be modified and they need to know what type of UI to show.

Jason Grigsby:
Is it a text string that should be edited with like a text input or does that text represent a color? And so the design tool should show a color picker. After the component is imported, it’s pretty easy to use. You just drag and drop it onto the canvas and then you can edit whatever properties the component allows you to edit. In this case, you can edit what the heading says. When someone else creates a component for you, you can find it by pressing the inserts or the plus the top. You notice that our components don’t have a preview. I’m pretty sure there’s probably a way to do this in Framer. But since this was an experiment we couldn’t figure it out and we just, you know, figured it wasn’t really worth the time right now. The icon component has a link to Storybook documentation right in the editing panel so you can find like what the name of the icons are so we can change it into Face Happy.

Jason Grigsby:
And then there’s this thing that I found a little strange in Framer. It made me sort of consider what we should be able to do with things that we import. So I couldn’t resize the icon but I had seen it resizable on a different document that one of my coworkers worked on. And I realized that actually if I typed in the numbers for both vertical and horizontal changes, that then I could resize the icon. But in other design tools you can’t do that actually UXPin and Figma don’t allow you to resize them. And so maybe, maybe actually we shouldn’t do that. Maybe the icon size should be set. Although on something like this, this is a shadow CTA component. It’s actually the thing that is used throughout the design that we built. It is supposed to be responsive, it should change and the fact that it can’t is a challenge.

Jason Grigsby:
So again, you have to edit it to set the height and the width. Another thing to notice is that it’s all left aligned in the document, but if you preview it off canvas, it ends up being centered like it’s supposed to be. If you do the preview in the canvas, it’s still still wrong. And when we brought in other components, sometimes they had errors in them. Now if this was our primary tool, I’m pretty sure we could have figured out a way around this problem. But for an experiment it’s a good example of the types of challenges you might run into. So while Framer does support importing components like we did there, they don’t support importing the entire design systems. Instead they recommend against it. They basically say that components oftentimes need tweaking and can be tough to integrate. It seems to me that for some organizations that you know, having some tweaking to do and having to work to integrate it might be worth it for the advantages it provides to their designers.

Jason Grigsby:
But I think it’s worth noting that if you use Framer for this, they’re not gonna support you right now. As far as the design tool is concerned, I kind of found Framer’s UI to be a little bit of a barrier. In order to add any shapes, you have to open that insert menu and then when you resize the object, you’re actually only editing the container. You have to double click to get to the path where you can like make a circle into an oval and stuff. And then once you’re in there, like there’s sort of the normal editing tools that you’re familiar with, but you either have to insert an object to get to that or you have to know the secret password, you have to type G to get to that graphic layer to have that menu. So there’s a lot of stuff about Framer that I think is really promising and it’s actually I think better for designers to code because there’s actually quite a bit of design or a bunch of developer tooling in there.

Jason Grigsby:
I think that Framer is promising but it isn’t exactly what we’re looking for. So we’ll move on to our second tool. So UXPin out of the box has several UI systems like Bootstrap and Material Design. If you want to add your own, you can do so either with the command line tool, you go to the bottom here and then it gives you an option to either import it with the command line tool tool or to give it a Storybook URL. So in this case we have a fork of the Storybook design system. We’ve got it up on Netlify, so we’re gonna grab that address and put it into that modal. And then when I click create library UXPin does the rest. I see a full list of components from our design system. I can drag a button into the canvas and there are properties for editing that button.

Jason Grigsby:
UXPin uses the property definitions that you set up in Story Pan or in Storybook to decide what is editable and what control should be displayed. For most components there could be so for most components there’s little extra time that you would need to do if you set it up in Storybook. Some of the more complex components have JSON editing in the interface, which might not be the best for designers. The shadowbox CTA works responsibly just right out of the box. But not every component can be edited. If it isn’t set up correctly in Storybook, then UXPin won’t know what to do with it. And the other thing that we found was that there were occasionally some components that had React errors. So for example, this coding component has a React error and actually the shadowbox CTA originally did.

Jason Grigsby:
But we spent a little extra time getting that one to work because it was essential for the designs that we wanted to test. I think if you were using UXPin for your own design system you could work around these problems and get them fixed. The freeform design tools in UXPin seem more intuitive to me than Framer. It’s easy to select shapes and add them to the page. You have all the normal design tools like opacity colors, border, there’s a pen tool types icons. There’s also a nice auto layout feature that I think is basically flexbox. So if you add a few components and they don’t fit on a row, then they wrap down to the next design. And you can use that actually with the system design system components as well. Finally UXPin has some accessibility features built in.

Jason Grigsby:
In the lower right corner there’s a small button that opens an accessibility menu. You can select AA or AAA depending on what your standards are. And then when you edit colors, it’ll provide feedback that the color doesn’t match, doesn’t have enough contrast. It also shows you your range of acceptable colors and you can simulate various types of colorblindness. Using UXPin, we were able to get fairly close to our target design without a lot of work. We just had to drag components into the correct places. We did have to recreate the heading component. Just basically set the fonts and size correct because that component wasn’t editable. And if you look closely you’ll notice that there’s a word that says pill in our search bar. But we couldn’t figure out how to get it out of there. But both of these seem like the sorts of things we could fix if this was our real design system and we’re using UXPin all the time.

Jason Grigsby:
Finally, let’s take a look at Figma. Figma on its own doesn’t have any ability to import components, but there’s a new service and Figma plugin called Interplay that makes it possible. So I needed some developer help to get Interplay set up. I had a very frustrating weekend. But eventually we got it set up. It runs a command line tool that then copies up your components and copies up design tokens. Inside of Interplay, you can have both those design tokens and components. You can see what’s been synced up. The tokens are presented in a list and they’re categorized and you can make changes to them in the UI if you like. And it also shows you the underlying JSON that’s being used to power that design tokens. The JSON is actually notable because it’s based on the draft specification being developed by the Design tokens community group.

Jason Grigsby:
This group is a bunch of people like us that are working to standardize how tokens are shared between applications. So we can use design tokens in more places without refactoring. They’ve published a draft, a public draft, of the format of the specification and are looking for feedback. So if you’re interested, you should take a look at it. Join the community group and hopefully this will make sharing design tokens between projects much easier. Interplay’s command line tool pushes the React components into its service as well. You can see them in its web interface and if you open up say a button, you’ll see all the variants as well the properties associated with it. You can also change some of the presets if you want, but all of this, the web interface for Interplay isn’t why Interplay exists. So let’s switch over to Figma and open up the Interplay plugin.

Jason Grigsby:
First we have to add the fork of our Storybook design system to this Figma file. Now we’ll see all of the components in the Interplay’s floating panel. We can open a component and, you know, pick a variant to drag onto our canvas and then we can edit the properties of the component. So we’re gonna edit, you know, the appearance of the button and change what the button says. And we can go down and we can, you know, edit things like the size of the button. We can edit the various properties. If we look at that shadowbox CTA component, the one that we need for our design, it is responsive from the beginning. But one of the things that’s interesting is that it’s missing the button. The button’s actually a sub-component of that component and Interplay actually understands that.

Jason Grigsby:
So you have to go tell the button or tell the component that they, you wanna add a button as a child. And then once you’ve done that, you get all the options to change things. But as you can see here, sometimes the components don’t update, particularly sub-components. So you have to tell Interplay to re-render the component. But it’s pretty nice. All the components are available to you in Figma, which isn’t possible otherwise. The design tokens are there also. So you can use them with any object. You can go in and you know, add a box and use a design token to set your border radiuses. Figma also has a tool that allows you to align elements similar to the one I was talking about with UXPin. It’s a bit like Flexbox. So first, you know, you can select some items and make sure that they’re lined up correctly. And then if you add auto layout that’s how you get it to be somewhat like Flexbox. And when you do that you get access to additional properties that you can edit inside of Interplay like the padding and gaps.

Jason Grigsby:
So let’s go back to Interplay for a moment and make a change. Let’s say that we’re gonna change the value of a design token. We just used this positive design token for that background. Let’s change it from green to light blue. After we make that change. Interplay indicates that there’s another, that there’s a change to the design system that needs to be published. It takes care of tracking version numbers and we add a change log note about what’s changed and then we can publish that change to Figma. In Figma, the design doesn’t change automatically, but you can see there’s a little indicator that says that there’s updates available. Once we click on that, it starts processing our design. And it says that something needs to update and once we update it we see the color goes from green to blue. As far as like sort of free form design, I think Figma design tools are a large part of why designers like it. I’m particularly impressed by how it handles controls on shapes. Being able to edit the sweep and ratio on the circle is really cool and I love how Figma names what you’re changing so you understand the relationship to sweep and and ratio. And of course you can use the design tokens from design systems with these shapes.

Jason Grigsby:
As far as accessibility is concerned, Figma doesn’t have a built-in accessibility feature but there are so many plug-ins for accessibility. Generally the wealth of plug-ins is a key Figma advantage. Although in this case it might take some time to sort through those plugins to see which ones are actually good. As for the test of whether or not we can build this design, the answer is yes. In fact we built it in Figma in the first place. You can see how the designs accommodate different screen resolutions. But they’re not responsive. We can make them a little bit more responsive with this plugin called breakpoints. Breakpoints is pretty cool because after you install it in Figma you get a breakpoints panel sort of like the Interplay one. So we’ll go in and accept the trial and then we get the ability to have an adaptive layout. We already have one on the page and that adaptive layout is basically a fancy frame where you can define different breakpoints. For example, say that under 600 pixels it should use the mobile layout that you’ve already designed. Between 600 900, it’s gonna use a tablet layout.

Jason Grigsby:
So we’ve taken a look at all these tools, let’s go back to our wishlists and see how we’re doing. So none of the tools have responsive design support fully, but I’ll give a slight edge to Figma with its breakpoints plugin. Both UXPin and Figma can be set up to treat the design systems as a source of truth. Framer explicitly says you shouldn’t import your full design system. All three can import components and create variants. UXPin and Figma like designing things from scratch and technically Framer does as well, but to me it doesn’t feel as much like a design tool As far as the should haves, all of the all three are built on the web. And could we just pause for a moment. These are remarkable design tools and they’re all web-based. That is so cool. UXPin and Figma with Interplay, they’re both easy to update with new versions. I didn’t mention this but with UXPin, if you make a design a change to your design system and it’s reflected in the Storybook, it just automatically updates in UXPin. Overriding system component behavior is something I’ve given some second thought to you like the icon, I’m not sure when you should allow it and when you shouldn’t and how you should document when it’s been overridden. Framer gave us the most flexibility there but I’m not sure whether that’s a good thing. All of them had some nice tools for prototyping, which I didn’t have time to include here. And UXPin and Figma have some accessibility testing options. As far as the nice to haves. UXPin and Figma have some integration with design system documentation. It’s not much though. All three had some nice collaboration tools.

Jason Grigsby:
Actually some really nice collaboration tools. It’s kind of fun to see somebody else edit a design document at the same time you do. There’s some built-in features for inspecting designs that all have animation support. In particular, some stuff that’s kind of like keynotes magic move. I’m pretty impressed with that. But I’m just one person, this is my subjective opinion and I’m not an expert by any means. I mean I stopped calling myself a designer years ago. So you should try these tools for yourselves. Figure out which ones seem like something your design team can adopt and then figure out what it will take to connect your design system to it. So let’s back up a moment here. How close are we to enabling designers who don’t code to fully participate in a process like this? So I mentioned how Figma’s auto layout was built to work somewhat like flexbox.

Jason Grigsby:
They wrote about the design of the feature and they wrote that it was supposed to be a thoughtful subset of flexbox. And it is thoughtful and it’s cool, the UI for it’s great, but that subset is also disappointing. For example, if the container’s too small, the items don’t wrap onto the next page. And thinking about this reminded me of this old website called Liquidappsive. It’s no longer live, but you can find it in archive.org and it would show you like what a liquid design looked like versus static versus responsive. And as you saw with that liquid design, like everything just gets squishy. A feature like auto layout, which we’re just now getting the design tools, in many ways it’s like we’re just now getting liquid layouts and liquidappsive, that’s site first launched in January of 2013. If we go back a couple years earlier, Ethan’s responsive web design article was published in 2010.

Jason Grigsby:
In the article he described three technical pieces to responsive designs: fluid grids, flexible images, immediate queries. It’s 12 years later and we don’t reliably have the equivalent of these in our design tools. So for the moment you can forget about CSS Grid or any of the new features that Jen Simmons describes in her intrinsic web talk. And frankly that’s pretty depressing. But despite the fact I’m still optimistic, design tools have made significant progress in the last two years alone. And it seems like every time I turn around I find out about a new tool or service that’s looking to streamline design process. And this tells me that the people making these tools are starting to look at the right problems and while it still may be clunky, a little clunky and a little bit of work to get your design system into your design tool, it is actually possible now and it wasn’t possible in the past. And I would argue it’s worth the effort. And perhaps as more organizations do that, the design tools will start catching up and they’ll spend less time figuring out how to export code and more time figuring out how to add breakpoints and CSS grid. And one way we can help make that happen is to take our wishlist to the makers of these tools and ask them to focus on these issues. In addition, I’m optimistic because working on this talk has caused me to reevaluate my assumption that moving people more towards this process is necessary. Now to be clear, I still believe that there are substantial benefits to this process, to the process we’ve adopted. And I want designers who cannot code to be able to design that full responsive experience. I started to wonder if part of what makes this work isn’t about designing in the browser, but about the fact that design and development overlap throughout the process.

Jason Grigsby:
And so perhaps if organizations can’t move away from this process entirely, they can still improve it. To do so, we need to remove the emphasis on the handoff and recognize that design and development should both occur throughout that process. And the good news is that there are several organizations working on tools to help with this kind of collaboration as well. So if this is a challenge in your organization, you’re not alone and there’s some help on the way. Finally, I wanna leave you with some wise words from Tyler about what is causing these handoff problems and how design systems help in ways that we might not always appreciate.

Tyler Sticka:
But that’s not why the bug, the bug doesn’t exist because the mediums are different. The bugs exist because there are always a thousand undocumented decisions that, you know, you could, you could devote a whole week to I’m gonna document everything and you’re gonna miss something cuz we’re humans or, or you know, vice versa. The designer will not have thought about a weird use case or something or an edge case or whatever. But companies are always going to look for opportunities to remove the need for employees to talk to each other cuz it makes scheduling a lot easier. . So I don’t know what to do about that, but but the truth is, all these things I think would be, I mean we’ve seen it at companies we’ve, we’ve talked to or whatever, is like half the time, the solution to the issues they have with the design to dev handoff is mostly, you know, a little bit of like technical stuff. But mostly just giving people like a, a systemic reason to talk to each other every now and then, you know I think that’s like design systems, if anything, are like a catalyst to force those conversations because they sort of exist between worlds and so they are sort of uncomfortable and there’s a tension there. And I actually think that’s really valuable.

Jason Grigsby:
Yes, it’s very valuable indeed. Thank you very much.