Entry-Level Product Designer Interview Preparation Guide | FAANG Standards

Direct answer

A teammate told me directly that in technical discussions I tended to dive straight into jargon-heavy back-and-forth with one or two people who already had context, which left others, including people newer to the codebase, unable to follow or contribute. I took it seriously rather than defending my intent, changed specific habits in how I ran discussions, and pushed a couple of those habits into how the team runs meetings generally, not just my own behavior.

Structured elaboration

This kind of feedback has a particular trap: the instinct to explain intent, "I didn't mean to exclude anyone," instead of engaging with the impact the other person actually experienced regardless of intent. The better response is to ask for a specific instance if one wasn't given, confirm you understand what happened from their point of view, and commit to a concrete, observable change rather than a vague promise to be more mindful. Personal behavior changes worth naming: explicitly summarizing context before diving into a technical debate, so people without the same background can follow; directly inviting quieter people by name to weigh in rather than assuming silence means agreement; pausing fast, jargon-dense exchanges to check whether everyone is tracking. Process changes matter too, since a personal habit change alone does not fix a recurring team pattern: adding a brief written context section to design docs before a discussion so people can prepare regardless of how much hallway context they already have; rotating who facilitates technical discussions so the same one or two voices do not dominate by default; explicitly reserving time in a meeting for questions before moving to open debate.

Worked example

A newer teammate told me, after a design discussion, that they had wanted to raise a concern about an approach but could not find an opening because two of us were deep in a fast, jargon-heavy exchange about implementation trade-offs for the whole meeting. I asked them to walk me through specifically where they had wanted to speak up, which turned out to be right after we had glossed over an assumption about how an existing system behaved, something they actually had direct, relevant experience with. My immediate behavior change: in the next several discussions I explicitly paused after any fast technical exchange to ask "does anyone have context that changes this?" before moving on, and I made a point of summarizing the working assumption before diving into detail, not just for that teammate but as a general habit. Beyond my own behavior, I raised it with the team and we changed how we ran design discussions: a short written summary of the proposal and key assumptions gets shared at least a day before the meeting, and we started rotating who facilitates so the discussion does not default to whoever is fastest to jump in.

Trade-offs and pitfalls

Responding to this kind of feedback by immediately explaining your intent, even sincerely, can land as dismissing the impact the other person actually experienced, so asking first and defending later matters. A personal habit change that is not paired with any process change tends to regress once the original feedback fades from memory, especially under time pressure, when a team reverts to whichever pattern is fastest, so a durable process change is what makes the fix stick. There is also a real trade-off between structuring discussions enough that everyone can follow and slowing every conversation down so much that genuine urgency gets lost; the goal is specific checkpoints, a pre-read, a pause for questions, rather than making every discussion uniformly slower.

A pairing works when the two typefaces have enough contrast to clearly be two different faces (so the pairing reads as intentional rather than a mismatch) but enough underlying harmony in their proportions and mood that they feel like they belong to the same family of decisions. Judging that means looking past the hero specimen and testing the pairing at every size it will actually be used at.

What I actually check

• Contrast in category or personality. Pairing a serif display face with a sans-serif body face, or two sans faces with clearly different personalities (one geometric and confident, one humanist and warm), gives enough separation that the pairing looks deliberate. Two faces that are nearly identical in shape tend to look like an accidental inconsistency rather than a pairing.
• Matching x-height (the height of lowercase letters like x, o, and n). If the display and body face have very different x-heights, body text set at a size meant to visually balance the display face can look uneven or mismatched in scale even when the point sizes are technically "correct."
• Weight availability. The body face needs enough weights (regular, medium, bold, and usually an italic) to carry its own internal hierarchy; a display face often only needs one or two weights, since it's rarely used for long stretches of text.
• Testing in context, not just as a hero image. A pairing that looks beautiful as a large headline and a paragraph mocked up side by side on one static screen needs to also be tested at every size it will actually appear at across the product, including the smallest ones.

