Figma and prototyping

In short

Figma is a browser-based, collaborative interface design and prototyping tool in which the design file, the component library and the clickable prototype all live in one place, editable by several people at once. Prototyping means linking those static frames with triggers, actions and transitions so a flow can be clicked through and tested before a single line of code is written. For a B.Des student this is the core production skill of the "Communication and digital" paper: viva and jury submissions now expect an auto-layout, component-driven file plus a working prototype link, not flat JPEGs. Indian employers — Zoho, Freshworks, Swiggy, Zomato, Razorpay, CRED, PhonePe, Tata Digital, Infosys and TCS design studios, and agencies like Lollypop, Think Design and Obvious — set portfolio reviews and live Figma tasks (build a screen, fix a broken auto layout, wire a 3-screen flow) as the technical round. Figma is a tool, not a statutory subject, so what is examined is the vocabulary, the file-structure logic and the ability to justify a prototype's fidelity.

Explained

Interface, file structure and the vector editing model

• Hierarchy: Organisation → Team → Project → File → Page → Frame → Group/Layer. Pages separate explorations, specs and archives inside one file.
• Frame vs Group: a frame is a container with its own size, layout, clipping, constraints and fill — it can be a screen or a card; a group is only a bounding box around children. Prototype connections and auto layout work on frames, not groups.
• Canvas tools: Move (V), Frame (F), Rectangle (R), Ellipse (O), Line (L), Pen (P), Text (T), Comment (C), Scale (K — scales strokes, corner radii and text with the object, unlike plain resize).
• Vector networks: unlike conventional Bézier paths, a Figma vector can have multiple edges meeting at one node, so icons can be drawn without duplicate overlapping paths; boolean operations (union, subtract, intersect, exclude) stay editable (non-destructive) until flattened.
• Layout aids: layout grids (columns, rows, grid), 8-point spacing convention, snapping, smart selection, rulers and guides.
• Measurement model: everything is in density-independent pixels (dp/px at 1×); exports are scaled 1×/1.5×/2×/3× for Android and 1×/2×/3× for iOS. PNG/JPG are raster; SVG and PDF are vector.
• Collaboration: multiplayer cursors, branching and merging (paid tiers), version history, comments, and Dev Mode which exposes measurements, generated CSS/Android/iOS snippets and "ready for dev" statuses.
• FigJam is the whiteboard counterpart used for affinity mapping, user flows and crit boards.

Auto layout, constraints and responsive behaviour

