Managing a Design System in Android Apps with FigmaExport

The industry’s consensus is clear: design handoff is the most broken process in product development. The solution lies in managing a design system through automation. Specifically, our solution is to use FigmaExport to automate the transfer of design tokens, colors, typography, and visual assets with a custom script for Android Development. This brings quite a few operational wins: 

• For one, it frees up designer/developer time. 
• Secondly, the manual process is error-prone. After all, there is only so long that a developer can copy-paste variables, color hex codes, and crop images attentively. 
• Finally, UIs need to up their accessibility game and account for edge cases and different states. Custom script frees up time and cognitive energy to do that. 
• Most importantly, correctly managing a design system yields at least a 1.5x increase in the startup’s UI output, according to Figma’s own experiment. In it, they measured the impact in hours for a team of 7 engineers, and the output was as if they added 3.5 more engineers to the team.

At You Are Launched, we believe that great design systems are not just about consistency; they are about speed, reliability, and developer experience. FigmaExport enables automation of moving from a Figma design to production-ready Android code.  Our solution shows how to automate the process, at the same time enforcing consistency and freeing developers to focus on building features instead of wrangling resources. This article shows how we use FigmaExport to make design systems maintainable and developer-friendly in Android apps with Jetpack Compose.

Approaches to Managing a Design System: Manual, Corporate AI Tooling, Custom Script

Manual approach: Legacy Style Guides

When design lives as a Style Guide, everything is passive. It is basically a file that says that our brand color is #FF5733, and the fonts are Roboto and Oswald. And it goes on to list all the design choices for buttons in different states, greys, text, icons, etc. The only thing that differentiates it from a printed-out handout is that developers don’t need to retype; they can copy one by one. Developers need to manually copy-paste all the design decisions, download assets, and crop them into different sizes. Following this approach, in the code, developers often ended up doing things like that:

Button(
    colors = ButtonDefaults.buttonColors(
        // Manually hardcoding values for every single UI element is tedious.
        // Plus, you must first translate Figma’s 6-digit hex (#FF5733) 
        // into an 8-digit ARGB format in Kotlin:
        containerColor = Color(0xFFFF5733) 
    )
) { /* Button content here */ }

So, Figma design would specify the values, and developers would use them across the app. The approach depends on hardcoded values, transferred by hand. This results in inconsistent UIs, broken layouts, and an unscalable app that deteriorates user experience as it grows.

Automation of Managing a Design System with Design Tokens

Moving from Style Guides to Design Systems means introducing design tokens. Now the brand colors and fonts live in variables, such as color_primary or spacing_md. This way, they are no longer passive names; they become XML attributes or Compose MDC3 tokens, and thus become executable code. 

This also establishes design living in Figma as a Single Source of Truth. Moreover, this way gives your team complete creative freedom: choose Google’s native Material Design or create a custom bespoke design. For example:

// script reads Figma, generates the Jetpack Compose Material 3 theme files, and 
// maps the  tokens, and the developer uses them in code like that
Button(
    colors = ButtonDefaults.buttonColors(
        containerColor = MaterialTheme.colorScheme.primary 
    )
) { /* Button content here */  }

Why is Automation Preferable? Industry Data

The fact is that the design handoff process generates counter-complaints between designers and developers. At the same time, the industry data shows their almost unanimous agreement that the process needs to be fixed: 91% of developers and 92% of designers attest to that, according to Figma’s research. Furthermore, based on Supernova’s survey, among existing approaches, manual is still the dominant practise. This is likely the reason why counter-complaints keep coming. 

So, the three major ways teams manage the design-to-code handoff process are:

• Manual – 44.5% of teams ; 
• Automated with tools – 43%;
• Automated in a custom way, such as the one we propose.

All in all, the manual handoff is time-consuming, inefficient, and leads to a range of issues.

At the same time, automation with AI tools has a different problem. Usually, these tools generate code for multiple platforms, and, as a rule, it works on screen. However, under the hood, it leads to bloated, hard-to-maintain code and a pipeline that requires overhead. This approach is a standard in the corporate world, but not suitable for early-stage startups and MVPs. 

