Senior UX Designer Interview Preparation Guide - Microsoft

Direct answer

I track a mix of leading indicators I can observe soon and lagging outcome indicators that take months, and I treat any single outcome metric with real suspicion, because most of the obvious ones have confounders that have nothing to do with the mentoring itself. If it isn't working, the signal usually shows up in behavior long before it ever shows up in an outcome number.

Leading indicators (fast, but softer)

• The mentee proactively brings a problem before being asked, rather than only responding when prompted.
• They apply a technique from an earlier conversation without being reminded.
• They can articulate their own reasoning, not just repeat a conclusion.
• They start contributing to others, a strong late signal that something has actually been internalized rather than just followed along with.

Lagging indicators, and why they alone are not enough

Promotion, retention, and performance rating movement all matter, but none of them are clean measures of mentoring on their own. Promotion timing is affected by team budget, level-bar changes, and reviewer variance, not just capability growth. Retention is affected by pay, personal circumstances, and the direct manager relationship, often far more than by a mentoring relationship. Treating either as a dashboard number risks giving mentoring false credit when someone would have succeeded anyway, or false blame when the real cause was entirely outside the relationship. That's the reason to pair outcome numbers with direct, harder-to-fake behavioral signals rather than reporting them alone.

Telling it isn't working, and what to do

