- Product design & build
This is a follow-up article to the Using Tailwind to remove inefficiencies between Product Design and Engineering. If you haven’t read it, it’s worth checking it out first.
In this article we will look at the following:
Issues we discovered with the Tailwind CSS UI Kit for Figma
First off, the Tailwind CSS UI kit is a brilliant starting point. It both helped us to try out the Tailwind process quickly to see if it was a viable option for us, and it gave us a solid base to build off of to create a base system for us to use in 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 being used.
When we were looking at this, we came across the problem 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.
Moulding the Tailwind UI Kit to our liking
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 on and off the visibility of layout guides in Figma (Ctrl + G, even on a mac!) so we felt this could be a way of managing the spacers in the design file.
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 we felt the trade-off here was worth it in terms of balancing the effort between our teams.
Amending the Inputs and Buttons structure
Strangely, by default, the existing components in the file don’t seem to use the spacers to structure them. So we set about amending these to use the spacers properly in the components. This was really simple using Auto Layout in Figma and allowed us to create really robust and scalable components, saving time and effort across the board.
One process we’ve been working on internally and were able to formalise in this process was using primitives for Figma Variants in our components. This meant that we had a master structure for all of the component variants which was used as a nested component in the variants. This made managing changes much easier and works well with the spacers and text styles all set up and working nicely.
Colours, colours everywhere
The default system contains a lot of colours. These are 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 as were currently being used. This seemed to work nicely.
How we’ve set up our Figma files for a Tailwind and Storybook workflow
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 and it also speeds 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.
With the projects we were looking to try Tailwind on, the first being a simple brochure design and build and a small single page product, there was an opportunity to make these simpler projects really straightforward and clear between design and engineering. 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” 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 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 block components, plus the fields needed for that instance of the component in the CMS.
I could go into a lot more detail around this, but I think that’s probably best left for another article!
Exploration and UI Definitions with Design Tokens
To ensure we weren’t constrained by any technical specifics using Tailwind, we started detached from the system. This enables us, when exploring aesthetics and discussing designs with the client, to not be too constrained in how we design the pages. 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 gets more 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. Colours are a great example of a Design Token, a shadow style, an individual text style, these are all examples of Design Tokens.
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.
To summarise, Design 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 to build on. This saves us a whole lot of time rather than creating a system from scratch for each project.
Now it’s time to start getting things a bit more solidified and preparing the “blocks” for use in the designs to pass onto engineering.
Keeping the Figma system structured and scalable
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), which still do have some nesting, but we didn’t explicitly define the breakdown of the atomic principles.
We would then hide these away in the Figma pages under a page section marker, this is just an empty page which has the name “-----------” which gives 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 so it helps navigate the page.
We used a traffic light system to show both to project and product management the status of the block from a design point of view, which really helps with ongoing visibility and status of the project. Yes we can use Trello or Jira, but at this stage simplicity is key.
Once each block is ready, we reference that block as a component into a separate file which contains the UI of the pages themselves - we find this approach aids client sign off. Moreover, working this way we are already preparing the development-ready blocks in a single place, even though they weren’t fully defined yet. Win win.
Merging blocks to reduce overall count and simplify CMS experience
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 at the detriment to the creativity of the design itself.
As a team, we went over the different blocks and worked out which could be merged from a front-end structure perspective. For instance, 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 simply 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”.
Using this method and collaborating together with product management and engineering we were able to drastically reduce the number of unique blocks into 15 rather than over 40. This makes things much easier for the end client to manage in the CMS when managing and building their own pages.
It’s important to note here that this wasn’t an easy process, and there were some long calls to get this right, but doing this upfront reduces a lot of headaches further down the line.
Designing those blocks
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.
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 greatly.
So what’s next?
Next time, we will 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 config file and the designs to developers and some of the challenges we faced in that process.
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, to discuss more.