Entry-Level UX Designer Interview Preparation Guide - FAANG Standards

Direct answer
The biases that most often distort usability research are in who you recruit, who runs the session, what participants are willing to admit, what they can accurately remember, what confirms what the team already believed, and who you can even still reach to study. Each has a specific, concrete mitigation you build into study design, recruitment, moderation, or analysis, not something you correct for after the fact, and reliability across moderators and locations comes from making the protocol itself the source of truth rather than any one moderator's judgment.

Structured elaboration

• Sampling bias (studying whoever is easiest to reach instead of who actually represents your users). Mitigation: set recruitment quotas up front (for example, by tenure with the product or device type) and pull from more than one channel, such as a customer list, a panel, and organic intercept, so no single channel dominates the sample.
• Moderator bias (the facilitator's own expectations leaking into wording, tone, or which follow-up question gets asked). Mitigation: write a moderator script with fixed task wording and fixed neutral follow-ups so the outcome does not depend on who reads it, and rotate which moderator runs which sessions.
• Social desirability bias (participants say what makes them look competent or agreeable rather than what they actually experienced). Mitigation: prefer behavioral evidence (did they hesitate, backtrack, need a hint) over self-rated competence, and normalize failure explicitly at the start of the session so admitting confusion carries no social cost.
• Recency bias (people over-weight whatever just happened, in both memory and stated importance). Mitigation: capture a reaction immediately after each task rather than relying on one recall interview at the end of a multi-task session.
• Confirmation bias (the team, or the moderator, unconsciously looks harder for evidence that matches what it already expected). Mitigation: write the hypotheses and what would disconfirm them before the study starts, and have someone who did not design the feature review the raw notes or clips.
• Survivorship bias (only studying people still using the product, missing everyone who already gave up on it). Mitigation: deliberately recruit churned or lapsed users alongside current ones, not just whoever is still active enough to respond to a recruiting email.

Worked example
Applying each mitigation concretely: for sampling bias, a checkout study that only invites power users active in the last week will over-represent expert behavior, so add a quota requiring at least a third of participants to be first-time or lapsed users. For moderator bias, if a moderator who helped design the feature asks "so was that easy?" after a task, the phrasing alone nudges an agreeable answer; the fix is a scripted, neutral "how did that go?" every moderator uses verbatim. For confirmation bias, if the team predicted a new icon would confuse people, a moderator primed with that expectation can code a neutral pause as "confusion"; a second reviewer who codes the same clip without knowing the hypothesis catches that drift.
For reproducibility across moderators and locations, the concrete check is inter-rater reliability, not just a claim of consistency. Suppose two coders independently tag 20 session clips for whether a "confusing checkout" theme is present. Coder 1 tags 12 as yes and 8 as no; Coder 2 tags 11 as yes and 9 as no; they agree on 10 clips as yes and 7 as no, disagreeing on the remaining 3. Observed agreement is (10 + 7) / 20 = 0.85. Expected agreement by chance is (12/20 times 11/20) plus (8/20 times 9/20), which is 0.33 plus 0.18, or 0.51. Cohen's kappa (a chance-corrected agreement score, where 0 is no better than chance and 1 is perfect agreement) is (0.85 minus 0.51) divided by (1 minus 0.51), which is 0.34 divided by 0.49, or about 0.69. That sits just under the commonly used 0.7 threshold for acceptable agreement, so the right response is not to ship the theme as-is but to sit the two coders down, resolve the 3 disagreements, sharpen the codebook definition of "confusing," and re-check on a fresh sample before trusting the theme across moderators.

Trade-offs and pitfalls
Full calibration and double-coding take real time that a fast internal iteration may not have, so scale the rigor to the decision's stakes: a quick design check does not need double-coding, a launch go or no-go decision does. Over-correcting for one bias can introduce another; recruiting only churned users to fight survivorship bias will skew the sample toward people who had the worst possible experience, which is its own distortion if the goal is understanding typical usage.

Direct answer

Do not treat the metric win and the UX risk as opposing bets. Before building anything, agree with design and product on the primary success metric and on explicit guardrail metrics chosen specifically to catch the kind of harm the primary metric would not see, then validate cheaply with a prototype or a small qualitative test before committing to a live experiment sized to detect both.

Structured elaboration

Agree on what "good" means before anyone builds

The primary metric, say a conversion or engagement number, tells you if the change works on its own terms. Guardrail metrics are chosen specifically because they would catch harm the primary metric is blind to, such as task completion, return usage a week later, or support-ticket volume. Naming guardrails upfront, with agreed thresholds, prevents "we'll know it if we see it" arguments after the fact.

Validate cheaply before going live

A clickable prototype or a small moderated usability session can surface confusion or trust issues that the metric alone cannot catch, at a fraction of the cost of a live experiment. This is not a substitute for the experiment, it is a cheap filter that catches the worst ideas before they reach real users.

Run a bounded experiment, not a full rollout

Start with a small slice of traffic, watch both the primary metric and the guardrails, and decide the stopping rule, meaning what result on which metric ends the test, before the test starts, not after you see the numbers.

Decide and communicate together

If the primary metric improves but a guardrail moves the wrong way, that is a real finding, not a technicality to explain away. Whether to ship, iterate, or drop the idea is a joint call between design, product, and whoever owns the guardrail metric, made against the thresholds agreed upfront.

Worked example

Design proposes reordering a list of recommended items to increase click-through rate. The concern is that users may have learned to expect a stable, predictable order, and reordering it could hurt their ability to quickly find what they are looking for on repeat visits, something click-through rate would not show because a user can click more and still be more frustrated.

Before building, the group agrees the primary metric is click-through rate, and the guardrails are task completion rate (did the user's search end in the outcome they were after) and a return-usage check at one week out. A moderated usability test with a handful of participants on a clickable prototype surfaces that new users find the reordered list fine, but a couple of returning participants mention it "looks different" and take longer to find what they normally click first. That is a signal, not a stop sign: the team ships the change to a small slice of traffic, watches both metrics for an agreed window, and only expands the rollout if task completion holds steady alongside the click-through gain.

Trade-offs and pitfalls

Over-instrumenting every change with a full guardrail suite slows teams down and trains people to skip the process for anything that feels small. Guardrails should be chosen deliberately for the specific risk in question, not applied as a blanket checklist.

The sharpest failure mode is agreeing on guardrails in principle but not on thresholds, so when a guardrail moves slightly, the debate about whether it is a real regression happens after the data is already in and someone has already committed emotionally to shipping. Fixing the threshold before the test removes that fight.

Direct answer

Don't frame this as accessibility versus the business. Reframe it as: you found a real risk in the current plan before it shipped, since people with low vision literally can't read the simplified version, and you have alternatives that get most of the conversion goal without breaking the accessibility bar.

Structured elaboration

Presenting the trade-off

• Name WCAG AA plainly: it's the mid-level conformance tier of the Web Content Accessibility Guidelines, the widely adopted standard for what "readable and usable" means for people with visual, motor, or cognitive differences. AA is the level most companies commit to, and in some regions it's also a legal requirement. Falling below it isn't a style preference gap, it means real users can't read the affected elements.
• Show the actual numbers side by side: the contrast ratio, a measured comparison of foreground to background lightness, your simplified version hits, versus the 4.5:1 minimum WCAG AA requires for normal text (3:1 for large text), so the gap is concrete rather than abstract.
• Frame the ask correctly: the business wants higher conversion, not literally less contrast. Reduced contrast was the means chosen to get there, not the actual goal, so there's room to reach the same goal a different way.

Evidence-backed alternatives that keep both

• Increase size, and at the right sizes weight, instead of darkening the color: AA's lower 3:1 bar applies only to text that is large by the standard's own definition, meaning at least 18 point (24 CSS pixels) at normal weight, or at least 14 point (about 18.7 CSS pixels) when bold. Bolding on its own does not buy you the 3:1 bar. A 13-pixel label set in bold is still normal text and still owes 4.5:1, and shipping it believing otherwise is the most common way a team fails an audit while thinking it passed. So this route genuinely works for elements that can grow into that range, a section heading or a large numeric value in a card, and it does not work for dense body copy or small labels, which is where most simplification requests actually land.
• Move the lightened color off body text and onto backgrounds or decoration only, keeping copy and controls on a compliant, higher-contrast token.
• Add a second cue besides color, such as an icon, underline, or spacing change, so the simplified look doesn't rely on contrast alone to communicate.
• Test both the simplified-but-compliant version and the original against the actual conversion goal, since the assumption that lower contrast drives conversion is itself a hypothesis, not a given.

Worked example

The brand's primary blue on a white card background measures 3.2:1, short of the 4.5:1 AA minimum for the body text sitting on it. Instead of accepting the miss, you keep the blue for the card's decorative border and icon, and set the body copy in a darkened variant of the same blue that measures 4.6:1, a difference most users read as "still on-brand," not "a different color." You A/B test this AA-compliant version against the original higher-contrast design; if conversion holds or improves, you've met the business goal without the accessibility miss.

Recording the decision: log the specific contrast ratios before and after, the alternative chosen and why, and the conversion result, in the design system's decision record, tagged to this component, so the next designer who touches this pattern inherits the reasoning instead of rediscovering the same contrast problem.

Trade-offs and pitfalls

• Treating this as purely a compliance checkbox misses the point: WCAG AA exists because real people are excluded below it, not because an auditor might flag it.
• "We'll fix accessibility later" rarely happens once a pattern ships into the design system and gets reused, which is exactly why the decision record matters.
• Don't assume lower contrast is what's actually driving the conversion goal until you've tested that specific claim. It's often a proxy for something else, such as fewer competing elements or clearer hierarchy, that's achievable without touching contrast at all.

I would treat this as a scope and risk exercise.

First, I would separate must-have items from nice-to-have items. Legal requirements are usually non-negotiable, so anything needed for compliance, consent, disclosures, or data handling stays in the first release. Then I would protect the core user value: the smallest version of the feature that still solves the main user problem.

Next, I would review the engineering constraint honestly. If the team can only support a narrow scope this quarter, I would avoid designs that depend on extra screens, complex states, or expensive custom interactions. I would choose the simplest flow that is legal, usable, and shippable.

I would communicate the trade-offs in plain language:

• What ships now and why
• What is deferred and why
• What risk remains because of the constraint
• What we will measure after launch

That conversation is easier if I show a release matrix, because it makes clear that deferring something is not rejecting it. It is sequencing it responsibly.

Direct answer
When there is almost no time or money, I lean on tactics that use people or data I already have access to: guerrilla intercepts, a quick check with reachable users or coworkers, and mining what's already sitting in analytics or support tickets. None of these replace a proper study; they exist to confirm or kill the biggest risk fast enough to act on today.

Structured elaboration

Assumption-to-tactic pairing
The fastest way to use these well is to write the assumption down first, then reach for whichever tactic is cheapest to prove it wrong. Example: the assumption is "users don't understand what the new discount badge means." The quickest falsification is a guerrilla intercept, showing 5 people the screen for 10 seconds and asking "what does this tell you?" If most give the wrong answer, the assumption is wrong and you know it by lunchtime, without opening a single support ticket.

Worked example: the 24 hours before prototyping
With one day before a prototype needs to exist, tactics have to complement each other, not repeat the same signal. A reasonable split: spend the morning mining support tickets and analytics for the actual language and frequency of the complaint, since that tells you how common it is and how people describe it. Spend the afternoon running 4 to 5 guerrilla intercepts to check whether a fresh person understands a rough sketch of the fix, which tells you whether the direction makes sense to someone new. Running two guerrilla sessions back to back on the same question would just repeat the first signal; pairing desk research with a live check gives two different kinds of evidence in the same day.

Trade-offs and pitfalls
Every one of these tactics trades representativeness for speed: a guerrilla sample skews toward whoever happens to be around, and a friendly-user test skews toward people who already understand your product. Treat the result as directional risk-reduction, not proof, and say so plainly whenever you share it. The common mistake is presenting a six-person guerrilla result with the same confidence as a proper study; the fix is a one-line caveat every time.

A skeleton to fill in. Situation: briefly set the stakes and the deadline pressure that made waiting for complete data not viable. Task: state the specific decision you had to make and name the specific missing piece, not a vague sense of uncertainty. Action, in four parts: (a) exactly what you identified as missing, named precisely rather than described as "incomplete data"; (b) the explicit assumption you wrote down to fill that gap, specific enough that someone else could check it; (c) a minimal, cheap, fast check or small experiment you ran to reduce the risk of that assumption before committing, not a full study; (d) the decision you actually made. Result: a real outcome with real metrics, plus a lesson specific enough that it changed a subsequent behavior, a checklist item, a threshold, not a generic "I learned to communicate more."

A fully worked instance. Situation: six weeks before a contractual customer commitment date in March of a product's second year, a team had to decide whether to ship a new PDF export feature using on-the-fly rendering or invest in a pre-rendering pipeline, with no data yet on how many customers would need large (500-plus row) exports, the case that would make on-the-fly rendering too slow. Task: decide by March 15 which architecture to commit two engineers and four available weeks to, ahead of the deadline.

Action: the missing piece was named precisely, not "usage data" broadly but specifically the distribution of export sizes among the 40 customers slated to get this feature at launch, which did not exist because the feature had not shipped yet. The assumption was written into the design document explicitly: "assume export size distribution mirrors the existing comma-separated-values (CSV) export feature's distribution, median 80 rows, 95th-percentile (p95, meaning the value only 5% of cases exceed) 600 rows, flagged as unverified for this feature's specific customer behavior." The minimal check: instrumented the existing CSV export with row-count logging for 10 days, half a day of engineering work, which had never existed before. It returned a real, if adjacent, number: observed p95 was actually 850 rows, higher than the assumption. Given that, the team chose the pre-rendering pipeline (the full four weeks), scoped to handle up to 2,000 rows with headroom, with the assumption and the 10-day proxy data documented as the basis, plus an explicit note to revisit the choice if post-launch usage came in far lower.

Result: shipped on time, April 26, for the customer deadline. At 60 days, actual PDF export p95 was 720 rows, within range of the proxy-informed decision. Had the team instead sized on-the-fly rendering to the original 600-row assumption, roughly 15% of customers would have hit timeouts on their largest exports, based on the 60-day distribution. Lesson, stated specifically: the team adopted a standing practice, now a named step in the design-document template ("proxy data check"), of instrumenting the nearest existing analog feature for at least a week before committing to architecture on anything with no usage history, rather than debating projected usage in a meeting.

A shorter version of the same shape shows up outside engineering too. A support-operations lead deciding whether to build a dedicated escalation queue for a new product line, with no historical ticket data for it yet, names the same missing piece precisely (ticket volume for the new line specifically, not "support load" broadly), writes down the assumption (using the closest existing product line's ticket-per-customer rate as a stand-in), runs the same kind of minimal check (tags and counts the first two weeks of real tickets after launch instead of waiting for a full quarter), and adopts the same kind of lasting change (a launch-checklist item: instrument ticket tagging before day one, not after volume becomes a problem).

What separates a strong answer from a mediocre one. A mediocre answer names a real decision and says "we didn't have data, so we made our best guess and it worked out," with no visible mechanism (no named assumption, no cheap validation step) and a vague, unfalsifiable lesson. A strong answer shows the exact missing input, a specific and checkable assumption, real evidence gathered before committing (even if small and imperfect), and a lesson concrete enough that it became a repeatable practice. Interviewers are listening for whether you distinguish "no data" from "no test of the assumption," since the latter is what's actually within your control under time pressure.

A concise B2B persona schema, with evidence per field

• Name and role: title, seniority, and decision-making power. Evidence: CRM job titles, account segmentation, customer interviews.
• Primary goals and success metrics: what this person is trying to achieve. Evidence: product analytics tying feature usage to outcomes, sales discovery notes, interviews.
• Key tasks and workflow: core tasks, tools used, handoffs to other roles. Evidence: contextual interviews, session recordings, product telemetry (funnels).
• Pain points and blockers: specific frustrations and constraints. Evidence: support tickets, NPS (net promoter score) verbatim comments, usability-test transcripts.
• Buying and evaluation criteria: what features, security posture, and return on investment they need to see. Evidence: win/loss interviews, procurement documents, requests for proposal (RFPs, formal documents a buyer sends asking vendors to bid).
• Technical context and data maturity: stack, integrations, and data literacy. Evidence: onboarding surveys, integration logs, customer-success calls.
• Organizational constraints and stakeholders: budget cycles, compliance requirements, and the decision chain. Evidence: account plans, contract terms, stakeholder interview maps.

A single page for two audiences
Order the fields so the top third, name and role, goals, pain points, serves a PM skimming for context in a meeting, and the middle and bottom, tasks and workflow, technical context, org constraints, serves a designer working through flows in detail. Both audiences read the same page; neither needs a separate version, because the depth increases as you move down rather than requiring a second document.

Why these sources
Interviews and contextual research capture motivation and workflow; analytics and CRM data validate frequency and scale; support and sales conversations surface high-signal pain points and buying reasons. Combining qualitative and quantitative evidence is what makes each field defensible rather than assumed.

Keeping personas up to date
Instrument the canonical signals behind each field (product events, account attributes) and run a quarterly automated check that flags drift, for example a shift in role distribution or a usage pattern that no longer matches the stated goals. Maintain the page in the design-system repo with a visible change log, sync with customer success and sales monthly, and run a lightweight re-validation, 5 to 8 interviews plus an analytics snapshot, after any major product release. Treat every field as a hypothesis with a stated confidence level, and prioritize re-research wherever confidence is low or the underlying metric has moved.

Direct answer

A strong pre-interview research plan works from the most authoritative sources outward: company-controlled material first (site, blog, filings), then people-and-code sources (LinkedIn, GitHub), then outside voices (news, reviews), synthesized into a short brief with the one or two findings that would most change your approach flagged as open questions to raise or confirm.

Structured elaboration

What to pull from each source:

• Engineering or product blog: what they're building and what they've recently launched or pivoted away from. Tells you current priorities, not just stated ones.
• LinkedIn: team size and growth trend, who the hiring manager's other reports are, recent hires or departures (a churn signal), and the seniority mix of recent hires.
• GitHub (if they have public repos): commit cadence, open-issue volume and age, contributor count. This is a proxy for engineering health and how much attention a given system gets.
• Public filings (a 10-K or 10-Q, the annual and quarterly financial reports public companies must file with regulators) or funding announcements for a startup: which business segment is growing, headcount trends, and risks the company names about itself.
• Recent news: layoffs, funding rounds, leadership changes, or product launches, which tell you whether the team is likely riding a tailwind or working through a headwind.

Most of what you find is context. Two findings are worth naming explicitly as the ones that would change how you approach the role, because they change what you do, not just what you know:

• The red flag that matters most: departures concentrated in the team you'd join. Not company-wide churn, which usually reflects the market, but several people at your level leaving that one team within a couple of quarters, especially alongside a posting that has been re-listed. That pattern points at the team rather than the industry. It changes your approach from selling yourself to diligence: you'd want the hiring manager's own account of what changed and who left, and you'd weight what individual engineers say about it far above what the recruiter does.
• The positive signal that matters most: recent, specific, public evidence the team ships. A dated engineering post describing a system they actually built and what went wrong, a changelog with real entries rather than "bug fixes," a conference talk by someone still there. Claiming a culture of ownership is free; a public record of shipping is expensive to fake. This one raises how much scope you'd be willing to take on at the stated level, rather than negotiating for a safer, narrower remit.

Two things also matter more than any single source:

1. When sources conflict, don't average them. If LinkedIn shows fast headcount growth but reviews mention understaffing complaints, hold both as live hypotheses and pick the one interview question that would resolve the conflict, rather than quietly picking whichever story you like better.
2. Synthesize into something short you'd actually use. A one-page brief (mission in one line, likely challenges ranked, two or three open questions) beats a folder of tabs you never revisit.

Worked example

Say you're interviewing for a Backend Developer role at a mid-size fintech company. The blog's last three posts are about migrating a monolith to services. LinkedIn shows engineering headcount growing noticeably over the past year, and most recent hires are titled "Senior," none "Staff." Their one public GitHub repo, a customer-facing SDK (software development kit, a packaged set of tools other companies use to integrate with a product), has a large number of open issues, the oldest well over a year old. News shows a funding round closed several months ago.

Reading this together: the funding round is the likely reason the headcount line moved, which makes this growth a funded plan rather than a churn backfill, and senior-heavy hiring during a service migration suggests they need people who can operate with less hand-holding. Those two together are the positive signal, and they're worth saying out loud because they tell you the role is probably real scope rather than a replacement seat. The stale open-source issues on a customer-facing SDK is the actual red flag worth raising, not as a criticism, but as a genuine question: is that repo neglected, or intentionally deprioritized while the team focuses elsewhere? Note it isn't a strong enough flag to change whether you'd take the role, only what you'd ask.

Trade-offs and pitfalls

The most common mistake is treating any single source as ground truth, LinkedIn headcount counts are noisy (they include inactive profiles and contractors), so weight repeated, specific signals over one-off numbers. It also helps to say your assumptions out loud early in the process, whether to the recruiter or the hiring manager, rather than presenting inference as settled fact, since that's what catches a wrong read before it steers your whole set of questions in the wrong direction. A related failure is collecting a fact and then never using it, if the funding round or the layoff never shows up in your reading of the team, it wasn't research, it was browsing. Finally, don't let the research become the performance itself, its job is to sharpen two or three real questions, not to be recited back verbatim.

Direct answer

Build one shared component library and data layer, then assemble a different template on top of it for each persona; detect which template to show at login (role-based) but always let people switch manually, gate access to templates and underlying data by the same role that assembles them, and validate the whole approach by measuring whether people using the tailored template actually finish their task faster than an equivalent group on a generic dashboard.

Structured elaboration

Template library
Build interchangeable components (KPI card, trend chart, alert strip, dense table, filter bar) as design-system tokens, and assemble three templates from them: Executive (a small number of large KPI cards plus trend sparklines and a share action, nothing dense), Operations (real-time status, alert thresholds, and granular tables people act on immediately), and Analyst (dense visualizations, filters, and exportable raw data).

Persona detection and selection
Default the template from the person's role at login (an explicit, primary signal), but always show a manual switcher and remember the last choice; use behavioral signals (which sections someone actually clicks) only as a secondary nudge, never as a silent, un-overridable switch.

Permissioning model
Role-based access controls which template and which underlying data a person can see, with attribute-based rules underneath for row or column-level masking (for example, an operations manager sees incident data for their own region, not every region). Keep an audit log of changes to a shared, executive-facing view, since a change there is visible to leadership.

Layout and density rules
Executive: 5 or fewer primary cards, ordered by business priority, one action per card at most. Operations: 6 to 12 elements, with live status and alerts given the largest, most prominent placement. Analyst: dense grids with collapsible panels so depth is available without forcing scroll for the average case.

Experimentation plan
A/B test a persona-tailored template against a generic one for a matched group of new users of each role, over a 6 to 8 week window (long enough to cover normal usage cycles), measuring time-to-task, whether the action a person took afterward matched the metric they were looking at (a rough proxy for decision accuracy), and satisfaction. Promote a template only once it beats the generic default with a sustained gap, not a first-week bump.

Worked example: two concrete personas

Executive dashboard. Top 5 KPIs only: revenue, active users, churn, net promoter score, and cash runway, each as one large card with a trend arrow, no drill controls on the main view. A single "Share" button exports the current view as a PDF or posts it to a messaging channel, since executives more often forward a number than interrogate it themselves.

Operations manager dashboard. Built for someone monitoring up to 50 concurrent users' live activity during an incident: SLA (service-level agreement, the target response or resolution time a team has committed to) compliance percentage, count of open incidents by severity, and capacity utilization percentage, shown as granular, frequently refreshed tables rather than summary cards, with threshold alerts (for example, more than 2 open severity-1 incidents triggers a message to the on-call channel). Where the executive view rewards a glance, this view rewards a scan: more rows, smaller type, faster refresh.

The contrast is the point: the same underlying incident and revenue data assembled two different ways, one optimized for "what's the number and should I care," the other for "what exactly is broken right now and who needs to act."

Trade-offs and pitfalls

• Personalization by default can surprise people who did not ask for it; make the default change and the manual override equally visible.
• Splitting templates multiplies QA and maintenance cost; a shared component library is what keeps that cost from tripling every time a metric definition changes.
• A behavioral-inference override that silently reassigns someone's template erodes trust faster than it saves clicks; always show why the system suggested a change and let the person say no.

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.