Signs it's not working: no observable change in independence over a reasonable window, the mentee still routes every decision through you, flat or disengaged body language in 1:1s, or the mentee saying directly that it isn't useful. Once suspected: ask directly rather than only inferring from behavior, check for a format mismatch (wrong cadence, wrong topics, or the mentee not feeling safe raising what's actually going on), adjust before assuming failure, and if the mismatch is genuinely personal rather than fixable, consider a different pairing without treating that as anyone's fault.

Worked example

After several weeks, a mentee was still checking in before making small, reversible decisions that should have been theirs to make. Rather than assuming a skill gap, a direct conversation surfaced that the actual blocker was fear of being wrong, not lack of ability. The adjustment was explicit permission to make a defined class of reversible decisions without approval, plus a standing offer to review the reasoning after the fact rather than before. Over the following sessions, they started making more of those calls on their own and explaining the reasoning unprompted.

Trade-offs and pitfalls

A junior answer to this question is usually a list of KPIs and stops there. A stronger answer explains why the obvious outcome metrics can lie, and pairs them with behavioral signals that are harder to fake. A common pitfall is over-attributing outcome metrics to the mentoring relationship (selection bias: motivated people who get assigned strong mentors were often already on a good trajectory). Another is waiting too long to check in because outcome metrics take a quarter or more to move, by which point a struggling relationship may have already quietly failed.

Direct answer

Before committing to a plan, spend the first days mapping every team your work actually depends on, get an explicit, dated commitment from each one on what they will deliver, and track those commitments in one visible place so a slip surfaces the moment it happens instead of at the deadline.

Structured elaboration

Map the dependency graph early, not incidentally

Run a short cross-functional session at kickoff specifically to list what you need from other teams: what, by when, and in what form. Treat this as a deliverable of the kickoff, not a side conversation that happens if someone remembers to ask.

Get commitments, not assumptions

"They know we need this" is not a commitment. A commitment has an owner, a date, and an explicit acceptance criterion, meaning what "done" looks like from your side, not just theirs. Ambiguous handoffs are where dependencies quietly slip.

Make status visible continuously, not just at standups

A shared dependency tracker, checked weekly at minimum, with a clear ready, at risk, or blocked status per item, turns a hidden slip into a visible one while there is still time to react.

If you are joining an initiative already in motion

The mapping happens differently. Your first days are spent finding out who currently owns each piece, which may not match the org chart or what the original plan assumed, and estimating the time-to-impact for each dependency, meaning how long before a slip there would actually hit your own critical path (the specific chain of dependent tasks whose delay would directly delay your own delivery date, unlike a dependency that has slack to spare), before you commit to a timeline of your own. Committing to a date before doing this is committing to someone else's assumptions.

Worked example

A project depends on three other teams: one providing a new data feed, one exposing an API endpoint, and one delivering a design system component. At kickoff, the team runs a short dependency-mapping session and gets each provider to commit to a specific date and a specific definition of ready, for the API that means a documented contract and a staging environment, not just "the code exists." These commitments go into a shared tracker with a status column, reviewed weekly.

In week two, the API team's status moves to at risk because their own upstream dependency slipped. Because the tracker surfaced this immediately rather than at the original deadline, there is still time to either help unblock the API team or replan the timeline around a slower path, instead of discovering the problem in the final week when no good options remain.

For the joining-in-progress case: an engineer joins a multi-team initiative already underway. In the first few days, instead of accepting the existing plan at face value, they interview each team named in the plan to confirm who currently owns each dependency, since ownership has quietly shifted since the plan was written, and estimate the time-to-impact of each one: the API dependency would only hurt the timeline if it slipped more than two weeks, while the data-feed dependency has almost no buffer at all. Only after that mapping do they commit to a delivery date of their own, rather than inheriting the original plan's assumptions unchecked.

Trade-offs and pitfalls

A heavy dependency-tracking process on a small, low-risk project wastes more time than it saves; scale the rigor to the size and risk of the dependency rather than applying it uniformly everywhere.

The most common failure is treating the mapping as a one-time kickoff exercise instead of a living tracker. A dependency list that is accurate on day one and never updated again is exactly as useless as never having made one, because the whole point is catching drift as it happens.

Direct answer. Task completion and NPS (Net Promoter Score, "how likely are you to recommend this to a friend or colleague") measure different constructs, so their moving in opposite directions is not a data-quality contradiction to resolve by picking a winner. Treat the qualitative "confusion about a core interaction" comments as a diagnostic hypothesis, quantify how much of the NPS drop concentrates in the group that hit that specific confusion, and ship a scoped fix to that interaction rather than either ignoring the NPS drop or rolling back a redesign that measurably helped task completion.

Reconcile by construct, not by picking a winner. Task completion is a narrow behavioral proxy for "can a user get through this one flow." It says nothing about effort, frustration, or the trust a user carries forward into their next visit, which is much closer to what NPS captures. A user can complete a task while disliking the process, so a redesign making one tested task technically easier while making the broader experience feel worse (through friction added elsewhere, an unfamiliar visual language, or the removal of something that acted as a trust signal) is a coherent, not contradictory, outcome.

Treat the qualitative comments as hypotheses, not conclusions. Tag and cluster the "confusion" comments to identify the specific step involved, and count how often it recurs across independent sessions, a pattern repeated by many separate participants is far stronger evidence than one vivid complaint. Cross-reference that step against session-replay or click data (rage clicks, repeated back-navigation, multiple attempts) to see whether behavioral signals corroborate the complaint even though the step still technically counted as "completed."

Additional analyses to run.

• Segment both the +5% completion figure and the NPS reading by whether a participant hit the flagged interaction; if the NPS drop concentrates in that sub-group, you've localized the cause instead of indicting the whole redesign.
• Look at time-on-task and retry/error counts for that specific step, not just pass or fail, since a step can be "completed" only after several confused attempts, friction the binary completion metric hides entirely.
• Check the study's own definition of "completed": a lenient definition (for example, "reached the confirmation page" even after backtracking to correct a mistake) can mask exactly this kind of friction.
• Run a small, targeted moderated follow-up (5 to 8 participants) focused specifically on the flagged interaction to observe it directly, rather than trying to re-derive the cause from the unmoderated task metrics alone.

Immediate product recommendation. Ship a scoped fix to the specific confusing interaction rather than a full rollback, since the underlying task-completion gain looks real and worth keeping. Instrument that one interaction going forward, and treat NPS (or a segment-level satisfaction proxy) as the guardrail that confirms the targeted fix, not the redesign as a whole, is what recovers it.

Illustrative diagnostic example. Suppose tagging finds that 30% of unmoderated sessions mention the confusing interaction. If you then re-cut task completion for just that 30% and it is flat or down, while the other 70% shows the full gain, you've shown the interaction is offsetting an otherwise real improvement for a specific subset, and a targeted fix, not scrapping the redesign, is the right call. (This split is illustrative to show the diagnostic method; the actual proportions would come from tagging the real session transcripts.)

Trade-offs and pitfalls. Don't resolve the conflict by averaging the two metrics or by picking whichever one supports a pre-existing opinion about the redesign. A single loud comment is not evidence on its own, tally frequency across independent sessions before acting on it. Don't treat "+5% improvement" as statistically solid without checking its own confidence interval, especially in a modest unmoderated sample, note this caveat rather than asserting the lift is real without having seen the interval. Finally, check that the qualitative and quantitative samples are actually drawn from comparable populations (a moderated recruit panel and an unmoderated panel can skew differently) before treating their signals as directly comparable.

Direct answer

Timebox roughly six to eight total hours of prep across the two days, front-loading breadth (company, product, team) on day one and narrowing to role-specific depth and a same-day source check on day two, then walk in with three concrete deliverables: a one-page brief, a short ranked list of open questions, and one specific, current observation you can offer unprompted.

Structured elaboration

A sample timeboxed plan:

• Hours 1-2 (Day 1): company fundamentals, product, business model, recent news or funding, from the company site plus one or two independent articles.
• Hours 3-4 (Day 1): team and role specifics, a deep read of the job posting, LinkedIn for the hiring manager and current team members, the engineering or product blog if one exists.
• Hours 5-6 (Day 2): operational signals, public GitHub, app store or review sites, a status page, anything hinting at pain points.
• Hour 7 (Day 2, morning of): a live-source check, since something can change in the last 48 hours (a launch, an outage, a leadership change), and citing something that already changed is worse than not mentioning it at all.
• Hour 8: synthesis, actually writing the one-pager and the ranked question list.

Deliverables: a one-page brief (mission, likely composition, top challenges), three to five ranked open questions you'd actually ask, and one specific, current observation that proves the research is fresh rather than generic.

Worked example

Interviewing Wednesday for a Data Engineer role. Monday evening: two hours on the company site plus an article about a recent funding round. Tuesday lunch: two hours on the job posting, which repeatedly mentions "streaming pipelines," plus the hiring manager's LinkedIn, which shows a recent post about migrating off a legacy extract-transform-load (ETL, the process of pulling data from a source, transforming it, and loading it into a destination system) tool. Tuesday evening: two hours on their public GitHub, a data-quality library with recent active commits, and review sites, where a recurring theme is "great team, tooling is dated." Wednesday morning: a quick check for anything new (nothing has changed) plus writing the brief. You walk in with the brief, a ranked question list (the streaming migration's timeline first, current data-quality monitoring second), and a specific observation: noticing a recent commit adding schema validation to that data-quality library, and asking whether it's related to the ETL migration.