A pairing mistake that looks fine in isolation

A common one: choosing a delicate, high-contrast serif for a display face (thin hairlines against much thicker main strokes) and then reusing that same face for small UI text, like 12px labels or captions. At a large headline size, those fine hairlines look elegant. At 12px, especially on lower-resolution or lower-quality displays, the hairlines can nearly disappear or render as broken, blurry strokes, so text that looked polished in a hero mockup becomes hard to read once it's applied to every small label across the interface. A practical rule I use: never let a high-contrast, delicate face drop below roughly 18 to 20px; hand off anything smaller to the body typeface instead.

Trade-offs and pitfalls

If a pairing feels risky to judge purely by eye, a "superfamily" (a serif and sans-serif version drawn together by the same type foundry, sharing proportions and metrics) is a safer starting point than pairing two unrelated typefaces from scratch. The deeper pitfall either way is judging a pairing only from its best-case hero comp instead of its worst-case usage: a real product applies a pairing across dozens of contexts, and the pairing has to survive all of them, not just the one screen it was chosen on.

Direct answer
Build the dashboard around three questions stakeholders actually ask (is the system being used, is it healthy, is it costing us anything), pull each metric from the tool that already produces it as a side effect of normal work (repo, Figma API, CI, bug tracker) rather than building new collection infrastructure first, and give each audience a role-specific view into the same underlying data rather than three separate dashboards.

Structured elaboration

Ten metrics

Visualizations and stakeholder views

• A single overview page with a status chip (healthy/watch/regressed) per metric, each linking to a time-series drilldown; this is the page every audience lands on first.
• Engineer view emphasizes metrics 3 through 7 (the CI-gated, code-adjacent ones) with direct links to the failing PR or component.
• Designer view emphasizes metrics 1, 2, 9, and 10, with links into the Figma library for duplicate or unused components.
• PM view emphasizes metrics 1, 8, and 9 rolled up by product team, since their question is usually "which team needs help adopting" rather than "which component regressed."

Privacy and instrumentation notes
Component-usage telemetry (feeding metrics 1, 7, 9) should record which component and variant rendered, not any user-entered content, and should be sampled and aggregated rather than stored as raw per-session events, to avoid both a PII problem and an unmanageable data volume.

Worked example
Take metric 1, component reuse rate, all the way through. Define it as: reuse_rate = library_component_render_count / total_ui_element_render_count, sampled from a set of representative pages rather than every page in production. Say the sample captures 500 rendered top-level UI elements across 20 representative pages, and 310 of those elements are library components rather than one-off custom markup:

$$\text{reuse\_rate} = \frac{310}{500} = 0.62$$

That's a 62% reuse rate, computed directly from the sampled counts shown, not asserted. If the threshold for this metric is set at 50%, the dashboard shows this team as healthy; if a different team's sample comes back at 38 reused out of 100 sampled elements ($38/100 = 0.38$), that team shows as below threshold and gets flagged on the PM view for an adoption conversation.

Trade-offs & pitfalls
Ten metrics is a lot to keep alive; the realistic failure mode isn't picking the wrong metrics, it's instrumenting all ten at launch, having two or three go stale within a quarter because nobody owns them, and the dashboard's credibility dying with them. Better to launch with the four or five metrics that already have a data source (reuse rate, prop divergence, accessibility pass rate, bundle contribution) and add the harder-to-source ones (duplicate detection, satisfaction survey) once those are proven sustainable. Threshold-setting is also a trap: thresholds pulled from nowhere ("50% reuse is healthy") invite alert fatigue or false confidence; treat initial thresholds as provisional, publish them as such, and recalibrate after a full quarter of real baseline data rather than defending an arbitrary number in a review.

Direct answer. Evaluating a velocity-improving but ARIA-deficient third-party UI library is a real trade-off, not a simple reject-or-accept decision: weigh the specific gaps against your actual usage (a library missing ARIA on a rarely-used component matters less than one missing it on your primary navigation), and consider wrapper components or contributed upstream fixes as mitigation before ruling the library out entirely.

