POV

/

12.04.21

Using Tailwind to increase efficiencies between product design and engineering

Product Process

We don’t consider product design and product engineering to be two separate teams; we're a single team working towards the same goals. 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 streamline product design and engineering processes. We'll cover:

  • The problems Tailwind can look to fix in your product design-to-engineering process

  • What a utility-first CSS framework like Tailwind is

  • How the Figma Tailwind CSS plugin helps to keep design and development in sync to increase efficiencies

Identifying the problem

We noticed that ensuring what the developers build matches the design output was a time drain in the team. 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 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.

As we explored 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 great 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 how it would aid 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, seeing 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 to test 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. Essentially, this feature allows designers to create super flexible and scalable layouts really quickly. This is great for both 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.

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:

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, confirm the shadow styles that have been defined in the system Preview, and optionally 'group colours' in the config file.

Once this was all complete, 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, and there are a couple in the near future that we think it could work nicely for.

Stay tuned for updates on how we're getting on...

Continue reading
ix-chevron-bg

Contact

Are you ready to make a digital step-change?

We believe that moving too slowly in digital is the biggest risk your business faces. If you are ready to move faster in digital, we are here to help.

Get In touch