Trade-offs and pitfalls

The most common failure is spending all the time on breadth and none on synthesis, ending up with a lot of facts and no point of view, so timebox the synthesis step explicitly rather than letting it get crowded out. Don't manufacture a specific observation to sound prepared if you genuinely didn't find one, admitting you focused your limited time elsewhere is stronger than a vague, generic comment.

Direct answer

Treat this like any investment decision: put a number, even a rough, clearly labeled estimate, on the upside, a number on the cost and risk, bring both to the SAME unit so they can actually be subtracted, and don't move forward without an explicit rollback plan and a monitoring window, since a change that adds latency during rollout needs a way to back out fast if the trade-off turns out worse than modeled.

Structured elaboration

Cost-benefit analysis

• Benefit side: fewer clicks in a key flow typically shows up as a small but real conversion or completion-rate lift. Frame it as a range, for example "we'd estimate roughly a 2 to 5 percent lift based on similar past click-reduction changes," and label it clearly as an estimate rather than a fact. Then convert it: a percentage lift is not a decision input until it has been multiplied through the flow's actual volume and the value of one conversion.
• Cost side: the engineering effort, a rough sprint or hours estimate, and the performance cost itself, about 200 milliseconds of added page-load time during rollout, a delay that has generally been shown to measurably hurt conversion on latency-sensitive flows, so it's a real cost, not a footnote. Convert the effort to money the same way, engineer-weeks times a fully-loaded weekly rate, and convert the latency to money by treating it as a conversion drag on the same baseline the benefit uses.
• Net view: subtract, don't gesture. State the recurring net benefit per period, the one-time cost, the resulting payback period, and, most usefully, the BREAK-EVEN lift, the smallest benefit that would still make the change worth building. The break-even number is what protects the decision from being hostage to a point estimate everyone knows is soft: if the break-even lift is far below the low end of your range, the decision is robust even if you are badly wrong.