Evaluating risks and benefits. Audit specifically which of the library's components you'll actually use and test THOSE for accessibility gaps directly (with axe and a manual keyboard pass), rather than trusting the library's general reputation or documentation claims; weigh the velocity gain against the actual remediation cost for just the gaps that affect your usage, not a worst-case reading of every component in the library.

Mitigation strategies.

• Wrapper components: build a thin accessible wrapper around the library's component that adds the missing ARIA attributes and keyboard handlers, isolating the fix in one place so a library upgrade doesn't require re-patching every usage site individually.
• Polyfills: for structural gaps, a small utility that post-processes the rendered DOM to add missing attributes can work as a stopgap, though it's more fragile since it depends on the library's internal markup staying stable across versions.
• Contributing upstream: filing the specific issue and, where feasible, submitting the fix yourself benefits every future version and every other consumer of the library, and is worth attempting even if it's slower than a local wrapper, since the wrapper approach accumulates technical debt that upstream contribution avoids.
• Vendor pressure: for a commercially-licensed library, raising the specific gap with the vendor and citing your organization's own compliance obligations sometimes gets a faster fix than a community open-source contribution would.

A worked instance. Concretely: suppose the audit finds the library's date-picker component renders no aria-expanded on its popover trigger button and never moves focus into the calendar grid when it opens. The wrapper fix is small: wrap the library's <DatePicker> in your own component that sets aria-expanded={isOpen} on the trigger button and, in an onOpen callback the library already exposes, calls .focus() on the calendar grid's first focusable date cell. That is roughly a day of engineering time including a manual keyboard-and-axe re-test, against a multi-week cost to build a compliant date-picker from scratch, exactly the kind of concrete number that makes "adopt-with-wrapper" comparable to "adopt as-is" and "avoid" rather than abstract.

Deciding with engineering and product stakeholders. Bring the audit findings, gap severity, and remediation-cost estimate to a single structured decision session with both groups rather than making the call unilaterally: engineering is the right owner of the remediation-cost and timeline estimate (how long a wrapper or upstream fix realistically takes), while product owns the velocity/timeline trade-off (what shipping later actually costs the roadmap) and typically the user-impact call (how many affected users, how central the broken components are to primary flows). Frame the decision as three concrete options, adopt as-is, adopt-with-wrapper, or avoid, each with its cost and risk stated in the same terms, so the group is choosing between comparable options rather than debating in the abstract.

When to walk away. If the gaps are in components central to your primary user flows and no combination of wrapper/upstream-fix is realistic on your timeline, the velocity gain isn't worth shipping something genuinely broken for a meaningful user population; that's a legitimate reason to choose a different library or build the component in-house despite the extra cost.

Trade-offs and pitfalls. Adopting the library first and deciding to "fix accessibility later" is a common trap, since the wrapper/patch work is easiest to design correctly BEFORE the library is deeply integrated across the codebase, and gets progressively more expensive to retrofit the more usage sites accumulate.

Direct answer
State the decision and the immediate next steps out loud before the meeting ends, then send a short written follow-up within the hour that restates the same thing, so there's both an in-the-room confirmation and a durable record that matches it.

Structured elaboration

1. Confirm verbally before people leave the room (or call). In the last minute or two, say "so to confirm, we've decided X, and the next steps are Y owned by Z by Thursday, does that match everyone's understanding?" This catches a misalignment while everyone who can correct it is still present.
2. Watch for silence versus agreement. Nobody objecting isn't the same as everyone actively agreeing; a direct question ("does that match?") is more reliable than just pausing and moving on if no one immediately speaks up.
3. Send the written follow-up promptly, ideally within the hour, restating the same decision and action items. The verbal confirmation and the written one should say the same thing; if they don't, that's usually a sign the verbal confirmation was rushed or unclear.
4. Keep the written version short and scannable, matching the same content as the verbal confirmation rather than adding new information the room didn't actually agree to.
5. Flag anything genuinely still unresolved, in both the verbal check and the written follow-up, rather than letting an unresolved point quietly look settled just because the meeting ended.