• Auto layout turns a frame into a flex container: direction (horizontal/vertical/wrap), gap between items, padding on four sides, alignment (9-point), and distribution ("packed" vs "space between").
• Resizing per axis: *Fixed* (a set number), *Hug contents* (shrinks to children — used on buttons and chips), *Fill container* (expands to the parent's available space — used on inputs and cards in a row).
• Nesting rule: a hug frame cannot contain a fill child on the same axis — the classic "circular sizing" error; fix by making one axis fixed.
• Absolute position removes one child from the flow (badges, close icons) while keeping it inside the auto-layout frame.
• Constraints apply to children of plain (non-auto-layout) frames: left/right/top/bottom/centre/scale, pinning elements as the frame resizes — the manual equivalent of responsive rules.
• Min/max width and height on an auto-layout frame let one component serve mobile and desktop widths.
• Why it is examined: auto layout is the single most asked practical skill in Indian UI interviews because it is the difference between a file that survives content change and one that must be redrawn.

Styles, components, variants and the design-system layer

• Styles are reusable definitions of colour (fills), text, effects (shadow, blur) and grids; changing the style updates every use.
• Variables (design tokens) hold colour, number, string and boolean values, support modes (light/dark, mobile/desktop, English/Hindi) and can be bound to properties and to prototype logic. They largely replace the older "component for every theme" workaround.
• Main component vs instance: edits to the main propagate to all instances; an instance can be overridden (text, fill, swap) and reset to main. Detaching breaks the link permanently — do it only with reason.
• Variants collect related states into one component set with properties (e.g. State = default/hover/pressed/disabled, Size = S/M/L, Icon = true/false); the combination grid is the product of the property values.
• Component properties: boolean (show/hide a layer), instance swap (change a nested icon), text, and nested-instance exposure — these keep the right panel clean for the consuming designer.
• Slot pattern: an empty instance-swap placeholder lets a card accept any content block.
• Libraries: publish a file as a library, then enable it in other files; updates are reviewed and accepted, with semantic versioning discipline in larger teams.
• Naming convention: Button/Primary/Large style slashes create folders in the assets panel — graded in portfolio reviews as evidence of system thinking.

Prototyping: triggers, actions, transitions and logic

• A prototype connection is a noodle from a hotspot (layer or frame) to a destination, defined by trigger → action → animation.
• Triggers: On click/tap, On drag, While hovering, While pressing, Key/Gamepad, Mouse enter/leave/down/up, After delay (for splash screens and auto-advancing banners).
• Actions: Navigate to, Open overlay, Swap overlay, Close overlay, Back, Scroll to, Open link, Change to (variant, for interactive components), Set variable, Conditional (if/else).
• Animations: Instant, Dissolve, Move in/out, Push, Slide in/out, and Smart Animate, which tweens matching layer names and positions between frames — the basis of morphing and shared-element transitions.
• Easing: linear, ease in, ease out, ease in-out, ease in-and-out back, custom bezier and spring curves; typical durations 150–400 ms, with 200–300 ms the safe default for screen transitions.
• Scrolling and stickiness: set frame overflow to vertical/horizontal/both; "Fix position when scrolling" pins headers, tab bars and FABs; scroll position preserved on navigation keeps a long list in place.
• Overlays: manual or relative position, with background blackout, "close when clicking outside", and swap for multi-step sheets — used for bottom sheets, toasts, modals and dropdowns.
• Interactive components: wire triggers *inside* a variant set so hover and press states work everywhere the component is used, without a connection per screen.
• Prototype settings: device and model, orientation, background colour, starting frame, and sharing as a view-only link; flows are named starting points so one file can present several journeys.
• Variables in prototypes: a counter (number), a logged-in flag (boolean), typed input captured into a string, and conditionals produce genuinely stateful demos — a cart total updating, for example — without code.
• Fidelity ladder: paper sketch → low-fi wireframe (grey boxes, no colour) → mid-fi (real layout, placeholder content) → hi-fi (final visual design) → high-behaviour prototype (micro-interactions, real data). Match fidelity to the question being asked; hi-fi too early invites comments on colour instead of structure.
• Horizontal vs vertical prototype: horizontal shows many screens shallowly (breadth, for stakeholder walkthroughs); vertical shows one flow completely (depth, for usability testing).

Testing, handoff and the surrounding workflow

• Prototype for testing: keep the happy path plus one error path, remove dead ends, label the flow, and avoid hotspot hints during a moderated test.
• Validation metrics usually read off a prototype test: task success rate, time on task, error/misclick count, and the System Usability Scale (SUS) score out of 100 (≈68 is the long-quoted average).
• Handoff: Dev Mode or inspect panel for spacing and CSS, named tokens matched to the code's variables, exported assets as SVG, an annotated redline page, and a component-to-code mapping (Figma component ↔ React/Flutter widget).
• Accessibility checks before handoff: contrast ratio (WCAG 2.1 AA: 4.5:1 for body text, 3:1 for large text and UI components), minimum touch target ~44×44 pt iOS / 48×48 dp Android, visible focus states, text that resizes to 200% without loss of content (WCAG 1.4.4) and reflow at 400% zoom (WCAG 1.4.10). India's Rights of Persons with Disabilities Act, 2016 and the GIGW (Guidelines for Indian Government Websites, latest edition GIGW 3.0) require government and public-service digital products to meet WCAG-aligned accessibility — so a government-facing prototype must show these states.
• Indian localisation: Devanagari and other Indic scripts need more line height and are typically 15–30% longer than English, so auto layout with hug/fill and variable modes for language is the practical answer; design for low-end Android, small screens and intermittent connectivity (offline and loading states as real frames).
• Data protection context: the Digital Personal Data Protection Act, 2023 drives consent screens, purpose notices and "withdraw consent" flows that are now routinely asked for in Indian product prototypes; detailed rules under the Act have been notified in stages, so treat specific compliance timelines as subject to change.
• Plugins and ecosystem: Content Reel and Unsplash (realistic content), Stark and Able (contrast), Autoflow (flow arrows), Figmotion (animation), Iconify, LottieFiles; variables and tokens can be exported to code via token plugins.
• Comparison with other tools: Adobe XD (development discontinued), Sketch (macOS only), Axure (logic-heavy), Framer and ProtoPie (code-level and sensor-level interaction), Balsamiq (wireframes), After Effects/Lottie (rich motion). Figma wins on collaboration and handoff; ProtoPie and Framer win on complex conditional or device-sensor interaction.

Key points

• Frame - a container with size, layout, clipping and constraints; prototyping and auto layout require frames, not groups.
• Auto layout - flex-style container with direction, gap, padding and alignment; makes designs respond to content.
• Hug / Fill / Fixed - the three resizing modes; hug shrinks to content, fill expands to parent, fixed is a set value.
• Constraints - pinning rules (left, right, centre, scale) for children of non-auto-layout frames when the frame resizes.
• Main component vs instance - one source of truth; overrides are local, detaching is permanent.
• Variants - states and sizes of one component in a set, selected by properties; count = product of property values.
• Component properties - boolean, instance swap, text and nested exposure, controlled from the right panel.
• Variables and modes - tokens for colour/number/string/boolean that switch by theme, device or language, and drive prototype logic.
• Trigger → action → animation - the three-part definition of every prototype interaction.
• Smart Animate - tweens layers with identical names across frames; the basis of morph and shared-element transitions.
• Overlay - a frame shown on top of the current one, used for modals, bottom sheets, toasts and dropdowns.
• Interactive component - states wired inside the component set, so hover/press work on every screen automatically.
• Fix position when scrolling - keeps headers, tab bars and FABs stationary inside a scrolling frame.
• Flow and starting frame - named entry points, so one file can present several journeys to stakeholders.
• Fidelity - low-fi tests structure, hi-fi tests visual and behavioural detail; choose by the question being asked.
• Dev Mode / Inspect - exposes spacing, tokens and generated code for handoff; not a replacement for specs and annotation.
• Accessibility floor - 4.5:1 body-text contrast (WCAG 2.1 AA), ~48 dp touch targets, visible focus; mandated for Indian government sites via GIGW and the RPwD Act, 2016.
• 8-point grid - spacing and sizing in multiples of 8 (4 for fine steps) keeps a system consistent across breakpoints.

Formulas and examples

Example 1 — Hug width of a button. A primary button is a horizontal auto-layout frame: icon 20 px, gap 8 px, label text 96 px wide, padding 16 px left and right, set to hug.

• Children total = 20 + 96 = 116 px; gaps = 8 × (2 − 1) = 8 px; padding = 16 + 16 = 32 px.
• Width = 116 + 8 + 32 = 156 px. If the label is translated to Hindi and becomes 128 px wide, width = 128 + 20 + 8 + 32 = 188 px — the button grows instead of clipping, which is the whole point of hug.

Example 2 — Fill-container cards on a mobile frame. A 360 px wide screen frame has 16 px horizontal padding and holds a horizontal auto layout with 3 cards, gap 12 px, each set to fill.

• Inner width = 360 − (16 + 16) = 328 px.
• Space for gaps = 12 × (3 − 1) = 24 px.
• Each card = (328 − 24)/3 = 304/3 ≈ 101.33 px (Figma rounds the display to 101.33; use 2 cards if integer widths matter: (328 − 12)/2 = 158 px).

Example 3 — Variant explosion. A button component has properties: Type (primary, secondary, tertiary, destructive) = 4, Size (S, M, L) = 3, State (default, hover, pressed, disabled) = 4, Icon (true/false) = 2.

• Variant count = 4 × 3 × 4 × 2 = 96 variants.
• Replacing Icon with a *boolean component property* removes that factor: 4 × 3 × 4 = 48 variants — a 50% reduction in a set a student must maintain by hand. This is the standard interview answer on keeping variant sets manageable.

Example 4 — Export sizes for an Android asset. A card illustration is drawn 180 × 120 px at 1×.

• 1.5× = 270 × 180 px; 2× = 360 × 240 px; 3× = 540 × 360 px.
• Raster memory at 3× (4 bytes/px, uncompressed) = 540 × 360 × 4 = 777,600 bytes ≈ 760 KB — the reason flat illustrations and icons go out as SVG (a few KB, resolution-independent) rather than PNG.

Example 5 — Prototype test numbers. A checkout prototype is tested with 8 students; 6 complete the task, average time 54 s, 5 misclicks in all.

• Task success rate = 6/8 × 100 = 75%.
• Misclicks per user = 5/8 = 0.63.
• With 8 participants a usability test typically surfaces most major issues in a single flow, but it is a qualitative sample — the 75% is a direction, not a statistic to quote as a population figure.

Where it is used

• Product and startup design teams: Zoho, Freshworks, Razorpay, CRED, Swiggy, Zomato, PhonePe, Meesho and Groww run their design systems as published Figma libraries with variables for light/dark modes.
• Agencies and studios: Lollypop, Think Design, Obvious, Codigo and Kalpa deliver clickable prototypes as the client deliverable; prototype links, not PDFs, are the basis of sign-off.
• IT services and enterprise UX: Infosys, TCS Interactive, Wipro, Accenture Song and Capgemini staff "UI/UX designer" and "product designer" roles whose first-round task is a Figma screen build plus a wired flow.
• Government and public digital services: UPI apps, DigiLocker, IRCTC and state portals — prototypes must demonstrate GIGW/WCAG-aligned contrast, touch targets and Indic-language states.
• Education and research: B.Des and M.Des juries, NID and IIT-Bombay IDC studio submissions, and FigJam boards for affinity mapping in UX research reports.
• Adjacent roles: design engineer, design technologist, UX writer (editing copy directly in instances), QA (comparing build to Dev Mode specs) and marketing teams building social and pitch layouts.

Interview questions

• Q: What is the difference between a frame and a group? A: A frame is a real container with its own size, layout, clipping and constraints and can hold auto layout and prototype links; a group is only a bounding box that resizes with its contents.
• Q: When would you use Fill container instead of Hug contents? A: Fill when the element should take whatever width the parent gives it (inputs, cards in a row); hug when the element should be exactly as wide as its content (buttons, chips, tags).
• Q: Why does Figma show a "circular sizing" error? A: Because a hug parent is asking its child for a size while a fill child is asking its parent for a size on the same axis; make one of them fixed.
• Q: How do you decide between a variant and a component property? A: Use variants for mutually exclusive visual states and sizes; use a boolean or instance-swap property for independent on/off or interchangeable elements, which keeps the variant count from multiplying.
• Q: What does Smart Animate actually match on? A: Layers with the same name and hierarchy in both frames — it interpolates their position, size, opacity and rotation, so renaming or restructuring layers breaks the transition.
• Q: What is an interactive component and why use it? A: A component set with triggers wired between its own variants, so hover, press and toggle states work on every instance without drawing a connection on each screen.
• Q: How would you prototype a bottom sheet? A: Make the sheet a separate frame, trigger "Open overlay" with relative position at the bottom, slide-in animation around 250 ms, background blackout on, and close on click outside.
• Q: Your prototype must show a cart count increasing. How, without code? A: Create a number variable, set the badge text to that variable, and attach a "Set variable: count = count + 1" action to the add button alongside the navigation.
• Q: What fidelity do you take into a usability test, and why? A: Enough fidelity to answer the question being tested — low-fi for structure and flow, hi-fi only when visual hierarchy or micro-interaction is the thing under test, because hi-fi pulls feedback towards colour and polish.
• Q: What do you hand to a developer besides the Figma link? A: Named tokens matching the code's variables, an annotated spec page with states and edge cases, exported SVG assets, and a note on behaviours Dev Mode cannot show — empty, loading, error and offline states.
• Q: How do you keep a design system from drifting once several designers use it? A: Publish one library with strict naming, review library updates rather than auto-accepting, keep styles and variables as the only source of colour and type, and forbid detached instances without a documented reason.
• Q: Figma can generate CSS — does that make handoff automatic? A: No; the generated code describes one static frame, not responsive rules, state logic or accessibility semantics, so annotated specs and a conversation with the developer still decide the build.

Common mistakes

• Prototyping from groups or ungrouped layers, then finding connections and auto layout unavailable.
• Building every state as a separate screen instead of using variants and interactive components, so a colour change means editing forty frames.
• Detaching instances to make a quick edit, which permanently cuts the component link and silently breaks the system.
• Renaming or re-nesting layers between frames and then blaming Smart Animate when the transition jumps.
• Random spacing (13, 17, 23 px) instead of a 4/8-point scale, which shows up immediately in a jury or portfolio review.
• Testing only the happy path, leaving the prototype with dead hotspots, no error state and no back route.
• Presenting a hi-fi prototype as final without contrast, touch-target and Indic-language checks — the exact faults picked up in Indian accessibility and localisation reviews.

Related topics

UI design · UX research and usability · Branding and communication design · Design software: Adobe tools · Design systems and style guides · Interaction and motion design