Microsoft Product Designer (Mid-Level) Interview Preparation Guide

Overview / Goal
I document decisions so anyone (engineer, PM, future designer) can quickly see the problem, options considered, why a choice was made, trade-offs, and next steps.

Primary artifacts

• Decision log (single source of truth): short entries with date, owner, context, options, chosen solution, trade-offs, links to artifacts.
• Design RFC / Proposal (Confluence or Notion): problem statement, goals, user research summary, success metrics, wireframes, prototype links, rollout plan.
• Specification sheet (Figma + handoff page): annotated screens, interaction notes, component props, accessibility requirements, edge cases, acceptance criteria.
• Component documentation (Design System): token values, API contract, usage examples, do/don’t, responsive behavior.

Templates & annotations

• RFC template: Context, Metrics, Alternatives, Decision, Migration plan.
• Figma annotations: numbered comment pins tied to spec checklist; prototype with flows labeled by ticket ID.
• Code comments & storybook links embedded in spec.

Keeping docs current

• Owner per doc and release: owners update decision log during PR or design review.
• Versioning: use Figma file versions + “Release vX” page; tag Confluence pages with release and add changelog summary.
• Process: require documentation update as part of Definition of Done; link docs in JIRA tasks; quarterly docs audit to retire obsolete entries.

Example: For a recent search redesign, I wrote an RFC listing three ranking approaches, annotated A/B trade-offs, linked research, and added the chosen approach to the component page. Engineers referenced the props table and QA used the acceptance criteria—reducing rework by 40%.

Situation: I was redesigning a sign-up flow for a consumer app, and my first concept put the main CTA front and center because I assumed speed was the biggest need.

Task: Usability testing showed the opposite. People were not hesitating because the button was hard to find. They were hesitating because they did not understand the options well enough to trust the choice.

Action: I reviewed the test notes, watched the sessions again, and pulled out three repeated moments of confusion. Then I changed the design to add short plain-language comparisons, clearer helper text, and a save-and-return path. A few teammates still preferred my original version, so I did not argue from opinion. I showed clips from the tests, explained the user goal in simple terms, and framed the change as reducing risk rather than just changing visuals.

Result: We launched the revised flow, and support feedback dropped around the confusing choice point. The biggest lesson for me was that research is valuable when it changes my mind, not when it confirms it.

Direct answer. The rule "use native semantics first, ARIA only when necessary" means you should reach for a built-in HTML element before recreating its behavior with ARIA attributes on a generic container, because native elements give you keyboard support, focus management, and correct accessible-name computation automatically. ARIA is a layer you add on top of HTML, and it can only describe semantics, it can never grant real keyboard behavior on its own.

Three examples where native elements should be used instead of ARIA.

1. A clickable action: use <button>, not <div role="button" tabindex="0"> plus manual Enter/Space handlers. The native element gives you both key bindings, focus, and disabled-state handling for free.
2. Navigation to another URL: use <a href>, not a <div role="link">. Native anchors support middle-click-to-open-in-new-tab, right-click context menu, and :visited styling, none of which ARIA can replicate.
3. A form field: use <input>, <select>, or <textarea> with a real <label>, not a styled <div> with role="textbox" and manual contenteditable handling, which requires reimplementing text-selection, IME composition (the multi-keystroke input method used to type languages like Chinese, Japanese, or Korean), and undo/redo behavior that the browser already provides, a reimplementation burden that mainly matters to the engineer building the field, not something a designer needs to personally verify.

One example where a custom widget genuinely needs ARIA. A tabbed interface (role="tablist", role="tab", role="tabpanel") has no native HTML equivalent; you build it from <div> or <button> elements and ARIA roles/states because the interaction model (arrow-key navigation between tabs, aria-selected state, one tabpanel visible at a time) is a defined interaction pattern the platform doesn't provide out of the box.

Common ARIA misuse anti-patterns.

