Design Tools and AI-Assisted Workflows Questions

Direct answer

A reliable export process fixes four things ahead of time so exports are predictable rather than ad hoc: the right format per asset type and platform, an explicit set of scale factors per platform, a naming convention developers can script against, and an optimization pass before handoff, then exports assets in batch rather than one at a time.

Structured elaboration

1. Choose format by asset type and destination. Icons and simple vector marks export as SVG (Scalable Vector Graphics, an XML-based vector format that stays crisp at any size and can be recolored with CSS) for web; on iOS and Android, a vector format is also usable where the platform's asset system supports it, otherwise export flattened rasters at each density instead. Complex raster imagery, photos, gradients, detailed illustration, exports as PNG when lossless quality or transparency is required, or a modern compressed format for web where file size matters more.

2. Scale factors per platform.

• iOS uses @1x/@2x/@3x naming, the same asset exported at one, two, and three times its base pixel size to match device pixel densities.
• Android uses density buckets: mdpi as the 1x baseline, then hdpi (1.5x), xhdpi (2x), xxhdpi (3x), xxxhdpi (4x), each exported into its own density-named folder.
• Web typically exports at 1x and 2x (sometimes 3x) for responsive image sets, or ships a single SVG that needs no scale variants at all.

3. Naming conventions developers can script against.

• iOS: base-name@2x.png, base-name@3x.png, following the platform's own suffix convention.
• Android: lowercase with underscores only, inside density-qualified folders (drawable-xhdpi/icon_name.png); Android's resource system rejects hyphens or uppercase letters in resource filenames, so this isn't a style choice, it's a build requirement.
• Web: kebab-case, e.g. icon-search.svg, consistent enough for a build script to glob and import predictably.

4. Optimize before handoff, including SVGs specifically. Raster exports get compressed to a sensible quality-versus-size trade-off rather than maximum quality regardless of size. SVGs get run through an SVG optimizer that strips editor metadata, redundant groups, and unnecessary path precision left behind by the design tool's own export, so what ships is a clean file, not a bloated raw export.

5. Batch and verify. Export whole frames or sections at once using each tool's export presets rather than one asset at a time, then spot-check a few files at their real target size and density before sending them over, since a scale-factor mistake shows up immediately at high density.

Worked example

A search icon needs to ship to iOS, Android, and web from one 24 by 24 vector source. For web: export as search.svg, run it through an SVG optimizer, and ship it as-is, no scale variants needed since it's vector. For iOS: export as a vector asset the platform's asset catalog can use at any scale, or, if the pipeline needs flattened rasters, export search@1x.png, search@2x.png, search@3x.png at 24, 48, and 72 pixels. For Android: export into drawable-mdpi/search.png (24px), drawable-hdpi/search.png (36px), drawable-xhdpi/search.png (48px), drawable-xxhdpi/search.png (72px), and drawable-xxxhdpi/search.png (96px), scaling off the 24px mdpi baseline, with filenames lowercase and underscore-separated throughout.

Trade-offs and pitfalls

Skipping the optimization pass ships editor cruft, hidden layers, overly precise path data, that bloats app or page size with no visual benefit; it's a nearly-free step that's easy to forget under deadline pressure. Defaulting to PNG everywhere instead of vector where vector actually applies needlessly multiplies the number of density-specific files that have to be generated and kept in sync. Getting Android's naming rule wrong, a hyphen or a capital letter in a resource filename, isn't a style nitpick, it fails the build outright, so it's worth catching at export time rather than letting engineering discover it later.

Direct answer

Use a hierarchical, slash-delimited convention of component, then property, then value, rather than free-text names, because a design tool like Figma turns forward slashes in a name into folder-like groups in its asset browser, and for a proper component with defined variant properties, exposes those same segments as filterable dropdowns rather than as separate, unrelated names.

Structured elaboration

Core pattern: name from general to specific, component/property/value, e.g. button/primary/large, input/text/disabled. This mirrors how someone actually searches: they usually know the component ("button") before they know the exact variant they need.

Casing and separators: pick one style, lower-case with hyphens for multi-word segments, e.g. icon-button/social/facebook, and enforce it everywhere, so a search for "button" reliably surfaces every button-family layer regardless of who created it.

