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

For something this small, fidelity should track risk, not polish. The visual design barely matters and can stay low-fidelity, but the state and timing behavior is the actual product, so that part needs to feel real, real typing, real delays, real error states, before tooling gets decided.

Structured elaboration

Start from the state machine, not the screen

Before opening a design tool, sketch the states the field can be in and what moves it between them: idle, editing, saving, saved, error, and a cancel path back out of editing. Naming these up front surfaces edge cases early (what happens if the user starts a second edit while the first is still saving, what does cancel revert to) and gives engineering a shared vocabulary before any pixels exist.

stateDiagram-v2
    [*] --> Idle
    Idle --> Editing: click field
    Editing --> Validating: blur or debounce
    Validating --> Saving: valid input
    Validating --> Error: invalid input
    Error --> Editing: user corrects
    Saving --> Saved: server ack
    Saving --> Error: request fails
    Saved --> Idle: after confirm
    Editing --> Idle: cancel or escape
    Error --> Idle: discard

In the diagram, "debounce" means waiting for a short pause after the user stops typing before triggering validation, instead of reacting to every keystroke or waiting only for the field to lose focus (blur).

Decide fidelity per concern, not for the whole prototype

• Visual: static mockups of each state are enough; there's no real ambiguity to resolve visually.
• Timing and motion: needs an interactive prototype with real transition delays, since timing is exactly what's being validated and can't be judged from a static frame.
• Copy and error states: needs real, specific validation and error text, since testing whether people understand why something failed requires the actual words, not placeholder copy.
• Tooling follows from that split: an interactive click-through prototype covers the timing and flow without needing real code or a live backend. The saving delay and error branch can be faked with a timer and a toggle.

Worked example

Build three linked frames per state, wire idle to editing on click, editing to a fake-saving state with a short, perceptible delay (long enough to notice, short enough to feel like autosave rather than a manual save action), and a branch to error with realistic copy such as "Couldn't save, check your connection" rather than a generic error label. Test with 5-6 participants doing a task that requires editing the field at least twice: once with the fake network slowed, once with an invalid value entered. Watch for whether they notice the save happened without hunting for confirmation, whether they trust it enough to navigate away mid-save, and whether, on error, they understand if their edit was lost or just not saved yet.

Trade-offs and pitfalls

• Skipping the state sketch and going straight to a polished mockup is the classic mistake at this scale: it produces a good-looking artifact that quietly omits the cancel-during-save or double-edit case, which only surfaces during build.
• Over-investing in visual fidelity for a component this small wastes the resource that's actually scarce: time to test the timing and error behavior against real users.
• Testing this component in isolation is faster, but a field embedded in a longer real task is what a shipped autosave interaction has to survive: interruptions, navigation, multitasking. Isolated testing is fine for a directional read; if the risk is high, test it inside the real flow it lives in.

Plan summary
I’d run a moderated prototype test with 8–12 participants in two 60-minute sessions (discovery & booking), scheduled on separate days rather than back to back, focused on revealing decision points while keeping cognitive load low. Two hours of conditional-pricing decisions in one sitting produces fatigue effects that are easy to misread as comprehension problems, which is the specific way this study can quietly generate wrong findings.

Fidelity choices

• Start mid-fidelity (clickable Figma) for overall flow and branching logic to test decisions without visual noise.
• High-fidelity screens only for key decision screens (pricing breakdown, add-ons, confirmation) to capture trust cues and comprehension.
• Use a lightweight backend mock (JSON scenarios) so interactions feel real but remain editable.

Branching strategy

• Map core decision tree and collapse low-impact branches; expose 2–3 realistic pathways per participant, one per scenario task, and cap it there: each additional branch is a full set of pricing and availability decision screens, and past about three the later branches mostly measure tiredness rather than comprehension.
• Use scenario-based routing: give each participant 2–3 personas/tasks that steer them into different branches (e.g., corporate vs. leisure, flexible vs. strict dates).
• If a participant reaches an uncommon branch, interviewer uses a scripted probe to simulate system responses rather than forcing every branch live.

Seeding realistic data

• Create 12 scenario templates with realistic inventory, blackout dates, tiered pricing rules, promos, and capacity limits.
• Vary variables systematically (price sensitivity, availability windows, promo eligibility) and attach persona motivations to each.
• Load data into the mock backend and show inline explanations (e.g., “Promo applies because…”) only when participants ask.

Metrics & signals