• Adding role="button" to a <div> without also adding tabindex="0" and manual keydown handling: the element gets a button role announced by a screen reader but remains completely unreachable by keyboard, which is often worse than doing nothing because it advertises an affordance that doesn't work.
• Redundant roles on elements that already have the right implicit role, like <button role="button">: usually harmless but a signal the author doesn't understand what's already provided, and in older browser/AT combinations redundant roles have occasionally suppressed the correct native behavior. One notable exception: <ul role="list"> (and <ol role="list">) is a deliberate, justified redundancy, not a mistake, because Safari and VoiceOver drop a list's implicit list/listitem roles once list-style: none is applied, so re-declaring role="list" restores semantics CSS silently removed.
• Using aria-label to override visible text with different wording (e.g. a button visibly labeled "Learn more" but aria-label="Learn more about our pricing plans"): this breaks voice-control users who say the visible label to activate it, since the accessible name no longer matches what they read on screen.

Trade-offs and pitfalls. ARIA can lie: setting aria-expanded="true" on a collapsed panel, or role="button" on an element with no click or keydown handler, makes an assistive-technology user believe something is true that the DOM doesn't back up. The WAI-ARIA specification itself states the first rule of ARIA is "don't use ARIA if you don't have to."

Pros / Cons (high-level)

• Pros

  • Single source of truth: interactive behaviors, states, and motion live where designers demo (e.g., a Figma prototype with interactive components).
  • Reduces ambiguity: developers can inspect micro-interactions and timing instead of inferring them from static specs.
  • Faster onboarding: cross-team stakeholders can play with patterns instead of reading long docs.

• Cons

  • Fragility: prototypes can drift from the production implementation or from the design tokens (the named values, like a specific color or spacing amount, that both design and code are supposed to share).
  • Discoverability and scalability: a large prototype can become cluttered, making the canonical (officially correct) pattern hard to find.
  • Governance overhead: without rules, multiple conflicting prototypes appear.

Guardrails I would implement (practical, role-specific)

• Ownership and canonization: designate a pattern owner (a designer plus a front-end engineer) for each component; only that owner can mark a prototype state "canonical," meaning the one true, current version.
• Versioning and release cadence: tie prototype releases to design-system version numbers and announce changes in release notes, the same way a piece of software would.
• Minimal, focused examples: one canonical setup per pattern, with variants swapped in via configurable options, to avoid duplicate demos of the same thing.
• Documentation surface: each prototype frame includes metadata: version, last-reviewed date, owner, and usage guidelines (tokens, do's and don'ts).
• Review process: require both a design and a dev review for any change that updates an interaction or a token.

Automation to keep it reliable (each item explained in plain terms)

