Meta Design Researcher (Entry Level) - Comprehensive Interview Preparation Guide

Approach overview
I'd combine a transparent algorithmic score with qualitative judgment. Create normalized dimension scores, weighted by stakeholder-aligned importance, then surface human overrides with documented rationale.

Scoring method

• Dimensions: Revenue impact, User impact (usability, accessibility), Ease of implementation, Strategic fit, Level of evidence.
• Rate each finding 1-5 per dimension; normalize to a 0-1 scale by dividing by 5.
• Weighted sum formula:

Score = w1*Revenue + w2*User + w3*Ease + w4*Strategic + w5*Evidence

(Each w sums to 1; default example: w1=0.2, w2=0.35, w3=0.15, w4=0.2, w5=0.1)

Worked example: a finding, "mobile users abandon during the payment step," scores Revenue=4, User=5, Ease=3, Strategic=4, Evidence=5 (each on the 1-5 scale). Normalized (divide by 5): 0.8, 1.0, 0.6, 0.8, 1.0. Score = 0.2(0.8) + 0.35(1.0) + 0.15(0.6) + 0.2(0.8) + 0.1(1.0) = 0.16 + 0.35 + 0.09 + 0.16 + 0.10 = 0.86 out of 1.0, a high-priority finding.

• Add modifiers: a risk multiplier for findings that touch high technical or UX debt areas (it lowers the score if implementing the fix risks breaking something else), and an evidence-strength discount that lowers the score slightly for findings resting on a single weak signal (e.g., one offhand comment) versus multiple corroborating sources (interviews plus support tickets plus analytics).
• Tie-breaker: prioritize higher user impact, then lower effort.

Judgment process

• Hold a calibration session with PMs, Engineering, and Research to set the weights and sample-rate a few findings together, so everyone's expectations align.
• Allow documented overrides (owner, reason, expected outcome, review date).

Presentation to stakeholders

• Interactive spreadsheet or dashboard: scores, visual priority bands (Critical/High/Medium/Low), evidence links, estimated effort, and OKRs impacted.
• A 2-slide summary: top 10 findings split into quick wins and strategic bets, plus a proposed roadmap.

Handling disputes

• Hear the concerns, show the data and the evidence level, and propose an A/B test or lightweight validation for disputed items. If it's an urgent political priority, accept a temporary override with defined KPIs and a 30/60-day re-evaluation.

Direct answer

A dedicated ideation phase exists to widen the option space before you commit build resources to any one direction. Prototyping tests a specific idea in enough fidelity to learn from; ideation generates the population of candidate ideas you choose that direction from. If you skip straight to prototyping, you are only ever testing the first plausible idea, not comparing it against anything.

Structured elaboration

Definitions

• Ideation: rapidly generating many candidate directions, in whatever medium is cheapest to produce and throw away.
• Prototyping: building a testable, sufficiently real version of one selected idea, to learn something a sketch cannot tell you (how it actually feels to use, whether it holds up under real data).

Why speed and quantity beat polish at this stage

• Cost of change: a sketch costs minutes to discard; a build costs days or weeks. Ideation deliberately stays in the cheap zone for as long as possible.
• Anchoring: a polished mockup signals false confidence and pulls reviewers toward evaluating the visual execution instead of the underlying idea.
• Coverage: generating more candidates raises the odds that a non-obvious, better direction is even in the room to be considered.

What you actually walk away with
Not a single deliverable, but a small set of genuinely distinct directions (not five variations on one idea), plus a record of what was considered and ruled out and why. That shortlist is what feeds the convergence step, where one or two directions get selected to prototype.

Common tools and when to reach for each