Worked example
Verbal, at the end of the meeting: "So to confirm: we're going with the phased rollout, Sam owns the migration plan by next Friday, and we're holding off on the customer announcement until that's done. Does that match what everyone heard?"

Written follow-up sent the same hour: "Recap from today: decided on the phased rollout. Sam: migration plan due next Friday. Customer announcement is on hold until the migration plan is ready. Shout if this doesn't match what you remember."

The two versions state the identical decision and owner, and the written version explicitly invites correction rather than assuming silence means agreement.

Trade-offs and pitfalls

• Skipping the verbal confirmation and only sending a written recap later means any misunderstanding surfaces after people have already left and possibly acted on their own interpretation.
• Skipping the written follow-up and only confirming verbally means anyone who wasn't in the room, or who forgets, has no record to check against.
• A written recap that silently adds detail beyond what was verbally confirmed can create a new source of disagreement; keep the two consistent, and if you realize something needs adding, flag it explicitly as new rather than folding it in unannounced.

Direct answer
The situation I'd describe is a mid-sized project where my manager wanted me to present a set of results to a client as more conclusive than the underlying data actually supported, because the client relationship was under strain and a confident-sounding update would help. My personal value was straightforward accuracy in what I present, even when the more cautious version is less comfortable to deliver; my manager's approach prioritized relationship repair over precision in that specific moment. I did not treat it as a fight to win outright; I looked for a version of the update that was honest and still served the relationship.

Structured elaboration

1. Name the actual tension precisely, not just "we disagreed." In this case it was not that my manager wanted me to lie; it was a difference in where to draw the line between appropriately confident communication and overstating certainty, which is a much more common and more defensible kind of workplace values conflict than an outright integrity violation.
2. Raise the concern directly and early, privately, before the moment it would matter (the client meeting), rather than either silently complying or making it a public confrontation. I asked my manager one on one what specifically in the data supported the stronger framing, which turned the conversation from a disagreement about values into a conversation about evidence.
3. Offer an alternative that serves the underlying goal your manager actually cares about. My manager's real goal was preserving the client relationship, not the specific wording; I proposed a version that led with the two results we were genuinely confident in, was transparent about the one metric still trending in the wrong direction, and paired it with a concrete next step and timeline. This served the relationship-repair goal without requiring me to overstate anything.
4. Be honest about what you would do if the answer had been no. If my manager had insisted on the original framing after that conversation, my actual next step would have been to ask to attach a short written appendix with the caveated numbers, so the honest version existed in the record even if it wasn't the headline; if that had also been refused, I would have escalated to my manager's manager rather than either comply silently or refuse outright, because the stakes (client trust, and my own credibility if the caveated number surfaced later) were high enough to warrant it.
5. Reflect honestly on what you learned, including about your own judgment, not only about the other person. I learned that raising the concern as a specific evidentiary question ("what supports this framing") got further, faster, than raising it as a values statement ("I'm not comfortable with this") would have, because it gave my manager something concrete to respond to.

Worked example
The client update, as originally proposed, said: "engagement is up and the rollout is on track." What the underlying data actually showed: two of three key metrics had improved meaningfully, but the third (a retention metric the client cared about specifically) had been flat to slightly down for three weeks running, with a plausible but unconfirmed hypothesis for why. The version I proposed and we ultimately sent said: "engagement and adoption are both up meaningfully this period; retention is currently flat, and we have identified a likely cause we're testing a fix for over the next two weeks, with a follow-up update once we have results." The client's actual reaction was more positive than my manager expected, specifically because the concrete next step read as more credible than an unqualified "on track" would have.

