The design industry has been trying to revolutionize design handoff for a while now. On one hand, we have traditional design handoff tools, which translate no more than Figma properties to styling code.
On the other hand, we have design-to-code tools, which produce complete code but tend to be extremely overzealous. On the whole, design handoff hasn’t really hit the mark; however, Anima might be on the verge of solving design handoff using AI.
In this article, I’ll clarify what’s wrong with design handoff in its current state and demonstrate how Figma and Anima can fix it.
The problem with traditional design handoff tools such as Figma’s “inspect” tool is that they only translate properties (e.g., Fill) to styling code (e.g., CSS). They do so reliably, but it doesn’t save developers a significant amount of time.
On the other hand, design-to-code tools turn designs into “complete” apps and websites but rarely allow developers to specify their output preferences (in regards to naming conventions, for example). In addition, the output is often inaccessible, bloated, and with little SEO. Plus, code generated from individual design elements are unlikely to work in an existing codebase, so design-to-code is often a start-from-scratch type scenario.
One “upside” to design-to-code is that some tools tether the design to the code so that there’s a single source of truth — if the design changes, so does the code, although it doesn’t really matter if the code isn’t good. This is why traditional design handoff tools use versioning features to keep developers up-to-date on design changes, and manual coding is the lesser of two evils.
However, Anima converts designs into rather clean React, Vue, HTML, JavaScript, TypeScript, CSS, and Tailwind code, providing developers with quite a boost compared to other design-to-code tools.
What truly makes Anima stand out, though, is its AI tools, enabling product teams to generate code with better SEO, better accessibility, plus, well…anything that can be described in an AI prompt. You can convert individual design elements or entire designs to code — it’s all up to you (or the developer, rather).
Let’s dive in.
When it comes to UI design tools, there’s often confusion surrounding variables and styles because they can both be used to make properties reusable. However, they translate to code differently, so this is a good time to establish what the rules are.
Firstly, store any reusable properties as Figma variables, then use those variables to create Figma styles. Now, instead of editing several styles that use a property, you can just update the variable, and it works the same way for code (for example, Figma variables translate to CSS variables and Figma styles translate to CSS classes). Use components in Figma, too.
Auto layout in Figma helps you create responsive structures in your designs, which Figma and Anima then translate to styling code.
Anima takes things a step further by generating the markup code, too. I think we’re all using auto layout quite liberally at this point, so this is just a reminder to continue with that, especially if you’re using Anima — less auto layout equals less responsive code.
When it comes to websites, auto layout mostly translates to Flexbox code (probably something similar for other platforms). However, grid layout code is usually preferred for grids, which Figma doesn’t support and isn’t the default option for Anima.
This means that developers (or designers, if they want to be helpful) will need to play around with Anima’s AI. Don’t worry — I won’t have you writing AI prompts or anything like that, because Anima has a grid preset. Before we activate that though, we need to ensure that we’re implementing auto layout correctly.
Previously, the way to simulate grids in Figma was to auto layout the rows and columns individually, but then we’d end up with auto layouts within auto layouts rather than true grids, which is fine for prototypes but doesn’t translate to code that well. Dev Mode would show the faux grid as individually existing rows and columns (columns within rows in my case):
However, auto layout has a new-ish Wrap option (it’s right after Vertical layout and Horizontal layout) for this exact scenario, so ungroup (command + shift + G / ctrl + shift + G) all of the frames that represent rows and columns. Now, the grid items are free-flowing inside of the grid container.
Next, set the auto layout of the grid container to Wrap. No rows, no columns, just a container with auto layout set to wrap:
From here, Figma inspect translates auto layout wraps to flex-wrap code, which is fine for some scenarios but not all; so to be on the safe side, you’ll want to go into Anima and activate the grid preset. To do this, start by toggling on the Dev Mode toggle (right side of the horizontal toolbar, or shift + D):
Next, switch to the Plugins tab (right sidebar), search for Anima using the search input, then select Anima when it comes up:
After that, make sure that you have the top-level frame selected, then click on the Edit AI Personalization button:
Finally, navigate to Presets > Responsive Design > select Use CSS grid > click on the Done button:
This will make Anima’s AI generate CSS grids when they’re the more suitable option and generate CSS flexboxes otherwise.
Semantic HTML elements (e.g., <main>Main content</main>) are those that provide more context than the generic divider element (e.g., <div>Generic division of content</div>). Some of them have unique qualities (<button>s are clickable), whereas others contribute to accessibility (see: HTML landmarks) and search engine optimization (<h1>Heading 1 content</h1>).
To make Anima generate semantic HTML instead of making most elements a <div>, you’ll need to activate the SEO friendly preset:
I also recommend describing your layers appropriately. If you name your layers nonsensically or display nonsensical text such as “akasdhasdkahda” (lol), Anima’s AI will get terribly confused and blurt out some nonsensical code.
In fact, if you learn the names of semantic HTML elements (there aren’t that many) and use them in/as your layer names where applicable, that helps Anima’s AI a lot. If you’re not really interested in doing that, a low-effort, high-impact trick is to wrap your main content in a frame called Main.
Since HTML documents can only contain one <main> element (this helps users that use screen readers skip to the main content), Anima’s AI usually wraps the content after it in a <footer> and the content before it in a <header>, usually with a <nav> inside (also useful for screen readers).
To establish an accessible heading structure, H1, H2, H3, H4, H5, and H6 (<h1>, <h2>, <h3>, <h4>, <h5>, and <h6> in HTML) are the keywords that you’re looking to use in your layer names. H1s are for main headings, H2s are for subheadings, H3s are for subheadings of subheadings, and so on.
Headings are hit-and-miss with Anima’s AI, but I find that Smart mode tends to produce better results than Fast mode.
If you need to demonstrate a responsive design using multiple top-level frames, you can use Anima to generate the responsive code for it, too, saving developers even more time. On the web, this code is called media query code.
Start by selecting the top-level frames (e.g., the mobile version, desktop version, etc.), then click on the Breakpoints button:
Next, name the breakpoint via the Responsive page title field (this doesn’t affect the output at all), then click on the Save page button:
Using Anima, we can ensure that simulated inputs output as functional inputs, and as the right type with some necessary validation rules. However, this requires a different approach.
Start by toggling off dev mode (shift + D). Next, select the text layer that needs to output as a functional input, navigate to Resources (shift + I) > Plugins from the horizontal toolbar, then search for and select Anima:
After that, Switch to Full flows code from the Anima modal:
Finally, choose Text input before defining its settings on the next screen:
Yes, but designers must take more care and time with their designs, as demonstrated in this article. The end result, though, is that product teams will build faster overall. It’s definitely worth trying out, at least.
This doesn’t mean that developers won’t need to customize the generated code, because they will, but this won’t involve fixing it or trimming it as much as it will building on top of it. In addition, there are even more features in the Anima plugin that can be used to improve the generated code output — these are more developer-centric though, which is why I didn’t talk about them.
Anima isn’t an all-or-nothing type situation either, since developers can choose to translate designs to code component-by-component. Anima isn’t trying to be a magic bullet like most design-to-code tools, just a helpful tool that product teams can utilize a little or a lot.
For example, if you want to generate a complete, production-ready app or website in just a few clicks (and maybe even host it), you can totally do that (although more developer involvement will obviously produce a better result).
One downside though is that Anima isn’t a design system management tool. If using AI, developers will need to store the code somewhere else because not only will the code change as the design changes, but the AI might generate the code differently every time. Developers should store it using GitHub, Storybook, or something similar after making any changes they might need to make.
If you have any questions, drop them into the comment section below (the Anima documentation is pretty good, though), and thanks for reading!
LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Adobe XD is Adobe’s version of Figma – but does it match up? This blog is an attempt at decoding the good and bad of both, and figuring out which one is best used for which use case.
Subscription pages are meant for users and businesses, and they should work well for both parties. This blog is a thorough discussion of what’s best and what’s not when it comes to designing subscription pages.
Call it what it is. Product designers and UX designers have unique roles, even if their titles often get swapped. In this blog, know the difference and own your expertise.
Search bars are more than icons and inputs — they can be a retention magnet or a churn trigger. Sharing my tried-and-tested search bar design principles in this blog!
Learn more →