Variant properties, not just names: for a real component with combinable variants, define each axis as its own variant property (State: Default, Hover, Disabled; Size: Small, Large) rather than encoding every combination into one long string. Mechanically, that means building each combination first as its own separate component (a Default/Small button, a Default/Large button, a Hover/Small button, and so on), selecting all of them at once, and running Figma's "Combine as variants" action (from the right-click menu, or the button that appears in the toolbar once multiple components are selected). That merges the separate components into a single component set, and Figma auto-detects the differing part of each one's name to make a first pass at the property axes; from there you open the component set's properties panel and rename each auto-generated property ("Property 1", "Property 2") to something meaningful ("State", "Size") and clean up its list of values. This is what actually produces a searchable, filterable dropdown in the panel; a flat text name is just a label, it doesn't give you that behavior on its own.

Frames and layers get named by role, not by shape. A frame represents a screen or section and should be named the way a user would describe that screen ("Checkout / Payment step"), not by position ("Frame 12"). Groups and layers inside get named by what they are ("Icon - chevron down"), not by their default shape name ("Vector 4").

Scaling across teams: publish the naming rules in the design-system documentation rather than leaving them as tacit convention, and enforce lightly, for example a spot-check by the design-system owner before a new component is published, since informal conventions drift once more than one team contributes to the same library.

Worked example

A design-system team publishes a Button component with variant properties Type (Primary, Secondary, Ghost), Size (Small, Large), and State (Default, Disabled). In the insert panel this shows up as one searchable "Button" entry with three dropdown filters, instead of the twelve separately-named components those three axes actually multiply out to (3 types x 2 sizes x 2 states = 12 combinations), things like "button-primary-small" and "button-primary-large-disabled" sitting side by side with no relationship to each other. That multiplication is the point: every axis you add multiplies the flat-naming cost while leaving the variant-set cost flat at one entry with one more dropdown, which is why the gap widens exactly as a library grows. A form team building a signup screen searches "input," finds input/text/disabled and input/text/error as clean, predictable siblings. A second team, months later, building an unrelated settings screen and never having talked to the first team, guesses the same search term and lands on the same family; that's the discoverability payoff in practice. On developer handoff, an instance named Button > Primary > Large shows up in the tool's inspection view with that same readable path, letting the engineer identify exactly which design-system component and variant to reference in code, instead of guessing from a name like "Rectangle 219."

Trade-offs and pitfalls

Nesting more than two or three meaningful segments becomes as unreadable as having no convention at all, so resist the urge to encode everything into the name. A convention nobody enforces decays quickly once a project is under deadline pressure, which is why periodic file audits matter, not just the initial documentation. Naming without actually restructuring into real variant properties is a half-measure: giving a component a flat name like button/primary/large without ever defining Type and Size as variant properties still won't produce the filterable dropdown behavior, so treat the naming convention as inseparable from actually adopting the tool's variant feature, not as a cosmetic label layered on top of separately built components.

Direct answer

Bring in plugins where the same manual step both recurs constantly across a design system's lifecycle and is easy to get subtly wrong by hand: batch renaming or restructuring layers at scale, checking new components for accessibility issues before they're published, catching unintended visual side effects when an existing component is edited, and keeping design tokens (named, reusable values, such as a color or a spacing size, stored once and referenced everywhere instead of being retyped or eyeballed) in sync with the values engineering actually ships. Each is worth its setup overhead specifically because a person doing it manually and repeatedly will eventually make an error that's expensive to catch after the fact.

Structured elaboration

Batch layer or component renaming. Run this when importing or cleaning up a batch of legacy assets being folded into the system, not on every save, since it's a one-time-per-migration operation. It's worth the overhead because manually renaming dozens of newly adopted layers to match a naming convention is exactly the kind of repetitive task where a person starts making inconsistent judgment calls somewhere around item thirty.

Accessibility and contrast checking. Run this at the point a component is about to be published to the shared library, as a gate, not continuously while exploring, since flagging every low-contrast rough draft is just noise. It's worth the overhead because a contrast mistake baked into a widely reused component silently multiplies across every product surface that consumes it, unlike the same mistake on a single one-off screen.