A bidirectional approach can also be overkill for a startup, as it complicates workflows considerably. However, it is quite viable after the startup achieves the product-market fit. 

What we offer, though, is a lean and pragmatic approach to managing a design system in Android apps for startups and MVPs. It eliminates the waste and mistakes of the manual approach while being very compact and efficient compared to a corporate AI tooling approach. Last but not least, our custom approach helps maintain complete control, enjoy clean code, and ensure great design scaling capabilities. 

Business Benefits of a Custom Script for Managing a Design System

First of all, having a design system reduces the cost of shipping new features, screens, or UI elements. Figma’s own experiment showed that doing any design task is 34% more effective with a design system. Figma also launched a survey to find out the most problematic areas of the design handoff process. 

The value of our custom script for managing a design system is twofold: it provides immediate operational gains and delivers indirect optimizations. 

Direct Gains of Custom Script

As for directly eliminating the listed issues, running an automated script solves the following:

• ‘Assets not exported or wrong format’. This issue means that in over half of the releases (58%), developers manually export images and other assets from Figma. Plus, they have to manually scale them up and down into different sizes. There is a chance of human error, and some images can break on one of the screen sizes. Our figma-export.yaml script will do this work instead of humans, which fully eliminates this problem.
• ‘Outdated designs in tickets’. This problem describes the situation when developers code up the new features based on outdated designs. It is not completely wasted effort, but it will still require significant rework. In our solution, we propose to use the exact Figma file ID (lightFileId: <figma-file-id>). This tethers the codebase to the designs. Then, to update the design, a developer needs to simply rerun the export command. There is no need at all to go and search through Jira tickets or some other project management software.

Indirect Benefits of Managing a Design System with a Custom Script

Our script with FigmaExport frees up tangible hours; the designer and developers can now collaborate on solving other common handoff issues:

• Missing effects such as loading states, hover, or error state changes. This problem affects, on average, 4 out of 5 features. So almost every feature needs more effects than the designer created initially. 
• Missing edge cases, such as rendering unexpectedly long texts or empty states. Once developers complete the feature, e.g., a product card, 3 out of 5 times, there are some sort of issues. For instance,  the product description field expects the description to be within one paragraph, but a few instances come with three paragraphs. Then, it creates an overflow or just stretches the card, breaking the entire layout. Should there be Read more? Or the scroll? If there is a read more, does it open on the same page or lead to a product page?
• Lastly, why do designers miss the accessibility specs and responsive behavior documentation? It might be due to a designer spending hours scaling all export assets manually. With deterministic automation, designers’ cognitive energy is freed to focus on designing systems for better user experiences. 

Last but not least, when design elements go missing, the designer and developers engage in a tedious ‘ping-pong’ communication. While designer-developer collaboration is vital, running a script redefines it. Now, the developers just get the updates into the code instead of constantly asking and copying and pasting them. The value of the script is not simply in automating repetitive tasks; it is more about freeing up mental energy to solve UI/UX challenges instead of arguing over missing bits. 

Introduction to FigmaExport for Managing a Design System

FigmaExport is a utility that automates exporting images, icons, colors, and typography styles directly from Figma into Swift (iOS) or Kotlin (Android) code.

This automated approach helps us:

• Save time: No more converting SVGs into vector drawables or manually preparing raster assets for different screen densities.
• Ensure accuracy: Assets in the app use the exact same names as in Figma, reducing duplication and confusion.
• Enforce consistency: Designers must use the shared design system in Figma, ensuring that the implementation always matches.
• Enable faster iteration: Updating the app’s look and feel becomes as simple as re-running the export script when designs change.

Atomic elements of Figma’s design system: design tokens

Any scalable system relies on well-defined atomic elements, and design tokens are such elements for managing a design system. The industry’s average is between 50 and 300 design tokens per project. Thus, when we mentioned freeing up hours of manual copy-pasting and removing human error, the number of tokens explains this well. 

Each design token is a semantic pair. It includes a variable name and a value. To imagine the risk of error, here are the human actions involved:

• a designer creates the design token in a Figma file;
• a developer reads it on Figma;
• a developer translates it to the Kotlin code;
• a developer maps it to a UI component(s);
• a developer aligns this with dark/light themes.

So, at least 5 human actions per design token, each of which contains a variable name and a value. Then, multiply it by 200, and each of the 2,000 instances carries a human error risk. Can you imagine missing a digit in a color hex code or an underscore in a variable name? These mistakes cause UIs to break and layouts to distort, which, ultimately, causes user experience to deteriorate. Also, consider that design is an iterative activity. So, changing or improving something happens regularly. As such, being able to make changes quickly and without worrying that they will break something is a foundation of successful Android development.

Preparing Figma for Export: Setup and Conventions

Before running exports, your Figma file must follow certain conventions:

• Icons & images: Place them inside frames named Icons and Illustrations, then publish them to the Team Library. (These names can be customized in FigmaExport config.)
• Colors: Define them as published styles. (Note: exporting Figma’s variable colors is still experimental at the time of writing.)
• Typography: Provide text styles with font names. Fonts themselves must still be handed off manually as a one-time step.

For additional details, such as dark mode handling, variable colors, or Dynamic Type support, check the official FigmaExport documentation.

Team Collaboration on Figma: Why This Setup Matters

Another important benefit of automated exporting stems from “Team Collaboration”. Automation requires everyone to follow a certain set of conventions. At first sight, it might seem like extra work, but actually, it enables safe and productive team collaboration.

The stats say that two-thirds of Figma users are non-designers. So, Figma design is often a live document that gets tweaked and used by everyone on the team. While the script itself doesn’t prevent the changes, nor should it, it acts as a gatekeeper and an enforcer. 

Consider this common scenario. 2 sprints after the founder approved the designs, they decide to change the brand color, leaving a comment on the Figma file. The designer can now tweak just a parent design token, and the developer runs the script – the change is reflected in the codebase and the app’s UI. Conversely, when a PM changes the wording on the copy in the design, it does not affect the codebase. FigmaExport works with tokens, not the copy itself. 

All in all, FigmaExport helps to preserve the structural integrity of the codebase and still enjoy the collaborative ecosystem of Figma. 

Integrating FigmaExport with Jetpack Compose for Managing a Design System

FigmaExport provides fine-grained control over how design system code and resources are generated.

In a modularized Android project, the design system module might look like this:

core/designsystem/
└── figma-export.yaml       → Figma export config
└── .figma-templates/       → FigmaExport generation templates
 ├── Colors.kt.stencil
 ├── colors.xml.stencil
 ├── header.stencil
 ├── Icons.kt.stencil
 ├── Typography.kt.stencil
 └── typography.xml.stencil
└── src/
 └── main/
  └── res/
   ├── figma-export-icons/  → Exported vector iconography
   └── figma-export-images/ → Exported raster assets
   

For startups and MVPs, ensuring a clean, modular Android architecture is imperative. By creating a core/designsystem module, the design remains separate from the business logic. So, when a new set of custom icons is rolled out or brand colors change, the change affects the design side of things, and business logic remains unaffected. 

Think about cart functionality, applying a coupon, or calculating the milestones. They all have the iconography that goes with it. However, a developer does not need to touch the feature logic – these features will pull the updated design package automatically as the script exports the designs from Figma to Kotlin code.

It’s not only about saving hours of developer work in case design files are scattered across the codebase. It is also about avoiding extra testing, which saves QA hours or cloud compute in automated testing pipelines. Overall, this saves the codebase from technical debt, provides scalability, and generates direct savings in money and time for the startup.   

Example FigmaExport.yaml Configuration

Here’s a typical figma-export.yaml configuration we use across multiple apps:

figma:
  lightFileId: <figma-file-id>
common:
  colors:
    useSingleFile: true
    darkModeSuffix: '_dark'
  icons:
    useSingleFile: true
    darkModeSuffix: '_dark'
  images:
    useSingleFile: true
    darkModeSuffix: '_dark'
