Lyft UX Designer (Mid-Level) Interview Preparation Guide

Direct answer

For a remote-first startup, Figma is the strongest recommendation of the three: it's fully browser-based with real-time multiplayer editing built into its core from the start, which matters more for a distributed team than for a co-located one, it has the deepest plugin ecosystem and design-system tooling of the three, and it gives engineering a built-in inspection view for handoff with nothing to install locally. Sketch is a credible second choice for a Mac-heavy team already invested in it, but is a materially weaker fit for a genuinely cross-platform distributed team. Adobe XD is not a sound choice for new work today, since Adobe itself has said it is no longer actively investing in the product.

Structured elaboration

Comparing across the named criteria plus two more worth adding explicitly, file performance at scale and prototyping fidelity:

Recommendation: Figma as the primary tool. "Remote-first" specifically makes real-time multiplayer editing and zero-install browser access disproportionately valuable, and its design-system and handoff tooling reduce the number of separate tools a team would otherwise need to stitch together.

Migration and onboarding considerations. Don't treat a migration from Sketch or Adobe XD as a straight file import: existing tools offer import paths for those file formats, but a component built as loosely grouped layers in the old tool typically needs to be rebuilt as a proper component with real variant properties to get the design-system benefits described above; a mechanical import alone just relocates the mess. Migrate by product area rather than all at once, letting one active initiative prove the new file and naming conventions work before the rest of the backlog follows, and keep the old tool's file as the frozen reference of record until the new one is validated on a real release. Onboarding a distributed team is comparatively light: there's no license to install locally, a new hire is added by email invitation to the relevant projects, and the file and permission structure a team already uses for organization applies unchanged; the main onboarding investment is walking new hires through the team's specific naming and page conventions, not the tool's mechanics.

Trade-offs and pitfalls

Recommending Figma doesn't mean every legacy file needs to migrate on day one; a working existing design-system file, for a small and stable team, represents a real switching cost against a real but not always urgent collaboration benefit, so weigh urgency honestly rather than assuming migration is free. A startup also shouldn't choose a tool purely on today's feature comparison without checking each vendor's own stated direction; a product a vendor has said it's no longer investing in is a real business-continuity risk for a young company that can't easily absorb a forced re-migration later.

Direct answer

GROW is a four-stage, question-led coaching structure: Goal (what success looks like), Reality (the current state), Options (possible paths forward), and Way forward (specific commitments). Applied to a 1:1 with someone who wants to grow a specific skill, it turns a vague aspiration into a concrete next step, and the same question-led habit also works inside a work review, not only a scheduled conversation.

Walking through the four stages

• Goal. Get specific: "What would 'better at this' actually look like, concretely, and how would you know it happened?"
• Reality. Surface the current state without judgment: "Tell me about a recent situation where this was hard, what made it hard?"
• Options. Generate paths rather than prescribing one: "What could you try next, and who or what could help?"
• Way forward. Get a specific, small commitment: "Which one thing will you actually do before we talk again, and what support do you need from me?"

Socratic questioning is the companion technique that runs through all four stages: instead of stating the answer, ask a question that leads the person to notice the gap themselves ("what did you expect to happen there, versus what actually happened?"). It works well when there's time to let someone arrive at the insight; it works poorly when someone is genuinely blocked and just needs the direct answer.

Extending this into reviewing someone's work

The same question-led approach makes a review of someone's work (code, a document, a design, an analysis) constructive rather than purely corrective. Concrete techniques: a review template that separates "must fix" from "worth considering" from "just for your awareness," so feedback doesn't read as one undifferentiated pile of criticism; annotated examples that show a better version alongside the original with a short reason, not just a comment naming the problem; and a Socratic question left in the review itself ("what happens here if this is empty?") instead of stating the bug outright, when the goal is teaching and there's no urgency forcing a direct fix.

Worked example

