Staff-Level UI Designer Interview Preparation Guide - FAANG Standards

Visual hierarchy is the deliberate use of visual properties, size, color, spacing, and position, to signal which elements on a screen matter most, so a user's eye lands on the right thing first without having to read everything to figure that out. On a screen with a lot competing for attention, hierarchy is what keeps it scannable instead of overwhelming.

Three core techniques, plus one that's easy to forget

1. Size and weight (typography). A larger, bolder element reads as more important simply because it takes up more visual space and effort to render. Example: on a pricing page with a headline at 16px regular and a plan price at 40px bold, a user's eye lands on the price before reading a single word of the headline, because size alone does the sorting.
2. Color and contrast. A saturated, high-contrast color surrounded by neutral tones pulls the eye toward it, because the eye is naturally drawn to what's different from its surroundings. Example: if the only saturated color on an otherwise gray-and-white settings screen is the "Save" button, that button becomes the obvious next click even before a user reads its label.
3. Spacing and isolation. Giving an element more surrounding whitespace than its neighbors signals that it's separate and worth pausing on, since crowded elements read as routine and isolated elements read as deliberate. Example: a promotional banner surrounded by 48px of empty space, versus 16px around ordinary list items, makes users' eyes stop on the banner instead of scanning past it as just another row.
4. Position. In left-to-right reading cultures, users scan roughly top-to-bottom and left-to-right, so placing the most important element first in that path (top of the screen, or the start of a row) gives it a head start on attention before a viewer has consciously decided what to look at.

How these combine, and where interaction states fit in

None of these techniques work alone in a real interface; a strong screen usually stacks two or three of them on the one element that matters most (the primary action might be the largest, most saturated, AND most isolated thing on the screen), while everything else stays comparatively quiet on all three dimensions. Hierarchy also isn't static: interaction states like hover, focus, and selected add a temporary layer of emphasis on top of the base hierarchy, for example an item highlighting on hover to say "this is clickable" or a focus ring appearing for a keyboard user. That temporary emphasis has to be consistent with the underlying hierarchy, not fight it, or the interface will feel like it's changing its mind about what matters.

Trade-offs and pitfalls

The most common mistake is treating hierarchy as "make everything important stand out," which cancels itself out: if five elements are all large, bold, and saturated, none of them wins and the screen reads as noisy rather than clear. Good hierarchy usually means suppressing far more elements than it emphasizes.

Direct answer

With sparse analytics, the first move isn't more research, it's a fast audit of what's actually being measured today, followed by triangulating cheap qualitative signal with whatever quantitative signal can be stood up quickly, so the highest-impact opportunity gets found through convergence of evidence rather than waiting for a perfect dataset that may never arrive.

Structured elaboration

Finding the opportunity

• Start with an instrumentation audit, not new research: what events are already logged, even informally in support tickets or ops spreadsheets, and where are the biggest blind spots in the core funnel from browse to contact to transaction. This usually takes days and shows where the team is flying blind.
• Talk to people who already have informal signal: support, sales, ops. They're sitting on qualitative evidence about where users get stuck that hasn't been formalized, and it's the fastest way to generate hypotheses before running new research.
• Run a small number of targeted interviews or session observations, aimed at the specific funnel step the instrumentation audit and internal stakeholders both point to, so the qualitative work confirms or kills a hypothesis instead of fishing for one from scratch.
• Prioritize by triangulation, not any single source. An opportunity that shows up independently in the instrumentation gaps, in support tickets, and in interviews is far more trustworthy on sparse data than one that shows up in only one source.

Escalating what's found

• Lead with the decision being asked for, not the process. Leadership needs the opportunity, the evidence, and the specific ask, not a narrated research journey.
• Show convergent evidence explicitly, the same friction point named in the funnel gap, in support tickets, and in interviews, rather than presenting sources separately, since convergence is what compensates for the lack of a large quantitative dataset.
• Name the confidence level honestly given sparse data. This is a well-triangulated hypothesis, not a proven, sized result, so the ask should be the smallest experiment that would size it, not a large investment on unproven evidence.

Worked example

On a plateaued marketplace, the instrumentation audit shows there's no event tracking between viewing a listing and sending a message, a real blind spot in the middle of the funnel. Support tickets independently show a recurring theme: users say they don't know what information to include in a first message and give up. A handful of quick user interviews confirm it: several participants say they closed the listing because composing a message felt like it required information they didn't have yet. All three sources point at the same gap, which is enough convergence to bring to leadership as the top opportunity, along with a proposal to instrument that specific step and run a lightweight prototype test of a structured, prompted first-message flow before committing to a larger redesign.

