Ignite: Our Approach to Design Systems and Faster Site Building

The foundation of almost every website in today’s world is made up of similar building blocks: cards, accordions, heroes, WYSIWYG text blocks, buttons…you know, the reasons why people complain that every website looks the same. We found ourselves looking for ways to shortcut the time we spent designing and building these same components over and over again and free ourselves up to work on the things that make digital experiences unique.

We knew there had to be a way to work more efficiently, collaborate better between designers and developers and spend more time on the fun, creative parts of digital product development that make a website stand out from others in its category.

To answer these problems, we created Ignite.

We sat down with Elliott Mower, Head of Product, and Jay Callicott, Head of Engineering, to talk about what Ignite is, why we built it the way we did and how other teams can use it in their work.

Mediacurrent: Elliott, how would you explain Ignite from a designer’s or a strategist’s perspective?

Elliott Mower: From the strategy and design perspective, Ignite is a way to get started on the meat of the project. Get to the more interesting things sooner. We took a step back and identified the things that we see commonly across all of the sites that we build. What are the same components that we see again and again and again? And how can we design the Platonic ideal of those components one time and build them one time and integrate them with the CMS one time, in the best way possible, but in a way that also allows you to configure and change and customize those components and add to them. So you start with this kit of 16 editorial components, but that is the foundation of the project. You can add to that. You don’t have to use all 16. You can change every single part of it.

From the design side, we created a UI kit in Figma that bundles the best pieces of Figma. We really wanted to lean on Figma’s native tooling. All the components that we have in the UI kit have auto layout, they use boolean properties, they use content layers. You can start working with those components very quickly. You can change things and scale rapidly. You can change all your styles. You can change all your fonts. You can change them once and they’ll cascade to the entire project. But you don’t have to think about designing a button again. You don’t have to think about designing a card again. You don’t have to think about designing a table again. We’ve done all of that, so you can take what we’ve done and roll with it.

Mediacurrent: Jay, what about as a developer? How would you explain Ignite?

Jay Callicott: From a developer’s point of view, I think it just makes their life easier. I was the tech lead on this project, and what we’ve done is a lot of set up — bundling of modules, configurations, things like that. But we spent a lot of time on the Layout Builder aspect of Drupal. We set up a bunch of different blocks — I think we’ve got 16 blocks out of the box — and we integrated them with our theme system. We did a lot of work in terms of integrating a design system with Storybook and Bootstrap, so it’s a really nice foundation to work with. You’re able to really jump into the project and not have to spend time on a lot of setup stuff.

MC: Jay, why did we create Ignite from your perspective?

JC: We created Ignite because we wanted to reinforce best practices across the team. At any given time, we have dozens of developers working on client projects, and we felt like we needed to reinforce some of that consistency. We want freedom for developers to make decisions on projects, but there still was a need to not reinvent the wheel. So we looked at how we could make things more efficient and follow best practices, especially on the creative end, which is where we spend a lot of time. How we develop components, how we integrate with a design system — we saw that was an area where we could have some improvements. We created Ignite to have a solid platform from end-to-end.

MC: Elliott, what about on your end? Why did we create Ignite?

EM: In my opinion, we created Ignite for two key reasons. One is to improve the design to development handoff so that we can establish a shared language and shared understanding from day one. We’re looking at the same things at the same time, in the same way, and when things get handed over from design to development there isn’t this gap between what they look like in Figma and what they look like when they’re actually built. We really wanted to streamline that process and solve some of the consistent issues that every team runs into.

The other piece of it is that we wanted to get to the fun stuff faster. We wanted to get to the things that are really unique to each project. Realistically, every website kind of has the same core characteristics. But the things people remember, the things that stand out and the things that are fun to work on are the things that fall outside of that core. So if we can have building blocks already taken care of, that frees up the design team and the development team to come up with the cool stuff and make the cool stuff. And that’s where the teams want to work. They don’t want to build another card, but they want to build some kind of unique experience that nobody’s ever done before.

MC: Jay, web starter kits and UI kits aren’t really a new thing. What makes Ignite different?

