How we tackled the challenges of the Tailwind CSS UI Kit for Figma
In our last article we talked about how we continually strive to improve our processes and deliver better products for Mediablaze clients
So how have we found the kit so far?
The Tailwind CSS UI kit helped us to swiftly assess the viability of the Tailwind process, and gave us a platform on which to create a base system to use in future projects. But it wasn’t seamless…
We found several issues with the way the Tailwind UI kit is currently set up. For example, some of the existing components — namely the buttons and inputs — aren’t built with the spacers themselves. We wanted to ensure that spacers were used for all padding and margin of components to remove any inconsistencies.
When investigating this, we discovered that the spacers use a fill colour by default. This would cause problems when showing the design to clients, requiring the designer to turn off the fills for each spacer and turn them on for the developer. It is exactly these inefficiencies we want to avoid.
Solving the challenge of spacers
Figma’s frames feature allows the creation of nested layouts and grids in designs. It’s also useful for showing constraints within a component or an area. This feature facilitates turning on and off the visibility of layout guides in Figma (Ctrl + G) so we identified this as a way of managing the spacers in the design file.
Fine tuning the Inputs and Buttons structure
The existing components in the file don’t use the spacers for structuring, so we amended these using Auto Layout in Figma. This allowed us to create really robust and scalable components, saving time and effort.
Ordering the primitives
One process we were able to formalise was using primitives for Figma Variants in our components, a task we have been working on internally. This gave us a master structure for all the component variants, and this was used as a nested component. This made managing changes much easier, and means the spacers and text styles work seamlessly.
Renaming the colours
The default system contains a wealth of colours, each based on the Tailwind colour classes. But at Mediablaze we like to think ahead. We prefer to name our colours based on their use case, rather than their hue, thereby avoiding syntax issues if the hue is changed at a later date.
To address this, we stripped out the colours we were unlikely to use and used the current naming conventions for the layers and the colour styles.
Creating a Tailwind and Storybook workflow
It is important to avoid any confusion and noise in the design file so that the engineers understand exactly what they’re building.
We tested Tailwind on two relatively simple projects: a classic brochure design and build, and a small, single page product. These gave us an opportunity to ensure that communication between design and engineering was clear and straightforward.
We aimed to swiftly define a Figma page structure to break the file down into each block (Storyblok uses the term ‘blocks’ for each ‘module’ or ‘strip’ of a website). This way, the only visual elements in that page are the exact design elements that have been linked in the Jira ticket. This makes it easier to communicate what needs to be built.
In collaboration with the product owner, project manager and the lead developer for the project, the structure of these blocks was taken into a Google Sheet. This is where we manage and test frontend components, and define which elements are used for different block components, as well as the fields needed for that instance of the component in the CMS.
Making calls on Design Tokens
We began the design process detached from the system in order to ensure it wasn’t constrained by any technical specifics using Tailwind. At this stage we tend to design more freely, giving the client an idea of our style, inspiration and how we plan to progress the design.
As the design becomes more refined, we start making calls on Design Tokens — the values or elements that are defined as rules or presets for a design system, such as colours.
These tokens are used to create larger elements (atoms, molecules and organisms at a system level), which ensures consistency throughout the design and facilitates a simpler build process.
Design Tokens make up the different styles within the Tailwind design system and are defined in the Tailwind config, which we export using the Figma Tailwind CSS plugin.
Building on the foundations
With the foundations in place, we started to define the components and blocks for the design.
We didn't need to employ a full atomic design principle due to the size of the projects. Instead we created the main components being reused across the project (e.g. cards, buttons). These were hidden away in the Figma pages under a page section marker, which helps the developer to navigate the page based only on what is relevant to them.
We used a traffic light system to show the design status of each block both to project and product management, enabling the ongoing visibility and status of the project.
Once each block is ready, we reference that block as a component into a separate file which contains the UI of the pages themselves. This approach accelerates client sign off and enables us to start preparing the development-ready blocks in a single place, even before they are fully defined.
Merging blocks to simplify the CMS experience
There is no limit to the number of blocks that can be designed, but we try to balance maximum creativity with minimum blocks, in order to optimise effort.
As a team, we worked out which blocks could be merged, and by collaborating with product management and engineering we substantially reduced the number of unique blocks from 40 to 15. This isn't an easy process, but doing this upfront reduces potential problems further down the line, and makes it easier for the client to manage in the CMS.
Block design
Next we formalised the blocks with the Tailwind styles and spacers (as discussed in our previous article). The client had a simple brand aesthetic which they wanted to maintain throughout the design. This made for a swift design process, and Tailwind was very intuitive.
The small single page product had a slightly more complex structure to it, with smaller nested components in each block. This helped us to pressure test the Tailwind process further. It was great to work with, as well as accelerating the build process.
Now for the next project...
Talk to Mediablaze
If you have a digital design and build project that would benefit from a bit of Mediablaze flair, please get in touch.