Trade-offs and pitfalls

• Triangulating instead of waiting for clean data is the right call at this scope, but it's easy to let one vivid support ticket or a strongly worded interview quote stand in for volume. Keep checking whether a signal shows up in more than one independent source before treating it as the top opportunity.
• Escalating with too much narrative and not enough of a concrete ask reads as interesting but not actionable to leadership; the ask, budget, engineering time, or a specific experiment, needs to be explicit.
• New instrumentation takes time to accumulate volume. Don't promise leadership a sized business case before the data exists to size it; promise a specific, time-boxed path to get there instead.

Direct answer

An API is a set of rules that lets two pieces of software ask each other for things and get a response back, the same way a restaurant menu lets you ask the kitchen for a specific dish without needing to know how it's cooked. For support, the practical version is: our product and some other company's system talk to each other automatically over the internet, in a fixed, agreed format, and when that conversation fails, it looks like "the app is broken" even though our code and their code may both be working correctly on their own.

Walking through the request/response flow, and what to leave out

• Client asks, server answers. Frame every API call as one system asking a narrow question ("what is this customer's order status?") and the other giving a narrow answer. Don't teach REST verbs or endpoint names to a support audience, they need the shape of the interaction, not the vocabulary.
• Name the four things that can go wrong, because that's what a support rep actually needs on the spot: the question was asked wrong (a bug on our side), the other system refused to answer (their outage, or our access was revoked), the answer came back garbled or incomplete (a partial failure), or the answer took too long and we gave up waiting (a timeout). Mapping a customer's symptom to one of these four buckets is the real skill being taught here, not the word "API" itself.
• Decide what to omit on purpose: authentication and rate limits are real and matter to engineers, but for a support rep they collapse into one sentence, sometimes the connection itself needs permission or is being used too much, and that shows up looking like the same kind of failure as an outage. Don't walk through how tokens work, it adds vocabulary without adding troubleshooting power.
• Check understanding with a real ticket, not a definition. Hand them a recent "the button doesn't do anything" ticket and ask which of the four failure buckets it fits.

Worked example

Say a customer reports our order-status page came back empty. Behind the scenes, when they loaded that page, our app sent a request to our shipping partner's system asking, in effect, "what's the status of order 48213?" Two things can happen: the shipping partner answers with the status and our page displays it, or something breaks in that exchange, their system is down, our request had a typo, or the token proving we're allowed to ask has expired, and our page has nothing to show, so it renders blank instead of an error message. For the support rep, the API is the reason "our website" and "the shipping company's website" can disagree at the exact same moment: they're two separate systems, and this blank page is what it looks like when the conversation between them fails partway through, not when either system is fundamentally broken.

Trade-offs and pitfalls

The waiter analogy earns its keep for the request/response shape, but it breaks down the moment a rep asks "so can I just call them and ask directly?", real APIs are automated, high-volume, and machine-to-machine, there's no waiter to flag down. Say that limit out loud rather than let them assume a human process exists behind it. The bigger pitfall is oversimplifying past the point of being useful: a support rep who can only say "it's an API problem" can't triage a ticket. The four-bucket failure model above is close to the minimum depth that turns the definition into something actionable, cut much further and the explanation stays clear but becomes useless.

Direct answer. Start from the capacity: derive what fits, define the one job the MVP (minimum viable product: the smallest product that tests the core idea) must prove, sort features with MoSCoW, and agree the cut order before work starts. Then explain cuts in terms of the goal, not preferences.

Capacity (illustrative: 2 engineers, 6 weeks). 2 x 6 = 12 person-weeks. Keep a 20% buffer (time held back for surprises): 12 x 0.2 = 2.4, leaving 9.6 person-weeks to plan.