Visual regression checking. Run this specifically when modifying an existing, already-adopted component, right before publishing the change, since the risk being managed is an unintended side effect on instances elsewhere, not the creation of new work. It's worth the overhead because a design system's whole value proposition is that one component powers many screens, so an invisible regression there has a much larger blast radius than a normal screen edit would.

Token synchronization. Run this at each release cutoff for the system, or whenever a token value changes, not per screen. Design tokens are named values, color, spacing, type scale, meant to be shared between the design file and the code that consumes them; it's worth the overhead because a value manually retyped into code from eyeballing the design file is a routine, easy-to-miss source of drift between design and implementation that a sync step removes entirely by making the file the actual source of truth.

Worked example

A design-system team is folding fifteen legacy components, inconsistently named things like "btn_2" and "Group 88," into the shared library ahead of a version-two release. They run a batch-rename pass first to bring naming in line with the team's convention, then an accessibility check specifically on two new button variants, a ghost button on a light background, before publishing, which catches a contrast ratio that looks fine to the eye but fails the intended threshold. Finally, after tweaking an existing card component's padding, a visual-regression check flags that three product screens using deeply nested card layouts shift unexpectedly, prompting a second look before publishing rather than three separate bug reports landing after the fact.

Trade-offs and pitfalls

Running every check on every single edit, contrast-checking a rough exploration, regression-checking a brand-new component with no existing instances to regress against, adds friction with no matching reduction in risk; gate the heavier checks specifically at publish time. Any plugin with broad read access to file content is a mild trust surface, so it's worth checking who publishes it and how actively it's maintained before giving it access to files containing unreleased work. Relying entirely on automated checks instead of also training designers to recognize these issues by eye turns the tooling into a crutch that masks a skill gap rather than a genuine backstop for edge cases a trained eye would also catch.

Direct answer

When inheriting a messy project, triage the existing content into three page buckets (drafts, components, releases) before redesigning anything, then apply frame naming and a simple work-in-progress-versus-production marker so the current state is legible to anyone opening the file, including you a week from now.

Structured elaboration

Step 1: audit before touching anything. Skim every existing page and frame to identify what's currently in use by an active flow or referenced by engineering. Cleanup that breaks a link someone else depends on is worse than the mess it fixed.

Step 2: build the target page skeleton.

• "00 Cover": a short note describing the conventions, for whoever opens the file next.
• "01 Drafts": loose exploration and anything still in motion.
• "02 Components": reusable pieces, pulled out of scattered screens and turned into real components.
• "03 Releases": final screens that match what's actually shipped or ready to ship.
• "04 Archive": superseded or abandoned work, kept for history but out of the way.

Step 3: rename frames. Replace generic auto-numbered names ("Frame 47") with a screen-plus-state scheme, e.g. "Checkout / Empty cart", "Checkout / Error - card declined", so the frame list itself is scannable without opening each one.

Step 4: extract component libraries. Any piece reused two or more times (buttons, form fields, cards) becomes a real component on the Components page rather than a duplicated group, and every duplicate on other screens gets swapped for an instance.

Step 5: mark work-in-progress versus production. The page split (Drafts versus Releases) is the primary signal, reinforced at the frame level with a small visible status marker, a "work in progress" versus "production" label component placed above a frame, or a consistent naming prefix, so status is clear even if someone views one frame outside its page context.

Worked example

Inheriting a single-page file with 60 unlabeled frames: first pass identifies the 8 frames matching the currently live app, drags them into "03 Releases," and renames each by screen name. Next, three recurring button styles duplicated across a dozen frames get consolidated into one Button component with variants (primary, secondary, disabled) on "02 Components," and every duplicate gets swapped for an instance of it. The remaining exploratory or dead frames go to "01 Drafts" or "04 Archive" (favoring Archive for anything untouched in months). A "work in progress" sticker gets added to the two flows still actively being iterated, so a product manager glancing at the file doesn't mistake them for final.

Trade-offs and pitfalls

This cleanup takes real time and can look like no visible progress to stakeholders since nothing new ships from it, so it's worth flagging up front as a fixed-scope investment rather than open-ended busywork. Renaming and moving everything before understanding what's live risks breaking a prototype link engineering is actively using, which is why the audit has to come before the reorganization, not after. Don't over-build the taxonomy for a small file either; four pages is often enough, and more structure than the team will actually maintain becomes its own mess again within a month.