• Quantitative: task completion rate per branch, time to decide at each decision screen, drop-off points.
• Qualitative: think-aloud transcripts, reasons for choices, confusion moments, trust indicators.
• Behavioral micro-metrics: number of times users expand pricing details, frequency of switching options, use of date flexibility.
• Success criteria: >80% complete booking on primary paths, decision time under target (e.g., 90s) on pricing screen, reduced confusion comments versus baseline.

Post-test

• Synthesize decision points, prioritize pain points by frequency and business impact, and iterate mid-fidelity before full visual polish.

Direct answer

For a team this size the file structure should map to ownership, not to project chronology: one design-system file that is the single source of truth for shared components, one project (a project is a folder-like container grouping related files) per active product initiative holding that initiative's editable working file, one standing prototypes project holding a prototype file per product area, and one standing research project for artifacts that inform design but are never themselves shipped.

Structured elaboration

Four file buckets, kept deliberately separate:

1. Design system file. One file, published as a shared team library so other files consume components by reference instead of copy-paste. This keeps the file small and fast and means an update to a component propagates everywhere it's used.
2. Product/feature files. One file per active initiative, owned by the designer driving it, living in that initiative's own project. Components inside are local instances pulled from the library, never duplicated originals.
3. Prototype files. Prototypes with heavy interaction wiring live in their own file, one per product area, and those files sit together in a single standing "Prototypes" project rather than inside each product's project. Two reasons for that placement, and they're the reasons this bucket exists at all: a prototype with many linked frames slows the file down for everyone editing it, and testing artifacts churn faster than production designs and need looser edit access than a product project's own permission policy should allow.
4. Research artifacts. Kept in their own standing "Research" project, never mixed into a component file, since they're synthesis material, not production UI, and they need the same loose edit access as prototypes for the same reason.

Naming pattern: apply project, then file, then page naming.

