Design Tools and AI-Assisted Workflows Questions
Working efficiently and confidently inside a design tool such as Figma, Sketch, or Adobe XD. Covers organizing files, pages, and layers for a team; naming conventions that stay searchable as a project grows; version history, branching, and merge practices that let several designers work at once without overwriting each other; and diagnosing a shared file that has grown slow to open and edit. Covers building components in the tool so they hold up in practice, using its layout, resizing, and variant systems so a component adapts across screen sizes and survives real content instead of tidy placeholders. Also covers working faster and automating repetition: keyboard shortcuts, choosing workflow plugins and knowing when to avoid them, and occasionally scripting one; export settings for production assets, including formats, scale factors, and file naming; and choosing or migrating between design tools for a team's needs. Does not cover design token architecture, component governance, or design system versioning; prototype fidelity or interaction pattern choices; accessibility auditing; responsive and multi-platform design strategy; or handoff specs, redlines, and developer communication, each of which is its own topic.
You receive hand-drawn wireframes for a six-step onboarding flow with repeated patterns (progress bar, card lists, CTA variations). Describe step-by-step how you would convert these into a Figma project: pages to create, how to identify and extract reusable components and variants, Auto Layout decisions, and a prototype plan for testing the flow with users. Include naming and versioning recommendations for collaborators.
Sample Answer
Direct answer
Treat this as a structured build, not a straight redraw: set up the file's page skeleton first, extract every repeated pattern, the progress bar, the card lists, the CTA (call-to-action, the primary button prompting the user's next step) variations, into reusable components and variants before building any of the six actual screens, assemble the screens from those pieces, wire a prototype for testing, and document naming and versioning so collaborators can follow the work as it evolves.
Structured elaboration
Pages to create: "00 Cover" (a brief describing the flow and its status), "01 Wireframe reference" (the hand-drawn sketches brought in for traceability, so reviewers can compare final screens back against the original intent), "02 Components" (extracted reusable pieces), "03 Onboarding flow" (the six final screens in sequence), "04 Prototype" (a copy wired for testing, kept separate so click-through hotspots don't clutter the production screens), "05 Archive."
Identifying and extracting reusable components: read through all six steps before building any of them and list what recurs. In this flow that's the progress bar (present on all six, with a different step highlighted each time), the card lists (recurring wherever the flow presents selectable options), and the CTA variations (a primary "Continue" versus a secondary "Skip" versus a disabled state before a required field is filled). Each becomes one real component with variant properties instead of six independently drawn copies: a progress-bar component with a step property (1 through 6), a card component with a selected/unselected property, and a CTA button with state (default, disabled) and type (primary, secondary) properties.
Auto Layout decisions: the progress bar itself is built with Auto Layout (Figma's layout system where a frame automatically resizes, spaces, and aligns its children as content changes, instead of every element being positioned by hand) so its segments space evenly regardless of step count; each card in a list is its own Auto Layout frame so its height adapts to variable text length instead of clipping; the CTA area at the bottom of each screen uses Auto Layout with alignment set to pin the button to the bottom edge consistently across all six screens, even when the content above it varies in length.
Assembling the six screens: each screen frame pulls the shared components as instances (the progress bar set to that step's value, whichever card or CTA state matches that step), so a later change to a base component, tightening the CTA button's corner radius, for example, propagates to all six screens automatically instead of requiring six manual edits.
Prototype plan for testing: wire the six frames in sequence, a "Continue" hotspot advancing forward and a "Back" or "Skip" path where relevant, and include the states that matter for the study, such as an error state if a step requires a note about a missing field. Keep the prototype in its own page or file copy so temporary interactions added just for the test session don't end up shipping. Plan the test around a small number of specific tasks (complete onboarding as a first-time user, back out and resume from a middle step) rather than open-ended exploration, so results are comparable across participants.
Naming and versioning: name the six screens by step and purpose ("01 Welcome," "02 Permissions," through "06 Confirmation") rather than by number alone; name components using a component/property/value convention (progress-bar/step, card/selected, cta/primary/disabled); version the flow with a named save point right before a testing round ("v1 for usability test, [date]"), so the exact version participants actually saw can always be recovered even after the working file has moved on.
Worked example
Steps 1 and 3 both use the card component to present two choices with different copy; because the card is a real component with a variant property rather than a redrawn shape each time, updating its corner radius once on the base component updates it everywhere it's used across all six screens. The progress-bar instance on step 3 is the same base component as step 1, with only its step property changed from 1 to 3, so its Auto Layout spacing never has to be manually recreated. In the prototype, step 1's primary CTA links to step 2, a back arrow links backward, and a disabled-state CTA on a later step becomes enabled only once the participant fills a required field, letting the moderator actually observe whether people notice why the button isn't responding.
Trade-offs and pitfalls
Redrawing each of the six screens by eye before extracting the shared pieces feels faster on day one, since the wireframes already show what each screen looks like, but it creates six independently diverging copies of the same progress bar and card, meaning any later change needs six edits instead of one; extract first even though it feels slower. Letting states or hotspots added only for the usability test creep into the production onboarding-flow page blurs the split between disposable testing artifacts and shippable work, so keep that boundary explicit. Skipping the versioned save point before a test round means an in-flight edit can silently change what a participant actually saw, undermining any attempt to explain a confusing result afterward.
You're designing a component that has to survive real content: variable-length text, user-uploaded images of unpredictable size, and a live data feed that might return nothing or far too much. Walk through how you'd build and stress-test it in Figma so it holds up across breakpoints and platforms instead of breaking the moment the content isn't the tidy placeholder you designed with.
Sample Answer
Direct answer
I'd build the component using Auto Layout (Figma's system for making a frame automatically resize, space, and align its children as content changes, instead of every layer being sized and placed by hand) so its size is driven by whatever content actually fills it, rather than a fixed frame sized to look right with the one tidy example I designed with, then deliberately stress-test it against a spread of realistic and adversarial content, empty, minimal, typical, and maximal, instead of only the happy path, so the breakage shows up in the design file rather than in production.
Building for variability
- Sizing: give every layer the right Auto Layout sizing mode for what it is: "hug" for text that should grow or shrink with its content, "fill" for anything that should stretch to its container, "fixed" only where a size is genuinely constant. The component's overall height or width becomes a function of its actual content, not an assumption baked into the frame.
- Text: decide a max-line or truncation rule up front (e.g. a 2-line clamp with an ellipsis) instead of leaving text unconstrained, and deliberately decide what a very short title (one word) should look like too, not just what a very long one does.
- Images: use a fixed-aspect-ratio container with a defined fill/crop behavior, so user-uploaded images of arbitrary source dimensions don't distort the layout or leave visible gaps. Decide and document what "no image at all" looks like as its own state (the layout reclaims that space, or shows a placeholder), rather than treating it as a smaller version of "has an image."
- Live data feed: design three states beyond the happy path explicitly: empty (real empty-state guidance, not a blank frame), sparse (one or two items, where a grid can otherwise look broken or lonely), and overflow (far more items than fit, needing pagination, infinite scroll, or a "show more" affordance you actually design rather than assume the tool or engineering will handle).
Stress-testing method
Don't validate only against your own placeholder copy. Pull or fabricate a genuinely adversarial content set, the longest real title you can find, a small or oddly-cropped real user-uploaded image, an empty feed and an overloaded one, and drop it into the component across every breakpoint and platform frame, checking specifically for text overlap, image distortion, broken row alignment between sibling cards, and inconsistent row heights in a grid. Re-run the same content set per platform, not just per breakpoint width, since comfortable line length and touch-target sizing differ by platform convention even at similar widths.
Worked example
Take a feed card. Content test set: a 1-character title through a genuinely long real headline (~120 characters); images including a square avatar, a wide banner photo, and a "no image" case; feed sizes of zero items, one item, exactly enough to fill one row, and far more than fit. Result of the stress test: the long headline without a clamp pushes that card's height noticeably past its row neighbors, breaking alignment, fixed by adding a 2-line clamp. The wide banner photo inside a container built for square avatars either stretches or leaves visible letterboxing, fixed by standardizing the image container's aspect ratio and fill behavior regardless of the source image's shape. The "no image" case leaves a blank gray box the same size as a populated one, reading as a broken loading state rather than an intentional one, fixed with a component property that removes the image slot and lets the text stack take that space, used only for the genuine "no image" case (a separate, distinct treatment covers "image still loading"). A one-item feed on a grid built for three columns leaves two glaring empty cells, fixed by having the grid collapse to a left-aligned row of only the populated cards instead of reserving ghost slots.
Trade-offs and pitfalls
- Designing purely for the absolute worst case (every field maxed out) makes the typical, common case look padded and awkward; the goal is testing the full range, then choosing defaults, like a 2-line clamp, that degrade gracefully rather than breaking at the extreme or looking wrong in the common case.
- Treating "no image" as just a smaller version of "has an image" instead of its own layout state is the most common source of a card that reads as subtly broken rather than intentionally different.
- Empty and overflow feed states are often left undesigned because they feel like edge cases, but the choice between pagination, infinite scroll, and a "show more" button is a real UX decision. Leaving it undesigned just hands that decision to whoever implements it, with no design intent behind it.
- Stress-testing with genuinely messy content matters because generic filler text is uniform in a way that hides exactly the length-variance problems the test exists to catch.
Explain what Auto Layout is in Figma or a similar design tool, and how it differs from manual positioning. Then walk through how you'd use it to build a horizontal row of buttons that needs to wrap, keep equal spacing, and stay centered as the screen gets smaller, and describe when you'd reach for constraints or manual resizing instead.
Sample Answer
Direct answer
Auto Layout is a rule-based layout engine built into a design tool's frames: instead of placing every element at a fixed x/y position and manually nudging things whenever content changes, you tell a frame how its children should be arranged, direction, spacing, alignment, padding, and the frame recalculates positions itself whenever content is added, removed, or resized, the same underlying idea as flexbox in CSS. Manual positioning has no such rule: every element keeps the exact coordinates it was given, and only the tool's separate constraints system (pinning edges) adjusts anything, and only in response to the parent frame's own resize, not to a sibling's content changing.
Structured elaboration
What Auto Layout manages once turned on: the arrangement direction of children, a consistent gap between items, inner padding around the group, how items align on the cross axis, and a sizing mode per child, whether it hugs its own content, fills the remaining space in its parent, or stays a fixed size.
Difference from manual positioning: manual layout stores each layer's coordinates directly, so nothing recalculates automatically when a sibling's width changes; you'd have to move every affected element by hand. Auto Layout stores relationships instead of coordinates, so it behaves like a live layout system rather than a fixed snapshot.
Building the button row, step by step:
- Turn the group of buttons into an Auto Layout frame arranged left to right.
- Set a fixed gap value between items so spacing is uniform rather than hand-eyeballed.
- Turn on the frame's wrapping behavior, so once the row runs out of horizontal room, additional buttons drop to a new line instead of overflowing or shrinking unreadably.
- For "stay centered as the screen gets smaller": set the row's own alignment to center, so wrapped rows re-center as a group, and set the outer frame to fill the available parent width rather than a fixed pixel width, since it needs less room to work with as the screen narrows, which is what triggers the wrap in the first place. Each button should hug its own text content rather than stretch, so buttons don't awkwardly grow to fill leftover space.
When to reach for constraints or manual resizing instead: constraints (pin to left, right, top, bottom, center, or scale) are the right tool for an element that needs to react to its parent frame resizing but has no internal sibling relationships to manage, a background image, a single decorative graphic, or a fixed watermark that should sit in the same corner regardless of screen size. Manual, fixed positioning suits content that is intentionally exact and never expected to reflow, like a pixel-precise illustration or a one-off frame that will never be resized. Reach for Auto Layout whenever a group of siblings needs correct spacing or order as items are added, removed, or the container resizes, which covers most real UI, including this button row.
Worked example
The button row above illustrates the main mechanism. A second, related case: an icon-plus-label button has to shrink cleanly when the icon is turned off. Built with manual, fixed positioning, removing the icon leaves an empty gap where it used to sit, since nothing else knows to move over. Built as an Auto Layout frame with the icon and label as two children, sizing set to hug contents, hiding or removing the icon layer makes the frame's own computed width shrink immediately and the label re-flows into the space, no manual repositioning needed. It's the same mechanism as the row, hug-versus-fill sizing plus automatic recalculation on content change, applied to a single component instead of a row of them.
Trade-offs and pitfalls
Auto Layout adds real setup overhead for something that will never change, like a static hero illustration, so it shouldn't be applied reflexively to every frame. Deeply nested Auto Layout frames, one inside another inside another, can be confusing to debug when a size behaves unexpectedly, since several frames are each claiming hug or fill; trace outward from the innermost frame when a layout looks wrong rather than guessing at the top level. A common early mistake is leaving the outer row at a fixed width: wrap will never trigger because nothing is actually running out of room, and this is usually the first thing to check if wrapping doesn't behave as expected.
You're advising a remote-first startup choosing between Figma, Sketch, and Adobe XD. Compare each tool on criteria such as real-time collaboration, cross-platform support, plugin ecosystem, design-system features, and developer handoff. Provide a recommendation and outline migration and onboarding considerations.
Sample Answer
Direct answer
For a remote-first startup, Figma is the strongest recommendation of the three: it's fully browser-based with real-time multiplayer editing built into its core from the start, which matters more for a distributed team than for a co-located one, it has the deepest plugin ecosystem and design-system tooling of the three, and it gives engineering a built-in inspection view for handoff with nothing to install locally. Sketch is a credible second choice for a Mac-heavy team already invested in it, but is a materially weaker fit for a genuinely cross-platform distributed team. Adobe XD is not a sound choice for new work today, since Adobe itself has said it is no longer actively investing in the product.
Structured elaboration
Comparing across the named criteria plus two more worth adding explicitly, file performance at scale and prototyping fidelity:
| Criterion | Figma | Sketch | Adobe XD |
|---|---|---|---|
| Real-time collaboration | Native multi-person simultaneous editing, the product's core differentiator from the start | Real-time co-editing and a web companion were added over time, on top of a single-player-first foundation | Supported co-editing, but with development effectively halted this isn't a growing strength |
| Cross-platform support | Runs in any modern browser plus native Mac and Windows apps, no OS lock-in | Historically Mac-only; a web app narrows the gap for viewing, commenting, and handoff, but native editing still leans Mac | Available on Mac and Windows, though a shrinking user base reduces the practical benefit |
| Plugin ecosystem | Largest and most actively maintained of the three | Smaller, mature, but growing more slowly | Has stagnated alongside the product itself |
| Design-system features | Strong native component and variant system plus shared libraries | Solid symbols and libraries feature, a reasonable foundation, one step behind Figma's variant model | Weaker component model, never the product's main focus |
| Developer handoff | Built-in inspection mode reading exact spacing, styles, and code-adjacent values with no extra install | Requires the app or a web handoff view, workable but an added dependency | Had an inspect feature, but it isn't receiving ongoing investment |
| File performance at scale | Handles large, heavily nested files reasonably well, though very large files with many components can still slow down | Traditionally strong single-file performance, less proven at large team-library scale | Not a meaningful axis to evaluate on a de-prioritized product |
| Prototyping fidelity | Solid built-in prototyping, transitions and interactive states, covering most hand-off needs without a separate tool | Historically a weaker area, often paired with a separate prototyping tool | Prototyping was one of XD's original strengths, but that matters little if it isn't the platform you'll build on long-term |
Recommendation: Figma as the primary tool. "Remote-first" specifically makes real-time multiplayer editing and zero-install browser access disproportionately valuable, and its design-system and handoff tooling reduce the number of separate tools a team would otherwise need to stitch together.
Migration and onboarding considerations. Don't treat a migration from Sketch or Adobe XD as a straight file import: existing tools offer import paths for those file formats, but a component built as loosely grouped layers in the old tool typically needs to be rebuilt as a proper component with real variant properties to get the design-system benefits described above; a mechanical import alone just relocates the mess. Migrate by product area rather than all at once, letting one active initiative prove the new file and naming conventions work before the rest of the backlog follows, and keep the old tool's file as the frozen reference of record until the new one is validated on a real release. Onboarding a distributed team is comparatively light: there's no license to install locally, a new hire is added by email invitation to the relevant projects, and the file and permission structure a team already uses for organization applies unchanged; the main onboarding investment is walking new hires through the team's specific naming and page conventions, not the tool's mechanics.
Trade-offs and pitfalls
Recommending Figma doesn't mean every legacy file needs to migrate on day one; a working existing design-system file, for a small and stable team, represents a real switching cost against a real but not always urgent collaboration benefit, so weigh urgency honestly rather than assuming migration is free. A startup also shouldn't choose a tool purely on today's feature comparison without checking each vendor's own stated direction; a product a vendor has said it's no longer investing in is a real business-continuity risk for a young company that can't easily absorb a forced re-migration later.
Describe step-by-step how you prepare and export visual assets (icons, raster images, SVGs) from Figma, Sketch, or Adobe XD for iOS, Android, and Web. Include file formats, scale factors, naming conventions, and how you ensure developers receive correctly optimized assets for each platform.
Sample Answer
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/@3xnaming, the same asset exported at one, two, and three times its base pixel size to match device pixel densities. - Android uses density buckets:
mdpias the 1x baseline, thenhdpi(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.
Unlock Full Question Bank
Get access to all 20 Design Tools and AI-Assisted Workflows interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.