Microsoft Entry-Level UX Designer Interview Preparation Guide

Wide (breadth) vs deep (depth) navigation trade-offs for a BI portal:

Overview:

• Wide (many top-level categories): exposes more options up-front, reduces click depth, good when users have varied, known tasks. Costs: cognitive load, crowded header/menus, harder to scan if too many items.
• Deep (nested menus): groups related items, supports discoverability through hierarchy and context, good for complex domain models. Costs: longer click paths, risk of users getting lost or forgetting location.

Heuristics for choosing:

• Prefer breadth when:
  • Primary users are power users who know names of dashboards/reports.
  • You have ≤10 high-level use cases (e.g., Finance, Sales, Ops).
  • Quick access and keyboard shortcuts matter.
• Prefer depth when:
  • Content is large (>50 items) and naturally hierarchical (regions → products → metrics).
  • You need to enforce mental models or governance (e.g., by business unit or data domain).
  • You want to surface contextual relationships between assets.

Mitigations: search, breadcrumbs, shortcuts

• Search: primary discovery tool for BI. Support fuzzy matching, tags, synonyms, recent/owned filters, and preview snippets. Make search omnipresent (global bar) to compensate for depth.
• Breadcrumbs: show full path for context in deep hierarchies so users orient and can backtrack; make each crumb clickable to jump up levels.
• Shortcuts / favorites: allow pinning, “recently viewed,” and role-based quick links to flatten common paths; expose keyboard shortcuts for power users.

Example: a company with diverse lines of business should use 6–8 top-level categories (breadth) plus a robust global search and per-user favorites. A single-product analytics team can use deeper nested menus to organize detailed metrics, with breadcrumbs and shortcuts to reduce friction.

Principle: balance scanability and structure. Use analytics (click paths, search terms) to iterate navigation.

A badly worded checkout question is "Didn't you find the new one-click checkout really easy to use?", it tells the participant which answer you want before they've said anything. A well-worded version is "Tell me about the last time you checked out on our site. Walk me through what happened, step by step." The difference is that the good version asks about a specific, remembered, past experience in neutral language and leaves room to hear something you didn't expect; the bad version signals the desired answer and makes disagreeing feel awkward.

That single failure (leading language) is one of several distinct ways a question can quietly go wrong. A few more, each with its own checkout example:

Why open phrasing dominates early on
Early in a study, you don't yet know what the real problems or mental models are, so an open question ("what happened, what were you thinking") can surface something you never would have thought to ask about directly. Closed questions are for later, once you already know what you're checking and just need a specific, quantifiable confirmation ("did the confirmation screen appear, yes or no").

Trade-offs and pitfalls
Every one of these problems can read as perfectly reasonable on a first pass, a double-barrelled question often just sounds like an efficient one, and a future-intent question often sounds like the most direct way to get the answer you actually care about. The cost shows up later, when the data can't tell you which of two things a participant meant, or when a stated future intent doesn't match what people actually do, and by then the session is over and the question can't be re-asked.

Direct answer

Structure it as an evidence led case, not a request for a favor. Open by naming the specific ask, promotion, a stretch assignment, or dedicated time and budget, back it with three or four concrete instances of impact and readiness, and pre-empt the most likely objection with a fallback. The conversation should feel like two people already broadly aligned on the goal, working out timeline and specifics, not a persuasion contest.

Structured elaboration

Open with the ask itself. Name what you want as your first sentence, not your last. Ambiguity in the open lets the conversation get steered before you've made your case.

Bring evidence, not adjectives. Two to four concrete instances where you already operated at the level you're asking for, a project led beyond formal scope, a decision others now rely on, a skill built and applied. Evidence should be specific enough that your manager could describe it to their manager without you in the room.

Anticipate the likely objections. There's no open role at that level, the timing is wrong for budget, you need more evidence in one area. A prepared response isn't a rebuttal, it's a next step, what would close the gap and by when.

Bring a fallback. If the primary ask can't be granted in full, have a smaller alternative ready, an interim scope change, a defined stretch project with a review date, or a partial commitment such as title now and a compensation review next quarter. Arriving with only one possible outcome makes it binary and easy to defer.

Close with a mechanism. Propose a specific follow up date and what would need to be true by then for the answer to change.