In a 1:1, a mentee said they wanted to get better at making structural decisions independently instead of always checking first. Goal: they described what "independent" would look like in practice (making a defined class of calls without asking). Reality: walking through a recent case, they could explain their reasoning but hadn't trusted it enough to act without confirmation. Options: they proposed trying it on a low-stakes decision first and reviewing the reasoning after the fact rather than before. Way forward: they committed to making the next reversible decision on their own and bringing the reasoning to the following session, with an explicit offer of support if it went wrong.

Trade-offs and pitfalls

A common mistake is treating GROW as a rigid script and marching through all four stages regardless of what the person actually needs that day. A stronger approach holds the structure loosely: skip Reality if it's already obvious, compress stages under time pressure, and know when the moment calls for direct answers instead of more questions, especially if something is safety-critical or urgent. Inside reviews specifically, overusing Socratic questions when someone is genuinely stuck can read as withholding rather than teaching, so it's worth pairing questions with a clear direct answer once the teaching moment has been made.

Direct answer
A moderation guide is the script a facilitator, the person running the session, called a moderator, follows during a moderated usability test, so every session stays consistent, ethical, and focused on the same tasks, no matter who's running it or which participant showed up.

Structured elaboration: what it includes

• Introduction: the study's purpose, roughly how long it will take, and a clear "there are no wrong answers" framing to reduce performance anxiety.
• Consent and privacy: confirmation of recording, how the data will be used, and that the participant can stop at any time.
• Warm-up: a quick, low-stakes task or a couple of background questions to settle nerves before the real tasks start.
• Task list: realistic scenarios phrased as goals, "you'd like to buy this item and have it shipped by Friday," not step-by-step instructions, plus the order they'll be given in.
• Probes: a small set of neutral, prepared prompts to draw out thinking without suggesting an answer.
• Timing notes: roughly how long each task should take, and what to do if a participant gets stuck past that point.
• Note-taking guidance: what to actually write down, errors, pauses, exact quotes, workarounds, so notes are comparable across sessions and moderators.
• Wrap-up: final open questions, any compensation logistics, and thanks.

Worked example: a neutral probe for checkout, and why it's neutral
Leading (avoid): "Don't you think that button is hard to find?" This tells the participant what answer is expected and plants the idea that the button is a problem, whether or not they actually thought so.

Neutral (use instead): "Can you tell me what you're thinking right now as you try to complete the purchase?" This asks the participant to narrate their own thought process without hinting at what the "right" observation is. If they do struggle with that button, they surface it themselves; if they don't, no idea was planted that they should have.

Trade-offs and pitfalls
A guide that's over-scripted can make a moderator sound robotic and miss genuinely interesting tangents; the goal is a consistent skeleton, not a script read word for word. Bias can leak in through tone and body language even when the wording is neutral, a raised eyebrow at "was that confusing?" gives away the expected answer just as much as a leading question would, so training a new moderator has to cover how to ask, not just what to ask.

Short answer

I would write a short decision record that a stranger can read in five minutes: what was decided, why, what else was considered, what was given up, and exactly what would make us revisit. The format follows the architecture decision record (ADR), a short written note per decision that Michael Nygard popularized in 2011 with sections for title, status, context, decision and consequences. I add options, scoring and revisit triggers.

The template, and why each part exists

Short excerpt (illustrative)

Decision: Ship the SSO login before the new reporting module. Status: accepted, review 15 March. Options: SSO first; reporting first; both with a smaller scope. Trade-off: reporting slips one quarter; three accounts that asked for it were told. Revisit if: more than two renewals cite reporting, or the SSO estimate grows past 8 weeks.

Decision log and retention

Keep a one-row-per-decision index (ID, date, decision, owner, status, review date) linked to each record. Store records in one searchable place such as the wiki or the product repository. Keep them as long as the product exists; mark old ones superseded instead of deleting or rewriting them, so history stays truthful.

Executive-facing version

A one-page summary on top of the record: recommendation, what we are not doing, the cost and risk, and the one thing we need from them.