This same shape recurs with other option pairs
The same benefit-versus-cost structure applies whenever a design choice trades a faster, simpler path against a richer, slower one. Choosing between two onboarding flows, one that gets users to their first useful result faster but is less distinctive to the brand, versus one that's more delightful but takes more steps, is the identical trade-off in a different unit: time-to-first-value against brand differentiation instead of clicks against latency. Deciding whether to keep a slower, more delightful onboarding animation against a push to cut time-to-first-action is the same shape again: a quantifiable speed cost against a real but harder-to-quantify experience benefit. In each version, the fix is the same: put a number on both sides, bring them to a common unit, run the change on a limited slice first, and let a measured outcome, not intuition about delight, settle it.

Stakeholder presentation outline

1. The ask, in one line: approve a staged rollout of the click-reduction change.
2. The problem and opportunity: current click count, hypothesis for why fewer clicks helps.
3. What's changing: a simple before-and-after of the flow.
4. Estimated benefit range, labeled as an estimate, with the reasoning behind it, converted to money.
5. Performance trade-off: the roughly 200 millisecond cost, who it affects, why it happens, backend work added to the request path, and what it is worth in the same money unit as the benefit.
6. The net: benefit minus costs, payback period, and the break-even lift.
7. Rollback plan: how to revert, for example a feature flag (a toggle that turns a feature on for some users and can switch it off instantly), and the specific conditions that trigger it.
8. Monitoring plan: what you'll watch, conversion on the flow, page-load time, error rate, and for how long.
9. The decision ask: approve a limited rollout under these guardrails.

Worked example

A checkout flow drops from 4 clicks to 2 by moving a step to the backend, adding an estimated 200 milliseconds to page load during the rollout window.

Benefit, stated with every input visible and labeled an estimate, not a measurement. The flow sees about 80,000 sessions a quarter and completes at 55 percent, so 44,000 completed orders. An estimated 3 percent relative conversion lift, based on the size of past click-reduction changes on this flow, means 45,320 orders, that is 1,320 more orders a quarter, or +1.65 percentage points of completion. At a $45 average order value that is about $59,400 a quarter, roughly $237,600 a year.

Costs, brought to the same unit. Engineering is roughly two engineering sprints, two two-week sprints for a team of three, about 12 engineer-weeks; at an illustrative fully-loaded rate of $4,000 per engineer-week that is about $48,000, one-time. The latency is a recurring drag, not a footnote: if the added 200 milliseconds costs even 0.5 percent relative conversion on this flow, an illustrative figure the canary is there to replace with a measured one, that is 220 orders a quarter, about $9,900 a quarter.

The net. $59,400 minus $9,900 is about $49,500 a quarter of net benefit, roughly $3,800 a week, against a $48,000 one-time build, so the change pays for itself in about 13 weeks if the estimate holds. Break-even: the build cost is covered inside the first year as long as the true lift is at least about 0.6 percent relative, well under the bottom of the 2 to 5 percent range, which is the real argument for approving it. Every number in that chain is an estimate built on a stated input, and the deck says so on every slide it appears.

Rollback: a feature flag that reverts the flow within minutes if triggered, with the trigger set at "conversion on the new flow drops more than 1 percentage point below the old flow's 55 percent baseline, or page-load time exceeds an agreed ceiling, sustained for more than 2 hours." Monitoring: a canary rollout (releasing to a small slice of traffic first to catch problems before a full launch) starting at 5 percent of traffic, checked daily for the first week, with conversion rate, load time, and error rate as the three watched numbers before expanding further.

Trade-offs and pitfalls

• Presenting the estimated benefit as if it were measured fact is the most common failure mode here. Label an estimate as an estimate every time it appears, including in slide titles.
• Stopping at "a 3 percent lift versus two sprints" is the second most common failure: a percentage and a sprint count cannot be subtracted, so a comparison stated that way is not a cost-benefit analysis, it is two facts sitting next to each other. Convert both sides to money before you ask anyone to decide.
• A rollback plan that isn't decided and shared before launch isn't really a rollback plan, it's a plan to argue about rolling back once something looks bad.
• Don't treat the 200 millisecond cost as automatically disqualifying. Whether it matters depends on how latency-sensitive that specific flow is, which is exactly what the canary rollout is there to find out cheaply, and the canary's measured drag should replace the illustrative 0.5 percent in the model as soon as it exists.

Direct answer

Treat this as a structured build, not a straight redraw: set up the file's page skeleton first, extract every repeated pattern, the progress bar, the card lists, the CTA (call-to-action, the primary button prompting the user's next step) variations, into reusable components and variants before building any of the six actual screens, assemble the screens from those pieces, wire a prototype for testing, and document naming and versioning so collaborators can follow the work as it evolves.