JC: Ignite is an end-to-end solution for Drupal, from the application side through the creative side. There wasn’t really something like that in our space. If there was something out there that already accomplished what we wanted to accomplish, we would just have used it. If there was an Open Source tool that did what we wanted to do, that would be fine. We didn’t have to create something on our own. But there just really wasn’t something that fit our approach that tackled our wishlist of needs. There are a lot of starter kits in our space that help more on the back-end. But there really isn’t much from what I could tell that tackles things more so on the creative side. We did evaluate some different theme systems, but they didn’t really accomplish the goals that we wanted to accomplish. So that’s where we invested the time to build something that would really meet our needs and the needs of our clients.

MC: Elliott, why did you choose Figma? What are some of the benefits of using Figma for a design system?

EM: We didn’t choose Figma, Figma chose us. I think it’s clear across the design industry that Figma is the product of choice. There are other good design products out there. Sketch came a long way from what we were previously doing in the Adobe suite, and I think that Adobe’s answer to that with XD is pretty strong, but Figma is in a class of its own. Figma has really invested in both sides of the equation. You can’t just make a design product for designers. You have to make a design product for developers, too. You have to make the transition process smoother.

There are things like auto layout, which allows you to create a component or a design element that has almost responsive behavior. Figma allows you to see how that would work. The way that they handle styles, you can create kind of a foundational design system. And they keep coming up with cool stuff, like the way they handle components where you can swap out different versions of it. Figma is really a design tool for the way that we design websites and apps and products of all kinds. The core of Figma is designing for a design system. There isn’t really something else on the market that does all of those things as well as it does.

MC: Jay, Ignite is built using Bootstrap. Why did you choose Bootstrap over other frameworks?

JC: We chose Bootstrap as our framework of choice for a few different reasons. First of all, we decided we needed to have an opinion in terms of how we would work in themes. We’ve used Bootstrap in the past, but sometimes we’ve used Foundation or other frameworks, or often no framework at all. We decided that we needed to have some consistency. That’s been a theme of today. So we collaborated with the creative team to look at some different frameworks. We really liked Bootstrap because it was a full UI kit. It was flexible. We are already familiar with it because we’ve worked on some Bootstrap projects and it’s really easy to work with. The documentation is great. It’s a very mature project. Leveraging a framework like this simply cuts down on a lot of custom work. I would say at least half the amount of custom lines of CSS. It was a pretty easy choice for us.

MC: Jay, what were some other technical decisions you made as you were building Ignite?

JC: The big one was Bootstrap. Storybook was the other big decision. A lot of agencies have been moving to Storybook in recent years, including agencies like ours that do a lot of work in Drupal. It’s not trivial to integrate Storybook because it runs on a different stack than Drupal. The way we integrate it was a big choice because there were some modules out there and systems out there that integrated them one way or another, so we had to make some choices around that. I think where we landed was really good.

So outside of those front-end choices, we made some smaller choices in terms of which modules to use. We relied a lot on our own experience over the years. With the previous iteration of what is now Ignite, we had some different modules and we re-evaluated everything from top to bottom. We removed a lot of stuff that we had used in the past in terms of configuration.

MC: Jay, Storybook is a big part of Ignite. What are some of the advantages of incorporating Storybook?

JC: It’s a really well-known tool. It’s really easy to work with. It’s well supported. I love the plugin ecosystem. There are a lot of good plugins. What’s nice for developers is that when you make changes it will reload updates in the browser, so as soon as you update markup or CSS, you instantly see it in the browser. That’s really helpful. For users, if you’re demonstrating something to a client, you can adjust the controls and settings on different components so they can see the different variations of a component. It’s a really nice tool.

MC: Elliott, anything you would add about the benefits of Storybook from the design side?

EM: The advantage is that you get to see things that are actually developed, but you get to see them in a way where they feel a bit more tangible. When you go into Storybook, you can start to play with your components. What would happen if we have four lines of text instead of three? What would happen if the image is square instead of rectangular? We can see how well the component responds to that. How does it break? Do we need to have a design solution for it? It gives you that bridge between that perfect world where we can control all the variables in Figma and a live website where there is less opportunity to change it. But you’re not going to break anything. You can play around with what your options are, but it’s still in a safe space.

MC: Elliott, along those lines, how do you keep everything in sync between Figma and the code? What does that handoff process look like so the designers and developers are all on the same page?

EM: Right now it is still a manual process, where if you make a change in Figma and you want to make that change in Storybook, that would require a conversation between a designer and a developer. We are working on some things to make that process automated. We’re moving in the direction of using design tokens, which take the design decisions that are in Figma and spit them out as sort of protocol that can be integrated into your project in an easy way that wouldn’t necessarily require a developer to go in and actually make that adjustment. That would allow us to make some of the global style changes super efficiently. We’d be able to play around with things in a much more fluid manner, without this disconnection between what exists in Figma and what exists in Storybook and ultimately on the site. We’re working on ways of smoothing that handoff process a little bit more and getting everybody to speak in a similar language.