Direct answer. Accessibility and inclusive design belong among core design values because they force a discipline that improves the product for everyone, not only the specific population directly served: designing for keyboard-only operability tends to clarify interaction models generally, and designing for plain language tends to improve comprehension for every reader, not only the population that strictly requires it.

A concrete example, stated honestly. On a project redesigning a multi-step form, treating accessibility as a first-class constraint (not a post-launch checklist item) led to simplifying the step structure itself: the original design had five steps with inconsistent field grouping that made keyboard-order and screen-reader navigation confusing to design correctly, and the fix that made it accessible also collapsed it to three more logically-grouped steps, which measurably reduced abandonment for the general user population, not only for assistive-technology users specifically.

Trade-offs considered. The design took an extra sprint the original timeline hadn't budgeted for; the trade-off accepted was a later ship date against a broken initial design that would have required a full accessibility retrofit later at higher cost, a bet that paid off given the abandonment-rate improvement but was a genuine trade-off made under real timeline pressure, not a cost-free decision.

How it was measured. Task-completion rate and step-abandonment rate before and after, plus a specific post-launch accessibility audit confirming the redesigned flow passed keyboard and screen-reader testing that the original never would have.

Trade-offs and pitfalls. A common weak answer to this kind of question states accessibility as a value without any concrete instance where it actually changed a real decision under real constraints; the strongest answers name the specific trade-off accepted (schedule, scope, or effort) rather than presenting the choice as costless, since interviewers are specifically listening for evidence the value survives contact with a real deadline.

Overview / goal
Create a staged operational plan that uses rapid qualitative usability testing to iterate on designs, then validates at scale with A/B experiments before full rollout, minimizing user risk and avoiding confounding effects.

Timeline (8-12 weeks)

• Weeks 0-1: Align goals, success metrics, MDE (minimum detectable effect: the smallest real change you actually want the test to be able to catch), and constraints.
• Weeks 1-3: Design + low-fidelity prototype; internal heuristic review.
• Weeks 3-4: Moderated remote usability tests (5-8 users) then quick iterations.
• Weeks 4-6: High-fidelity prototype + unmoderated task-based testing (15-30 users) then final tweaks.
• Weeks 6-10: Instrumentation, feature-flagged A/B experiment (4-6 weeks to reach power).
• Weeks 10-12: Analyze, stakeholder review, progressive rollout (10% -> 50% -> 100%) with gating at each step.

Responsibilities

• Product Designer: craft flows, prototypes, define qualitative scripts, review usability findings, define UX acceptance criteria.
• Research: recruit, run moderated/unmoderated sessions, synthesize qualitative insights and usability metrics (task success, time, and SUS, the System Usability Scale, a 10-item survey that converts perceived ease of use into a 0-100 score).
• Product Manager: define business goals, primary/guardrail metrics, MDE, rollout plan, stakeholder sign-off.
• Engineering: implement feature flags, telemetry, experiment SDK, ensure data integrity and rollout automation.
• Data/Analytics: validate instrumentation, run experiment analysis, compute power, monitor metrics.

Instrumentation & metric definitions

• Events: view, click, task_complete, error, session_id, user_id, variant_id, timestamp.
• Primary metric: conversion funnel metric tied to the goal (e.g., completion rate).
• Guardrails: retention (7/30-day), error rate, task failure rate, page load.
• Qualitative metrics: task success %, time on task, major usability issues count, SUS.
• Statistical setup: before launching, pre-register the hypothesis and work with the experimentation or analytics team to size the test for the MDE you actually care about, and to decide up front how, or whether, results can be checked before the test ends without compromising the read. That sizing and significance work is their discipline to run; the design and research side's job is making sure the right primary metric and MDE exist for them to size against.

Gating criteria for rollout

• Usability: task success >= target (e.g., +10% vs baseline) and no critical usability issues.
• Experiment: primary metric shows statistically significant improvement (or non-inferiority) and no regression on guardrails.
• Data quality: instrumentation validated, low event loss, consistent cohorts.
• Stakeholder sign-off.

Avoiding confounding across studies