Worked example

"I asked for time on my manager's calendar and opened directly, saying I wanted to talk about taking the stretch assignment leading the migration project and what that meant for my scope going forward. I brought three examples where I'd already operated at that level informally, a cross team escalation I'd resolved without waiting for my manager, a proposal the team had adopted, and feedback from a peer who said they now came to me first on a certain class of problem. My manager's first response was that the team couldn't spare me from current work. I'd anticipated that and offered a fallback, take the assignment for the first phase only with a defined handoff point, so my current responsibilities weren't left uncovered. We agreed to that scope, with a check in scheduled for the midpoint to decide whether to extend it."

Trade-offs & pitfalls

• Leading with feelings instead of evidence invites the manager to respond to the emotion rather than the case.
• Bringing only one possible outcome, with no fallback, turns the conversation into a yes or no vote you can lose outright.
• Overloading the evidence list dilutes it. Two or three strong, specific instances beat six vague ones.
• Skipping the close is the most common gap. A conversation that ends without an agreed next step tends to quietly disappear from both people's priorities.

Direct answer. Alt text should describe the function or informational content an image conveys, not its visual appearance for its own sake, and the right choice depends entirely on the image's purpose: informative images need a text equivalent of the information, decorative images need an empty alt="" so screen readers skip them silently, and information-dense images need a short alt plus a separate longer description.

The three images.

1. Product photo showing features: alt="Wireless mouse, top view, showing the two side buttons and scroll wheel". Describe what's relevant to a shopper who can't see the photo, not generic filler like "image of a product."
2. Decorative background pattern: alt="" (empty, not omitted). An empty alt attribute tells assistive technology to skip the element entirely; omitting the attribute altogether can cause some screen readers to read the filename instead, which is worse than silence.
3. Infographic chart of monthly sales: a short alt naming the chart type and topic (alt="Bar chart of monthly sales, January through June") is not enough on its own; a chart needs a longer description exposed via aria-describedby pointing at an adjacent text block or data table that states the actual trend and values, since the short alt can't carry the analytical content a sighted user gets by looking at the whole chart.

Trade-offs and pitfalls. A common mistake is writing alt text as "image of..." or "picture of...", which is redundant since screen readers already announce that an image is present; the wasted words push the actually useful content further into the announcement. Another common mistake is treating every image with any visual complexity as automatically needing alt="", when the real test is informational value to the user, not visual complexity: a complex decorative pattern is still alt="", and a simple chart with real data is still informative and needs a real description.

Direct answer

Feedback that changes scope or timeline is a decision point, not just bad news to deliver. I confirm the feedback is real and understand its root cause, quantify what it actually costs in effort and calendar time, bring stakeholders a small set of concrete options rather than a single fait accompli, update the sprint plan to match whatever gets chosen, and run a short retrospective to reduce the odds the same category of surprise happens again.

Structured elaboration

A scope or timeline change triggered by feedback usually moves through four steps:

1. Quantify the impact. Translate the feedback into a concrete delta: how many additional days or story points, which specific tickets are affected, and which milestone or launch date is now at risk. A vague "this will take longer" is not useful to stakeholders; a specific delta is.
2. Communicate early, with options, not just a status update. Bring stakeholders a short menu, typically something like cut a piece of scope, move the date, or add capacity, each with its own trade-off, and a recommendation with reasoning. Surfacing this as soon as the impact is known, rather than waiting until close to the original deadline, is what preserves trust even when the news itself is unwelcome.
3. Update the sprint plan concretely. Re-estimate the remaining tickets, resequence the backlog to reflect the decision that was made, and make sure everyone working on the feature (not just the people in the stakeholder conversation) sees the updated plan.
4. Run a retrospective and change the process, not just the plan. Ask what category of thing was missed or underestimated, and add a check earlier in the process (a review gate, a checklist item, an earlier stakeholder sign-off) so that category of surprise is more likely to surface before the sprint plan is locked in next time.

Worked example