The analog-to-digital move matters for remote teams specifically: sketch fast on paper (it's still faster than a mouse for early divergence), then photograph or re-draw into the shared board so distributed participants can cluster and vote on equal footing.

Worked example

Given a brief to redesign a dashboard's data-summary card, a facilitator runs a fifteen-minute timeboxed round: each participant sketches three layout variants on paper (grid, list, hybrid) without discussion. Sketches are photographed into a shared Miro board so remote participants can see them alongside in-room ones. The group clusters similar sketches, discusses briefly, and picks one direction to carry into Figma for a clickable prototype. Nothing was built in Figma until a direction had already survived divergence and a first round of group discussion.

Trade-offs and pitfalls

• Skipping ideation and prototyping the first idea anchors the team early and means any later usability test is only ever confirming or denying one option, not comparing options.
• Running ideation with no convergence step afterward produces a pile of sketches and no decision; ideation needs to end in a shortlist, not just stop.
• Reaching for a high-fidelity tool too early (styled Figma components during divergence) tends to seduce the group into polishing one idea instead of generating several.

Goal: create repeatable upstream discovery sessions that let non-PM teammates confidently lead interviews while producing rigorous, roadmap-actionable insights.

Preparation (48–72h before)

• Clarify objective: single research question (e.g., "How do mid-market ops teams prioritize integrations?")
• Recruit participants and share context + 10–15 min pre-read
• Create a 45–60 min interview script with 3 parts: warm-up (5m), problem exploration (20–25m), solution/behaviour probes (15m), closing (5m)
• Shared artifact: one-page brief (goal, success criteria, personas, key metrics to validate)
• Mini training (30–45m): coaching session for non-PM leads on open questions, neutral prompts, note-taking, and consent
• Assign roles (these are in-room roles for the session itself, not a full RACI stakeholder chart, since only 4 people are in the room):
  • Interview Lead (engineer/designer): asks questions, probes
  • PM: oversees objective alignment, observes, asks follow-ups sparingly
  • Note-taker/Researcher: timestamps and captures verbatim quotes and signals (video/audio if allowed)
  • Timekeeper: ensures flow

During the interview

• Use the script but privilege curiosity; stop at 60m max
• Interview Lead focuses on "tell me about a time" and follow-ups; PM reserves one or two clarifying questions
• Note-taker fills a templated note: participant, pain points, behavioral evidence, quotes, opportunity hypotheses, confidence level (1–5)

Debrief (within 48h)

• 30–45 min structured debrief with all participants:
  • Summary (2–3 key observations)
  • Highlight 3 strong quotes
  • Convert each observation to an evidence-backed hypothesis and signal strength
  • Quick mapping: which roadmap items this affects (add/update/kill)
  • Actions: who will validate, what metric to move, and next steps
• Capture in shared repository (Confluence/Notion) using a consistent template and tag by persona, product area, and priority

Ensuring insights influence roadmap

• Weekly research-to-roadmap sync: PM reviews new hypotheses, maps to roadmap backlog, and applies a triage rubric (impact vs. confidence vs. cost)
• Create measurable experiments for high-impact/low-confidence items (prototype, A/B, concierge) with owners and timelines
• Quarterly metrics review: show how validated insights changed KPIs and roadmap decisions to stakeholders
• Celebrate and close the loop: share participant outcomes and product changes with interviewers to reinforce why their work mattered

Worked example: a hypothesis surfaced in one session, "mid-market ops teams abandon our integrations setup because the OAuth step requires IT approval they don't have," scores Impact = 4 (blocks activation for a meaningful segment), Confidence = 3 (a clear pattern in 4 of 6 interviews, not yet quantitatively confirmed), Effort = S (a small onboarding-copy and permissions-flow change would test it). That high-impact, medium-confidence, small-effort combination is exactly the profile that jumps the triage queue.

Example quick templates to hand non-PM leads

• 5-question starter script, note template, debrief agenda, and triage rubric (Impact 1-5, Confidence 1-5, Effort S/M/L)

This playbook balances structure and flexibility so engineers/designers can lead conversations, produce usable evidence, and feed findings directly into prioritization and experiments.

Overview & goal
Test how users with motor impairments (e.g., tremor, limited dexterity, one-handed use) perform fine-touch gestures and identify failure modes to produce concrete design + engineering fixes.

Recruitment & channels

• Criteria: ages 18+, self-reported motor impairment affecting touch, a range of severity (mild/moderate/severe), including assistive-device users, cognitive ability to consent, smartphone familiarity.
• Channels: disability orgs (e.g., United Spinal, Cerebral Palsy alliances), clinics and occupational therapists (OTs, clinicians who work directly with patients on fine-motor and daily-living skills), accessibility mailing lists, social media groups, panels from previous research.
• Target n = 12-20 for qualitative depth across severity strata.

Consent & accommodations

• Plain-language consent; offer large-print + audio read-aloud.
• Pre-screen for fatigue, pain; schedule short sessions (30-45 min) with breaks.
• Pay participants and allow caregiver presence; offer remote or in-person based on preference and mobility.

Task design & alternative interactions

• Tasks: common fine-touch flows (pinch-to-zoom, drag-and-drop, small target tap, swipe with angle precision, multi-finger gestures).
• Scenarios: realistic tasks (selecting a small UI control, repositioning an item, confirming a modal).
• Provide alternative interactions: single-tap alternatives, long-press, voice commands, hardware-button shortcuts, configurable target sizes.
• Counterbalanced order; start with the baseline (current gestures), then alternatives.

Instrumentation & metrics

• Quantitative: success rate, time-on-task, error counts (mis-taps, aborted gestures), touch precision (distance from target centroid), gesture completion rate, number/force of correction attempts, number of retries, unintended activations.
• Sensors/logging: raw touch events with timestamps, pressure/size where available, heatmaps of touch points, accelerometer data if tremor analysis is desired.
• Qualitative: think-aloud, post-task SUS (System Usability Scale, a 10-question survey producing a 0-100 usability score) plus custom accessibility Likert questions, contextual interviews on fatigue and cognitive load.

Analysis & dev-facing recommendations

• Present issues as reproducible bug stories: "When required to perform a 2-finger pinch on targets under 24px, users with tremor failed 78% of the time, with reproduction steps and logs attached."
• Prioritize fixes by severity and impact: quick wins (increase touch target to 44-48px, add single-tap alternatives), medium (gesture fallbacks, adjustable dwell time), longer-term (gesture recognition tolerant to jitter, machine-learning smoothing).
• Provide implementation notes: use platform hit-area APIs, increase touch slop, debounce timing, expose settings (target size, gesture sensitivity), add telemetry events for rollout monitoring.
• Deliverables: annotated session clips, touch heatmaps, metric dashboards, accessibility acceptance criteria, and design tokens for the design system.

Outcome & next steps
Run iterative A/B tests with telemetry, validate improvements with the same cohort, and bake settings into the product's accessibility panel.

I don't compute a single blended weighted score. I check how many of my three sources, interviews, survey, and analytics, independently agree on each specific claim, use that agreement count as the confidence tier, and present the disagreements explicitly to stakeholders alongside a clear recommendation, rather than hiding the uncertainty behind a false-precision number.

Step 1, define the attributes to check: list the specific claims the persona needs (primary motivation, top pain point, typical behavior) rather than trying to triangulate everything at once.

Step 2, gather each source's signal on the same claim: interviews (what fraction of interviewees say it), survey (what fraction of respondents rank it as their top factor), analytics (what fraction of users' behavior is consistent with it).

