Using Tailwind to increase efficiencies between Product Design and Engineering

Unlike some agency teams, we don’t consider Product Design and Product Engineering to be two separate teams, we are a single team working towards the same goals. We are working to the same end user stories and the more we can reduce duplication of effort between different areas of the team, the better.

This time around, come with us on a journey to explore how we can use Tailwind to make product design and engineering processes more streamlined.

In the Mediablaze product team, we are always striving to improve our process to deliver better products for our clients. The more we can remove inefficiencies in our processes, the greater opportunity we have to spend time on the things that really matter; such as the challenging problems of the project, rather than things like matching a design in code or pushing pixels.

Identifying the problem

We noticed that a time drain in the team was around ensuring what the developers build, matches the design output. Even when the design is pixel perfect, it can still take time setting up all the spacing variables, text styles, colours, shadow properties and everything else in the build. This is something that the design team has already spent countless hours on perfecting in the design process, so why is another member of the team doing the same thing, but in code?

So we began exploring this further and looking at possible solutions.

Streamlining the process by making better use of the tools we have

Figma, as a cloud-based tool, has APIs that enable developers to create custom plugins that wouldn’t be possible with other applications. This usually means that there are ways of integrating the app with other platforms. We began looking at the automation of Figma Design Tokens - a way of keeping a design system in sync with development.

Think of the traditional design to developer scenario. The designer creates Design Tokens for the system; colours, text styles, spacing and more. When the designer makes changes to one of those tokens, they have to ensure they communicate this to the developer for them to then ensure they make the change in the code. You can see how this can become tedious and time consuming, so it’s great that there are ways to automate the updating of these to keep development and design in sync.

There’s a great article on prototypr about this and how design tokens work in the development process if you want to find out more.

There’s something in the wind. It’s Tailwind.

In our exploration into automating Design Tokens (which is another topic that we are looking at coming back to in the near future), we came across Tailwind. Tailwind is what is known as a Utility First CSS framework. A utility-first CSS framework is a CSS library made up of very small, specific CSS statements that perform one function only. Similar to the “composition over inheritance” pattern that we’ve seen become more popular due to frameworks like React, the industry as a whole has seen a shift away from ‘semantic naming’ in CSS, toward a more functional, compositional approach. Adam Wathan, the creator of Tailwind has written a very good article on the subject and the rationale for going “utility-first”.

Using these rules, naming conventions and a plugin for Figma - which gets some of the up-front work started - we can generate the beginnings of a Tailwind config file. This config file is used to define the classes which the developers reference in the code.

Whilst this will load some more time up-front in the design process, we were excited about the improvement it would create in the development process, removing a lot of that initial development set-up and the consistencies that would constantly need to be maintained between design and development moving forward.

We decided it was worth putting this to the test and see how it would work in a real-life scenario.

Taking Tailwind for a test-drive

We started by creating a test file in Figma. The team found an amazing Tailwind CSS UI kit file from the Figma community, much thanks goes out to the creator of this, Florentin Eckl. From here we were able to use this for the purposes of testing the process from design to development which saved us a lot of set-up time.

The kit contains already set-up text styles using the Tailwind syntax for the text style names, defined colours again for the default Tailwind values, spacers using Tailwind’s default 4px increments, shadows and more. This gave the team a great system to build a basic layout to try out for the test.

Figma has a feature called “Auto Layout”. It’s an incredibly helpful tool and is constantly being updated to make it even better. Those who use this will know what I mean. But essentially, this feature allows designers to create super flexible and scalable layouts really quickly. This is both great for productivity and for those times when you need to add another row into a form field or a new tab in a card, just pop in place and everything else shifts for you, maintaining the spacing rules you’ve defined.

We wanted to use the Tailwind spacers as part of our design workflow using Auto Layout. This would allow us to create flexible layouts which are using the Tailwind classes as the spacing properties. Keeping everything really consistent and super easy for any designer to pick up and run with.

We created two very simple three card modules, with a simple background variant using the Tailwind library. This was enough to test the use of the design system in nested components. You can see the Figma file here.

We then use the Figma Tailwind CSS plugin from the Figma community to generate a base Tailwind Config file for development. When we ran the plugin, it asked to check and define the following;

• The naming and values for the colours that we had defined in the system were correct

• Confirm the font families used and choose the “base” font-size from the sizes that were available in our text-styles, this would then generate the rem values for the text styles that we had defined in the system

• View and confirm the shadow styles that have been defined in the system

• Preview and optionally “group colors” in the config file

Once this is all complete and we are happy with what is being generated we generated the file and used it for the build process.

Our Tech lead, Chris Till, then took this config and built the design quickly to ensure the inspection was clear and simple and that the implementation was as efficient as we expected.

It was. So far, so good.

So what's next?

There’s not much left to do other than keep trying it! We are actively looking to implement this process into more projects that we feel it will suit. There are a couple of projects in the near future that we think it could work nicely for, and we are excited about giving it a proper run.

Stay tuned for updates on how we are getting on.

Work with Mediablaze

We’re always on the lookout for good people and we are actively looking for a Senior Product Designer to join the team. If this article has been an interesting read for you, then get in touch with me, James Clifton, Lead Product Designer, I’d be delighted to talk with you.

Moreover, if you have a project that would benefit from a bit of Mediablaze flair then get in touch.