Partway through building a feature, a compliance review flagged that one of the data fields we planned to collect needed explicit consent handling that had not been scoped. I estimated the additional work as roughly a few extra engineering days spread across two engineers, mainly for the new consent flow and its tests. Rather than simply announcing a delay, I brought product and engineering leadership three options: cut a secondary, non-essential control from the initial release and ship it as a fast follow, push the launch date by the estimated delta, or bring in short-term help to parallelize the consent work with the rest of the feature. I recommended cutting the secondary control, since it was not legally required for launch and could ship a couple of weeks later without much cost. Once that was agreed, I moved the secondary control's ticket to the next sprint's backlog, resequenced the remaining tickets, and updated the sprint board so the whole team saw the same plan. In the retrospective, we identified that compliance had historically been consulted only once a feature was mostly built; the process change was moving that review earlier, into the design-review stage, so this category of surprise is now far more likely to surface before a sprint plan is committed to.

Trade-offs and pitfalls

Quantifying impact precisely is genuinely hard early in a change, so the pitfall is presenting a single overconfident number instead of a defensible range with the assumptions behind it stated. Delaying the stakeholder conversation to "protect" the team from bad news, hoping the schedule can somehow be recovered, tends to backfire: stakeholders trust a team that flags risk early far more than one that surprises them close to the deadline, even when the underlying news is the same. Cutting scope silently, without stakeholder buy-in, avoids an uncomfortable conversation but usually resurfaces as a trust problem later when the missing scope is noticed. Finally, a retrospective that only produces a plan for this one feature, without a durable process change, tends to let the same category of surprise recur on the next feature.

Direct answer
Opinionated, constrained systems trade flexibility for consistency, speed, and lower cognitive load; flexible, primitive-based systems trade some consistency for the ability to handle edge cases the system's author never anticipated. The senior move is not to pick one system-wide, but to default opinionated for the common path and provide a small number of well-governed, opt-in escape hatches for the long tail, rather than making the whole system either rigid or wide open.

Structured elaboration

Decision criteria

Guardrails

• The token layer (color, spacing, type scale) stays immutable outside an RFC. Tokens are the highest-leverage place for consistency, so they get the least flexibility, not the most.
• A two-tier component catalog: a small "core" tier that is opinionated by default, and a clearly labeled "extension" or "primitive" tier that trades guardrails for control.
• Automated enforcement: a design-token lint step in CI that flags hardcoded colors/spacing outside the token set, and a deprecation lint that flags usage of primitives that have graduated into a core pattern.

Review workflows

• New-pattern proposals go through a lightweight RFC: problem, why the existing opinionated component doesn't cover it, proposed primitive-level solution, and an explicit review from design + engineering + accessibility.
• A quarterly triage reviews everything built on primitives/escape hatches and either promotes recurring patterns into the core opinionated set or flags them for removal.

Technical pattern: opt-in composition
The default import of a component stays opinionated (fixed variants, no arbitrary style props). An explicit, differently-named import exposes the unstyled primitive for the rare case that needs it, so reaching for flexibility is a visible, deliberate choice rather than an accident:

// Opinionated default: limited, documented variants only
import { Button } from "@ds/button";
<Button variant="primary">Save</Button>

// Opt-in escape hatch: same behavior/a11y wiring, no style opinions
import { ButtonPrimitive } from "@ds/button/primitive";
<ButtonPrimitive className={campaignSpecificStyles}>Save</ButtonPrimitive>

Both share the same underlying keyboard/focus/ARIA logic (via a shared hook), so the flexible path never loses accessibility correctness, only visual opinion.

Worked example
A marketing team asks for a hero CTA button with a custom gradient and shape for a single campaign landing page. Applying the criteria: frequency is one-off (low), the surface is isolated to one campaign page rather than shared product chrome (low consistency stakes), and there's real time pressure. Conclusion: use the opt-in ButtonPrimitive escape hatch rather than modifying the core Button, tag the usage as an exception (see the exception-workflow pattern for governance), and don't touch the token layer. If three more teams request the same gradient treatment within the following quarter, that recurrence is the signal to promote it into a documented Button variant instead of leaving four independent one-offs in the wild.

Trade-offs & pitfalls
Too many guardrails without an escape hatch pushes teams into shadow systems: arbitrary inline styles that bypass the design system entirely, which is worse than a governed exception. Too few guardrails, especially at the token layer, causes visible drift and accessibility regressions that are expensive to unwind once dozens of products depend on them. The most common wrong turn is treating "flexible" as "unreviewed": an exception without an owner, an expiry, and a promotion/removal decision doesn't stay an exception, it quietly becomes permanent technical and design debt.