Step 3, count agreement instead of blending into one weighted score

• High confidence: all three sources point the same direction
• Medium confidence: two of three agree, one is silent or weak
• Low confidence: sources actively conflict, or only one source has any signal at all

Step 4, surface contradictions explicitly, and check for a definition mismatch first: if interviews say "users hate the mobile app" but analytics shows mobile usage holding steady, don't average those away. Dig in first: "hate" in an interview often means one specific friction point, not overall abandonment, so check whether the complaint maps to a single feature rather than the whole app before concluding the sources disagree at all.

Step 5, avoid overgeneralizing from whichever source is loudest: a strongly-worded interview quote or a vivid open-text comment is not automatically the majority view. Always report it alongside how many sources and how large a sample actually support it, not as a standalone claim.

Step 6, present uncertainty in a way that still supports a decision: lead with the recommendation, then show the confidence tier and the evidence behind it, rather than burying the ask under a wall of caveats. For a Medium or Low confidence item that still needs a decision, name the cheapest next check that would raise confidence, and recommend proceeding with that check scheduled, not stalling.

Worked example, convergence: for the claim "primary motivation is saving money, not saving time," 7 of 10 interviewees name cost as their top motivation, 70%; 340 of 500 survey respondents rank cost as their #1 factor, 68%; and of users who converted in the sample period, 61% clicked a "compare pricing" link versus 24% who clicked "save time" copy. All three sources converge around 60-70%, so this is High confidence, worth building the pricing-forward design direction around.

Worked example, a contradiction resolved: 4 of 10 interviewees, 40%, say "I hate the mobile app," but analytics shows average mobile session length held flat over the quarter. Digging into the 4 interview transcripts shows all four are complaining about the same specific step, a slow image upload, not the app broadly. Reframed as "the image upload step is a specific pain point," it's now consistent with steady overall session length, since people still use the app, they just get stuck at one step. The contradiction was a definition mismatch, not a real disagreement, and the recommendation is unchanged either way: fix the image upload step, now with a clearer, evidence-backed reason.