• Pre-register tests and timelines; avoid running overlapping experiments on the same UI elements or user cohorts.
• Use mutually exclusive randomization or stratified holdouts.
• Freeze adjacent UI changes during the experiment window; schedule blackout windows for releases.
• Segment analysis to detect interaction effects; run interaction tests when overlap is unavoidable.
• Keep prototypes used in qualitative testing functionally equivalent to the experimental variant, to reduce mismatches.
• Validate baseline stability (a pre-period A/A test if needed).

Why this works
Qualitative testing catches discoverable usability problems fast and cheaply; A/B testing verifies impact at scale. Clear responsibilities, instrumentation, gating, and anti-confounding rules preserve validity and enable confident, incremental rollouts.

Direct answer

Build the funnel in three levels that narrow: first ask "is the drop real?", then "where is it concentrated?", then "what changed there?". At each branch, pick the test that costs hours rather than weeks. NPS (Net Promoter Score) is the share of promoters (answering 9 or 10 to "how likely are you to recommend us, 0 to 10") minus the share of detractors (0 to 6). Because the fall is company-wide, I would suspect measurement or mix changes and company-level causes before a single feature.

Structured elaboration

Worked example

Illustrative numbers for the mix test. Last quarter respondents were 70% small business at NPS 50 and 30% enterprise at NPS 30, so company NPS was 0.7 x 50 + 0.3 x 30 = 44. This quarter the mix is 40% / 60% with both segments unchanged: 0.4 x 50 + 0.6 x 30 = 38. A 6-point company-wide fall appeared with no change in how any customer feels. Reweighting to last quarter's mix returns 44 and kills "everyone is unhappier" at level 2. (This works because NPS is a difference of percentages, so the company score is a weighted average of segment scores.)

Trade-offs and pitfalls

• Test the measurement first. A real investigation on a broken measurement wastes weeks.
• Verbatim comments suggest themes but cannot size them. Treat them as leads to confirm with counts.
• Several causes can be true at once. Killing a branch means "does not explain the drop", not "has no effect".
• Order by cost. Run all level 1 and 2 queries in the same afternoon before any interviews.

Direct answer

The signal that you're explaining from the wrong assumption rarely sounds like disagreement, it sounds like follow-up questions that are individually reasonable but all slightly off-topic from what you just said, or a question that only makes sense if the listener is picturing a different setup than the one you're describing. The recovery move is to name the assumption you were making out loud, confirm the real one, and re-explain from there, rather than trying to patch the existing explanation with corrections.

Reading the signal and recovering

• Watch for questions that are technically reasonable but don't fit the thing you just explained. That mismatch, not confusion or silence, is usually the clearest early signal that a core assumption is wrong, not that the explanation itself was unclear.
• Don't try to bolt a correction onto the explanation already in progress; restart the relevant section from the correct assumption. Patching creates a hybrid explanation that fits neither model and confuses people further.
• Name the assumption explicitly before re-explaining ("I've been describing this assuming X, it sounds like your setup actually uses Y"). This turns an awkward correction into a moment that builds credibility, you caught it and adapted, rather than one that erodes it.
• Afterward, build a habit of confirming the assumption BEFORE it becomes load-bearing next time; a single check-in question near the start of a similar conversation is cheaper than a mid-conversation pivot.

Worked example

Situation: I was walking a prospective enterprise customer's security and platform leads through how our API gateway handles authentication, about twenty minutes in, still assuming they used the same token-based authentication most of our customers use.

Signal: two of the listeners exchanged a confused look, and one asked a question about certificate rotation and certificate authority chains, a question that only makes sense if you're authenticating with mutual TLS instead of tokens. That question was the signal, it was reasonable on its own, but it didn't fit anything I'd just described.

Action: I paused and named the assumption directly: "I've been describing this assuming you use token-based authentication between services, it sounds like you're actually using mutual TLS, is that right?" Once they confirmed, I didn't try to graft mutual TLS onto the token explanation, I restarted that section from scratch: how our gateway validates a client certificate, how certificate rotation works on our side, and where their rotation policy would need to line up with ours, using a fresh, small diagram rather than editing the one already on screen.