Structured elaboration

Pages to create: "00 Cover" (a brief describing the flow and its status), "01 Wireframe reference" (the hand-drawn sketches brought in for traceability, so reviewers can compare final screens back against the original intent), "02 Components" (extracted reusable pieces), "03 Onboarding flow" (the six final screens in sequence), "04 Prototype" (a copy wired for testing, kept separate so click-through hotspots don't clutter the production screens), "05 Archive."

Identifying and extracting reusable components: read through all six steps before building any of them and list what recurs. In this flow that's the progress bar (present on all six, with a different step highlighted each time), the card lists (recurring wherever the flow presents selectable options), and the CTA variations (a primary "Continue" versus a secondary "Skip" versus a disabled state before a required field is filled). Each becomes one real component with variant properties instead of six independently drawn copies: a progress-bar component with a step property (1 through 6), a card component with a selected/unselected property, and a CTA button with state (default, disabled) and type (primary, secondary) properties.

Auto Layout decisions: the progress bar itself is built with Auto Layout (Figma's layout system where a frame automatically resizes, spaces, and aligns its children as content changes, instead of every element being positioned by hand) so its segments space evenly regardless of step count; each card in a list is its own Auto Layout frame so its height adapts to variable text length instead of clipping; the CTA area at the bottom of each screen uses Auto Layout with alignment set to pin the button to the bottom edge consistently across all six screens, even when the content above it varies in length.

Assembling the six screens: each screen frame pulls the shared components as instances (the progress bar set to that step's value, whichever card or CTA state matches that step), so a later change to a base component, tightening the CTA button's corner radius, for example, propagates to all six screens automatically instead of requiring six manual edits.

Prototype plan for testing: wire the six frames in sequence, a "Continue" hotspot advancing forward and a "Back" or "Skip" path where relevant, and include the states that matter for the study, such as an error state if a step requires a note about a missing field. Keep the prototype in its own page or file copy so temporary interactions added just for the test session don't end up shipping. Plan the test around a small number of specific tasks (complete onboarding as a first-time user, back out and resume from a middle step) rather than open-ended exploration, so results are comparable across participants.

Naming and versioning: name the six screens by step and purpose ("01 Welcome," "02 Permissions," through "06 Confirmation") rather than by number alone; name components using a component/property/value convention (progress-bar/step, card/selected, cta/primary/disabled); version the flow with a named save point right before a testing round ("v1 for usability test, [date]"), so the exact version participants actually saw can always be recovered even after the working file has moved on.

Worked example

Steps 1 and 3 both use the card component to present two choices with different copy; because the card is a real component with a variant property rather than a redrawn shape each time, updating its corner radius once on the base component updates it everywhere it's used across all six screens. The progress-bar instance on step 3 is the same base component as step 1, with only its step property changed from 1 to 3, so its Auto Layout spacing never has to be manually recreated. In the prototype, step 1's primary CTA links to step 2, a back arrow links backward, and a disabled-state CTA on a later step becomes enabled only once the participant fills a required field, letting the moderator actually observe whether people notice why the button isn't responding.

Trade-offs and pitfalls

Redrawing each of the six screens by eye before extracting the shared pieces feels faster on day one, since the wireframes already show what each screen looks like, but it creates six independently diverging copies of the same progress bar and card, meaning any later change needs six edits instead of one; extract first even though it feels slower. Letting states or hotspots added only for the usability test creep into the production onboarding-flow page blurs the split between disposable testing artifacts and shippable work, so keep that boundary explicit. Skipping the versioned save point before a test round means an in-flight edit can silently change what a participant actually saw, undermining any attempt to explain a confusing result afterward.

Direct answer. When stakeholders prioritize speed or visual polish over accessibility, the most effective move is reframing the conversation around a specific, scoped trade-off rather than an abstract "we should care about accessibility" appeal, proposing a minimal viable accessibility improvement that fits the existing timeline instead of demanding the full fix immediately.

Framing the trade-off. State the specific, concrete cost of not addressing it ("this custom dropdown will be completely unusable for anyone navigating by keyboard alone or with a screen reader, a mainstream assistive-technology workflow, not a rare edge case") rather than a general values statement; pair it with a specific, bounded ask, since a stakeholder under time pressure responds better to "can we ship the native <select> now and revisit the custom design after launch" than to "we need to fix all of this before we ship."

Stakeholders to consult and measurable criteria. Loop in whoever owns the launch timeline (to find genuinely available slack) and whoever owns technical risk (to confirm the minimal fix is actually low-cost); measurable criteria might be a specific WCAG success criterion the current approach fails, or a quick keyboard-only test recording that makes the problem concrete and undeniable rather than abstract.

A worked example. A checkout flow launching in one week has a custom-styled radio-button group with no visible focus indicator. The minimal viable fix (adding :focus-visible styles, roughly an hour of work) ships in the current timeline; the larger accessibility pass on the whole checkout flow's information architecture gets scoped as a fast-follow ticket with an owner and a target sprint, not left as an unowned "someday" item that never gets picked up.

Trade-offs and pitfalls. Insisting on the complete fix when the team is genuinely timeline-constrained often results in accessibility being cut entirely rather than partially addressed, since an all-or-nothing ask gives a time-pressured stakeholder only two choices, ship broken or slip the deadline, and slipping the deadline usually loses; a scoped minimal-viable-fix ask that still meaningfully reduces harm, with the larger fix genuinely scheduled rather than vaguely deferred, gets more real accessibility improvement shipped over time than a rejected all-or-nothing demand.

Before running any activity, find out why half the teams haven't adopted, a technical gap (a needed variant doesn't exist), an awareness gap (they don't know the system covers their case), or a trust gap (past releases were slow or buggy), because the right evangelism plan differs by cause. The plan itself has two layers: an org-wide campaign to drive the initial push, and a steady-state onboarding and maintenance ritual so adoption doesn't regress once the push ends.

Diagnose first

A short audit across the non-adopting teams: sample their screens against the system's components, and a quick survey (or a handful of 1:1s) asking directly what's blocking them. This turns "half the teams haven't adopted" from one problem into a small number of concrete blockers to address.

Org-wide campaign activities

• Roadshow demos: short, recorded walkthroughs per squad showing real components and tokens relevant to their product, not a generic system overview.
• Champion program: 1 to 2 reps per non-adopting team, given early access to upcoming changes, a dedicated channel, and quarterly syncs; champions are the on-the-ground advocate who make the system's case in their own team's standups.
• Structured onboarding curriculum: a defined 90-day milestone structure rather than a one-off workshop, for example: weeks 1 to 2 audit the team's current UI against the system, weeks 3 to 6 migrate the team's top three screens, weeks 7 to 12 reach full fluency and contribute one pattern back upstream.
• Individual onboarding: for a single new designer/engineer pair joining a team, a concrete 30-day plan (week 1: read docs, build one component from the library into a real screen; week 2 to 3: pair with a champion on a migration; week 4: contribute a small doc fix or pattern back), with short weekly check-ins.

PM-specific lever: tie adoption to the roadmap

Adoption stalls when design-system work is always deprioritized against feature work. The fix a PM can drive is making adoption a scheduled part of the roadmap, not a favor: a phased rollout plan with adoption gates tied to release milestones (for example, "screen X ships only once it's built on system components") turns adoption from optional cleanup into a release requirement.

Upstream-contribution lever

To stop teams silently forking product-specific variants instead of contributing back, make contributing back genuinely easier than forking: a lightweight RFC template, a fast review SLA (target under one week for a small variant proposal), and visible credit for merged contributions in release notes.

Sustaining adoption after the push

A weekly design-engineering sync, a token/version sync cadence so consuming teams aren't surprised by drift, and a component sign-off review gate before a new pattern ships, keep the system healthy after the initial campaign ends; without an ongoing ritual, adoption regresses back toward zero as the campaign's energy fades.

Handling a resistant, high-impact team

Listen first: find the actual blocker (a missing variant, a performance concern, a release-timeline conflict) rather than assuming it's simple resistance. Propose a small, time-boxed pilot on one screen to de-risk the ask. Negotiate a compromise where possible (they keep one custom variant but agree to consume shared tokens, so at minimum visual consistency holds even if component reuse doesn't). Escalate to a sponsor only if the team's fork creates real brand or accessibility risk, not simply because they said no once.

Worked example: setting a measurable target

If the audit finds 5 of 10 product teams are on the system today (the "half" in the prompt, $5/10 = 0.5$), a realistic two-quarter target from a champion-led rollout would be 8 of 10 teams ($8/10 = 0.8$), tracked by the KPI "% of UI surface built from system components" per team, not by roadshow attendance, which measures interest, not adoption.

Trade-offs and pitfalls

Chasing engagement metrics like roadshow attendance or Slack channel size instead of usage metrics (component adoption in shipped code, migration completion rate) makes a stalled campaign look successful right up until someone checks the actual UI. Mandating adoption top-down without first fixing the real blocker just pushes teams toward quieter forking instead of open resistance, which is harder to detect and fix later. And a champion program with no real incentive (early access, credit, a say in the roadmap) fizzles after the initial enthusiasm, so the steady-state ritual matters as much as the launch campaign.

Situation: Executive homepage has limited real estate; we need a repeatable, quantitative way to rank KPIs so the highest-value metrics appear first.

Model overview:

1. Inputs (per KPI):

• Business Impact (BI): expected strategic value (0–100), derived from stakeholder scoring or mapped to revenue/cost impact.
• Volatility (V): recent variability (e.g., rolling std dev relative to mean).
• Frequency-of-Use (F): how often execs click/view the KPI (events per week).
• Novelty (N): recency of change or newness (binary/newness score or magnitude of recent change).

2. Normalization:

• Apply min-max normalization to each factor to map to 0–1:
  norm_x = (x - min_x) / (max_x - min_x). If distribution has outliers, clamp percentiles (5th–95th) before scaling.

3. Weighting (example weights; adjust by stakeholder consensus):

• w_BI = 0.45
• w_F = 0.25
• w_V = 0.15
• w_N = 0.15
  Weights sum to 1. Emphasize impact and use for execs.

4. Combined score:
   Score = w_BI * norm_BI + w_F * norm_F + w_V * norm_V + w_N * norm_N

5. Tie-breakers / business rules:

• If KPI has missing/low-quality data, apply a data-quality penalty (multiply score by 0.8).
• For very volatile but low-impact KPIs, require BI > threshold (e.g., 0.3) to appear.
• To surface emergent issues, optionally add urgency boost = alpha * norm_V * norm_N (alpha small, e.g., 0.05).

Example (assuming Frequency-of-Use ranges 0 to 100 views per week, so F=50 normalizes to 0.5, and Volatility and Novelty are already expressed on a 0 to 1 scale, so their normalized value equals their raw value):
Suppose KPI A: BI=80 (norm 0.8), F=50 views/wk (norm 0.5), V=0.4 (norm 0.4), N=0.2 (norm 0.2).
Score = 0.450.8 + 0.250.5 + 0.150.4 + 0.150.2 = 0.36+0.125+0.06+0.03 = 0.575

Implementation notes:

• Compute norms and scores daily; store history to analyze changes.
• Expose weights as configurable parameters and validate via A/B tests with execs.
• Visualize top N by score and allow manual pinning (override) with audit logging.

This model is simple, transparent, tunable, and aligns KPI placement with strategic value, usage, and emergent signals.

Guerrilla usability test

• Timeline: 1 day (2–4 hours field sessions + same-day synthesis)
• Sample: 5–10 participants (convenience sampling in public)
• Typical insights: Major usability blockers, task flow breakdowns, quick validation of navigation labels or CTA clarity
• Limitations: Non-representative sample, limited context for complex tasks, shallow demographics — avoid definitive product decisions without follow-up

Remote unmoderated test

• Timeline: 2–3 days to set up and collect results (short tasks 10–20 mins)
• Sample: 20–50 participants (targeted via panel for basic segmentation)
• Typical insights: Quantitative task completion rates, time-on-task, screen recordings for common friction points, preference between variants
• Limitations: No probing for "why", possible task misunderstanding, quality control needed (attention checks)

Intercept interviews (in-app or contextual)

• Timeline: 1–3 days (rapid recruitment + 15–30 min sessions)
• Sample: 8–15 users (targeted by behavior or page)
• Typical insights: Motivation, immediate context for behavior, quick hypotheses about churn or confusion triggers
• Limitations: Short sessions can be surface-level, potential self-selection bias, limited longitudinal view

How I choose: match technique to question—use guerrilla for early concept checks, unmoderated for scalable task metrics, intercepts for contextual motivations. Combine methods where feasible to offset limitations.