android:
  templatesPath: ".figma-templates"
  mainRes: "src/main/res"
  resourcePackage: "com.sampleapp.core.designsystem"
  mainSrc: "src/main/java"
  colors:
    composePackageName: "com.sampleapp.core.designsystem.resources.figma.colors"
  icons:
    output: "figma-export-icons"
    composePackageName: "com.sampleapp.core.designsystem.resources.figma.icons"
  images:
    format: png
    output: "figma-export-images"
    scales: [1, 1.5, 2, 3, 4]
    composePackageName: "com.sampleapp.core.designsystem.resources.figma.images"
  typography:
    nameStyle: camelCase
    composePackageName: "com.sampleapp.core.designsystem.resources.figma.typography"
    

This configuration maps Figma resources to Android XML and Kotlin code using templates stored in .figma-templates. Default templates are available in the FigmaExport repo.

In simple terms, this file is like the rulebook for your app’s visual identity. For instance, the darkModeSuffix: '_dark' line means that the script automatically knows that the Figma file will have designs for light and dark themes. So, it would know all the color combinations that apply to one and the other without having to manually map them. Another line scales: [1, 1.5, 2, 3, 4] tells the script to slice and scale every asset for budget phones and high-resolution high-end devices. Finally, this bit of code resourcePackage: "com.sampleapp.core.designsystem" makes sure that if tomorrow your startup onboards a new developer, this new person will be constrained to use the exact brand colors and typography. This is sort of a locked-down single source of truth – it contains all approved design choices for the entire Android app.

How to Run the Export Script

To run exports:

1. Install FigmaExport via Homebrew:
   brew install RedMadRobot/formulae/figma-export
2. Set up your Figma API token as an environment variable:
   export FIGMA_PERSONAL_TOKEN=<your_token>
3. Run the CLI tool in your designsystem module:
   figma-export colors or figma-export icons, etc.

This bit here is where startups generate their ROI. This is literally where a multi-day game of telephone between designers and developers is replaced by a developer typing a three-word command and hitting Enter. 

Automated Assets: What Gets Generated in the Android Codebase

Depending on the resource type, FigmaExport generates different outputs. Below are real examples of what you can expect.

🖼️Exporting Figma Icons to Android

Example result for icons: vector drawable XMLs and Kotlin wrappers with @Composable functions for direct usage in Jetpack Compose.

/*  
Do not edit this file!  
  
This file was generated by FigmaExport, any changes made  
to it will be lost the next time the file is generated.  
  
For more details see https://github.com/RedMadRobot/figma-export  
*/  
package com.sampleapp.core.designsystem.resources.figma.icons  
import androidx.compose.material3.Icon  
import androidx.compose.runtime.Composable  
import androidx.compose.ui.Modifier  
import androidx.compose.ui.graphics.Color  
import androidx.compose.ui.res.painterResource  
import com.sampleapp.core.designsystem.R  
object FigmaIcons  
@Composable  
fun FigmaIcons.IcAdd(  
    modifier: Modifier = Modifier,  
    contentDescription: String? = null,  
    tint: Color = Color.Unspecified  
) {  
    Icon(  
        painter = painterResource(id = R.drawable.ic_add),  
        contentDescription = contentDescription,  
        modifier = modifier,  
        tint = tint  
    )  
}

🎨 Mapping Figma Colors to Jetpack Compose

Example result for colors: XML resource definitions plus Kotlin wrappers exposing them as Compose Color.

<?xml version="1.0" encoding="utf-8"?>  
<!--  
Do not edit this file!  
  
This file was generated by FigmaExport, any changes made  
to it will be lost the next time the file is generated.  
  
For more details see https://github.com/RedMadRobot/figma-export  
--> 
<resources>  
    <color name="basic_green">#188519</color>  
    <color name="basic_red">#CC0025</color>  
    <color name="basic_white">#FFFFFF</color>
