POV
/
12.04.21
/f/108600/2680x1508/eefa93a998/tailwind.jpg)
Product Process
This is a follow-up article to Using Tailwind to remove inefficiencies between Product Design and Engineering. We'd suggest reading that first, if you haven't already.
In this piece, we'll look at:
The problems we encountered in the existing Tailwind CSS UI Kit for our process and what we did to solve them
How we have altered and used the Tailwind kit to build robust and scalable components
How we've structured our Figma files for a better engineering process without lengthy documentation
First off, the Tailwind CSS UI Kit is a brilliant starting point. It helped us to try out the Tailwind process quickly to see if it was a viable option for us, and helped us build a solid base system for future projects.
However, as we began using the system in our process, we found a few issues with the way it’s currently set up. 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 spacing inside and outside of components to remove any inconsistencies. With the idea of the developer not needing to know the base spacing values, we needed to ensure there were spacer components being used to define the classes.
We then noticed that the spacers, by default, use a fill colour which would cause problems when showing the design to clients. It would result in the designer having to turn off the fills for each spacer and turning them on for the developer, resulting in inefficient use of time.
/f/108600/2590x1108/1bf1baf418/tailwind-spacers-problem.png){kind=spacer}
Solving the spacers problem
Figma’s frames feature allows you to create nested layouts and grids in your designs. It’s also really handy for showing constraints within a component or an area. This feature makes it really easy to turn the visibility of layout guides on and off in Figma (Ctrl + G, even on a mac!) so we felt this could be a way of managing the spacers in the design file.
/f/108600/2000x968/0f643efdbc/tailwind-hidden-spacers.jpg){kind=spacer}
The only downside to this is that it makes it a little harder for the developer to highlight the spacer components, as they don’t have a fill attribute. But, for us, the trade-off was worth it in terms of balancing the effort between our teams.
Strangely, by default, the existing components in the file don’t seem to use the spacers to structure them. So we amended these to use the spacers properly in the components. This was really simple, using Auto Layout in Figma, and allowed us to create robust and scalable components, saving time and effort across the board.
One process we’ve been working on internally, and were able to formalise here, was using primitives for Figma Variants in our components. We therefore had a master structure for all of the component variants, which was used as a nested component in each. This made managing changes much easier and works well with the spacers and text styles.
/f/108600/2294x1104/87fb80fbf9/primitive-button-component.png)
The default system contains a lot of colours, based on the Tailwind default colour classes. We prefer to name our colours based on their use case, rather than a description of the hue. This way, the colour name is agnostic and it doesn’t cause syntax issues if the hue is changed at a later date and no-longer matches.
In this instance, we simply stripped out all the colours that we were unlikely to use, and used the same naming conventions for the layers and the colour styles.
/f/108600/2520x1718/bb8757d40b/stripped-out-colours.png)
One of the issues we sometimes have with the translation between design and engineering is removing any confusion and noise from the design so that the engineers are crystal clear on what they’re building.
Sometimes, as designers, we prefer to have lots of artboards and visual elements in a single view. This can help with workflow as well as speed things up when using references or similar areas of a design to inform the area you’re working on. However, if time is tight and things are unclear, it can create issues for the engineering team.
/f/108600/2330x1350/c9aa63e9a8/cluttered-figma-file.png)
With the small projects we were trialling Tailwind on – the first being a simple brochure design and build, and a small single page product – there was an opportunity for enhanced clarity between design and engineering teams. Projects of this size don’t need too many layers of process, however it’s really important to maintain the quality of each stage to ensure nothing is lost in translation, and that there is no wasted effort in either discipline.
We aimed to define a Figma page structure quite quickly which breaks the file down into each block (Storyblok uses the term 'blocks' for each 'module' 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, and it’s 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 were then taken into a Google Sheet. This document contained a frontend sheet with considerations for Storybook (where we manage and test frontend components) and a backend sheet with considerations for Storyblok, where we define which components are used for different blocks, plus the fields needed for that instance of the component in the CMS.
/f/108600/2950x1430/fee5b12230/block-definitions.png)
To ensure we weren’t constrained by any Tailwind technical specifics when exploring aesthetics and discussing designs with the client, we started detached from the system. Moreover, at this stage we tend to design more freely, giving the client an idea of the style we are working towards, our inspiration and how we intend to move forward with the design.
As the design is refined, things begin to take shape, and this is when we start making calls on Design Tokens. Design Tokens are values or elements that are defined as rules or presets for a design system, like colours.
We then use those tokens to create larger elements (atoms, molecules and organisms at a system level) which ensures consistency throughout the design and helps to maintain a simpler build process.
These tokens are what 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. Fortunately for us, as we already have a base system in place, it’s about stripping out all the unneeded styles, amending existing ones to what we need, and then building on that which gives us a solid base. This saves us a whole lot of time rather than creating a system from scratch for each project.
Now it’s time to start setting things in stone, preparing the 'blocks' for use in the designs and passing these on to engineering.
Now that we’ve spent so much time ensuring the foundations are in place, we can begin to define the components and blocks for the design.
Depending on the size of the project, we might end up using a full atomic design principle. This would involve designing things at their smallest element level (atoms), then nesting those into larger elements (molecules) and again into even larger elements (organisms). However, with the size of the projects we were designing for at this stage, this level of nesting wasn’t needed. So we created the main components that we knew were being reused across the project (e.g. cards, buttons).
We then hid these away in the Figma pages under a page section marker (an empty page which has the name “-----------”, giving the pages in Figma a visual grouping). Anything below the marker wasn’t relevant to a developer in order to build the blocks that were listed above, helping them navigate the page.
/f/108600/756x678/2c272c32ff/figma-page-structure.png)
We used a traffic light system to show project and product management the status of the block from a design point of view.
Once each block was ready, we referenced it as a component into a separate file which contained the UI of the pages themselves. This aids client sign off as well as preparing the development-ready blocks in a single place, even when they aren't fully defined. Win win.
Due to the way we break the blocks down, there’s no limit to the number of blocks that can be designed. We wanted to try and keep blocks to a minimum to reduce effort, but not to the detriment of the design creativity itself.
As a team, we went over the different blocks and worked out which could be merged from a front-end structure perspective. Take the following, for example. If there's a block which has an image on the left, a heading on the right with body copy beneath it and a button, we don’t want to have a completely separate block if that block doesn’t have an image. It should simply be the same block, and if the user doesn’t define an image, then it’s not shown. The same goes for having the image on the left or the right, it should simply be a toggle for the user to specify 'image right' rather than the default of 'image left'.
/f/108600/1465x1124/b64877d9ce/block-variants.png)
Using this method and collaborating with product management and engineering, we were able to drastically reduce the number of unique blocks to 15 rather than 40+. This makes things much easier for the client to manage in the CMS when building their own pages.
It’s important to note here that this wasn’t an easy process, but doing this upfront reduces a lot of headaches further down the line.
This part was relatively straightforward because we had done so much of the thinking already. At this stage, it was just about formalising the blocks with the Tailwind styles and spacers as discussed in our previous article.
The brochure build project wasn’t difficult at this stage as the client had a simple aesthetic to their brand which they wanted to maintain throughout the design. This made for a nice and quick design process for these blocks and meant that the use of Tailwind was very straightforward. The blocks themselves mainly use large typography elements which were great to work with.
/f/108600/987x1233/87bdac111e/brochure-site-tailwind-example.png)
The small single page product had a slightly more complex structure to it, with smaller nested components in each block which helped us to pressure test the Tailwind process a bit further. But it proved to be brilliant to design with and sped up the build process.
/f/108600/1028x1038/783c0c418e/fuel-calculator-tailwind-example.png)
In our next piece in this series, we'll discuss how the development process with Tailwind went, and if it was as good as we were hoping it would be. We will discuss the handoff of that configuration file and the designs to developers, as well as some of the challenges we faced in that process.
If you have a digital design and build project that would benefit from iCrossing's design flair then please get in touch.
/f/108600/2680x1508/b3e305a229/tailwind-article1-featured.jpg)
/f/108600/2121x1414/0700c3e0c2/balancing-childcare-working-from-home.jpg)
/f/108600/1920x1280/eddb67683c/arek-adeoye-ljocgjs63sm-unsplash.jpg)
Contact
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.