One of the things that’s discussed a lot on design Twitter and design Medium is, ‘Should designers code?’ We’re not in the camp that designers should code. We’re in the camp that everybody should know a little bit about what it takes to make the website actually come together. That doesn’t mean that we’re going to minimize the work that the designer does, or we’re going to eliminate the role of a front-end developer. We’re just wanting to make sure that everybody is speaking the same language in the same way so, like I was saying earlier, we can focus on the new stuff.

We wouldn’t be able to necessarily automate the process of creating something from scratch, although we are looking into ways of maybe automating that process. We’re thinking about ways we can use AI to work in that process. But with things like global changes, we’re working on a way to make that process much smoother.

MC: Elliott, how would you start using Ignite to create a design system?

EM: The foundation of a design system in Ignite is very much like the way that Jay talked about approaching some of the technical decisions that went into making the product. We wanted to make some decisions about how things should work, but they are strong opinions that are loosely held. So a lot of the things that people struggle with when they’re creating a design system from scratch or when they’re converting a print brand guide into a digital design system is where do you start? How many things do you need? How many different sizes of type do you actually need for a website? How many different colors do you need? And what kinds of colors do you need to add to your core color palette? We wanted to create a foundational system that had some decisions there, so that you can bring your brand into this system, but some of the structures are already set up.

It also doesn’t mean that you have to religiously adhere to those structures. You can change them. But we wanted to create something that would be logical and well structured, that would allow you to come in with your colors, your fonts, your icons, your imagery, your copy and be able to plug them into the system and you can roll with it. So you don’t have to think about all of the micro decisions that have to happen when you’re creating a design system from scratch.

MC: Jay, anything you would add from a developer’s side?

JC: If you’re curious about how to get started with Ignite and the whole design system from the developer perspective, you want to go visit our documentation, our project page, visit the demo and test it out. We’ve got a full demo that you can install. You can review the open source file for Figma. You can play around with all the different settings. Just get comfortable with how it works. If you feel like it’s a great fit, with the help of the documentation, you’ll be able to incorporate those changes into your theme system. And at that point it’s really pretty standard triple theming, Drupal site building, things like that.

MC: Elliott, how are you thinking about maintaining and adding onto Ignite in the future?

EM: We have some immediate things that we’re working on and then we have some longer term aspirations. So more on the immediate side, we’re looking at ways to develop the product to be available on multiple CMS platforms. To do that, we’re looking at ways to make it decoupled, so you can have a separate front-end and back-end product. We’re also looking at ways that I talked about earlier of using design tokens to automate or simplify the design to development handoff.

We’re still figuring out what our general maintenance cadence is or how we’re going to add to the product. We are using Ignite as the foundation for our products. As an agency that serves a variety of clients, we’re going to be out in the world working on projects and we’re going to see that there are components that come up again and again across projects. In a few projects we’ve been working on recently, there have been needs for a masonry grid component. It would be nice to have one in Ignite that we can use on future projects.

The other cool thing about having this as an Open Source project is having the opportunity of getting input or ideas from other people. We’re really interested in having other people outside of Mediacurrent testing out Ignite, maybe using it in their own projects and letting us know what they think about it.

MC: Jay, anything you want to add?

JC: For the immediate future, I would add that we want to make this really accessible for people to learn. We’ve got some good documentation now, but we’re working on some really good training material. We plan to have some live training opportunities this year. A little further out, there are some good opportunities to integrate some AI tools to help with different things. The area where I think AI could be really helpful in the semi-near-term is helping create components. I think there is a way to have AI assist to make that process more efficient. So really exciting things to look forward to.

Thanks to Jay and Elliott for their deep dive into Ignite and how we’ve approached it. Check out ignite.build to learn more about Ignite and get started using it with your own team.

Jay and Elliott did a deeper dive into Ignite on a recent webinar. You can check out the recording to see Ignite in action.

Elliott Mower is Head of Product at Mediacurrent. He is agressively inbox zero.

Jay Callicott is Head of Engineering at Mediacurrent. He spent 2 years teaching conversational English in Wuhan, China.