Result: the confusion visibly cleared, and the conversation shifted into their actual technical questions, which we were then able to answer directly instead of talking past each other. Afterward, I started opening similar demos by confirming the authentication method in use before describing the flow, rather than assuming the common case, and this specific mismatch didn't come up again in later conversations of the same kind.

Trade-offs and pitfalls

The riskiest moment is right after you notice the mismatch and before you've named it out loud; there's a real pull to keep going and hope it resolves itself, which almost never works and usually compounds the confusion. The other pitfall is over-correcting into re-explaining everything from scratch when only one assumption was wrong, that wastes the audience's patience and buries the actual fix. Isolate exactly which piece depended on the wrong assumption and restart only that piece.

Direct answer

Qualitative research tells us why people struggle and what they need; it does not tell us how many people are affected or whether our specific solution fixes it. Engineering cost tells us what the answer will cost. So I would not choose between "believe the research" and "believe engineering". I would turn the recommendation into a testable claim, price the cheapest way to test it, and choose among proceed now, postpone, or test an alternative on that basis.

Process

1. Restate the recommendation as a problem and a hypothesis (a testable guess about cause and fix). "Users cannot find X, which blocks Y. We believe moving it to Z fixes this." Separate the observed problem (strong, from interviews) from the proposed solution (a guess).
2. Probe the evidence with the researcher. How many participants, which segments, how consistent, what did people do versus say? A handful of interviews is good at surfacing problems and weak at sizing them, so I look for a cheap quantitative check (support ticket counts, funnel drop-off at that step: the share of users who reach a step in a flow but do not continue past it) to size the problem.
3. Unpack the engineering "expensive" with the engineers. Ask what drives the cost: new back-end work, a design-system change (editing the shared set of interface components that many screens reuse), migration of existing users? Ask for the smallest slice that tests the idea and a rough range, not a single number.
4. Generate options at different costs. Typical ladder: a clickable prototype test (days), a partial change to the most-hit screen, a feature-flagged experiment (the change shown to a random share of users behind an on/off switch, compared with everyone else), the full redesign.
5. Decide with explicit criteria: size of the problem, confidence the solution works, cost, reversibility, and what else the team would not build.

Worked example (illustrative)

Eight interviews show people abandoning the setup flow at the account-linking step. Engineers estimate 10 engineer-weeks (one engineer working one week each) for the full redesign. A funnel check shows 1,000 sign-ups a month reach account linking and 600 complete it, so 400 (40%) abandon, and the problem is real. Instead of 10 weeks, we spend 1 week on a clickable prototype test with new users and 2 weeks building a simplified version behind a flag for an experiment, 3 weeks of team effort before the experiment can start. The calendar time to a read is longer: the 500-per-group sample needs 1,000 users, and only 1,000 sign-ups a month reach account linking, so the experiment runs for about a month after the build, roughly 7 calendar weeks in all (1 prototype + 2 build + about 4 running). Decide the thresholds first. Lift means the increase in completion rate compared with the control group. If the simplified version lifts completion by 10 points or more (60% to 70%, 100 extra completions a month), proceed to the full redesign or ship the simple version permanently. If lift is under 3 points, postpone and log it. Between 3 and 10 points, extend the test, because with 500 users per group the random noise is about 3 points (square root of 0.6 x 0.4 / 500 x 2 is about 0.031), so small differences cannot be trusted.

Pitfalls

• Treating "5 of 8 said it" as a measured rate. It is a clue, not a percentage.
• Letting engineering cost veto without asking for a smaller slice; or letting the research sponsor dismiss cost.
• Closing the loop poorly: tell the researcher and engineers what was decided and what evidence would reopen it.

Direct answer