Trade-offs & pitfalls: a single blended weighted score looks more rigorous than it is, since the weights themselves are usually a judgment call dressed up as math; an agreement count is more honest about what you actually know. Chasing every contradiction to full resolution can stall a decision indefinitely, so reserve deep digging for contradictions on high-stakes attributes and note the rest as open questions. And presenting five caveats before the recommendation trains stakeholders to skip straight to the caveats and ignore the ask, so lead with the decision.

Direct answer

With no usable documentation and nobody left who built it, I stop trying to read my way to understanding and start reconstructing behavior empirically: instrument it, watch real inputs and outputs, and make the smallest reversible change first specifically to test whether my mental model is right, rather than trusting a theory I have not checked. I avoid breaking things by treating every early change as a hypothesis test done somewhere safe, not a production edit, until the model has proven itself on several small, low-risk moves.

Structured elaboration

• Read what the system actually does before trusting anything written or remembered about it: logs, real request and response pairs, database contents, since these reflect the system's actual behavior, not someone's outdated description of it.
• Instrument first: add logging or observability around the parts you are least sure about before changing anything, so the next real event teaches you something.
• Reconstruct behavior from inputs and outputs the way you would reverse-engineer a black box: form a hypothesis about what a given input should produce, check it against real examples, and revise.
• Get a safe place to experiment before touching anything live, a copy of the data, a staging environment, or a way to run a change against real traffic without it taking effect, so early wrong hypotheses cost nothing.
• Make the smallest reversible change first, a tiny, easily undone edit that specifically tests one part of your mental model, before attempting the actual fix or improvement requested.
• Recover dependencies and lineage explicitly when nothing describes them; undocumented systems are often more entangled with their neighbors than they appear.
• The point at which larger changes become safe is when the model has correctly predicted several real, non-trivial cases in a row, not simply when you have read enough to feel confident.

Worked example

I inherited a legacy billing-reconciliation service with no documentation and no remaining team member who had built it, expected to make a safe fix within two weeks because it was silently miscounting a category of refunds. I started by reading real inputs and outputs, pulling actual transaction records and comparing them against what the service reported, rather than reading the code top to bottom first. I added logging around the specific refund-handling path, since that was the area least understood and most relevant to the reported problem, and waited for real traffic to pass through it rather than guessing from the code alone. I formed a hypothesis about how the service classified a certain refund type, based on the logs, and tested it against a known historical case with a manually verified correct answer; the hypothesis was wrong on the first try, which pointed to an undocumented currency-rounding step. Before changing anything real, I set up a way to replay real historical transactions against a modified copy of the service in a non-production environment, and confirmed the fix produced the correct classification across a batch of known cases before touching the live path. I made the smallest possible change to production first, and watched it against real traffic for a day before considering the fix complete.

Trade-offs and pitfalls

• Trusting outdated documentation, when some exists but is stale, can be worse than having none, since it actively misleads instead of leaving you appropriately uncertain; verifying against real behavior catches this either way.
• Skipping the safe-environment step to save time, and testing hypotheses directly against production, turns every wrong guess into a live incident instead of a cheap lesson.
• Declaring the system "understood" after one successful fix overstates what is actually known; the honest scope is understanding the specific path that was touched, with the rest genuinely unknown until it is tested the same way.

Direct answer

Each task prompt should state a realistic goal in the participant's own language, never name the feature being tested, and give a defined starting state, so the moderator (or the unmoderated platform) can score success against a known outcome instead of a self-report. Pair every task with a short post-task probe that checks whether the participant understood what the suggestion was doing, not just whether they clicked it, because a high click rate on a "smart" feature nobody understands is a bad outcome, not a good one.

Scenario: a grocery-delivery app's mid-fidelity "smart suggestions" panel, which recommends items to add to the cart based on what's already there (cart has pasta and sauce, so it suggests parmesan and garlic bread).

Task 1 - discoverability

• Prompt: "You're putting together everything for dinner tonight. You've already added pasta and a jar of pasta sauce to your cart. Continue adding whatever else you'd want for that meal."
• Goal: does the participant notice and act on the suggestion panel without being told it exists.
• Expected outcome: success looks like the participant interacting with, or at least mentioning, the suggested items unprompted; failure looks like never looking at the panel and adding items only through search.
• Success criteria: final cart contains at least one suggested item, or the participant explicitly explains why they ignored it.

Task 2 - comprehension

• Prompt: "You just added a bag of coffee to your cart. Look at what else is available and decide whether you want to add anything."
• Goal: whether the participant can explain why an item is being suggested, not just whether they add it. Correctly declining a suggestion is a valid, calibrated response.
• Expected outcome: success is an accurate explanation of the relationship between the suggestion and the cart, regardless of whether they add it; failure looks like confusion about why an unrelated item appeared, or mistaking it for an ad.
• Success criteria: post-task probe response is scored right/wrong against the actual logic, not against whether they clicked.