Direct answer

An artifact gets acknowledged when it only informs; it gets acted on when it embeds a specific, timed decision the reader cannot avoid making. I pick the format based on two things: how much attention the audience has in that moment, and whether I need a decision now or buy-in over time, and I lean on synthesis-native artifacts (short clips, one-page briefs, live workshops, and a searchable insight log) rather than a long report as the default.

Formats and when each fits

• Short highlight clips (20 to 60 seconds): for a moment with very little attention, like a standup or a Slack thread, where seeing a real user struggle for 30 seconds lands harder and faster than a paragraph describing the same struggle.
• One-page insight brief: for a moment where someone needs to make a scoped decision, for example approving a sprint of work; it forces me to state one ask, not ten observations.
• Live synthesis workshop: for a moment where I need the team to reach the insight themselves, not just receive it from me, for example when a finding contradicts an existing roadmap bet and buy-in matters more than speed. Walking design and engineering through the same raw quotes and having them cluster the patterns produces ownership that a slide never does.
• Tagged insight repository entry (a searchable, tool-based log of findings, evidence, and status): for a moment that is not urgent at all, when I want the finding to still be findable in six months when someone is scoping a related feature.

Choosing the format (worked example)

A finding that 6 of 8 usability participants missed a critical action button because it was below the fold needs a decision this sprint. I would not write a report; I would send a 30-second clip of one participant scrolling past the button, in the channel the engineering team already checks daily, with one line: "6 of 8 participants missed this button, here's one of them; can we move it above the fold this sprint?" That gets a yes or no in the same thread within the hour, versus a report that gets a "thanks, will read" and then silence.

Persuasion and timing

I ship the artifact within 48 hours of the study wrapping, while the team still remembers the context; a technically excellent brief delivered three weeks later competes with five other priorities that arrived since. I also tie every insight to a metric or goal the team already tracks, so accepting the recommendation does not require them to first accept a new way of measuring success.

Measuring whether it worked

I track downstream signal, not just views: how many tickets reference the finding, whether the proposed experiment actually got scheduled, and I ask PMs and engineers directly, on a light cadence, whether the last few artifacts changed anything they did.

Trade-offs and pitfalls

The pitfall is defaulting to whichever format is fastest for me to produce rather than the one that fits the moment; a beautifully produced report nobody has time to read in a crunch week is a wasted afternoon. The other pitfall is over-clipping: five short videos with no synthesis around them just relocate the "who has time to watch all this" problem instead of solving it, so every clip still needs one sentence of context and one ask attached.

Situation & goal
As a UX designer I’d reduce cognitive and implementation complexity while keeping product teams flexible and consistent.

Strategy overview

• Break variant axes: separate concerns into orthogonal axes — visual (color/intent), size, state (loading/disabled), and affordance (icon/label). Limit each axis to 3–4 meaningful options (e.g., primary/secondary/ghost).
• Semantic tokens: introduce tokens like “action-bg”, “danger-text”, “focus-ring” mapped to theme values. Teams use semantic names instead of raw colors so intent is preserved across themes.
• Composition over monolithic variants: offer a small core set of atomic button building blocks (BaseButton, IconSlot, Badge) and composition utilities (props or slots) so designers/devs compose instead of toggling dozens of hard-coded variants.

Migration plan

• Audit: inventory all button instances in product (Figma + code).
• Prioritize: map high‑impact screens first.
• Create guidelines & patterns: Figma components using tokens and composed variants; documentation with examples.
• Phased rollout: provide automatic codemods to replace old variant names, then manual review for ambiguous cases.
• Support: office hours, checklist for QA, measure regressions post-rollout.

Outcome & rationale
This reduces combinatorial explosion, improves accessibility and theming, and empowers product teams to compose intent-driven buttons rather than juggling brittle variant permutations.

Direct answer

First diagnose why the meeting is stalling: usually it's because status-sharing and decision-making are mixed together, and no one is clearly accountable for closing a decision when people disagree. The fix separates the two (status moves async, meeting time is reserved for decisions), names a decision owner per topic, and tracks decisions in writing so they don't get relitigated the next week.