Direct answer

Three shortcuts that consistently save real time are a quick-actions command search, a modifier-key hover measurement, and a shortcut that wraps a selection into an Auto Layout frame in one step. Each replaces a slow menu hunt or multi-step process with something close to instant, and each is worth explicitly teaching rather than assuming a junior designer will stumble onto it alone.

Structured elaboration

1. Quick-actions command search. A searchable command palette, opened with a keyboard shortcut or a search icon in the toolbar, that lets you type a few letters of an action ("detach instance," "flatten," "create component") and run it directly, instead of hunting through nested right-click menus. On a real project it earned its keep on the actions that are buried or have no default binding at all, "detach instance" and "flatten" being the usual two: mid-review, needing to detach one instance to try a one-off treatment, typing four letters ran it without the visible stall of hunting a nested right-click menu while screen-sharing. Over a week of component work that is dozens of menu hunts replaced by dozens of four-letter searches, and it removed the specific failure where you know the action exists but cannot remember which submenu it lives under. Teaching it to a junior: show it once, then for the next week, whenever they reach for a menu, ask "could the command search find that faster" instead of just telling them the answer, so the habit actually forms.

2. Modifier-key hover measurement. Holding a modifier key while hovering over a nearby layer shows the exact pixel distance between it and whatever's currently selected, instead of eyeballing spacing or manually placing guides. On a real project this was the fastest way to confirm whether two supposedly identical cards in a list actually had matching padding, and it caught a small discrepancy that would otherwise have shipped. Teaching it to a junior: have them run this check themselves during their own design review pass, before handing a file over, so they build the habit of self-checking spacing instead of relying on a reviewer to catch it.

3. Wrap-selection into Auto Layout. A single shortcut that turns a selected group of layers directly into an Auto Layout frame (Auto Layout is Figma's layout system that automatically resizes, spaces, and aligns a frame's children as content changes, instead of everything being positioned by hand), instead of manually creating a frame, dragging children into it, and turning Auto Layout on as three separate steps. This turns "structure this row properly" from a multi-click chore into one keystroke, meaningfully lowering the friction to actually using Auto Layout consistently rather than skipping it under deadline pressure. On a real project the payoff showed up on a hand-placed six-chip filter row: wrapping it took one keystroke instead of create-frame, drag-the-children-in, enable-layout, re-fix-the-spacing, and the real saving arrived a day later when a label changed from "Price" to "Price (incl. tax)" and the five chips beside it repositioned themselves instead of needing a manual nudge each. Teaching it to a junior: pair with them on their first few components and have them apply it live, since the manual habit is easy to default back to if it isn't broken early.

Worked example

A concrete half-hour: a designer is turning a hand-built settings screen into proper components before handing it to engineering. She selects the six-row preferences list and wraps it into an Auto Layout frame with the wrap-selection shortcut, one keystroke instead of four steps, then repeats it for each row. She holds the measurement modifier and hovers between rows one and two, then two and three, and sees 12px and 14px, catching that one row was nudged by hand at some point; she fixes it to a uniform 12px gap in the parent frame rather than per row. Then she needs "detach instance" on a single row to try a one-off treatment, and runs it from the command search instead of hunting the menu. Three frictions, finding an action, measuring, structuring, each removed by one of the three above, and none of the three required knowing where anything lives in a menu tree.

On teaching the exact key bindings: rather than dictating them here, point a junior at the tool's own keyboard-shortcut panel and at the command search, which lists each action alongside its current binding. That is the durable version of the lesson, since it stays correct after the tool renames an action or rebinds a key, and it is also the answer to "what was that shortcut again" without asking anyone.

Trade-offs and pitfalls

Shortcuts are tool-specific and occasionally get rebound across tool updates, so the durable lesson isn't "memorize these exact keys," it's "know where the searchable command list lives, and recognize the categories of friction, finding an action, measuring, structuring a layout, worth looking a shortcut up for." Overloading a junior designer with a long list on day one rarely sticks; teaching a small number at a time, tied to a task they're actually doing that day, works better than handing over a reference sheet nobody revisits.