Trade-offs & pitfalls
The common failure in answering this question is picking an example that is really just "I disagreed with a decision," with no genuine values dimension, or the opposite extreme, an example so severe (fraud, safety, legal risk) that it reads as a one-time crisis story rather than the kind of ordinary, recurring tension this question is actually probing for. Another pitfall is describing the resolution as pure capitulation ("I raised it once, they said no, I dropped it") or pure martyrdom ("I refused and it cost me"), neither of which shows the judgment interviewers are actually testing for: the ability to find a version of the truth that serves both your own integrity and the legitimate underlying goal the other person had.

Direct answer

Scope, timeline, and resources trade against each other: holding any two roughly fixed, the third has to flex, and the most common mistake is trying to fix all three at once and quietly letting quality absorb the difference instead. When a deadline and headcount are both fixed, the honest lever left is scope, and naming that explicitly, rather than pretending everything can still be delivered, is what protects both the deadline and the quality of what does ship.

Structured elaboration

The triangle is a forcing function for an explicit trade-off conversation rather than a silent one. If timeline is fixed (a launch date tied to a marketing commitment) and resources are fixed (the team isn't growing before then), scope is the only remaining lever, and narrowing it, cutting the feature list, is preferable to the alternative of keeping the full scope and letting the team either work unsustainable hours or ship at lower quality without saying so. Extending the timeline or adding resources are the other two levers, but each has its own cost: extending timeline delays value delivery and may miss the reason the deadline existed in the first place; adding resources (particularly late) often slows a project down before it speeds it up, since onboarding new people to a half-built effort has real overhead.

Worked example

A team commits to shipping a redesigned onboarding flow before a fixed marketing launch date, with a headcount that isn't changing. Partway through, new requirements emerge that would add two weeks of work. Rather than silently absorbing the extra work into unpaid overtime or shipping it half-tested, the explicit trade-off conversation: "given the launch date and team size are both fixed, here are the two features we'd cut to stay on track, or here's the one-week delay if we keep everything," puts the actual choice in front of the stakeholder who can weigh in on which lever they'd rather pull, rather than the team making that call invisibly.

Trade-offs and pitfalls

Communicating this trade-off requires naming the cut explicitly rather than hedging ("we'll try to fit it all in"), because a hedge just defers the same conversation to a worse moment, closer to the deadline, with less room to adjust. The pitfall on the other side is invoking the triangle reflexively for every scope addition, even small ones that don't actually threaten the deadline, which trains stakeholders to see every request as a negotiation and erodes the trust the framing is meant to build.

Direct answer

Information architecture (IA) organizes what exists and how it relates: hierarchy, grouping, and the paths between screens. Content design writes the words that sit inside that structure: labels, microcopy, and tone that tell the user what they are looking at and what will happen if they act. IA decides the skeleton; content design decides how the skeleton speaks.

Structured elaboration

Deliverables and responsibilities

How each shapes navigation, labeling, and flow

• Navigation: IA decides which items exist in the top-level nav and which are nested; content design writes the label text so a user understands the destination before clicking it.
• Labeling: IA proposes label candidates from the taxonomy (validated with card sorts); content design chooses the exact phrasing that matches how users actually talk, not internal jargon.
• User flow: IA maps the required steps and branch points; content design writes the prompts, confirmations, and error recovery text that remove friction at each step.

Worked example

Consider a mid-sized web app with two BI dashboards: a Sales Dashboard (day-to-day numbers for reps) and an Executive Summary Dashboard (aggregated trends for leadership). IA decides where each one lives: the Executive Summary sits as the default landing page under "Reports," while the Sales Dashboard is nested one level deeper under "Reports > Sales," because leadership opens the app less often and needs the big picture first, while reps live inside the sales detail all day. Content design then decides that "Revenue" means the exact same calculation on both dashboards (not gross on one and net on the other) and writes the empty state for a rep with no data yet: "No sales logged this week. Once you close a deal, it will show up here."

When IA should override the visual design, and why. Say the company merges the Sales Dashboard and the Executive Summary Dashboard into one reporting section after two products get combined post-acquisition. If the visual team restyles both dashboards into a shared design system before the routes, labels, and redirects from the two old URLs are consolidated, users bookmark or search-index the wrong page, get duplicate paths to the same report, and the redesign has to be partially undone once the structural collision surfaces. Deciding the structure first and the visual polish second avoids throwing away UI work.

Three measurable outcomes that tell you which discipline has a problem

1. Findability: can a user locate the right report in a tree test within a target number of clicks? A miss here usually points at IA (wrong branch, wrong hierarchy), not wording.
2. Comprehension: does a user, shown a metric label out of context, describe what it means correctly? A miss here points at content design (the label or definition is unclear), even if the user found the right page.
3. Task completion: does the flow end where it should (a report gets opened, a filter gets applied)? A miss here can be either discipline depending on where in the flow it breaks down, which is why the first two outcomes matter as a diagnostic pair.

Trade-offs and pitfalls

Treating content design as "just copy that gets added at the end" is the most common mistake: by then the IA decisions (what exists, in what order) are locked, and content design is stuck writing labels for a structure that never matched how users think. Conversely, over-indexing on IA and shipping generic placeholder copy ("Item," "Section 2") means the correct structure ships behind confusing wording that undermines it. The two disciplines should be in the room together before wireframes freeze, not sequentially.

Direct answer

The second explanation almost never wins by being louder or more detailed than the first. It wins by changing the format, meaning I switch from telling to showing, and by rooting the explanation in a decision the person actually needs to make rather than in the mechanics of the tool itself. To avoid condescension, I treat the first miss as information about my explanation, not about their ability.

Structured elaboration

When a first explanation does not land, I go through a specific adjustment process rather than just repeating myself more slowly:

1. Diagnose what actually did not land, by asking a targeted question rather than re-explaining immediately. Usually the gap is one of three things: the vocabulary I used, the lack of a concrete example, or the fact that I explained the mechanism instead of the decision it enables.
2. Change the format, not just the pace. If the first pass was verbal, the second pass gets a visual or a live walkthrough. If the first pass was abstract, the second pass starts from a specific, real example the person already cares about.
3. Anchor the explanation in a decision they need to make, not in how the underlying system works. People retain "here is what you do when you see X" far better than "here is how X is calculated."
4. Check understanding by having them use it themselves, not by asking if it makes sense. Watching someone operate the thing and narrate their reasoning out loud surfaces exactly where the model in their head diverges from reality.

To avoid condescension, I frame the second attempt as "let me show you a different way to look at this" rather than "let me try explaining this more simply," and I never reference the fact that this is a repeat explanation in front of other people.

Worked example

I owned a dashboard that tracked monthly customer churn, acquisition channel, and cohort value for Product and Customer Success managers, most of whom were not technical. After my first walkthrough, several of them still could not use it to decide which customers to prioritize for retention outreach; they nodded along in the room but did not use it afterward.

For the second attempt, I changed three things. First, storytelling: instead of walking through the chart types, I opened with a real scenario, "we're seeing a spike in churn from one acquisition channel this quarter, here is what that costs us and how we'd catch it," and used the dashboard to answer that story as it unfolded. Second, guided filters: rather than describing the filters, I handed them the dashboard and had each person isolate a cohort and change the date range themselves while I coached, so the tool's behavior stopped being something I described and became something they had just done. Third, annotated visuals: I added in-dashboard annotations next to each chart naming the business question it answers, so the connection between a chart and a decision was visible without me being in the room. Afterward, I gave each person a short realistic scenario and had them talk through, using the dashboard, what they would do, which told me directly whether the explanation had landed rather than relying on their saying it made sense.

Trade-offs and pitfalls

• Switching format on the second attempt costs more preparation time than repeating yourself; it is worth it specifically because a second identical explanation rarely succeeds where the first one failed for the same underlying reason.
• Anchoring purely in decisions can under-explain the tool for a stakeholder who later needs to use it in a situation you did not walk through. If the audience needs durable independence, not just one correct decision, the mechanism has to come back in briefly, just after the decision framing rather than before it.
• The biggest condescension risk is not tone, it is implying the person should have understood the first time. Framing the second pass as offering a different angle, rather than a simpler one, avoids that without softening the actual content.
• Hands-on practice only works if you can tolerate the person making a visible mistake in front of you or others; rushing to correct every misstep undercuts the exact learning-by-doing effect you are relying on.

Direct answer

"Feels smooth" is really a frame-budget problem: at a 60fps target you have 1000ms divided by 60 frames, 16.7ms, to do everything needed for one frame, and on a low-end device with a weak GPU, only compositor-friendly properties reliably fit inside that budget. I'd design the animation around those properties from the start rather than designing something rich and shrinking it later, measure it with dropped-frame percentage, the share of frames that render late during the animation, and jank, a perceptible skip or stutter caused by badly dropped frames, on the actual target device class, and prototype the low-end version differently from the flagship demo from day one: real low-end hardware, with the network throttled to simulate the patchy connection.

GPU acceleration and repaint reduction, explained

Some properties, transform translate, scale, rotate, and opacity, can be handled by the compositor, a separate step backed by the device's GPU that combines already-drawn layers on screen without asking the rest of the rendering pipeline to redraw anything. Animating these is comparatively cheap even on weak hardware. Other properties, width, height, top or left position, box-shadow, blur, force a repaint: the system redraws the actual pixels of the affected element, and often its layout neighbors, on every single frame, which is expensive, and on a low-end GPU with limited fill-rate this is usually where perceptible jank comes from. Concretely, for a card-flip or slide: build it from transform and opacity only, translate the card horizontally, rotate it around the vertical axis for a flip, fade in the new face, and avoid animating a drop shadow's blur radius directly, since that forces a repaint every frame. Fake the same depth cue with a pre-rendered, static shadow that only fades in and out through opacity.

What I'd prototype differently for a low-end and patchy-network demo versus a flagship demo

• Device: test and demo on an actual low- or mid-tier Android device, not a flagship or a desktop browser simulator, since a simulator typically runs on desktop-class hardware and won't reproduce the problem.
• Network: throttle the connection to a slow, high-latency profile, a few hundred kilobits per second with noticeable round-trip delay, rather than testing on office wifi, since a patchy network changes what "smooth" even means. If the content the animation reveals hasn't loaded yet, the animation needs a defined behavior, wait, show a placeholder, or fail gracefully, rather than assuming the data is always there the instant the transition starts.
• Assets: use production-weight images and content in the prototype, not lightweight placeholders, since a slide animation over a placeholder gray box will always look smoother than the same animation once a real, larger image has to decode and paint.

Metrics I'd bring to engineers, in terms they can act on directly

• Frame budget: state the 16.7ms-per-frame number explicitly and name which specific properties in the design exceed it, a repaint-triggering blur is a description of a device-independent problem, not an environment-dependent timing claim.
• Dropped-frame percentage during the animation, measured with the platform's own rendering profiler, Android's on-device GPU rendering tools, or a browser's built-in performance panel for a web-based build, since this is the standard way engineers already talk about jank internally, and handing them a percentage in their own units gets a faster, more precise fix than "it feels laggy."
• A named property list, which elements in the design currently animate width, height, or blur versus transform and opacity, since that list is directly actionable: an engineer can swap the implementation without needing to re-derive what's expensive from scratch.

Trade-offs and pitfalls

It's tempting to validate an animation only after it's already built, when the fix options have narrowed to keeping it or cutting it; involve engineering during the design of the motion itself, which properties, roughly how long, so the performance conversation happens before there's a finished thing anyone feels reluctant to change. The other common mistake is chasing a specific frame-rate number as if it's the whole story: a technically smooth animation that reveals content before the network has actually delivered it will still feel broken, so treat animation performance and content readiness as one combined problem, not two separate ones.