</resources> 
/*  
Do not edit this file!  
  
This file was generated by FigmaExport, any changes made  
to it will be lost the next time the file is generated.  
  
For more details see https://github.com/RedMadRobot/figma-export  
*/  
package com.sampleapp.core.designsystem.resources.figma.colors  
import androidx.compose.runtime.Composable  
import androidx.compose.runtime.ReadOnlyComposable  
import androidx.compose.ui.graphics.Color  
import androidx.compose.ui.res.colorResource  
import com.sampleapp.core.designsystem.R  
object FigmaColors  
@Composable  
@ReadOnlyComposable  
fun FigmaColors.basicGreen(): Color = colorResource(id = R.color.basic_green)

✍️ Automating Typography and Font Styles

Example result for typography: XML styles and Kotlin TextStyle definitions for Compose.

<?xml version="1.0" encoding="utf-8"?>  
<!--  
Do not edit this file!  
  
This file was generated by FigmaExport. Any changes made  
to it will be lost the next time the file is generated.  
  
For more details, see https://github.com/RedMadRobot/figma-export  
-->  
<resources>  
    <style name="bodyMedium">  
        <item name="android:fontFamily">@font/almarai_regular</item>  
        <item name="android:textSize">10.0sp</item>  
        <item name="android:letterSpacing">0.02</item>  
    </style>  
</resources>  
/*  
Do not edit this file!  
  
This file was generated by FigmaExport, any changes made  
to it will be lost the next time the file is generated.  
  
For more details see https://github.com/RedMadRobot/figma-export  
*/  
package com.sampleapp.core.designsystem.resources.figma.typography  
import androidx.compose.ui.text.TextStyle  
import androidx.compose.ui.text.font.Font  
import androidx.compose.ui.text.font.FontFamily  
import androidx.compose.ui.unit.sp  
import com.sampleapp.core.designsystem.R  
object FigmaTypography {  
    val bodyMedium = TextStyle(  
        fontFamily = FontFamily(Font(R.font.almarai_regular)),  
        fontSize = 10.0.sp,  
        letterSpacing = (0.2).sp,  
        lineHeight = 14.0.sp  
    )  
}

⚠️ You still need to manually add fonts to your project’s resources

🖼️ Slicing and Scaling Raster Images Automatically

When it comes to image resources, FigmaExport imports them into the figma-export-images resource folder according to its configuration. The export is done in all of the specified resolution scales, and the result is saved into the Android’s dpi qualifiers structure.

No Jetpack Compose wrappers are generated. To use exported assets, use painterResource with the Image composable

Image(   
    painter = painterResource(R.drawable.img_content_search_placeholder),  
    contentDescription = "No results found"  
)

Optionally, images can be converted to WebP format with configurable compression:

images:  
  format: webp  
  webpOptions:  
	# Encoding type: lossy or lossless  
    encoding: lossless  
    # Encoding quality in percent. Only for lossy encoding.
    # quality: 90
  output: "figma-export-images"
  

⚠️ For the conversion to work, you must have the WebP utility installed. For example, using the homebrew brew install webp

Conclusion: Driving ROI by Managing a Design System with Automation

Managing a design system across design and development doesn’t have to be repetitive or error-prone. By adopting FigmaExport, we’ve automated one of the most tedious parts of app development – ensuring that colors, icons, typography, and images flow smoothly from canvas into code without a single Slack message.

For Android developers working with Jetpack Compose, this means:

• Faster iteration cycles
• Less manual asset handling
• Enforced consistency with the design system

At You Are Launched, this approach lets us spend less time on boilerplate and more time crafting the experiences that matter. If you’re building apps with a strong design identity, FigmaExport is the tool that will make your design system truly scalable.

Choosing a lean and pragmatic approach to your app’s design handoff process ends up being a strategic lever for your startup’s speed-to-market and growth. Managing a design system the way we propose increases your startup’s UI output, protects your business logic, and establishes a single source of truth when it comes to design decisions. This reduces the re-testing of business logic components, eliminates human error, and saves cloud compute costs for CI/CD pipelines. Business-wise, utilizing FigmaExport gives your startup the flexibility of creative freedom, agility to pivot and scale, all the while shipping production-ready UIs at a fraction of the ‘manual way’ cost.

FAQ: Managing a Design System in Android Apps with FigmaExport