Task 3 - trust at a high-intent moment

• Prompt: "You've finished your shopping list and you're about to check out. Before you pay, make any last changes you want to your cart."
• Goal: whether the panel resurfaces at checkout without feeling like pressure.
• Expected outcome: success is neutral-to-positive sentiment about the panel at this stage; failure is the participant describing it as an upsell trying to get more money out of them.
• Success criteria: engagement (or considered non-engagement) with the panel, plus the sentiment captured in the debrief probe.

Probes to run alongside the tasks (uncovering mental models, not opinions)

• "What did you think was going to happen when you saw those extra items?"
• "Was there a moment you expected something different to happen than what actually did?"
• "How would you describe, in your own words, what that panel is doing?"

Trade-offs and pitfalls

• Never name the feature in the prompt itself. If the participant already has a nickname for it, that's fine, but don't seed it.
• A prompt like "click the smart suggestion widget and add an item" instructs the exact action and manufactures a 100% success rate; it measures compliance with instructions, not real discoverability.
• Only measuring clicks misses the more diagnostic signal for a "smart" feature: comprehension. A participant can click without understanding, and that's a worse finding than a participant who correctly declines.
• Overspecifying the starting cart risks telegraphing what you want them to notice; underspecifying wastes moderator time restating context. Fix the starting state as a config the moderator (or unmoderated platform) sets up before the session, not something read aloud to the participant.

Direct answer

Convincing a skeptical engineering team works the same way convincing any technical peer does: a working prototype and real measurements under realistic conditions, framed around the team's own operational incentives (on-call burden, SLA risk, meaning the risk of missing the SLA, short for service-level agreement, a committed target for uptime or response time that the team is held to, and cost they're accountable for), and a rollout plan that limits their exposure if the bet turns out wrong.

Structured elaboration

Framework:

1. Find the team's actual objection. It's usually operational risk or migration cost, not disagreement with the idea itself.
2. Build the smallest prototype that produces real evidence under realistic traffic, not a synthetic benchmark.
3. Translate the result into the team's own incentives: fewer pages, lower SLA risk, cost they own, not just "it's faster."
4. Propose a reversible rollout: a feature flag, a canary (a canary release: rolling the change out to a small slice of real traffic first, so any problems show up on a limited group before the change reaches everyone), a defined rollback trigger, so agreeing doesn't feel like a one-way door.

Worked example

Situation. At a company serving a vision model through CPU-based microservices, the on-call rotation was regularly paged during traffic peaks. The infra team was skeptical of a GPU-backed migration, worried about operational complexity and vendor lock-in, having been burned before by a migration that added more toil than it removed.

Stakes. Staying on CPU meant recurring SLA breaches and on-call fatigue, but the infra team's skepticism, left unaddressed, meant the migration simply wouldn't happen regardless of the theoretical performance case.

The influence moves.

• Talked to the on-call engineers directly, not just their manager, and learned the real objection wasn't the GPU idea itself but the memory of a prior migration that shipped without runbooks (a runbook is a written, step-by-step guide for operating or recovering a system, so whoever is on call at 2am has an actual procedure to follow instead of improvising) or a rollback path.
• Built a small prototype on a single GPU node and ran it against a slice of real production traffic over a short pilot window, rather than a synthetic load test, so the team could see behavior under conditions they recognized.
• Framed the result in terms the team owned: fewer pages during peak traffic and a lower likelihood of breaching the SLA they were accountable for, not just raw speed.
• Addressed the vendor lock-in and complexity objection directly: proposed a portable, standard runtime rather than a vendor-specific one, and delivered a runbook and autoscaling policy alongside the code, treating operational readiness as part of the deliverable.
• Proposed a gradual, flagged rollout with a defined rollback trigger tied to error-rate and latency regressions (an automatic rule that watches two production health signals, the percentage of requests failing and how slow responses get, and rolls the change back on its own if either one crosses a set threshold), so the team wasn't betting the whole service on day one.

Resolution. The infra team co-owned the rollout plan and adopted the runbook as their own; the prior migration's bad memory stopped being the default reason to say no.

What a senior candidate does differently. Doesn't lead with performance numbers; leads with the team's actual objection (the operational scar tissue from before), and treats the runbook and rollback plan as part of the pitch itself, not paperwork produced after the team says yes.