I would build a composite metric from each product's own normalized, comparable score rather than its raw revenue or usage number, since raw numbers naturally let the biggest product dominate the average by sheer scale, and then choose a weighting scheme deliberately rather than defaulting to a straight revenue-proportional weight. I would decompose the composite so every team can see exactly how much their product is contributing to the shared number, and I'd govern the weights explicitly (reviewed on a fixed cadence, changes require sign-off) rather than let them drift silently as the portfolio's revenue mix shifts.

Structured elaboration

Decomposing the composite: define a normalized product-health score per product first (for example, a 0 to 100 index blending activation, retention, and satisfaction for that product specifically), then combine those normalized scores across products with an explicit weighting formula, rather than trying to average raw metrics that live on different scales (a product measured in ARR (annual recurring revenue) and a product measured in daily active users can't be averaged directly). Publish a simple metric tree showing each product's contribution to the total, so a movement in the composite can always be traced back to which product drove it.

$$\text{composite} = \sum_i w_i \cdot s_i$$

where $s_i$ is product $i$'s normalized 0-100 health score and $w_i$ is its weight, with the weights summing to 1.

Two weighting or normalization approaches:

1. Revenue-weighted: $w_i$ proportional to each product's share of total ARR. Simple and intuitive, but it lets the largest product dominate almost completely, exactly the failure mode the question is asking to avoid.
2. Log-weighted: $w_i$ proportional to $\log(\text{ARR}_i + 1)$ instead of raw ARR. Compresses the gap between a huge product and a small one, so the small product's score still meaningfully moves the composite, while still giving more weight to a product that generates materially more revenue.
3. (A third, simpler option worth naming as contrast) Equal-weighted: every product counts the same regardless of size. This fully removes size as a factor, which is honest about wanting every product to matter equally in strategy, but it also means a large regression affecting millions of users counts the same as a small one affecting a handful, which is its own kind of distortion.

Governing the weights: review the weighting scheme on a fixed cadence (quarterly is typical), require a metrics council or a named executive sign-off to change it, and publish the current weights alongside the composite so no team can quietly argue after the fact that the weighting was unfair to them.

Preventing a single large product from dominating: beyond the weighting formula itself, cap any single product's contribution at a maximum share (for example, no product can count for more than 50% of the composite regardless of its actual revenue share), and always report the per-product decomposition alongside the composite number so a "the composite looks fine" read can't hide one product's real regression.

Worked example

Three products: A at $50M ARR with a normalized health score of 62, B at $8M ARR with a score of 78, C at $2M ARR with a score of 85 (smaller products often show stronger relative health scores because they're newer and less burdened by legacy complexity).

Revenue-weighted: weights are 50/60 = 0.833 for A, 8/60 = 0.133 for B, 2/60 = 0.033 for C.

$$\text{composite}_{\text{revenue}} = 0.833(62) + 0.133(78) + 0.033(85) \approx 64.9$$

Log-weighted: using $\log_{10}(\text{ARR}+1)$, the raw logs are 1.71 for A, 0.95 for B, 0.48 for C, summing to 3.14, giving normalized weights of roughly 0.544, 0.304, and 0.152.

$$\text{composite}_{\log} = 0.544(62) + 0.304(78) + 0.152(85) \approx 70.4$$

Equal-weighted, for contrast: $(62+78+85)/3 = 75.0$.

The revenue-weighted composite (64.9) is pulled almost entirely toward A's score of 62; the log-weighted version (70.4) still tilts toward A but gives B and C meaningfully more voice; the equal-weighted version (75.0) ignores size entirely. None of the three is objectively correct, the choice encodes a real strategic decision about how much a large legacy product's health should dominate the company's shared number, and a senior candidate names that trade-off explicitly rather than presenting one formula as the answer.

Trade-offs and pitfalls

The trap in composite metrics is treating the weighting choice as a neutral technical detail rather than the strategic decision it actually is; a team unhappy with how they're being measured will often (correctly) point out that the weighting scheme itself determined the outcome. The second trap is publishing the composite without the per-product decomposition, which makes the number impossible to act on: a flat composite could be hiding one product improving sharply while another declines, and without the breakdown nobody would know which lever to pull.