How to redesign it

Step 1: diagnose before redesigning. Ask whether people are status-updating instead of deciding, whether it's unclear whose call something is, or whether decisions do get made but aren't tracked so they resurface. Each cause has a different fix.

Step 2: separate status from decisions.

Step 3: track decisions so they don't restall. Keep a lightweight decision log: what was decided, who owns it, and the date. If an item can't close live, name a follow-up owner and a deadline instead of letting it silently carry over.

Step 4: reconsider the cadence. If most items now resolve async, a lower-frequency decision meeting paired with a written weekly status may serve the group better than a fixed weekly sync for everything.

Worked example

Situation: a cross-functional project with design, engineering, and data has a standing 60-minute weekly sync. Status updates take up 45 minutes, decisions surface in the last 15, and things 'decided' in the room get revisited the following week.
Action: introduced a pre-read posted 24 hours ahead covering status and any open decisions that need a live call; restructured the meeting to skip status entirely and spend the full time on flagged decisions, each with a named owner; started a shared decision log so a closed decision has a record to point back to.
Result: the meeting shortened from 60 to 30 minutes because status moved out of the room, and decisions stopped resurfacing because there was now a written record of what was actually agreed and by whom.

Trade-offs and pitfalls

• Cutting the meeting without giving people another outlet just moves the stalling into chat threads. Live time is still needed for genuine disagreement, don't eliminate it entirely.
• Naming a decision owner can feel like taking authority away from the group. Frame it as who is accountable if the call turns out wrong, not as a power grab.
• Async pre-reads fail without a light enforcement habit. If nobody protects the norm, it quietly reverts to status-in-the-room within a few weeks.
• Adding a decision log and a template is itself process. If it isn't paired with removing something (like the status round-robin), it just adds overhead on top of the original problem.

Overview / Goal
I would persuade leadership to invest in accessibility remediation by combining targeted stakeholder engagement, paired quantitative + qualitative evidence, a cost/benefit framing tied to business metrics, and a 6–8 week pilot to demonstrate impact quickly.

Step-by-step strategy

1. Stakeholder map (who to engage)

   • Product VP, PMs owning affected features, Engineering lead, QA, Legal/Compliance, Customer Support, Sales, and one executive sponsor (e.g., Head of Product).
   • Bring in users with disabilities and accessibility champion(s) from engineering/design.

2. Collect evidence

   • Quantitative: analytics showing 10% affected cohort (drop-offs, conversion gaps, task completion rates), accessibility audit scores (WCAG failure counts), customer support tickets related to accessibility, potential revenue at risk.
   • Qualitative: 5–8 moderated usability sessions with users who have disabilities, annotated recordings, verbatim quotes, and one emotional journey map showing pain points.

3. Frame costs and benefits

   • Costs: scoped engineering hours, QA, design resources, and potential temporary sprint re-prioritization. Provide a three-tier estimate (quick fixes, medium effort, major refactor).
   • Benefits: increased conversions, reduced support costs, legal risk mitigation, improved NPS/retention, positive brand value. Model ROI with conservative lift assumptions (e.g., 5% of lost conversions recovered → revenue delta).

4. Messaging to leadership

   • Start with business impact (revenue, conversion, legal risk), then human stories (short user video clip + quote), then a clear asks (budget, timeline, sponsor).
   • Offer phased approach to limit risk.

5. Pilot plan (6–8 weeks)

   • Week 0: Align goals, KPIs (e.g., +task completion, -support tickets), and target pages/components.
   • Weeks 1–2: Run focused automated + manual audit; recruit 5 users for baseline usability tests.
   • Weeks 3–5: Implement prioritized quick wins (ARIA fixes, labels, color contrast, keyboard navigation).
   • Week 6: Re-test with users, measure KPIs, present results and ROI projection.

Success metrics

• Task completion lift, reduction in abandonment, fewer accessibility-related tickets, NPS changes, and time-to-resolution for fixes.

Why this works

• Combines leadership’s data-driven preference with emotional, human evidence; low-risk pilot demonstrates measurable impact and builds momentum for broader investment.