• Projects: one per product area, named "[Product area]", e.g. "Checkout", "Onboarding Flow", plus three standing projects that are not product areas: "Design System", "Prototypes", "Research".
• File: "[Area] - Product" (the working file, in that area's project), "[Area] - Prototypes" (in the Prototypes project), "[Area] - Research" (in the Research project).
• Pages: every page in every file carries a two-digit numeric prefix, so the sort order stays meaningful as pages are added, and "00 Cover" is page one of every file without exception. A product file's pages are "00 Cover", "01 In progress", "02 Ready for dev", "03 Archive". A file with genuinely different content, the design-system file, say, keeps the same prefix rule with names that fit what it holds. What has to hold everywhere is the prefix and the ordering, not one fixed list of page names for every file.

Permissions:

• Design-system file: edit access limited to the one or two people who own it; everyone else has view/library-consumer access only, preventing accidental edits to shared components.
• Product projects: the owning designer and design lead get edit access; product managers get comment access, so they can leave feedback without moving frames or breaking a layout structure.
• Prototypes and Research projects: broader edit access, since anyone running a test or workshop needs to add notes or frames. This is the concrete payoff of giving those two buckets their own projects instead of scattering their files inside product projects: access is granted per project, so one setting covers every area's prototype file, rather than maintaining a hand-made permission exception inside every product project.

Onboarding benefits from this directly: a fixed project structure and page-naming convention means a new hire's first stop, the design-system file's "00 Cover" page, tells them where everything else lives without a message thread explaining it.

Worked example

A workspace holds projects "Design System", "Checkout", "Onboarding Flow", "Prototypes", and "Research". The Design System file has pages "00 Cover", "01 Foundations", "02 Components", "03 Icons", "04 Changelog", is published as a library, and only the system owner and design lead can edit it. The Checkout project holds one file, "Checkout - Product", with pages "00 Cover", "01 In progress", "02 Ready for dev", "03 Archive", owned by the checkout designer, with the PM on comment access. The heavily-wired 40-frame clickable prototype for an upcoming usability test is not in that project: it lives as "Checkout - Prototypes" in the Prototypes project, kept out of the roughly 200-frame production file so it doesn't slow that file down for the rest of the team, and editable by anyone running the test without touching the Checkout project's permissions. Research findings live as "Checkout - Research" in the Research project, linked from the product file's cover page rather than pasted directly in. The library-performance payoff shows up concretely here: because Checkout's product file only holds instances of the shared Button and Card components rather than duplicated originals, the file stays lean even as the flow grows, and a later corner-radius change to Button in the system file updates every instance across every product file automatically.

Trade-offs and pitfalls

Splitting into too many small files creates its own navigation cost; the four-bucket split above is deliberately coarse, not one file per screen. If the library owner becomes a bottleneck, updates stall, so a documented request-and-review process matters more than restricting edit access ever more tightly. Comment-only access can frustrate a PM who genuinely wants to reorganize a flow, so set that expectation up front rather than loosening the permission the first time it's inconvenient. The most common failure mode is mixing exploratory and shippable work on the same page, letting "In progress" bleed into "Ready for dev", which defeats the whole scheme; that discipline has to be enforced by habit and review, not by the folder structure alone. The second most common failure mode is applying the page convention to product files but quietly skipping it in the design-system file, which is the one file every new hire opens first, so a convention that lapses exactly there fails at the moment it was supposed to pay off.

Direct answer
When feedback on your design gets challenged, the strongest response is to separate synthesis from ego: understand exactly what is being challenged, gather just enough evidence to know if the concern is real, iterate with options rather than a single fix, and then explain the trade-off you chose. Caving immediately or defending the original design without checking are both weaker moves than treating the pushback as a hypothesis to test.

Structured elaboration

A repeatable approach to critical feedback

1. Listen and categorize: is this a usability concern, a technical or feasibility risk, or a business-metric worry? Each needs different evidence to resolve.
2. Validate quickly: a short prototype test with a handful of users, or a look at existing analytics, tells you whether the concern is real before you redesign anything.
3. Iterate with alternatives, not one fix: present two or three concrete options so stakeholders are choosing between trade-offs, not approving or rejecting your ego.
4. Communicate the decision with the reasoning visible: what you tested, what you found, and why you picked this option, so the choice can be challenged on its merits later.

Junior versus senior reaction
A junior reaction is to revise the design immediately to make the feedback go away without first checking whether the concern is supported by evidence, or to get defensive and argue for the original choice. A senior reaction treats the feedback as a hypothesis: validate it cheaply, bring back a measurable comparison, and let the evidence, not who has more authority in the room, settle the disagreement.

Worked example
Situation: I was designing a checkout flow for a subscription product. In review, the product manager and an engineering lead pushed back that the new multi-step flow would raise drop-off risk and delay the launch.
Task: figure out whether the design actually hurt conversion or usability, iterate if it did, and get the team aligned on a final approach.
Action: I split the concern into usability, technical risk, and business impact. I ran a short moderated test with a handful of target users and reviewed the existing flow's analytics. The finding was mixed: users valued the extra step because it clarified pricing and trial terms, but the flow could be tightened. I built two options: a condensed single-page version, and a hybrid two-step version using progressive disclosure (showing only the essential fields first and revealing the rest only if needed). I presented both to the stakeholders with the test notes and a plan to compare them with a short controlled experiment, an A/B test, where different users see different versions and you compare the outcome.
Result: the team agreed to ship the hybrid as a monitored rollout. Comprehension held up in the follow-up check, drop-off did not get worse, and the number of billing-related support questions visibly dropped. The product manager specifically called out that having the trade-off laid out with evidence, rather than just an opinion, made the decision easy to sign off on.

Trade-offs and pitfalls
Validating every piece of feedback with a full study would stall the project, so the skill is choosing a validation method cheap enough to run in a day or two. The opposite failure, complying with every stakeholder objection without checking it, trains stakeholders to override design with opinion instead of evidence. If you genuinely do not have data for part of the story, say that plainly rather than implying a number you do not have; a confident but invented metric is worse than admitting the result was directional.

Situation. Sales wanted single sign-on (SSO, letting a company's employees log in with their corporate identity) for enterprise deals; support wanted a self-serve password and account recovery flow. Both leaders were certain, and I had one team for the quarter.

What I weighed

• Reach: recovery touched most users; SSO touched the few large accounts.
• Revenue: 5 open enterprise deals asked for SSO; recovery drove a large share of support tickets.
• Cost: SSO was roughly twice the effort.
• Confidence: I checked deal notes and ticket data rather than relying on the anecdotes of each leader.

How I decided. I agreed the goal with both before looking at features: "reduce time to revenue and cost to serve". Then I scored both options with a weighted table (each criterion gets a weight for how much it matters, each option a 1 to 5 score per criterion, and the weighted scores are added up), shared it, and let each leader challenge an input.

SSO: 0.45 x 5 + 0.15 x 2 + 0.20 x 2 + 0.20 x 4 = 3.75. Recovery: 0.45 x 2 + 0.15 x 5 + 0.20 x 4 + 0.20 x 4 = 3.25. The support lead challenged the weights: if reach is 25% and revenue 35%, Recovery edges ahead, 3.55 to 3.45. So the decision depended on revenue carrying the most weight, which followed directly from the goal we had both agreed to. I kept the weights and added a stopgap (a cheap temporary measure that relieves the pain until the full fix) to answer her case. The sequence: the stopgap came first, in weeks 1 and 2 (a clearer reset email and a help article), then SSO for the rest of the quarter.

The one who lost. I called the support lead before announcing. I gave her the data, the stopgap, and a firm date for the full flow, and asked her team to review the stopgap.

Result. Two of the five enterprise deals closed on schedule (the other three were still in negotiation at quarter end), ticket volume stayed flat, and the support lead agreed to the next planning round because the criteria were visible.

The same method in other situations. If the disagreement is with a PM about scope, use the same shared criteria; if the tension is AI project deadline vs quality vs cost, say which of the three was fixed and which flexed. Example: the demo date was fixed at 8 weeks and the team was fixed at 4 engineers, so scope flexed: we shipped the model for 3 of 5 document types.

What I would do differently: bring both leaders into the scoring session earlier.

Direct answer

The mismatch has three families of explanation: the test did not measure what we think, the interview signal was misleading, or the redesign worked on something that is not the bottleneck. I would investigate in this order: (1) check the experiment and measurement (a data query, hours), (2) look at step-level funnel data for where the redesign did or did not move behaviour, (3) re-read the interview evidence for opinion versus behaviour. Activation means a new user reaching the first meaningful value action, such as completing a first project.

Structured elaboration

A. The test did not measure the change.

• Users never saw the new flow (an exposure bug: the assignment logic put people in the wrong group, or the rollout, the gradual release to a share of users, reached the wrong audience). The new arm, meaning the group of users assigned the redesigned flow, is the group to check first.
• Activation is defined so the redesign cannot move it, or is measured over too short a window.
• Too few users to detect a small effect (with a small sample, random noise can be as large as the real change, so a real improvement looks flat; a sample-size calculation says how many users are needed).

B. The interview signal was misleading.

• Participants are polite and say they like things (social desirability: people give answers that make them look agreeable).
• Prototype in a guided session is not the real flow, with real data and distractions.
• Recruited participants were more motivated than typical signups.
• Questions led toward praise.

C. The redesign improved something that is not the bottleneck (the step where the most potential activations are lost).

• Drop-off lives in a later step.
• Improvement increased completion but with lower-intent users, so later steps got worse (the effect is masked).

Why this order: A is a broken instrument (the measurement setup: tracking, assignment and the metric definition). If it is broken, B and C are unanswerable. It is also the cheapest. C is next because step-level data is already collected. B comes last because it needs new research, and I would run it only on the part that C narrowed.

Worked example

Illustrative numbers. Of 1,000 signups, 800 finished onboarding (80%) and 25% of finishers started a first project, so 200 activated (20%). After the redesign, 900 finish onboarding (90%), but only about 22% of finishers start a project, so about 198 activate, roughly the same 20%. Overall activation shows nothing, yet step-level data shows the redesign did what interviews praised (more people finish) while pulling in lower-intent users at the next step. The next test is a change to the step after onboarding, not further polish on the flow people already like.

A second case, where the redesign simply hit the wrong step (illustrative): of 1,000 signups, 92% finish onboarding before the redesign and 95% after, but only 20% of finishers start a project at the next step either way. Activation goes from 1,000 x 0.92 x 0.20 = 184 to 1,000 x 0.95 x 0.20 = 190, a gain of 6 users, too small to see in a flat topline. The bottleneck is the 20% step, so that is where the next test goes.

Trade-offs and pitfalls

• Do not call the interviews wrong. Interviews measure comprehension and attitude well and behaviour poorly.
• A flat topline (the single overall number on the experiment dashboard) can hide offsetting movements. Always look at steps.
• Do not rerun interviews first. It feels natural to a researcher, but it is the most expensive way to learn nothing new.
• What would change my order: if the experiment dashboard (the tool showing how many users are in each group and the metric for each) showed fewer users than planned in the new arm, I would stop and fix exposure before anything else.

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.