MoSCoW (Must, Should, Could, Won't have this time; an approach from rapid application development, a style of building software in short cycles) with estimates, for a community app where people post and follow each other:

Musts total 8.0, plus the Should 1.5 gives 9.5, within 9.6. Coulds (2.0) are not in the committed plan; they only start if we are ahead. Check the Must share against the DSDM (Dynamic Systems Development Method) guideline. MoSCoW was created by Dai Clegg in 1994 for rapid application development and is used heavily in DSDM, whose published guidance is typically no more than 60% Must Have effort, measured against the planned effort for the timeframe (Won't items excluded), with around 20% Could Have effort as contingency. Planned effort here is 8.0 + 1.5 + 2.0 = 11.5 person-weeks, so Musts are 8.0 / 11.5 = 69.6%, Shoulds 13.0% and Coulds 17.4%. That is above the 60% guideline, so this plan is at the risky end: confidence that every Must lands is lower than DSDM recommends. (Against the whole 12 person-weeks the Musts are 67%, and against the 9.6 plannable weeks 83%, but neither is the basis the guideline uses.) The 2.4-week buffer is my own addition, not part of DSDM's rule, and it does not fix the ratio; the fix is to narrow Musts before the build starts, for example a simpler profile (1.0 instead of 1.5) and a chronological feed (1.5 instead of 2.0), which brings Musts to 7.0 of 10.5 planned (66.7%), closer to the guideline though still above it, and to keep the buffer for the surprises that remain.

What to cut first if it slips. Reverse order of value. Because the Coulds are not in the committed plan, the first cut is simply not starting them (notifications, then analytics beyond one launch event) and spending that time on the buffer. If the slip continues, cut comments next, keeping likes only. Musts are never cut; if even they slip, move the date or the launch audience, not quality of safety features like report and block.

Choosing in/out. I use a PR/FAQ (a press release and customer FAQ written as if launched). Write the headline first, for example: "Neighbours can now sign up, post, follow each other, see a feed and stay safe with report and block." If a feature is not needed to write that headline, it is not a Must; direct messages do not appear in it, so they are a Won't. Another way to cut is to serve one segment first. Suppose the app has moderators (volunteers who review reports), power users (who post daily) and casual users (who mostly read). Pick the segment whose need is sharpest, for example moderators, who need report and block to keep a new community safe, and give the others a clear later path.

Explaining cuts. Show the table and the rule: "This is what the first version must prove. Each cut buys the buffer that protects the date." Give the owner of each Won't a date to revisit.

Situation: I led a launch that needed Product, Engineering, and Support to deliver the same outcome, which was reducing customer setup time.

Task: Each team had different priorities, so I needed one shared goal and a way to surface trade-offs early.

Action: I started with a single business metric, then broke it into team-level commitments. Product owned the user flow, Engineering owned reliability, and Support owned readiness. I held a weekly cross-functional checkpoint where each team shared risks, not just status. When conflicts came up, I made the trade-off explicit. For example, we chose to delay one nonessential feature so we could simplify onboarding and reduce support tickets.

Result: The teams stayed aligned, the launch shipped with fewer surprises, and the process made future collaboration easier because everyone knew how decisions would be made.

The key lesson was that shared outcomes work best when the goal is visible, disagreements are discussed early, and trade-offs are decided openly instead of being left to drift.

Direct answer

For a team this size the file structure should map to ownership, not to project chronology: one design-system file that is the single source of truth for shared components, one project (a project is a folder-like container grouping related files) per active product initiative holding that initiative's editable working file, one standing prototypes project holding a prototype file per product area, and one standing research project for artifacts that inform design but are never themselves shipped.

Structured elaboration

Four file buckets, kept deliberately separate:

1. Design system file. One file, published as a shared team library so other files consume components by reference instead of copy-paste. This keeps the file small and fast and means an update to a component propagates everywhere it's used.
2. Product/feature files. One file per active initiative, owned by the designer driving it, living in that initiative's own project. Components inside are local instances pulled from the library, never duplicated originals.
3. Prototype files. Prototypes with heavy interaction wiring live in their own file, one per product area, and those files sit together in a single standing "Prototypes" project rather than inside each product's project. Two reasons for that placement, and they're the reasons this bucket exists at all: a prototype with many linked frames slows the file down for everyone editing it, and testing artifacts churn faster than production designs and need looser edit access than a product project's own permission policy should allow.
4. Research artifacts. Kept in their own standing "Research" project, never mixed into a component file, since they're synthesis material, not production UI, and they need the same loose edit access as prototypes for the same reason.

Naming pattern: apply project, then file, then page naming.

• Projects: one per product area, named "[Product area]", e.g. "Checkout", "Onboarding Flow", plus three standing projects that are not product areas: "Design System", "Prototypes", "Research".
• File: "[Area] - Product" (the working file, in that area's project), "[Area] - Prototypes" (in the Prototypes project), "[Area] - Research" (in the Research project).
• Pages: every page in every file carries a two-digit numeric prefix, so the sort order stays meaningful as pages are added, and "00 Cover" is page one of every file without exception. A product file's pages are "00 Cover", "01 In progress", "02 Ready for dev", "03 Archive". A file with genuinely different content, the design-system file, say, keeps the same prefix rule with names that fit what it holds. What has to hold everywhere is the prefix and the ordering, not one fixed list of page names for every file.

Permissions:

• Design-system file: edit access limited to the one or two people who own it; everyone else has view/library-consumer access only, preventing accidental edits to shared components.
• Product projects: the owning designer and design lead get edit access; product managers get comment access, so they can leave feedback without moving frames or breaking a layout structure.
• Prototypes and Research projects: broader edit access, since anyone running a test or workshop needs to add notes or frames. This is the concrete payoff of giving those two buckets their own projects instead of scattering their files inside product projects: access is granted per project, so one setting covers every area's prototype file, rather than maintaining a hand-made permission exception inside every product project.

Onboarding benefits from this directly: a fixed project structure and page-naming convention means a new hire's first stop, the design-system file's "00 Cover" page, tells them where everything else lives without a message thread explaining it.

Worked example

A workspace holds projects "Design System", "Checkout", "Onboarding Flow", "Prototypes", and "Research". The Design System file has pages "00 Cover", "01 Foundations", "02 Components", "03 Icons", "04 Changelog", is published as a library, and only the system owner and design lead can edit it. The Checkout project holds one file, "Checkout - Product", with pages "00 Cover", "01 In progress", "02 Ready for dev", "03 Archive", owned by the checkout designer, with the PM on comment access. The heavily-wired 40-frame clickable prototype for an upcoming usability test is not in that project: it lives as "Checkout - Prototypes" in the Prototypes project, kept out of the roughly 200-frame production file so it doesn't slow that file down for the rest of the team, and editable by anyone running the test without touching the Checkout project's permissions. Research findings live as "Checkout - Research" in the Research project, linked from the product file's cover page rather than pasted directly in. The library-performance payoff shows up concretely here: because Checkout's product file only holds instances of the shared Button and Card components rather than duplicated originals, the file stays lean even as the flow grows, and a later corner-radius change to Button in the system file updates every instance across every product file automatically.

Trade-offs and pitfalls

Splitting into too many small files creates its own navigation cost; the four-bucket split above is deliberately coarse, not one file per screen. If the library owner becomes a bottleneck, updates stall, so a documented request-and-review process matters more than restricting edit access ever more tightly. Comment-only access can frustrate a PM who genuinely wants to reorganize a flow, so set that expectation up front rather than loosening the permission the first time it's inconvenient. The most common failure mode is mixing exploratory and shippable work on the same page, letting "In progress" bleed into "Ready for dev", which defeats the whole scheme; that discipline has to be enforced by habit and review, not by the folder structure alone. The second most common failure mode is applying the page convention to product files but quietly skipping it in the design-system file, which is the one file every new hire opens first, so a convention that lapses exactly there fails at the moment it was supposed to pay off.

Direct answer

I'd treat inconsistent spacing as two separate problems: find and fix the current drift in the file, and separately, put a structural guard in place so the same components can't drift again the same way. Fixing the instances without fixing why they drifted just means the next handoff has the same conversation.

Auditing the current inconsistencies

I'd scan the file's Instances panel for the affected component and compare their padding and gap values directly, since a component can show three visually similar cards with, say, 14px, 18px, and 12px of internal padding that all look "roughly the same" at a glance but are actually three different values. A spacing-audit plugin can surface these deviations automatically across a large file faster than eyeballing every instance.

Fixing them

Starting from the main component (not a copy of an instance), I'd rebuild its layout using Auto Layout, a Figma feature that behaves like a flexible box container: instead of manually positioning each element, you set padding and gap rules once and every element inside follows them automatically. I'd replace the inconsistent hard-coded pixel values with a single spacing token (for example spacing.md = 16px) pulled from the shared spacing scale, then update every instance to inherit from the corrected main component rather than editing each one by hand. Where an instance has a genuinely intentional override (a card that's meant to be denser for a specific reason), I'd document why directly on that instance so the next person auditing the file doesn't "fix" it back to the standard value by mistake.

Preventative measures

• A documented spacing scale (a small fixed set of token values like spacing.xs, spacing.sm, spacing.md, rather than any pixel value being allowed) that every component is expected to use.
• Auto Layout as the default for new components, with layer structure and naming locked so it's harder to accidentally introduce an arbitrary offset.
• A short do/don't reference directly on the component's page in Figma, showing the correct spacing next to a common mistake.
• A spacing-lint check run as part of the design review before a component is considered handoff-ready, so drift is caught before it reaches engineering, not after.
• A brief walkthrough for the team on why and how to use the spacing tokens, since most drift comes from someone not knowing the token existed, not from ignoring it deliberately.

Worked example

Auditing a "Card" component turns up three instances in the file with padding values of 14px, 18px, and 12px, none of which match the design system's 16px spacing.md token. I rebuild the main Card component with Auto Layout set to 16px padding on all sides, update the three drifted instances to reset to the main component instead of keeping their local overrides, and verify visually that nothing else shifted unexpectedly as a side effect of adding Auto Layout. Going forward, the spacing-lint check flags any new Card instance that doesn't inherit the token value, before it ever reaches a handoff document.

Trade-offs and pitfalls

Retrofitting Auto Layout onto an older component can shift the layout in ways you don't expect, since the container now actively manages positioning instead of the static positions you had before, so a visual check after conversion is necessary, not optional. The other pitfall is building the token library and stopping there: without an enforced check at review time, spacing drifts right back in over the next few months as new instances get created the old way, one small "close enough" override at a time.

The framework: severity triage, then match mitigation to severity, then make the deferred work impossible to forget.

Start by triaging every accessibility violation against a concrete severity scale, not a vague "bad/worse" sense. A workable three-tier scale:

• Blocking: a user with a disability cannot complete a core task at all (for example, a checkout button with no accessible name, so a screen reader announces nothing actionable, or a modal that traps keyboard focus with no way out).
• Degrading: the task is completable but meaningfully harder or slower (for example, a form with low-contrast error text that a low-vision user can complete only with extra effort).
• Cosmetic: a real WCAG (Web Content Accessibility Guidelines) violation that does not block or meaningfully degrade any task (for example, a decorative icon missing an aria-label when it carries no information).

Concrete example: launching a checkout flow. Triage finds one Blocking issue (the "place order" button has no accessible label, so it's literally invisible to screen reader users), two Degrading issues (contrast ratio of 3.8:1 on form validation text, below the 4.5:1 WCAG AA minimum), and four Cosmetic issues (missing alt text on non-essential marketing images).

Interim mitigations, sized to the severity. For the Blocking issue, you do not launch it as-is: either fix it (adding an aria-label is usually a same-day fix, far cheaper than full remediation) or, if genuinely un-fixable before launch, stand up a documented fallback path (a phone or chat order line specifically flagged for accessibility support) so no user is fully locked out. For Degrading issues, ship with the known gap but add a lightweight mitigation where cheap (bump the specific contrast value even if the broader design system audit waits). Cosmetic issues simply get logged, no mitigation needed pre-launch.

Communication, tailored per audience. To engineering: a ticket per issue, tagged with severity, effort estimate, and target sprint, so remediation is plannable work, not an open-ended promise. To the PM: frame it as a trade-off in product terms, "the Blocking issue is fixed before launch; the two Degrading issues ship with an interim contrast bump and are fully remediated within two sprints; four Cosmetic issues are tracked for the next design-system pass." To legal: this is the audience most people forget, and it matters most, since unremediated violations carry real exposure: WCAG 2.1 AA is the de facto standard referenced in disputes under ADA Title III (the part of the US disability-rights law covering private businesses) and Section 508 (the federal law requiring US government websites to be accessible). Legal needs to know exactly what's shipping unfixed, why (the mitigation, not just "we ran out of time"), and needs to sign off on the residual risk in writing, since a documented good-faith remediation plan is meaningfully different, legally, from silence.

Accountability for the post-launch fix. The trap here is "we'll fix it after launch" with no forcing function, which in practice means it never gets fixed once the team moves to the next deadline. Make it concrete: every deferred issue gets a ticket, an owner, and a target release, and the Blocking-tier bar for the next release is "zero known Blocking issues," gating that release the same way you'd gate a security vulnerability. Put a specific date on the calendar (not "next quarter") to revisit the full list with the PM and confirm what actually shipped.

The mediocre answer here is a vague promise: "we'll note the issues and revisit later." Without severity tiers, without owners, and without a legal sign-off on the specific residual risk, "later" is functionally "never," and the team has neither reduced harm now nor guaranteed remediation later.

This same shape applies outside of web engineering. A data team publishing a public-facing report with inaccessible tables (no header structure a screen reader can navigate) faces the identical decision: triage which tables are load-bearing for a blind user's actual task versus decorative, ship a plain-text summary as an interim mitigation for the load-bearing ones, and put a ticket and a date on the real fix rather than letting "we'll clean it up later" quietly become permanent.

Approach (brief)
I treat consistency as a product-wide system, not a one-off visual decision. I build reusable artifacts, automate checks, and keep a clear workflow so designers and engineers can apply the same rules everywhere.

Artifacts & tokens I create

• Design token set (color, spacing, typography, elevation, motion) exported as JSON/Style Dictionary for devs and synced to Figma as variables.
• Component library in Figma with variants (buttons, inputs, cards) that include usage notes and accessibility states.
• Visual style guide that documents voice, grid, iconography, and micro-interaction patterns.
• Component changelog and versioning table.

Workflows & enforcement

• Single source Figma library + strict branching for updates; a maintainer approves merges.
• Pull-request checklist: token usage, accessibility, responsive behavior, QA steps.
• Cross-functional review cadence: weekly design-system triage with PMs and engineers for breaking changes.
• Automation: linting (eslint-like for styles), Storybook with visual regression tests, and a regression checklist for releases.

Example
When redesigning our primary form, I updated the spacing token, bumped component version, updated Storybook snapshot tests, and ran a visual review — this prevented 12 inconsistent instances from shipping.

This combination of tokens, components, documentation, automation, and governance keeps visual and interaction consistency scalable.

Approach overview

I prototype fast, test with users, and convert perceptual results into developer-ready timing/easing specs. My goal: match motion to intent (micro vs macro) and optimize perceived responsiveness.

Creating variations

• Build lightweight prototypes in Figma (Smart Animate), Principle, or Framer. Export multiple variants: short (80-120ms), medium (200-300ms), long (400-600ms); easing: linear, ease-in, ease-out, cubic-bezier presets, and spring settings. A spring-based animation is controlled by stiffness (how fast the spring snaps toward its target position, higher feels snappier) and damping (how much it overshoots and wobbles before settling, higher damping settles faster with less bounce).
• Keep other variables constant (color, size) so timing is isolated.
• Produce side-by-side and single-interaction A/B flows and an interactive gallery users can trigger.

Worked example: choosing one value for a button-press ripple
Rather than leaving the recommendation as an 80-160ms range, walk one interaction all the way to a chosen number. Build the button ripple at 80ms, 120ms, and 160ms and show all three to a handful of test users side by side. In a scenario like this, 80ms tends to feel abrupt and easy to miss, 160ms starts to feel like a delay, and 120ms with ease-out is typically the one most people describe as "instant but still visible." That is the value that ships in the spec: 120ms, cubic-bezier(0.0, 0.0, 0.2, 1). The same process, build 3 candidate values, test head to head, pick the one that reads as immediate without feeling invisible, applies to any interaction in the range, not just this one.

Collecting feedback

• Moderated usability sessions: task-based scenarios (e.g., "dismiss modal", "tap button"); ask for immediate impressions and preference.
• Quantitative: measure perceived latency with first-click-to-feedback and success time; use a 7-point Likert scale (a numbered agree/disagree rating) for responsiveness, naturalness, and delight.
• Qualitative: concurrent think-aloud and short interviews to surface friction.
• Rapid remote tests: use tools like Maze to collect preference votes and quick reaction times from larger samples.

Analyzing and deriving the spec

• Identify the variants with the highest perceived responsiveness and task efficiency. Prefer shorter durations for tactile microinteractions (e.g., button ripple 80-160ms, landing on 120ms per the worked example) and a physics-based spring for spatial movements (modal open 240-400ms with moderate damping).
• Translate to developer tokens: duration, easing (cubic-bezier or spring params), delay, and motion role, meaning whether the animation is critical (must be seen to understand what happened, e.g. a modal appearing) or decorative (nice to have but safe to skip, e.g. a subtle hover glow).
• Deliver a spec doc: examples, GIFs, accessibility notes (reduce-motion alternatives), and code snippets (CSS cubic-bezier and JS spring values).

Outcome and rationale

I prioritize task speed for micro feedback, and momentum/weight for modal transitions, backed by measured preferences and performance data, so engineers can implement consistent, perceptually-optimized motion.