Trade-offs and pitfalls

• A synthetic benchmark convinces almost nobody who owns the pager. Realistic, even narrow, production traffic carries far more weight than a bigger but synthetic number.
• Skipping operational-readiness work to "prove the architecture works first" is a common mistake; for the team that has to operate it, the runbook and rollback plan are the pitch.
• A migration that can't be rolled back cheaply reads as a one-way door regardless of technical merit, and skeptical teams correctly resist one-way doors more than they resist new technology.

Direct answer

Build trust before you need anything, by being reliable on small things, transparent about your constraints and capacity, and by giving the other person visibility into your world so they aren't surprised later. Waiting to invest in the relationship until you need a favor makes the ask feel transactional.

Framework

Lead with reliability on small things. Deliver on small, early commitments, answer a question promptly, show up to their planning session, so your word has a track record before there's a high-stakes ask on either side.

Be transparent about constraints. Proactively share capacity, risk, and known limitations rather than letting the other person find out the hard way, mid-project.

Give visibility into your world. Invite them into a review or share a roadmap or dashboard, so they understand your constraints without needing you to explain from scratch every time.

Make it reciprocal early. Ask what they need and what's on their plate too. Trust runs both directions, not just from you demonstrating value to them.

Worked example

Situation: a new product manager joins and will depend on your team, for example a platform or infrastructure team, for their roadmap.
Action: in the first couple of weeks, gave the PM read access to the team's capacity and roadmap view along with a short walkthrough, rather than waiting for them to ask. Proactively flagged one known constraint, a piece of infrastructure that was close to capacity, before it affected their planning. Followed through quickly and visibly on a small early request, answering a scoping question the same day, to establish reliability before anything high-stakes came up.
Result: by the time the PM had a genuinely high-stakes ask, an accelerated timeline, there was already a working relationship and a shared understanding of constraints. The conversation started from what's actually possible given what you already know, instead of starting from zero.

Trade-offs and pitfalls

• Trust-building gestures can look like busywork if they aren't tied to something concrete. Keep them small and genuinely useful, not performative.
• Over-sharing every constraint upfront can read as excuse-making before there's even a request. Calibrate to what's actually relevant to their planning.
• The senior differentiator is doing this proactively, before there's a need, rather than scrambling to build rapport only once you need something from the other person, which reads as transactional.

Protocol to minimize interference

• Pretest and train participants with a short warm-up: calibrate eye-tracker, then practice think-aloud on a neutral task so verbalization becomes natural.
• Use concurrent think-aloud but prompt minimally (neutral probes) and avoid asking for long explanations during critical visual tasks; instead collect brief utterances and follow up with retrospective probing after each task.
• Keep tasks short (3–5 min) and insert short breaks to recalibrate and reduce cognitive load.
• Use a comfortable mic (lavalier) and non-intrusive eye-tracker (desktop or remote) to avoid disrupting gaze.

Data collection & alignment

• Record:
  • Eye-tracking stream (timestamped gaze, fixations, saccades)
  • High-resolution screen capture with timestamps
  • Audio (lapel mic) and time-synced video of participant
  • Event logs (task start/end, stimuli)
• Sync via common clock or sync pulses at start (e.g., clapper event on screen + audio beep). Export all streams with millisecond timestamps and align them in analysis software (e.g., ELAN, Tobii Pro Lab, custom Python).

Analysis approaches

• Quantitative-first: compute metrics per task/area of interest (AOI)—mean fixation duration, fixation count, saccade amplitude, dwell time.
• Qualitative-first: transcribe verbalizations, segment into utterance timestamps, code for cognitive states (e.g., confusion, goal, strategy).
• Multimodal fusion:
  • Time-window mapping: link each utterance to concurrent eye metrics (e.g., 500 ms before/after utterance onset) to infer visual focus during verbal reports.
  • Sequence analysis: identify patterns like “long fixation → verbalized confusion → corrective saccade.”
  • Mixed-methods matrices: rows = tasks/AOIs, columns = metrics + verbal codes to spot convergences/divergences.
• Validation: triangulate with task performance (error rates, completion time) and retrospective probes.
• Deliverables: heatmaps annotated with exemplar quotes, timeline visualizations of gaze+utterances, and prioritized design recommendations grounded in joint evidence.

Why this works: minimizes cognitive load during visual tasks, preserves natural talk, and produces precisely aligned multimodal data so you can link where users looked with what they were thinking.