• Token sync: automate moving design tokens from Figma into the code repo (e.g., the Figma Tokens plugin exporting into a tokens repo), with CI checks, meaning automated checks that run every time someone updates the prototype or code, that fail loudly if the two sides fall out of sync.
• Visual regression tests: publish the interactive components to Storybook (a tool that catalogs a design system's components so they can be viewed and tested in isolation), and run automated screenshot comparisons via a service like Percy or Chromatic, which screenshots the prototype after every change and flags anything that visually changed, so a designer can eyeball exactly what shifted.
• Linting and CI: pre-merge checks (automated checks that must pass before a change is allowed in) that validate the prototype's metadata, verify the canonical flag is set correctly, and confirm a linked Storybook entry actually exists.
• Smoke tests: automated Playwright tests, meaning a script that opens the prototype in a real browser and clicks through the canonical interactions after every deploy, to catch anything broken.
• Alerts and stale detection: a cron job (a task that automatically runs on a fixed schedule, like every night) that flags any prototype frame not reviewed within N months, and automatically creates a task in the design backlog.
• Demo and changelog automation: automatically generate release notes from pull-request titles and labels, and send them to Slack.

Why this works

These guardrails balance fidelity and maintainability: the prototype stays useful for designers and engineers because it is versioned, reviewed, and continuously validated against the real code. Automation minimizes manual drift and surfaces stale content for someone to fix, keeping the prototype a trustworthy living document rather than a set of screenshots nobody trusts.

Direct answer

Keep a single, easy-to-find decision log tied directly to the work it affects: what was decided, the options considered, the reasoning, and who owns it, updated by whoever is making the decision at the moment it is made, not reconstructed later from memory.

Structured elaboration

What belongs in an entry

A short, consistent structure works better than a long one, because people will actually fill it out: a title, the date, who owns it, the context in one or two sentences, the options considered with their trade-offs, the decision itself, and the reasoning behind it in a few bullet points.

Where it lives

The log needs to be one discoverable place, linked from the tickets, docs, or roadmap items it affects, not scattered across meeting notes and chat threads. A shared doc or wiki page with a simple table works; the tool matters less than the discipline of always linking to it.

Who keeps it current

The person who owns the decision, not a rotating scribe with no stake in it, writes or finalizes the entry, ideally right after the decision is made, while the reasoning is still fresh and easy to state accurately.

How it gets used afterward

In retrospectives, revisit decisions that affected the outcome and check whether the original assumptions held. For onboarding, a short list of the most consequential recent decisions gives a new team member the context that would otherwise take weeks of osmosis to pick up.

Worked example

A team is deciding between two ways to notify users of an event: a push notification versus an in-app banner. The entry, once decided, looks like this: title, "Notification channel for event alerts"; date and owner, the decision owner's name and the date; context, users were missing time-sensitive alerts under the current in-app-only approach; options considered, push notification (faster delivery, requires a new permission prompt), in-app banner only (no new permission needed, slower to be seen), and both channels (best coverage, more engineering and support surface); decision, push notification with an in-app banner as a fallback for users who decline the permission; reasoning, the delay in the in-app-only approach was the specific problem being solved, and the fallback covers users who opt out.

Anyone who later asks why the team does not just use an in-app banner, since it is simpler, can read this entry and see the trade-off was already considered, rather than re-litigating it from scratch.

Trade-offs and pitfalls

A log nobody updates is worse than no log: it creates false confidence that the reasoning is captured somewhere, while actually going stale. The fix is keeping entries short enough that updating one takes minutes, rather than requiring a formal write-up every time.

A log can also be used as a weapon later, such as insisting a past decision still holds in a situation where circumstances genuinely changed and revisiting was the right call. The log should record reasoning, not lock in a decision forever; a review date or a note on when to re-evaluate keeps it a living reference instead of a trap.

Direct answer

I treat a critique session like any other high-stakes conversation: I prepare the ground before it happens, manage myself while it's happening, and treat the meeting as incomplete until the feedback actually changes something afterward. Mentally, the biggest shift is deciding ahead of time that the work is not the same thing as my competence, so criticism of the work doesn't have to feel like criticism of me.

Structured elaboration

Before, logistically. Share the work ahead of time when possible so reviewers arrive having actually looked at it rather than reacting cold. Decide in advance what you specifically want feedback on (a whole redesign invites scattered opinions; "does this checkout flow reduce the confusion we saw in testing" invites focused ones), and be ready to give just enough context that people aren't guessing at constraints you already ruled out.

Before, mentally. Remind yourself the goal of the session is to find problems while they're still cheap to fix, not to get a passing grade. If you expect a specific person to be tough, decide in advance how you'll respond to their first hard comment so you're not improvising your composure in the moment.

During. Listen to finish a full thought before responding, and default to a clarifying question rather than an explanation when a comment feels unfair or off-base; often what sounds like "this is wrong" is actually "I don't understand why you chose this," and those need very different responses. Write things down even when you disagree, so you're not relying on memory (or on your own filtered version of what was said) later.

After. Feedback that isn't tracked tends to quietly evaporate. Group what you heard into what you'll act on now, what needs more discussion first, and what you're consciously not acting on and why, then close the loop with whoever raised it so they see the input actually went somewhere rather than into a void.

Worked example

Preparing to present a checkout redesign to stakeholders, I send the prototype and a short note the day before explaining what changed and specifically asking whether the new confirmation step reduces the confusion we saw in earlier testing, rather than asking "what do you think" broadly. Going in, I've decided that if the most vocal stakeholder pushes back hard on the visual direction (which has happened before), I'll ask what specifically feels off before defending any choice. During the session, when someone says the flow "feels clunky," I ask which step specifically felt clunky rather than explaining my reasoning for the whole flow. Afterward, I write up what changes I'm making immediately (the confirmation step), what needs more discussion (the visual direction, since the feedback was vague), and what I'm not changing and why (the number of steps, which testing had already validated), then send that back to the group so they know their input landed somewhere concrete.

Trade-offs and pitfalls

Over-preparing can backfire: arriving with the work so polished and the framing so tight that it discourages real critique, or defensively pre-answering objections before anyone raises them. Taking notes on everything without triaging afterward just produces a long list that never turns into action, which is functionally the same as not listening at all. And closing the loop only with the loudest voice in the room, while quieter but valid feedback from someone else gets dropped, teaches people that only forceful feedback gets acted on.

Approach summary

I design for RTL (right-to-left) languages and for text that grows when translated by treating direction and flexible sizing as first-class rules in the design system, not exceptions handled at the end. Concretely that means: mirror layout using direction-aware CSS instead of hard-coded left/right values, reserve extra space for languages that translate longer than English, and define different truncation rules for mobile versus desktop.

Layout & alignment

Use logical CSS properties (margin-inline-start/end instead of margin-left/right, text-align: start/end instead of left/right) so the whole layout flips automatically when the page's dir attribute is set to "rtl," instead of needing a second, hand-maintained set of RTL-specific styles. Build components on flex or grid so the reading direction can reverse the row order, rather than positioning elements at fixed pixel offsets. Keep spacing on a token scale (small, medium, large, defined once) so hit areas and gutters can grow without a designer re-measuring every screen.

Icons & imagery

Flip only icons whose meaning depends on direction, like a "back" arrow or a forward chevron; an icon like a play button or a checkmark should stay exactly as it is. Mirror direction-dependent icons with a CSS transform (scaleX(-1)), and keep a deliberately mirrored version of any illustration that has text baked into the image itself, since text inside an image doesn't flip automatically the way a CSS layout does.

Typography & spacing: why translated text needs a buffer

Translated UI text is very often longer than the English original, and how much longer depends on the language. As a concrete example: the English word "Settings" is 8 characters. Its German translation, "Einstellungen," is 13 characters, about 60% longer. A button or label sized to fit "Settings" exactly will clip or wrap awkwardly once translated.

As a widely used rule of thumb for planning space (not exact for every string, since shorter strings tend to expand more than longer ones), European languages commonly seen in software localization expand English UI text by roughly this much: German by around 30%, Russian by around 20%, and French by around 15%. Build in the biggest buffer for short labels and button text, since that's where expansion hurts most, not for paragraphs.

The practical response: don't set fixed-width buttons. Let a button grow to fit its label, or allow the label to wrap onto a second line, rather than clip or overflow.

Truncation and differential behavior

• Mobile: favor readability over density. Let long labels wrap onto a second line, use multi-line buttons, and put less-critical detail behind a tap (a modal or an expanded view) rather than cramming it into one line.
• Desktop: truncating with an ellipsis is more acceptable in compact lists because there's more room elsewhere on the page, but pair every truncated label with a hover tooltip or an accessible full-text alternative so no information is silently lost. For dense tables, let a row expand in place on click instead of truncating permanently.
• Never truncate the verb in a critical action, like the label on a "Delete" or "Submit" button. If a button needs to shrink, shrink something else on the screen first.

Responsive patterns

Define the width at which a layout switches from one line to a stacked layout. Where the same component can appear at different widths on the same page, for example a card in a narrow sidebar versus the same card in the main content column, use container queries (rules based on the size of the component's own box, not the whole screen) instead of a single global breakpoint, so the component adapts correctly wherever it's placed.

Validation & testing at scale

• Pseudo-locales: a fake locale used in design and QA reviews that accents every character and adds bidi markers and extra length to strings. "Bidi" is short for bidirectional text, meaning right-to-left and left-to-right text mixed on the same line, which happens whenever, for example, an English brand name sits inside an Arabic sentence. Pseudo-locales surface mirroring and overflow bugs before a single real translation exists.
• Automated visual comparisons: a check that takes a screenshot of each component before and after a change and flags anything that visually shifted, run across a matrix of locales and screen widths, including RTL screenshots, so a translation-triggered layout break gets caught in a pull request rather than after release.
• Automated interaction tests that explicitly set dir="rtl" and verify that alignment, focus order (the order the Tab key moves through elements), and keyboard navigation still work correctly in a mirrored layout.
• Track two ongoing numbers release over release: the percentage of components passing the visual comparison check, and the number of localization bugs reported, so the process measurably improves rather than just feeling better.
• For a final human check, batch up real translated screenshots for translators and native speakers to review in context, not just as a raw text list, watching specifically for mirrored icons pointing the wrong way, punctuation in the wrong place, and toolbar order.

Example

A primary action button uses flexible sizing rather than a fixed width, so it can grow to fit "Settings" in English or "Einstellungen" in German without clipping. Its icon only flips if it's a directional icon, like an arrow; a checkmark icon on the same button stays fixed.

This keeps the design resilient and testable across RTL and long-string locales, and across mobile and desktop, without needing a separate design per language.

Approach summary
I’d build a single source-of-truth icon system in our design system that serves desktop and mobile by defining clear style rules, tokens, components, and a governance process so icons are visually consistent and developer-friendly.

Style guidelines

• Choose one primary style family and complementary variants:
  • Primary: 2px stroke outlined icons with 16px optical stroke weight for body UI.
  • Alternate: Filled icons only for high-emphasis actions (e.g., primary CTA) and small-system use where readability suffers.
• Rules: never mix filled + outlined for the same semantic purpose; use rounded or sharp corner radius consistently (e.g., 2px radius).
• Accessibility: ensure contrast and clear semantics; use simpler shapes for small sizes.

Sizing & spacing

• Base grid: 24px canvas standard (also export 16/20/24/32 variants).
• Icon sizes: mobile primary 20px, desktop primary 24px, touch targets remain 44–48px.
• Internal padding: center icons in the canvas with 2–4px visual padding; align key visual strokes to 0.5px grid for raster parity.
• Spacing tokens: icon-spacing-xs/s/m tied to spacing system (e.g., gap-xxs = 4px).

Naming conventions

• Namespace + semantic name + variant: icon.system-name_action_variant
  • Examples: icon.ui_search_outline, icon.action_delete_filled, icon.alert_warning_outline
• Use semantic names (search, close, settings) not visual metaphors.

File delivery formats

• Primary source: optimized SVGs (cleaned, no inline styles, viewBox fit to canvas).
• Exports: SVG sprite, individual SVGs, PNGs at 1x/2x/3x, and React/Vue icon components (auto-generated).
• Package: Figma components (master icons with variants) + NPM icon package with tree-shaking.
• Include metadata (name, usage, accessible label, size variants) in a JSON manifest.

Add / Retire process

• Contribution PR template: designer provides Figma component, SVG, usage rationale, accessibility notes, and examples.
• Review board: design system maintainer + frontend engineer review for semantics, overlap, and performance.
• Versioning & changelog: accepted icons added to kit; deprecated icons flagged in docs, recommended replacements provided, and removed from codebase after one release cycle with migration notes.
• Automation: CI validates SVG optimization, naming, and manifest inclusion.

Outcome
This ensures consistent visual language across platforms, predictable developer integration, and a lightweight governance loop that keeps the icon set lean and usable.

Situation
At my last company I owned the onboarding flow for a B2C productivity app. Analytics showed a 42% drop-off during the account-setup step and NPS from new users was below target.

Task
Improve completion rate and first-week retention by redesigning the onboarding to reduce friction and increase perceived value.

Action

• Ran mixed research: quantitative funnel analysis (n = 18,000 sign-ups) to pinpoint the exact step, then 5 moderated usability tests and 7 remote unmoderated sessions (total 12 participants) to observe pain points and language confusion.
• Findings: users hesitated at a multi-field "preferences" screen; unclear benefit for each field; perceived time cost.
• I sketched three alternatives: (A) keep current but add microcopy, (B) progressive disclosure (collapse optional fields), (C) split onboarding into two micro-steps with value-first preview.
• Prototyped B and C in Figma and ran a 2-week A/B test (control vs C) with 10,200 visitors.
• Collaborated with PM and engineering to implement C with analytics tracking and an optional skip.

Result

• Completion rate up 18% (from 58% to 76%) for the tested cohort.
• Time-to-complete onboarding decreased 35%.
• One-week retention improved 9%, and qualitative feedback in follow-ups showed higher clarity and less perceived effort.

Learned to combine funnel metrics with small-sample usability to design targeted, measurable changes.

Direct answer
When a mentee gets defensive and stops acting on feedback, the fastest way to make it worse is to double down with more direct feedback. Slow down, diagnose why the message isn't landing (the content, the delivery, or something the mentee brings into the room), then rebuild the conversation as a two-way one instead of a one-way correction. If the pattern doesn't shift after a genuine attempt at that, it needs to be named and escalated, not quietly tolerated.

Diagnose before you re-deliver

• Separate "defensive because of how I said it" from "defensive because of what's underneath it." Workload, unclear expectations, a confidence hit, or feedback that reads as a character judgment rather than a specific behavior all produce the same surface symptom (pushback, non-action) for different reasons.
• Ask, don't assume: open with a genuinely curious question rather than a repeat of the critique. "Walk me through how that landed for you" gets you information; "you need to stop being defensive" gets you more defensiveness.

Use motivational interviewing instead of more direct pressure

• Motivational interviewing is built for exactly this: someone who may intellectually agree but is resisting behaviorally. Instead of arguing for the change, reflect their own stated goals back to them and let them articulate the gap ("You mentioned you want to lead the next project. How does this pattern affect that?"). People act on reasons they generate themselves far more than reasons handed to them.
• Keep the ratio of affirmation to correction visible. If every interaction is corrective, the mentee starts hearing footsteps before you speak, which is what produces reflexive defensiveness.

Rebuild the mechanism, not just the next conversation

• Shrink the ask: instead of a broad critique, propose one small, concrete, reversible change and a short check-in window.
• Make feedback bidirectional: ask what kind of feedback has landed well for them before, and adjust format (written vs. verbal, immediate vs. batched) accordingly.

Know when coaching has run its course

• If, after two or three honest attempts using the above, the pattern is unchanged (commitments still not acted on, same defensiveness), that's a signal the issue may be outside what coaching alone fixes: a skill gap being misread as attitude, a values or fit mismatch, or a factor you're not positioned to see.
• At that point, loop in the mentee's manager, or HR if the dynamic has become adversarial, rather than continuing to privately absorb it. Frame it factually: what you tried, what changed, what didn't. This isn't giving up on the mentee; it's recognizing some situations need authority or context you don't have.

Worked example
A mentee kept missing agreed follow-ups on code review comments and would get visibly short in Slack whenever it came up. The instinct was to restate the same feedback more firmly. Instead, the better move: open the next 1:1 with "I want to understand how the review feedback has been landing for you, not go through it again," and listen first. It turned out the mentee had inherited a legacy module nobody had explained well, and every review comment felt like it was pointing out someone else's mess. The fix wasn't more feedback, it was pairing on the module once and shrinking the ask to one file at a time. If that hadn't worked, the next honest step would have been raising the pattern with the mentee's manager, not repeating the same conversation a fourth time.

Trade-offs and pitfalls

• The junior mistake is treating defensiveness as a discipline problem and pushing harder; that reliably produces more resistance, not less.
• Over-correcting the other way (going silent on real issues to avoid triggering defensiveness) just delays the same conversation and lets performance drift.
• Escalating too early, before you've tried adjusting your own approach, reads as offloading a coaching problem; escalating too late lets a stalled dynamic damage trust or delivery. The senior move is trying a genuine adaptation first, timeboxing it, and being honest about whether it moved anything.